შესვლა Kubernetes-ში: EFK vs PLG

მონიტორინგი გახდა მზარდი ღრუბლოვანი გადაწყვეტილებების ძალიან მნიშვნელოვანი კომპონენტი, რადგან განაწილებული სისტემების სირთულე იზრდება. აუცილებელია მათი ქცევის გაგება. ჩვენ გვჭირდება მასშტაბირებადი ხელსაწყოები, რომლებსაც შეუძლიათ შეაგროვონ მონაცემები ყველა სერვისიდან - და მიაწოდონ სპეციალისტებს ერთი ინტერფეისი შესრულების ანალიზით, შეცდომების დემონსტრირებით, ხელმისაწვდომობით და ჟურნალებით.

იგივე ინსტრუმენტები უნდა იყოს ეფექტური და პროდუქტიული. ამ სტატიაში ჩვენ გადავხედავთ ორ პოპულარულ ტექნოლოგიურ დასტას: EFK (Elasticsearch) და PLG (Loki) და განვიხილავთ მათ არქიტექტურასა და განსხვავებებს.

EFK სტეკი

შეიძლება უკვე გსმენიათ ძალიან პოპულარული ELK ან EFK-ის შესახებ. დასტა შედგება რამდენიმე განსხვავებული ნაწილისგან: Elasticsearch (ობიექტების შენახვა), Logstash ან FluentD (ლოგის შეგროვება და აგრეგაცია) და Kibana ვიზუალიზაციისთვის.

ტიპიური სამუშაო პროცესი ასე გამოიყურება:

ელასტიური ძებნა - განაწილებული ობიექტების შენახვა ძიებით და რეალურ დროში ანალიტიკით. შესანიშნავი გადაწყვეტა ნახევრად სტრუქტურირებული მონაცემებისთვის, როგორიცაა ჟურნალები. ინფორმაცია ინახება როგორც JSON დოკუმენტები, ინდექსირებულია რეალურ დროში და ნაწილდება კლასტერულ კვანძებში. გამოყენებულია ინვერსიული ინდექსი, რომელიც შეიცავს ყველა უნიკალურ სიტყვას და ასოცირებულ დოკუმენტს სრული ტექსტის საძიებლად, რომელიც თავის მხრივ დაფუძნებულია Apache Lucene საძიებო სისტემაზე.

FluentD არის მონაცემთა შემგროვებელი, რომელიც აერთიანებს მონაცემებს მათი შეგროვებისა და მოხმარებისას. ის მაქსიმალურად ცდილობს მონაცემთა JSON-ში ორგანიზებას. მისი არქიტექტურა გაფართოებულია, უფრო მეტია ასობით სხვადასხვა გაფართოება, საზოგადოების მხარდაჭერით, ყველა შემთხვევისთვის.

კიბანა - მონაცემთა ვიზუალიზაციის ინსტრუმენტი Elasticsearch-ისთვის სხვადასხვა დამატებითი შესაძლებლობებით, მაგალითად, დროის სერიების ანალიზი, გრაფიკის ანალიზი, მანქანური სწავლება და სხვა.

Elasticsearch არქიტექტურა

Elasticsearch კლასტერის მონაცემები ინახება მის ყველა კვანძზე გავრცელებულად. კლასტერი შედგება მრავალი კვანძისგან ხელმისაწვდომობისა და გამძლეობის გასაუმჯობესებლად. ნებისმიერ კვანძს შეუძლია შეასრულოს კლასტერის ყველა როლი, მაგრამ ფართომასშტაბიანი განლაგებისას კვანძებს, როგორც წესი, ენიჭებათ ინდივიდუალური დავალებები.

კლასტერული კვანძების ტიპები:

• სამაგისტრო კვანძი - მართავს კლასტერს, მინიმუმ სამია საჭირო, ერთი ყოველთვის აქტიური;
• მონაცემთა კვანძი - ინახავს ინდექსირებულ მონაცემებს და მასთან ერთად ასრულებს სხვადასხვა დავალებებს;
• ingest node - აწყობს მილსადენებს მონაცემების ინდექსირებამდე ტრანსფორმაციისთვის;
• საკოორდინაციო კვანძი - მოთხოვნის მარშრუტიზაცია, ძიების დამუშავების ფაზის შემცირება, მასობრივი ინდექსირების კოორდინაცია;
• alerting node — გაფრთხილების ამოცანების გაშვება;
• მანქანათმცოდნეობის კვანძი - მანქანათმცოდნეობის ამოცანების დამუშავება.

