Fluentd: आउटपुट बफर कॉन्फिगर करणे महत्वाचे का आहे

आजकाल, ELK स्टॅकशिवाय कुबर्नेट्स-आधारित प्रकल्पाची कल्पना करणे अशक्य आहे, जे क्लस्टरच्या दोन्ही ऍप्लिकेशन्स आणि सिस्टम घटकांचे लॉग वाचवते. आमच्या प्रॅक्टिसमध्ये, आम्ही Logstash ऐवजी Fluentd सह EFK स्टॅक वापरतो.

Fluentd हा एक आधुनिक, सार्वत्रिक लॉग कलेक्टर आहे जो अधिकाधिक लोकप्रिय होत आहे आणि क्लाउड नेटिव्ह कंप्युटिंग फाउंडेशनमध्ये सामील झाला आहे, म्हणूनच त्याचा विकास वेक्टर कुबर्नेट्सच्या संयोगाने वापरण्यावर केंद्रित आहे.

Logstash ऐवजी Fluentd वापरण्याची वस्तुस्थिती सॉफ्टवेअर पॅकेजचे सामान्य सार बदलत नाही, तथापि, Fluentd ला त्याच्या अष्टपैलुत्वामुळे त्याच्या स्वतःच्या विशिष्ट बारकावे द्वारे दर्शविले जाते.

उदाहरणार्थ, जेव्हा आम्ही लॉगिंगच्या उच्च तीव्रतेसह व्यस्त प्रकल्पात EFK वापरण्यास सुरुवात केली, तेव्हा आम्हाला या वस्तुस्थितीचा सामना करावा लागला की किबानामध्ये काही संदेश वारंवार वारंवार प्रदर्शित केले गेले. या लेखात आम्ही तुम्हाला सांगू की ही घटना का उद्भवते आणि समस्येचे निराकरण कसे करावे.

दस्तऐवज डुप्लिकेशनची समस्या

आमच्या प्रकल्पांमध्ये, Fluentd ला डेमनसेट म्हणून तैनात केले जाते (कुबर्नेट्स क्लस्टरच्या प्रत्येक नोडवर एका प्रसंगात स्वयंचलितपणे लॉन्च केले जाते) आणि /var/log/containers मधील stdout कंटेनर लॉगचे निरीक्षण करते. संकलन आणि प्रक्रिया केल्यानंतर, JSON दस्तऐवजांच्या स्वरूपात लॉग इलास्टिकसर्चला पाठवले जातात, क्लस्टर किंवा स्टँडअलोन स्वरूपात, प्रोजेक्टच्या स्केलवर आणि कामगिरी आणि दोष सहिष्णुतेच्या आवश्यकतांवर अवलंबून. किबाना हा ग्राफिकल इंटरफेस म्हणून वापरला जातो.

आउटपुट बफरिंग प्लगइनसह 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"

जेव्हा इलास्टिकसर्च विनंती_टाइमआउट पॅरामीटरने निर्दिष्ट केलेल्या वेळेत विनंतीला प्रतिसाद देऊ शकत नाही तेव्हा या चेतावणी येतात, म्हणूनच फॉरवर्ड केलेला बफर फ्रॅगमेंट साफ करता येत नाही. यानंतर, 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 ला अनुक्रमणिकेवर दस्तऐवज त्वरित लिहिता येत नसेल तर, दस्तऐवज रांगेत आणि डिस्कवर संग्रहित केला जातो. म्हणून, आमच्या बाबतीत, वर वर्णन केलेल्या त्रुटीकडे कारणीभूत असलेल्या समस्येचे स्त्रोत दूर करण्यासाठी, बफरिंग पॅरामीटर्ससाठी योग्य मूल्ये सेट करणे आवश्यक आहे, ज्यावर फ्लुएंड आउटपुट बफर पुरेसे आकाराचे असेल आणि त्याच वेळी वाटप केलेल्या वेळेत साफ करणे व्यवस्थापित करा.

हे लक्षात घेण्यासारखे आहे की खाली चर्चा केलेल्या पॅरामीटर्सची मूल्ये आउटपुट प्लगइनमध्ये बफरिंग वापरण्याच्या प्रत्येक विशिष्ट प्रकरणात वैयक्तिक आहेत, कारण ते बर्याच घटकांवर अवलंबून असतात: सेवांद्वारे लॉगवर संदेश लिहिण्याची तीव्रता, डिस्क सिस्टम कार्यप्रदर्शन, नेटवर्क चॅनेल लोड आणि त्याची बँडविड्थ. म्हणून, प्रत्येक वैयक्तिक केससाठी योग्य असलेल्या, परंतु अनावश्यक नसलेल्या बफर सेटिंग्ज प्राप्त करण्यासाठी, लांब शोध आंधळेपणाने टाळून, आपण ऑपरेशन दरम्यान फ्लुएंडने त्याच्या लॉगवर लिहिलेली डीबगिंग माहिती वापरू शकता आणि तुलनेने त्वरीत योग्य मूल्ये प्राप्त करू शकता.

समस्या रेकॉर्ड केल्याच्या वेळी, कॉन्फिगरेशन असे दिसत होते:

 <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 आकार chunk_limit_size 32 मेगाबाइट्सपेक्षा जास्त सेट केला असेल, तर ElasticSeacrh ते स्वीकारणार नाही, कारण येणारे पॅकेट खूप मोठे असेल. म्हणून, जर तुम्हाला बफर आणखी वाढवायचा असेल, तर कमाल रांगेची लांबी queue_limit_length वाढवणे चांगले.

