ლოკიდან მორების შეგროვება

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

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

რა არის ლოკი

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

მთავარი გვერდი, GitHub

სანამ შევისწავლით თუ რისი გაკეთება შეგიძლიათ Loki-სთან, მსურს განვმარტო რას ვგულისხმობთ „მხოლოდ მეტამონაცემების ინდექსირების იდეაში“. მოდით შევადაროთ Loki მიდგომა და ინდექსირების მიდგომა ტრადიციულ გადაწყვეტილებებში, როგორიცაა Elasticsearch, nginx log-ის ხაზის მაგალითის გამოყენებით:

172.19.0.4 - - [01/Jun/2020:12:05:03 +0000] "GET /purchase?user_id=75146478&item_id=34234 HTTP/1.1" 500 8102 "-" "Stub_Bot/3.0" "0.001"

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

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

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

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

ჟურნალის ძებნა

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

საძიებო ინტერფეისი ასე გამოიყურება:

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

{image_name="nginx.promtail.test"} |= "index"

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

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

{instance=~"kafka-[23]",name!="kafka-dev"} 
// Найдёт логи с лейблом instance, имеющие значение kafka-2, kafka-3, и исключит dev 

ფილტრი არის ტექსტი ან regexp, რომელიც გაფილტრავს სელექტორის მიერ მიღებულ ყველა მონაცემს.

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

შესაძლებლობების სრული აღწერა შეგიძლიათ იხილოთ დოკუმენტაციაში LogQL.

ჟურნალის გარჩევა

მორების შეგროვების რამდენიმე გზა არსებობს:

• Promtail-ის გამოყენება, დასტის სტანდარტული კომპონენტი ჟურნალების შეგროვებისთვის.
• პირდაპირ დოკერის კონტეინერიდან გამოყენებით Loki Docker Logging Driver.
• გამოიყენეთ Fluentd ან Fluent Bit, რომელსაც შეუძლია მონაცემების გაგზავნა Loki-ზე. Promtail-ისგან განსხვავებით, მათ აქვთ მზა პარსერი თითქმის ნებისმიერი ტიპის ჟურნალისთვის და ასევე შეუძლიათ მრავალხაზოვანი ჟურნალების მართვა.

ჩვეულებრივ Promtail გამოიყენება პარსინგისთვის. ის აკეთებს სამ რამეს:

• პოულობს მონაცემთა წყაროებს.
• ამაგრებს მათ ეტიკეტებს.
• უგზავნის მონაცემებს ლოკის.

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

არის Kubernetes-თან ინტეგრაცია: Promtail ავტომატურად, Kubernetes REST API-ის მეშვეობით, ამოიცნობს კლასტერის მდგომარეობას და აგროვებს ჟურნალებს კვანძიდან, სერვისიდან ან პოდიდან, დაუყოვნებლივ აქვეყნებს ლეიბლებს Kubernetes-ის მეტამონაცემებზე (პოდის სახელი, ფაილის სახელი და ა.შ.) .

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

