🥇Fluentd: आउटपुट बफ़र को कॉन्फ़िगर करना क्यों महत्वपूर्ण है

आजकल, ईएलके स्टैक के बिना कुबेरनेट्स-आधारित परियोजना की कल्पना करना असंभव है, जो क्लस्टर के अनुप्रयोगों और सिस्टम घटकों दोनों के लॉग को सहेजता है। हमारे अभ्यास में, हम लॉगस्टैश के बजाय फ्लुएंट के साथ ईएफके स्टैक का उपयोग करते हैं।

फ्लुएंट एक आधुनिक, सार्वभौमिक लॉग कलेक्टर है जो अधिक से अधिक लोकप्रियता प्राप्त कर रहा है और क्लाउड नेटिव कंप्यूटिंग फाउंडेशन में शामिल हो गया है, यही कारण है कि इसका विकास वेक्टर कुबेरनेट्स के साथ संयोजन में उपयोग पर केंद्रित है।

लॉगस्टैश के बजाय फ्लुएंट का उपयोग करने का तथ्य सॉफ्टवेयर पैकेज के सामान्य सार को नहीं बदलता है, हालांकि, फ्लुएंट को इसकी बहुमुखी प्रतिभा के परिणामस्वरूप अपनी विशिष्ट बारीकियों की विशेषता है।

उदाहरण के लिए, जब हमने लॉगिंग की उच्च तीव्रता वाले एक व्यस्त प्रोजेक्ट में ईएफके का उपयोग करना शुरू किया, तो हमें इस तथ्य का सामना करना पड़ा कि किबाना में कुछ संदेश कई बार बार-बार प्रदर्शित किए गए थे। इस लेख में हम आपको बताएंगे कि यह घटना क्यों होती है और समस्या का समाधान कैसे किया जाए।

दस्तावेज़ दोहराव की समस्या

हमारी परियोजनाओं में, फ्लुएंट को डेमॉनसेट के रूप में तैनात किया गया है (कुबेरनेट्स क्लस्टर के प्रत्येक नोड पर एक उदाहरण में स्वचालित रूप से लॉन्च किया गया है) और /var/log/कंटेनर्स में स्टडआउट कंटेनर लॉग की निगरानी करता है। संग्रह और प्रसंस्करण के बाद, JSON दस्तावेज़ों के रूप में लॉग को परियोजना के पैमाने और प्रदर्शन और दोष सहनशीलता की आवश्यकताओं के आधार पर क्लस्टर या स्टैंडअलोन रूप में उठाए गए 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"
  }
}

इसके अलावा, दो से अधिक दोहराव भी हो सकते हैं।

फ़्लुएंट लॉग में इस समस्या को ठीक करते समय, आप निम्नलिखित सामग्री के साथ बड़ी संख्या में चेतावनियाँ देख सकते हैं:

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 पैरामीटर द्वारा निर्दिष्ट समय के भीतर किसी अनुरोध का जवाब नहीं दे सकता है, यही कारण है कि अग्रेषित बफर खंड को साफ़ नहीं किया जा सकता है। इसके बाद, फ़्लुएंट बफर फ़्रैगमेंट को फिर से 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 फ़ील्ड मान प्रदान करता है। संदेशों की प्रतियां इस प्रकार दिखाई देती हैं.

किबाना में यह इस तरह दिखता है:

समाधान

इस समस्या को हल करने के लिए कई विकल्प हैं। उनमें से एक प्रत्येक दस्तावेज़ के लिए एक अद्वितीय हैश उत्पन्न करने के लिए फ़्लुएंट-प्लगइन-इलास्टिक्स खोज प्लगइन में निर्मित तंत्र है। यदि आप इस तंत्र का उपयोग करते हैं, तो 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>

समस्या को हल करते समय, निम्नलिखित मापदंडों के मान मैन्युअल रूप से चुने गए थे:
खंड_सीमा_आकार - खंडों का आकार जिसमें बफ़र में संदेश विभाजित होते हैं।

फ्लश_इंटरवल - समय अंतराल जिसके बाद बफर साफ़ हो जाता है।
क्यू_लिमिट_लेंथ - कतार में खंडों की अधिकतम संख्या।
request_timeout वह समय है जिसके लिए फ़्लुएंट और ElasticSearch के बीच संबंध स्थापित किया जाता है।

कुल बफ़र आकार की गणना पैरामीटर क्यू_लिमिट_लेंथ और चंक_लिमिट_साइज़ को गुणा करके की जा सकती है, जिसे "कतार में टुकड़ों की अधिकतम संख्या, जिनमें से प्रत्येक का एक दिया गया आकार है" के रूप में व्याख्या किया जा सकता है। यदि बफ़र आकार अपर्याप्त है, तो निम्न चेतावनी लॉग में दिखाई देगी:

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

इसका मतलब है कि बफ़र के पास आवंटित समय में साफ़ होने का समय नहीं है और पूर्ण बफ़र में प्रवेश करने वाला डेटा अवरुद्ध है, जिससे लॉग का हिस्सा नष्ट हो जाएगा।

आप बफ़र को दो तरीकों से बढ़ा सकते हैं: या तो कतार में प्रत्येक टुकड़े का आकार बढ़ाकर, या कतार में मौजूद टुकड़ों की संख्या बढ़ाकर।