ქვემოთ მოცემული დიაგრამა გვიჩვენებს, თუ როგორ ხდება მონაცემების შენახვა და ტირაჟირება კვანძებში, რათა მივაღწიოთ უფრო მაღალ მონაცემთა ხელმისაწვდომობას.

თითოეული ასლის მონაცემები ინახება ინვერსიულ ინდექსში, ქვემოთ მოცემული დიაგრამა გვიჩვენებს, თუ როგორ ხდება ეს:

დაყენების

დეტალების ნახვა შესაძლებელია აქ, მე გამოვიყენებ საჭის სქემას:

$ helm install efk-stack stable/elastic-stack --set logstash.enabled=false --set fluentd.enabled=true --set fluentd-elastics

PLG დასტა

არ გაგიკვირდეთ, თუ ამ აკრონიმს ვერ იპოვით, რადგან ის უფრო ცნობილია როგორც Grafana Loki. ნებისმიერ შემთხვევაში, ეს დასტა პოპულარობას იძენს, რადგან ის იყენებს დადასტურებულ ტექნიკურ გადაწყვეტილებებს. შესაძლოა უკვე გსმენიათ Grafana-ს შესახებ, პოპულარული ვიზუალიზაციის ინსტრუმენტი. მისმა შემქმნელებმა, პრომეთეს მიერ შთაგონებულმა, შეიმუშავეს Loki, ჰორიზონტალურად მასშტაბირებადი, მაღალი ხარისხის ჟურნალის აგრეგაციის სისტემა. Loki ინდექსებს მხოლოდ მეტამონაცემებს და არა თავად ჟურნალებს, ტექნიკურ გადაწყვეტას, რომელიც საშუალებას იძლევა იყოს მარტივი და ეკონომიური.

პრომტეილი - აგენტი ოპერაციული სისტემიდან Loki კლასტერში ჟურნალების გაგზავნისთვის. გრაფანა არის ვიზუალიზაციის ინსტრუმენტი, რომელიც დაფუძნებულია ლოკის მონაცემებზე.

Loki აგებულია იმავე პრინციპებზე, როგორც პრომეთე, რაც მას კარგად უხდება Kubernetes-ის ჟურნალების შესანახად და ანალიზს.

ლოკის არქიტექტურა

Loki შეიძლება გაშვებული იყოს როგორც ერთი პროცესი, ასევე მრავალი პროცესი, რაც ჰორიზონტალური მასშტაბის საშუალებას იძლევა.

მას ასევე შეუძლია იმუშაოს როგორც მონოლითური აპლიკაცია ან როგორც მიკროსერვისი. ერთი პროცესის შესრულება შეიძლება სასარგებლო იყოს ადგილობრივი განვითარებისთვის ან მცირე მონიტორინგისთვის. სამრეწველო განხორციელებისთვის და მასშტაბური დატვირთვისთვის, რეკომენდებულია მიკროსერვისის ვარიანტის გამოყენება. მონაცემების ჩაწერისა და წაკითხვის ბილიკები გამოყოფილია, ასე რომ, საჭიროებისამებრ შეიძლება დაზუსტდეს და მასშტაბირება.

მოდით შევხედოთ ჟურნალების შეგროვების სისტემის არქიტექტურას დეტალების გარეშე:

და აქ არის აღწერა (მიკროსერვისის არქიტექტურა):

კომპონენტები:

პრომტეილი — კვანძებზე დაინსტალირებული აგენტი (როგორც სერვისების ნაკრები), ის ამოიღებს ჟურნალებს ამოცანებიდან და წვდება Kubernetes API-ს მეტამონაცემების მოსაპოვებლად, რომელიც მონიშნავს ჟურნალებს. შემდეგ ის აგზავნის ჟურნალს Loki-ს მთავარ სერვისში. მეტამონაცემების რუკების მხარდაჭერა მხარს უჭერს იგივე მონიშვნის წესებს, როგორც პრომეთე.