जेव्हा बफर ओव्हरफ्लो होणे थांबते आणि फक्त टाइमआउट अपुरा संदेश शिल्लक राहतो, तेव्हा तुम्ही विनंती_टाइमआउट पॅरामीटर वाढवणे सुरू करू शकता. तथापि, तुम्ही मूल्य 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 पॅरामीटरने सेट केलेल्यापेक्षा जास्त वेळ लागला. ही डीबगिंग माहिती आहे आणि आम्ही विनंती_टाइमआउट पॅरामीटरचे मूल्य निवडताना त्याचा वापर करतो.

सामान्यीकृत निवड अल्गोरिदम खालीलप्रमाणे आहे:

1. रिक्वेस्ट_टाइमआउट आवश्यकतेपेक्षा जास्त असण्याची हमी दिलेल्या मूल्यावर सेट करा (शेकडो सेकंद). सेटअप दरम्यान, या पॅरामीटरच्या योग्य सेटिंगसाठी मुख्य निकष म्हणजे कालबाह्यतेच्या कमतरतेसाठी चेतावणी गायब होणे.
2. स्लो_फ्लश_लॉग_थ्रेशोल्ड थ्रेशोल्ड ओलांडल्याबद्दलच्या संदेशांची प्रतीक्षा करा. elapsed_time फील्डमधील चेतावणी मजकूर बफर साफ केल्याची वास्तविक वेळ दर्शवेल.
3. निरीक्षण कालावधी दरम्यान प्राप्त झालेल्या कमाल elapsed_time मूल्यापेक्षा अधिक मूल्यावर request_timeout सेट करा. आम्ही विनंती_कालबाह्य मूल्याची गणना elapsed_time + 50% म्हणून करतो.
4. लॉगमधून लांब बफर फ्लशबद्दल चेतावणी काढून टाकण्यासाठी, तुम्ही slow_flush_log_threshold चे मूल्य वाढवू शकता. आम्ही हे मूल्य elapsed_time + 25% म्हणून मोजतो.

या पॅरामीटर्सची अंतिम मूल्ये, आधी नमूद केल्याप्रमाणे, प्रत्येक केससाठी वैयक्तिकरित्या प्राप्त केली जातात. उपरोक्त अल्गोरिदमचे पालन केल्याने, आम्ही वारंवार संदेशाकडे नेणारी त्रुटी दूर करण्याची हमी देतो.

खालील सारणी दर्शविते की दररोज त्रुटींची संख्या, संदेशांची डुप्लिकेशन कशी होते, वर वर्णन केलेल्या पॅरामीटर्सची मूल्ये निवडण्याच्या प्रक्रियेत बदल होतो:

नोड-1
नोड-2
नोड-3
नोड-4

आधी नंतर
आधी नंतर
आधी नंतर
आधी नंतर

बफर फ्लश करण्यात अयशस्वी
1749/2
694/2
47/0
1121/2

पुन्हा प्रयत्न यशस्वी झाला
410/2
205/1
24/0
241/2

हे देखील लक्षात घेण्यासारखे आहे की परिणामी सेटिंग्ज त्यांची प्रासंगिकता गमावू शकतात कारण प्रकल्प वाढतो आणि त्यानुसार, लॉगची संख्या वाढते. अपुऱ्या कालबाह्यतेचे प्राथमिक लक्षण म्हणजे फ्लुएंट लॉगवर दीर्घ बफर फ्लशबद्दलचे संदेश परत येणे, म्हणजेच, स्लो_फ्लश_लॉग_थ्रेशोल्ड थ्रेशोल्ड ओलांडणे. या बिंदूपासून, विनंती_टाइमआउट पॅरामीटर ओलांडण्यापूर्वी अजूनही एक लहान फरक आहे, म्हणून या संदेशांना वेळेवर प्रतिसाद देणे आणि वर वर्णन केलेल्या इष्टतम सेटिंग्ज निवडण्याच्या प्रक्रियेची पुनरावृत्ती करणे आवश्यक आहे.

निष्कर्ष

Fluentd आउटपुट बफरचे फाइन-ट्यूनिंग हे EFK स्टॅक कॉन्फिगर करण्याच्या मुख्य टप्प्यांपैकी एक आहे, त्याच्या ऑपरेशनची स्थिरता आणि निर्देशांकांमध्ये कागदपत्रांची योग्य जागा निश्चित करणे. वर्णन केलेल्या कॉन्फिगरेशन अल्गोरिदमच्या आधारावर, तुम्ही खात्री बाळगू शकता की सर्व लॉग इलास्टिकसर्च इंडेक्समध्ये योग्य क्रमाने, पुनरावृत्ती किंवा तोटा न करता लिहिले जातील.

आमच्या ब्लॉगवरील इतर लेख देखील वाचा:

• जा आणि Zabbix 5.0 मित्र बनले
• डाउनटाइमशिवाय कुबर्नेट्स क्लस्टर अपग्रेड करणे
• कुबर्नेट्स: सिस्टम संसाधन व्यवस्थापन कॉन्फिगर करणे इतके महत्त्वाचे का आहे?
• डॉकर प्रतिमा संकुचित करण्यासाठी तीन सोप्या युक्त्या
• मोठ्या संख्येने विषम वेब प्रकल्पांचा बॅकअप

स्त्रोत: www.habr.com