यदि आप चंक आकार चंक_लिमिट_साइज को 32 मेगाबाइट से अधिक पर सेट करते हैं, तो ElasticSeacrh इसे स्वीकार नहीं करेगा, क्योंकि आने वाला पैकेट बहुत बड़ा होगा। इसलिए, यदि आपको बफ़र को और बढ़ाने की आवश्यकता है, तो अधिकतम कतार लंबाई क्यू_लिमिट_लेंथ को बढ़ाना बेहतर है।

जब बफ़र ओवरफ्लो होना बंद हो जाता है और केवल टाइमआउट अपर्याप्त संदेश रह जाता है, तो आप request_timeout पैरामीटर को बढ़ाना शुरू कर सकते हैं। हालाँकि, यदि आप मान को 20 सेकंड से अधिक पर सेट करते हैं, तो फ़्लुएंट लॉग में निम्नलिखित चेतावनियाँ दिखाई देने लगेंगी:

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"

यह संदेश किसी भी तरह से सिस्टम के संचालन को प्रभावित नहीं करता है और इसका मतलब है कि बफर फ्लश समय धीमे_फ्लश_लॉग_थ्रेशोल्ड पैरामीटर द्वारा निर्धारित से अधिक समय लेता है। यह डिबगिंग जानकारी है और हम इसका उपयोग request_timeout पैरामीटर का मान चुनते समय करते हैं।

सामान्यीकृत चयन एल्गोरिथ्म इस प्रकार है:

request_timeout को आवश्यकता से अधिक (सैकड़ों सेकंड) होने की गारंटी वाले मान पर सेट करें। सेटअप के दौरान, इस पैरामीटर की सही सेटिंग के लिए मुख्य मानदंड टाइमआउट की कमी के लिए चेतावनियों का गायब होना होगा।
Slow_flush_log_threshold सीमा से अधिक होने के बारे में संदेशों की प्रतीक्षा करें। elapsed_time फ़ील्ड में चेतावनी पाठ बफ़र साफ़ होने का वास्तविक समय दिखाएगा।
अवलोकन अवधि के दौरान प्राप्त अधिकतम elapsed_time मान से अधिक मान पर request_timeout सेट करें। हम request_timeout मान की गणना elapsed_time + 50% के रूप में करते हैं।
लॉग से लंबे बफ़र फ्लश के बारे में चेतावनियाँ हटाने के लिए, आप धीमे_फ्लश_लॉग_थ्रेशोल्ड का मान बढ़ा सकते हैं। हम इस मान की गणना elapsed_time + 25% के रूप में करते हैं।

इन मापदंडों के अंतिम मान, जैसा कि पहले उल्लेख किया गया है, प्रत्येक मामले के लिए व्यक्तिगत रूप से प्राप्त किए जाते हैं। उपरोक्त एल्गोरिदम का पालन करके, हम उस त्रुटि को खत्म करने की गारंटी देते हैं जिसके कारण बार-बार संदेश आते हैं।

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

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

के बाद से पहले
के बाद से पहले
के बाद से पहले
के बाद से पहले

बफ़र को फ्लश करने में विफल
1749/2
694/2
47/0
1121/2

पुनः प्रयास सफल हुआ
410/2
205/1
24/0
241/2

यह अतिरिक्त रूप से ध्यान देने योग्य है कि परिणामी सेटिंग्स परियोजना के बढ़ने के साथ-साथ अपनी प्रासंगिकता खो सकती हैं और, तदनुसार, लॉग की संख्या बढ़ जाती है। अपर्याप्त टाइमआउट का प्राथमिक संकेत फ्लुएंट लॉग में एक लंबे बफर फ्लश के बारे में संदेशों की वापसी है, जो कि धीमे_फ्लश_लॉग_थ्रेसहोल्ड सीमा से अधिक है। इस बिंदु से, request_timeout पैरामीटर पार होने से पहले अभी भी एक छोटा सा मार्जिन है, इसलिए इन संदेशों का समय पर जवाब देना और ऊपर वर्णित इष्टतम सेटिंग्स का चयन करने की प्रक्रिया को दोहराना आवश्यक है।

निष्कर्ष

फ्लुएंट आउटपुट बफर को फाइन-ट्यूनिंग ईएफके स्टैक को कॉन्फ़िगर करने, इसके संचालन की स्थिरता और इंडेक्स में दस्तावेजों के सही स्थान का निर्धारण करने के मुख्य चरणों में से एक है। वर्णित कॉन्फ़िगरेशन एल्गोरिदम के आधार पर, आप यह सुनिश्चित कर सकते हैं कि सभी लॉग बिना दोहराव या हानि के, सही क्रम में इलास्टिकसर्च इंडेक्स पर लिखे जाएंगे।

हमारे ब्लॉग पर अन्य लेख भी पढ़ें:

स्रोत: www.habr.com

फ्लुएंटडी: आउटपुट बफ़र को कॉन्फ़िगर करना क्यों महत्वपूर्ण है

दस्तावेज़ दोहराव की समस्या

समाधान

निष्कर्ष

हमारे ब्लॉग पर अन्य लेख भी पढ़ें:

एक टिप्पणी जोड़ें उत्तर रद्द