დისტრიბუტორი — სერვისის დისტრიბუტორი, რომელიც მუშაობს როგორც ბუფერული. მილიონობით ჩანაწერის დასამუშავებლად, ის აგროვებს შემოსულ მონაცემებს, აკუმშავს მას ბლოკებად, როგორც კი ჩამოდის. რამდენიმე მონაცემთა ჩაძირვა მუშაობს ერთდროულად, მაგრამ ჟურნალები, რომლებიც მიეკუთვნება მონაცემთა ერთ შემომავალ ნაკადს, უნდა გამოჩნდეს მხოლოდ ერთ მათგანში მისი ყველა ბლოკისთვის. ეს ორგანიზებულია ნიჟარების რგოლში და თანმიმდევრულ ჰეშირებად. შეცდომის ტოლერანტობისა და ზედმეტობისთვის, ეს კეთდება n-ჯერ (3 თუ არ არის კონფიგურირებული).

ინგესტერი - სერვისის მიმღები. მონაცემთა ბლოკები ჩამოდის შეკუმშული ჟურნალების დამატებით. მას შემდეგ, რაც ბლოკი საკმარისი ზომისაა, ბლოკი გადადის მონაცემთა ბაზაში. მეტამონაცემები მიდის ინდექსში, ხოლო ჟურნალის ბლოკის მონაცემები მიდის Chunks-ში (ჩვეულებრივ, ობიექტების შენახვა). გადატვირთვის შემდეგ, მიმღები ქმნის ახალ ბლოკს, სადაც დაემატება ახალი ჩანაწერები.

ინდექსი - მონაცემთა ბაზა, DynamoDB, Cassandra, Google BigTable და ა.შ.

ბლოკები - ჟურნალის ბლოკები შეკუმშული ფორმით, ჩვეულებრივ ინახება ობიექტების საცავში, მაგალითად, S3.

კითხვარი - კითხვის გზა, რომელიც ასრულებს ყველა ბინძურ საქმეს. ის უყურებს დროის დიაპაზონს და დროის ნიშანს და შემდეგ უყურებს ინდექსს შესატყვისების საპოვნელად. შემდეგი, ის კითხულობს მონაცემთა ბლოკებს და ფილტრავს მათ შედეგის მისაღებად.

ახლა ვნახოთ ყველაფერი მოქმედებაში.

დაყენების

Kubernetes-ში ინსტალაციის უმარტივესი გზაა საჭის გამოყენება. ჩვენ ვვარაუდობთ, რომ თქვენ უკვე დააინსტალირეთ და დააკონფიგურირეთ იგი (და მესამე ვერსია! დაახლ. მთარგმნელი)

დაამატეთ საცავი და დააინსტალირეთ სტეკი.

$ helm repo add loki https://grafana.github.io/loki/charts
$ helm repo update
$ helm upgrade --install loki loki/loki-stack --set grafana.enabled=true,prometheus.enabled=true,prometheus.alertmanager.persistentVolume.enabled=false,prometheus.server.persistentVolume.enabled=false

ქვემოთ მოცემულია საინფორმაციო დაფის მაგალითი, რომელიც აჩვენებს მონაცემებს Prometheus-ისგან Etcd მეტრიკებისთვის და Loki-დან Etcd pod ჟურნალებისთვის.

ახლა მოდით განვიხილოთ ორივე სისტემის არქიტექტურა და ასევე შევადაროთ მათი შესაძლებლობები ერთმანეთს.

შედარება

შეკითხვის ენა

Elasticsearch იყენებს Query DSL და Lucene შეკითხვის ენას სრული ტექსტის ძიების შესაძლებლობების უზრუნველსაყოფად. ეს არის დამკვიდრებული, ძლიერი საძიებო სისტემა ოპერატორის ფართო მხარდაჭერით. მასთან ერთად შეგიძლიათ მოძებნოთ კონტექსტის მიხედვით და დაალაგოთ შესაბამისობის მიხედვით.