1. ანალიზების ეტაპები. ეს არის RegEx და JSON ეტაპი. ამ ეტაპზე ჩვენ ვიღებთ მონაცემებს ჟურნალებიდან ე.წ. ჩვენ შეგვიძლია გამოვყოთ JSON-დან, უბრალოდ, საჭირო ველების კოპირებით ამოღებულ რუკაში, ან რეგულარული გამონათქვამების (RegEx) მეშვეობით, სადაც დასახელებული ჯგუფები „დასახულია“ ამოღებულ რუკაში. Extracted რუკა არის გასაღები-მნიშვნელობის მაღაზია, სადაც გასაღები არის ველის სახელი და მნიშვნელობა არის მისი მნიშვნელობა ჟურნალებიდან.
2. ტრანსფორმაციის ეტაპები. ამ ეტაპს აქვს ორი ვარიანტი: ტრანსფორმაცია, სადაც ვადგენთ ტრანსფორმაციის წესებს და წყარო - მონაცემთა წყარო ამოღებული რუქიდან ტრანსფორმაციისთვის. თუ ამოღებულ რუკაში ასეთი ველი არ არის, ის შეიქმნება. ამ გზით შესაძლებელია ეტიკეტების შექმნა, რომლებიც არ არის დაფუძნებული ამოღებულ რუკაზე. ამ ეტაპზე ჩვენ შეგვიძლია მოპოვებული რუკის მონაცემებით მანიპულირება საკმაოდ მძლავრი გამოყენებით გოლანგის შაბლონი. გარდა ამისა, უნდა გვახსოვდეს, რომ ამოღებული რუკა მთლიანად იტვირთება ანალიზის დროს, რაც შესაძლებელს ხდის, მაგალითად, მასში არსებული მნიშვნელობის შემოწმება: „{{if .tag}tag value is exist{end}}“. შაბლონი მხარს უჭერს პირობებს, მარყუჟებს და სტრიქონების ზოგიერთ ფუნქციას, როგორიცაა Replace და Trim.
3. მოქმედების ეტაპები. ამ ეტაპზე შეგიძლიათ გააკეთოთ რაღაც ამოღებული შინაარსით:
   • შექმენით ლეიბლი ამოღებული მონაცემებიდან, რომელიც იქნება ინდექსირებული Loki-ს მიერ.
   • შეცვალეთ ან დააყენეთ ღონისძიების დრო ჟურნალიდან.
   • შეცვალეთ მონაცემები (ლოგის ტექსტი), რომელიც გადავა Loki-ზე.
   • შექმენით მეტრიკა.
4. ფილტრაციის ეტაპები. მატჩის ეტაპი, სადაც ჩვენ შეგვიძლია გავაგზავნოთ ჩანაწერები, რომლებიც არ გვჭირდება /dev/null, ან გავაგზავნოთ შემდგომი დამუშავებისთვის.

ჩვეულებრივი nginx ჟურნალების დამუშავების მაგალითის გამოყენებით, მე გაჩვენებთ, თუ როგორ შეგიძლიათ გაანალიზოთ ჟურნალები Promtail-ის გამოყენებით.

ტესტისთვის ავიღოთ როგორც nginx-proxy შეცვლილი nginx სურათი jwilder/nginx-proxy:alpine და პატარა დემონი, რომელსაც შეუძლია ჰკითხოს საკუთარ თავს HTTP-ის საშუალებით. დემონს აქვს რამდენიმე საბოლოო წერტილი, რომლებზეც მას შეუძლია სხვადასხვა ზომის პასუხები, სხვადასხვა HTTP სტატუსით და სხვადასხვა დაყოვნებით.

ჩვენ შევაგროვებთ ჟურნალებს დოკერის კონტეინერებიდან, რომლებიც შეგიძლიათ იხილოთ გზაზე /var/lib/docker/containers//-json.log

docker-compose.yml-ში ჩვენ ვაკონფიგურირებთ Promtail-ს და ვაზუსტებთ კონფიგურაციის გზას:

promtail:
  image: grafana/promtail:1.4.1
 // ...
 volumes:
   - /var/lib/docker/containers:/var/lib/docker/containers:ro
   - promtail-data:/var/lib/promtail/positions
   - ${PWD}/promtail/docker.yml:/etc/promtail/promtail.yml
 command:
   - '-config.file=/etc/promtail/promtail.yml'
 // ...

დაამატეთ ლოგების ბილიკი promtail.yml-ზე (კონფიგურაციაში არის „დოკერის“ ვარიანტი, რომელიც იგივეს აკეთებს ერთ სტრიქონში, მაგრამ ეს არც ისე ნათელი იქნება):

