Fluentd: რატომ არის მნიშვნელოვანი გამომავალი ბუფერის კონფიგურაცია

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

Fluentd არის თანამედროვე, უნივერსალური ჟურნალის კოლექციონერი, რომელიც სულ უფრო მეტ პოპულარობას იძენს და შეუერთდა Cloud Native Computing Foundation-ს, რის გამოც მისი განვითარების ვექტორი ორიენტირებულია Kubernetes-თან ერთად გამოყენებაზე.

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

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

დოკუმენტების დუბლირების პრობლემა

ჩვენს პროექტებში Fluentd განლაგებულია როგორც DaemonSet (ავტომატურად გაშვებული ერთ ინსტანციაში Kubernetes კლასტერის თითოეულ კვანძზე) და აკონტროლებს stdout კონტეინერის ჟურნალებს /var/log/containers. შეგროვებისა და დამუშავების შემდეგ, ჟურნალები JSON დოკუმენტების სახით იგზავნება ElasticSearch-ში, გაზრდილი კლასტერული ან დამოუკიდებელი სახით, რაც დამოკიდებულია პროექტის მასშტაბზე და შესრულებისა და ხარვეზების ტოლერანტობის მოთხოვნებზე. Kibana გამოიყენება როგორც გრაფიკული ინტერფეისი.

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

127.0.0.1 192.168.0.1 - [28/Feb/2013:12:00:00 +0900] "GET / HTTP/1.1" 200 777 "-" "Opera/12.0" -

თუმცა, ElasticSearch-ში არის რამდენიმე დოკუმენტი, რომელიც შეიცავს ამ შეტყობინებას:

{
  "_index": "test-custom-prod-example-2020.01.02",
  "_type": "_doc",
  "_id": "HgGl_nIBR8C-2_33RlQV",
  "_version": 1,
  "_score": 0,
  "_source": {
    "service": "test-custom-prod-example",
    "container_name": "nginx",
    "namespace": "test-prod",
    "@timestamp": "2020-01-14T05:29:47.599052886 00:00",
    "log": "127.0.0.1 192.168.0.1 - [28/Feb/2013:12:00:00  0900] "GET / HTTP/1.1" 200 777 "-" "Opera/12.0" -",
    "tag": "custom-log"
  }
}

{
  "_index": "test-custom-prod-example-2020.01.02",
  "_type": "_doc",
  "_id": "IgGm_nIBR8C-2_33e2ST",
  "_version": 1,
  "_score": 0,
  "_source": {
    "service": "test-custom-prod-example",
    "container_name": "nginx",
    "namespace": "test-prod",
    "@timestamp": "2020-01-14T05:29:47.599052886 00:00",
    "log": "127.0.0.1 192.168.0.1 - [28/Feb/2013:12:00:00  0900] "GET / HTTP/1.1" 200 777 "-" "Opera/12.0" -",
    "tag": "custom-log"
  }
}

უფრო მეტიც, შეიძლება იყოს ორზე მეტი გამეორება.

Fluentd-ის ჟურნალებში ამ პრობლემის გადაჭრისას შეგიძლიათ იხილოთ გაფრთხილებების დიდი რაოდენობა შემდეგი შინაარსით:

2020-01-16 01:46:46 +0000 [warn]: [test-prod] failed to flush the buffer. retry_time=4 next_retry_seconds=2020-01-16 01:46:53 +0000 chunk="59c37fc3fb320608692c352802b973ce" error_class=Fluent::Plugin::ElasticsearchOutput::RecoverableRequestFailure error="could not push logs to Elasticsearch cluster ({:host=>"elasticsearch", :port=>9200, :scheme=>"http", :user=>"elastic", :password=>"obfuscated"}): read timeout reached"

ეს გაფრთხილებები ხდება მაშინ, როდესაც ElasticSearch ვერ დააბრუნებს მოთხოვნაზე პასუხს request_timeout პარამეტრით განსაზღვრულ დროში, რის გამოც გადაგზავნილი ბუფერის ფრაგმენტი ვერ გასუფთავდება. ამის შემდეგ, Fluentd ცდილობს კვლავ გაგზავნოს ბუფერის ფრაგმენტი ElasticSearch-ში და თვითნებური რაოდენობის მცდელობის შემდეგ, ოპერაცია წარმატებით სრულდება:

2020-01-16 01:47:05 +0000 [warn]: [test-prod] retry succeeded. chunk_id="59c37fc3fb320608692c352802b973ce" 
2020-01-16 01:47:05 +0000 [warn]: [test-prod] retry succeeded. chunk_id="59c37fad241ab300518b936e27200747" 
2020-01-16 01:47:05 +0000 [warn]: [test-dev] retry succeeded. chunk_id="59c37fc11f7ab707ca5de72a88321cc2" 
2020-01-16 01:47:05 +0000 [warn]: [test-dev] retry succeeded. chunk_id="59c37fb5adb70c06e649d8c108318c9b" 
2020-01-16 01:47:15 +0000 [warn]: [kube-system] retry succeeded. chunk_id="59c37f63a9046e6dff7e9987729be66f"

თუმცა, ElasticSearch განიხილავს თითოეულ გადაცემულ ბუფერულ ფრაგმენტს, როგორც უნიკალურს და ანიჭებს მათ უნიკალურ _id ველის მნიშვნელობებს ინდექსირების დროს. ასე ჩნდება შეტყობინებების ასლები.