ბეჭდის მეორე მხარეს არის LogQL, რომელიც გამოიყენება Loki-ში, PromQL-ის (პრომეთეს შეკითხვის ენა) მემკვიდრე. ის იყენებს ჟურნალის ტეგებს ჟურნალის მონაცემების გასაფილტრად და შესარჩევად. შესაძლებელია ზოგიერთი ოპერატორისა და არითმეტიკის გამოყენება, როგორც აღწერილია აქ, მაგრამ შესაძლებლობების მხრივ ჩამორჩება ელასტიკურ ენას.

ვინაიდან Loki-ში შეკითხვები ასოცირდება ტეგებთან, მათი კორელაცია ადვილია მეტრიკასთან და, შედეგად, უფრო ადვილია ოპერატიული მონიტორინგის ორგანიზება.

მასშტაბურობა

ორივე სტეკი ჰორიზონტალურად მასშტაბირებადია, მაგრამ Loki ამარტივებს, რადგან მას აქვს კითხვისა და წერის ცალკეული ბილიკები და მიკროსერვისის არქიტექტურა. Loki შეიძლება მორგებული იყოს თქვენს საჭიროებებზე და შეიძლება გამოყენებულ იქნას ჟურნალის ძალიან დიდი მოცულობის მონაცემებისთვის.

მრავალწლიანობა

კლასტერული მრავალბინიანობა OPEX-ის აბრევიატურაში გავრცელებული თემაა, ორივე სტეკი უზრუნველყოფს მრავალბინიანობას. არსებობს რამდენიმე Elasticsearch-ისთვის გზები კლიენტის განცალკევება: ცალკეული ინდექსი თითოეული კლიენტისთვის, კლიენტზე დაფუძნებული მარშრუტიზაცია, უნიკალური კლიენტის ველები, საძიებო ფილტრები. ლოკის აქვს მხარს ვუჭერთ HTTP X-Scope-OrgID სათაურის სახით.

ღირებულება

Loki საკმაოდ ეკონომიურია იმის გამო, რომ ის არ ახდენს მონაცემების ინდექსირებას, მხოლოდ მეტამონაცემებს. ეს აღწევს დაზოგვა შენახვაზე და მეხსიერება (ქეში), ვინაიდან ობიექტების შენახვა უფრო იაფია ვიდრე ბლოკის შენახვა, რომელიც გამოიყენება Elasticsearch კლასტერებში.

დასკვნა

EFK სტეკი შეიძლება გამოყენებულ იქნას სხვადასხვა მიზნებისთვის, რაც უზრუნველყოფს მაქსიმალურ მოქნილობას და Kibana-ს ფუნქციებით მდიდარი ინტერფეისით ანალიტიკისთვის, ვიზუალიზაციისთვის და შეკითხვებისთვის. მისი შემდგომი გაძლიერება შესაძლებელია მანქანური სწავლის შესაძლებლობებით.

Loki სტეკი სასარგებლოა Kubernetes-ის ეკოსისტემაში მისი მეტამონაცემების აღმოჩენის მექანიზმის გამო. თქვენ შეგიძლიათ მარტივად დააკავშიროთ მონაცემები მონიტორინგისთვის Grafana-ში დროის სერიებზე და ჟურნალებში.

რაც შეეხება ხარჯებს და ჟურნალის გრძელვადიან შენახვას, Loki არის შესანიშნავი შესასვლელი წერტილი ღრუბლოვან გადაწყვეტილებებში.

ბაზარზე მეტი ალტერნატივაა – ზოგიერთი შეიძლება თქვენთვის უკეთესი იყოს. მაგალითად, GKE-ს აქვს Stackdriver ინტეგრაცია, რომელიც უზრუნველყოფს შესანიშნავი მონიტორინგის გადაწყვეტას. ამ სტატიაში ჩვენს ანალიზში ისინი არ შევიტანეთ.

ბმულები:

• https://github.com/grafana/loki/blob/master/docs/overview/comparisons.md
• https://www.elastic.co/blog/found-elasticsearch-from-the-bottom-up
• https://www.elastic.co/blog/found-elasticsearch-in-production/

სტატია თანამშრომლებმა თარგმნეს და მოამზადეს ჰაბრისთვის Slurm სასწავლო ცენტრი - ინტენსიური კურსები, ვიდეო კურსები და კორპორატიული ტრენინგი პრაქტიკოსი სპეციალისტებისგან (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)

წყარო: www.habr.com