scrape_configs:
 - job_name: containers

   static_configs:
       labels:
         job: containerlogs
         __path__: /var/lib/docker/containers/*/*log  # for linux only

როდესაც ეს კონფიგურაცია ჩართულია, ჟურნალები ყველა კონტეინერიდან გაეგზავნება Loki-ს. ამის თავიდან ასაცილებლად, ჩვენ ვცვლით სატესტო nginx-ის პარამეტრებს docker-compose.yml-ში - დავამატებთ ჟურნალის ტეგის ველს:

proxy:
 image: nginx.test.v3
//…
 logging:
   driver: "json-file"
   options:
     tag: "{{.ImageName}}|{{.Name}}"

promtail.yml-ის რედაქტირება და Pipeline-ის დაყენება. შეყვანა მოიცავს შემდეგი ტიპის ჟურნალებს:

{"log":"u001b[0;33;1mnginx.1    | u001b[0mnginx.test 172.28.0.3 - - [13/Jun/2020:23:25:50 +0000] "GET /api/index HTTP/1.1" 200 0 "-" "Stub_Bot/0.1" "0.096"n","stream":"stdout","attrs":{"tag":"nginx.promtail.test|proxy.prober"},"time":"2020-06-13T23:25:50.66740443Z"}
{"log":"u001b[0;33;1mnginx.1    | u001b[0mnginx.test 172.28.0.3 - - [13/Jun/2020:23:25:50 +0000] "GET /200 HTTP/1.1" 200 0 "-" "Stub_Bot/0.1" "0.000"n","stream":"stdout","attrs":{"tag":"nginx.promtail.test|proxy.prober"},"time":"2020-06-13T23:25:50.702925272Z"}

მილსადენის ეტაპი:

 - json:
     expressions:
       stream: stream
       attrs: attrs
       tag: attrs.tag

ჩვენ ამოვიღებთ ველებს stream, attrs, attrs.tag (თუ ისინი არსებობს) შემომავალი JSON-დან და ვდებთ ამოღებულ რუკაში.

 - regex:
     expression: ^(?P<image_name>([^|]+))|(?P<container_name>([^|]+))$
     source: "tag"

თუ მოვახერხეთ ტეგის ველის მოთავსება ამოღებულ რუკაში, მაშინ regexp-ის გამოყენებით გამოვყავით გამოსახულების და კონტეინერის სახელები.

 - labels:
     image_name:
     container_name:

ჩვენ ვაძლევთ ეტიკეტებს. თუ ამოღებულ მონაცემებში ნაპოვნია image_name და container_name კლავიშები, მაშინ მათი მნიშვნელობები მიენიჭება შესაბამის ეტიკეტებს.

 - match:
     selector: '{job="docker",container_name="",image_name=""}'
     action: drop

ჩვენ უარვყოფთ ყველა ჟურნალს, რომელსაც არ აქვს დაინსტალირებული ლეიბლები image_name და container_name.

  - match:
     selector: '{image_name="nginx.promtail.test"}'
     stages:
       - json:
           expressions:
             row: log

ყველა ჟურნალისთვის, რომლის image_name არის nginx.promtail.test, ამოიღეთ ჟურნალის ველი წყაროს ჟურნალიდან და ჩადეთ იგი ამოღებულ რუკაში მწკრივის ღილაკით.

  - regex:
         # suppress forego colors
         expression: .+nginx.+|.+[0m(?P<virtual_host>[a-z_.-]+) +(?P<nginxlog>.+)
         source: logrow

ჩვენ ვასუფთავებთ შეყვანის ხაზს რეგულარული გამონათქვამებით და ამოვიღებთ nginx ვირტუალურ ჰოსტს და nginx log ხაზს.

     - regex:
         source: nginxlog
         expression: ^(?P<ip>[w.]+) - (?P<user>[^ ]*) [(?P<timestamp>[^ ]+).*] "(?P<method>[^ ]*) (?P<request_url>[^ ]*) (?P<request_http_protocol>[^ ]*)" (?P<status>[d]+) (?P<bytes_out>[d]+) "(?P<http_referer>[^"]*)" "(?P<user_agent>[^"]*)"( "(?P<response_time>[d.]+)")?

გააანალიზეთ nginx ჟურნალი რეგულარული გამონათქვამების გამოყენებით.

    - regex:
           source: request_url
           expression: ^.+.(?P<static_type>jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|pdf|txt|tar|wav|bmp|rtf|js|flv|swf|html|htm)$
     - regex:
           source: request_url
           expression: ^/photo/(?P<photo>[^/?.]+).*$
       - regex:
           source: request_url
           expression: ^/api/(?P<api_request>[^/?.]+).*$

მოდით გავაანალიზოთ request_url. regexp-ის გამოყენებით განვსაზღვრავთ მოთხოვნის მიზანს: სტატიკური მონაცემების, ფოტოების, API-ს და შესაბამისი გასაღების დაყენება ამოღებულ რუკაზე.

       - template:
           source: request_type
           template: "{{if .photo}}photo{{else if .static_type}}static{{else if .api_request}}api{{else}}other{{end}}"

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

       - labels:
           api_request:
           virtual_host:
           request_type:
           status:

ჩვენ დავაყენეთ ეტიკეტები api_request, virtual_host, request_type და status (HTTP status) იმის მიხედვით, რაც მოვახერხეთ ამოღებულ რუკაში ჩასმა.

       - output:
           source: nginx_log_row

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

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

ერთი რამ უნდა გვახსოვდეს, რომ დიდი რაოდენობით მნიშვნელობების მქონე ეტიკეტების მოძიებამ შეიძლება მნიშვნელოვნად შეანელოს ლოკი. ანუ ინდექსში არ უნდა ჩადოთ, მაგალითად, user_id. დაწვრილებით ამის შესახებ სტატიაში ”როგორ შეუძლიათ Loki-ში ლეიბლებს ჟურნალის მოთხოვნები უფრო სწრაფი და მარტივი გახადონ" მაგრამ ეს არ ნიშნავს იმას, რომ თქვენ არ შეგიძლიათ მოძებნოთ user_id-ის მიხედვით ინდექსების გარეშე. თქვენ უნდა გამოიყენოთ ფილტრები ძიებისას (მონაცემების „დაჭერა“) და აქ ინდექსი მოქმედებს როგორც ნაკადის იდენტიფიკატორი.

მორების ვიზუალიზაცია

Loki-ს შეუძლია იმოქმედოს როგორც მონაცემთა წყარო Grafana გრაფიკებისთვის LogQL-ის გამოყენებით. შემდეგი ფუნქციები მხარდაჭერილია:

• მაჩვენებელი — ჩანაწერების რაოდენობა წამში;
• დროთა განმავლობაში დათვლა — ჩანაწერების რაოდენობა მითითებულ დიაპაზონში.

ასევე არსებობს აგრეგაციის ფუნქციები Sum, Avg და სხვა. თქვენ შეგიძლიათ შექმნათ საკმაოდ რთული გრაფიკები, მაგალითად HTTP შეცდომების რაოდენობის გრაფიკი:

მონაცემთა სტანდარტული წყარო Loki გარკვეულწილად შემცირებულია ფუნქციონალურობით პრომეთეს მონაცემთა წყაროსთან შედარებით (მაგალითად, თქვენ არ შეგიძლიათ შეცვალოთ ლეგენდა), მაგრამ ლოკი შეიძლება დაუკავშირდეს წყაროს პრომეთეს ტიპს. მე არ ვარ დარწმუნებული, არის თუ არა ეს დოკუმენტირებული ქცევა, მაგრამ ვიმსჯელებთ დეველოპერების პასუხის მიხედვით "როგორ დავაკონფიგურიროთ ლოკი, როგორც პრომეთეს მონაცემთა წყარო? · გამოცემა #1222 · grafana/loki”, მაგალითად, სრულიად ლეგალურია და Loki სრულად თავსებადია PromQL-თან.

დაამატეთ Loki, როგორც მონაცემთა წყარო, ტიპით Prometheus და დაამატეთ URL /loki:

ჩვენ შეგვიძლია შევქმნათ გრაფიკები, თითქოს პრომეთეს მეტრიკაზე ვმუშაობდეთ:

მე ვფიქრობ, რომ ფუნქციონალურობის შეუსაბამობა დროებითია და დეველოპერები ამას მომავალში გამოასწორებენ.

მეტრიკა

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

დაამატეთ სხვა განყოფილება promtail.yml-ს:

- match:
   selector: '{request_type="api"}'
   stages:
     - metrics:
         http_nginx_response_time:
           type: Histogram
           description: "response time ms"
           source: response_time
           config:
             buckets: [0.010,0.050,0.100,0.200,0.500,1.0]
- match:
   selector: '{request_type=~"static|photo"}'
   stages:
     - metrics:
         http_nginx_response_bytes_sum:
           type: Counter
           description: "response bytes sum"
           source: bytes_out
           config:
             action: add
         http_nginx_response_bytes_count:
           type: Counter
           description: "response bytes count"
           source: bytes_out
           config:
             action: inc

ოფცია საშუალებას გაძლევთ განსაზღვროთ და განაახლოთ მეტრიკა ამოღებული რუქის მონაცემებზე დაყრდნობით. ეს მეტრიკა არ იგზავნება Loki-ში - ისინი გამოჩნდება Promtail /metrics ბოლო წერტილში. ამ ეტაპზე მიღებული მონაცემების მისაღებად პრომეთე უნდა იყოს კონფიგურირებული. ზემოთ მოყვანილ მაგალითში, request_type=“api”-სთვის ჩვენ ვაგროვებთ ჰისტოგრამის მეტრიკას. ამ ტიპის მეტრიკებით მოსახერხებელია პროცენტების მიღება. სტატიკური და ფოტოსთვის, ჩვენ ვაგროვებთ ბაიტების ჯამს და რიგების რაოდენობას, რომლებშიც მივიღეთ ბაიტები, რათა გამოვთვალოთ საშუალო.

წაიკითხეთ მეტი მეტრიკის შესახებ აქ.

გახსენით პორტი Promtail-ზე:

promtail:
     image: grafana/promtail:1.4.1
     container_name: monitoring.promtail
     expose:
       - 9080
     ports:
       - "9080:9080"

დარწმუნდით, რომ მეტრიკა გამოჩნდება promtail_custom პრეფიქსით:

პრომეთეს დაყენება. დავამატოთ ვაკანსიის პრომტეილი:

- job_name: 'promtail'
 scrape_interval: 10s
 static_configs:
   - targets: ['promtail:9080']

და ჩვენ ვხატავთ გრაფიკს:

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

სკალირება

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

ნაჭრების შენახვა შესაძლებელია S3-თან თავსებად საცავში, ხოლო ჰორიზონტალურად მასშტაბირებადი მონაცემთა ბაზების გამოყენება შესაძლებელია ინდექსების შესანახად: Cassandra, BigTable ან DynamoDB. Loki-ს სხვა ნაწილები - დისტრიბუტორები (წერისთვის) და Querier (შეკითხვებისთვის) - არის მოქალაქეობის არმქონე და ასევე ჰორიზონტალურად მასშტაბური.

DevOpsDays Vancouver 2019 კონფერენციაზე, ერთ-ერთმა მონაწილემ კალუმ სტიანმა გამოაცხადა, რომ ლოკისთან ერთად მის პროექტს აქვს პეტაბაიტი ჟურნალი, საერთო ზომის 1%-ზე ნაკლები ინდექსით: ”როგორ აკავშირებს ლოკი მეტრიკასა და ჟურნალს - და დაზოგავთ ფულს".

ლოკის და ELK-ის შედარება

ინდექსის ზომა

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

ორი ხაზის მაგალითი ჟურნალიდან:

ELK-ის მიერ ინდექსირებისას, მან მიიღო ინდექსის ზომა 30,3 მბ:

Loki-ს შემთხვევაში, ამან გამოიწვია დაახლოებით 128 KB ინდექსი და დაახლოებით 3,8 MB მონაცემები ნაწილებად. აღსანიშნავია, რომ ჟურნალი ხელოვნურად იყო გენერირებული და არ გააჩნდა მრავალფეროვანი მონაცემები. ორიგინალურ Docker JSON ჟურნალზე მარტივი gzip მონაცემებით შეკუმშვა იყო 95,4% და იმის გათვალისწინებით, რომ მხოლოდ გაწმენდილი nginx ჟურნალი გაეგზავნა თავად Loki-ს, გასაგებია 4 მბ-მდე შეკუმშვა. Loki ეტიკეტების უნიკალური მნიშვნელობების საერთო რაოდენობა იყო 35, რაც ხსნის ინდექსის მცირე ზომას. ELK-სთვის ჟურნალიც გასუფთავდა. ამრიგად, ლოკიმ შეკუმშა ორიგინალური მონაცემები 96%-ით, ხოლო ELK 70%-ით.

მეხსიერების მოხმარება

თუ შევადარებთ მთელ პრომეთეს და ELK დასტას, მაშინ ლოკი რამდენჯერმე ნაკლებს "ჭამს". ნათელია, რომ Go სერვისი მოიხმარს Java სერვისზე ნაკლებს და JVM Heap Elasticsearch-ის ზომისა და Loki-სთვის გამოყოფილი მეხსიერების შედარება არასწორია, მაგრამ მიუხედავად ამისა, აღსანიშნავია, რომ Loki იყენებს გაცილებით ნაკლებ მეხსიერებას. მისი CPU უპირატესობა არც ისე აშკარაა, მაგრამ ის ასევე არსებობს.

სიჩქარის

ლოკი უფრო სწრაფად „ჭამს“ ლოგინებს. სიჩქარე ბევრ ფაქტორზეა დამოკიდებული - როგორი ლოგებია, რამდენად დახვეწილი ვართ მათ ანალიზში, ქსელში, დისკზე და ა.შ. - მაგრამ ის ნამდვილად უფრო მაღალია ვიდრე ELK (ჩემს ტესტში - დაახლოებით ორჯერ მეტი). ეს აიხსნება იმით, რომ ლოკი გაცილებით ნაკლებ მონაცემს დებს ინდექსში და შესაბამისად ნაკლებ დროს ხარჯავს ინდექსირებაზე. ძიების სიჩქარით, სიტუაცია საპირისპიროა: Loki შესამჩნევად ანელებს რამდენიმე გიგაბაიტზე დიდ მონაცემებს, ხოლო ELK-ის ძიების სიჩქარე არ არის დამოკიდებული მონაცემთა ზომაზე.

ჟურნალის ძებნა

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

ინტერფეისი

უპირველეს ყოვლისა, ლამაზია (ბოდიში, წინააღმდეგობა ვერ გავუწიე). Grafana-ს აქვს ლამაზი გარეგნობის ინტერფეისი, მაგრამ Kibana ბევრად უფრო მდიდარია ფუნქციებით.

ლოკის დადებითი და უარყოფითი მხარეები

ერთ-ერთი უპირატესობა ის არის, რომ ლოკი ინტეგრირდება პრომეთესთან, ასე რომ, ჩვენ ვიღებთ მეტრიკას და გაფრთხილებას. მოსახერხებელია ჟურნალების შეგროვება და მათი შესანახი Kubernetes Pods-დან, რადგან მას აქვს Prometheus-ისგან მემკვიდრეობით მიღებული სერვისის აღმოჩენა და ავტომატურად ამაგრებს ეტიკეტებს.

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

დასკვნა

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

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

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

მდებარეობს სტატიაში გამოყენებული კოდის საცავი აქ.

წყარო: www.habr.com