კიბანაში ასე გამოიყურება:

გადაწყვეტა

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

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

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

პრობლემის ჩაწერის დროს, კონფიგურაცია ასე გამოიყურებოდა:

 <buffer>
        @type file
        path /var/log/fluentd-buffers/kubernetes.test.buffer
        flush_mode interval
        retry_type exponential_backoff
        flush_thread_count 2
        flush_interval 5s
        retry_forever
        retry_max_interval 30
        chunk_limit_size 8M
        queue_limit_length 8
        overflow_action block
      </buffer>

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

• flush_interval — დროის ინტერვალი, რომლის შემდეგაც ბუფერი იშლება.
• queue_limit_length — რიგების მაქსიმალური რაოდენობა.
• request_timeout არის დრო, რომლის დროსაც მყარდება კავშირი Fluentd-სა და ElasticSearch-ს შორის.

ბუფერის მთლიანი ზომა შეიძლება გამოითვალოს queue_limit_length და chunk_limit_size პარამეტრების გამრავლებით, რაც შეიძლება განიმარტოს, როგორც "რიგში ნაჭრების მაქსიმალური რაოდენობა, რომელთაგან თითოეულს აქვს მოცემული ზომა." თუ ბუფერის ზომა არასაკმარისია, შემდეგი გაფრთხილება გამოჩნდება ჟურნალებში:

2020-01-21 10:22:57 +0000 [warn]: [test-prod] failed to write data into buffer by buffer overflow action=:block

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

თქვენ შეგიძლიათ გაზარდოთ ბუფერი ორი გზით: რიგის თითოეული ნაწილის ზომის გაზრდით, ან რიგში მყოფი ნაწილების რაოდენობის გაზრდით.

თუ თქვენ დააყენეთ chunk_limit_size-ის ზომა 32 მეგაბაიტზე მეტს, მაშინ ElasticSeacrh არ მიიღებს მას, რადგან შემომავალი პაკეტი ძალიან დიდი იქნება. ამიტომ, თუ თქვენ გჭირდებათ ბუფერის შემდგომი გაზრდა, უმჯობესია გაზარდოთ რიგის მაქსიმალური სიგრძე queue_limit_length.

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

2020-01-21 09:55:33 +0000 [warn]: [test-dev] buffer flush took longer time than slow_flush_log_threshold: elapsed_time=20.85753920301795 slow_flush_log_threshold=20.0 plugin_id="postgresql-dev" 

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

განზოგადებული შერჩევის ალგორითმი შემდეგია:

1. დააყენეთ request_timeout მნიშვნელობაზე, რომელიც გარანტირებულია საჭიროზე მეტი (ასობით წამი). დაყენების დროს, ამ პარამეტრის სწორი დაყენების მთავარი კრიტერიუმი იქნება გაფრთხილებების გაქრობა დროის ნაკლებობის შესახებ.
2. დაელოდეთ შეტყობინებებს slow_flush_log_threshold ზღვრის გადალახვის შესახებ. გამაფრთხილებელი ტექსტი ველში elapsed_time აჩვენებს ბუფერის გასუფთავების რეალურ დროს.
3. დააყენეთ request_timeout მნიშვნელობა, რომელიც აღემატება დაკვირვების პერიოდში მიღებულ მაქსიმალურ გასული_დროის მნიშვნელობას. ჩვენ ვიანგარიშებთ request_timeout მნიშვნელობას, როგორც გასული_დრო + 50%.
4. ხანგრძლივი ბუფერული გამორთვის შესახებ გაფრთხილებების ჟურნალიდან ამოსაღებად, შეგიძლიათ გაზარდოთ slow_flush_log_threshold-ის მნიშვნელობა. ჩვენ ვიანგარიშებთ ამ მნიშვნელობას, როგორც გასული_დრო + 25%.

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

ქვემოთ მოყვანილი ცხრილი გვიჩვენებს, თუ როგორ იცვლება დღეში შეცდომების რაოდენობა, რაც იწვევს შეტყობინებების დუბლირებას, იცვლება ზემოთ აღწერილი პარამეტრების მნიშვნელობების შერჩევის პროცესში:

კვანძი-1
კვანძი-2
კვანძი-3
კვანძი-4

სანამ შემდეგ
სანამ შემდეგ
სანამ შემდეგ
სანამ შემდეგ

ბუფერის გამორეცხვა ვერ მოხერხდა
1749/2
694/2
47/0
1121/2

განმეორებითი ცდა წარმატებით დასრულდა
410/2
205/1
24/0
241/2

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

დასკვნა

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

ასევე წაიკითხეთ სხვა სტატიები ჩვენს ბლოგზე:

• წადი და Zabbix 5.0 დამეგობრდნენ
• Kubernetes კლასტერის განახლება შეფერხების გარეშე
• Kubernetes: რატომ არის ასე მნიშვნელოვანი სისტემის რესურსების მართვის კონფიგურაცია?
• სამი მარტივი ხრიკი დოკერის სურათების შესამცირებლად
• დიდი რაოდენობით ჰეტეროგენული ვებ პროექტების სარეზერვო ასლი

წყარო: www.habr.com