Fluentd: किन यो आउटपुट बफर कन्फिगर गर्न महत्त्वपूर्ण छ

आजकल, ELK स्ट्याक बिना Kubernetes-आधारित परियोजनाको कल्पना गर्न असम्भव छ, जसले क्लस्टरको दुवै अनुप्रयोग र प्रणाली घटकहरूको लग बचत गर्दछ। हाम्रो अभ्यासमा, हामी Logstash को सट्टा Fluentd सँग EFK स्ट्याक प्रयोग गर्छौं।

Fluentd एक आधुनिक, विश्वव्यापी लग कलेक्टर हो जसले अधिक र अधिक लोकप्रियता प्राप्त गर्दैछ र क्लाउड नेटिभ कम्प्युटिङ फाउन्डेशनमा सामेल भएको छ, त्यसैले यसको विकास भेक्टर Kubernetes सँग संयोजनमा प्रयोगमा केन्द्रित छ।

Logstash को सट्टा Fluentd प्रयोग गर्ने तथ्यले सफ्टवेयर प्याकेजको सामान्य सारलाई परिवर्तन गर्दैन, तथापि, Fluentd यसको बहुमुखी प्रतिभाको परिणामस्वरूप यसको आफ्नै विशिष्ट बारीकियों द्वारा विशेषता हो।

उदाहरणका लागि, जब हामीले लगिङको उच्च तीव्रताको साथ व्यस्त परियोजनामा ​​EFK प्रयोग गर्न थाल्यौं, हामीले किबानामा केही सन्देशहरू धेरै पटक दोहोर्याइएको थियो भन्ने तथ्यको सामना गर्‍यौं। यस लेखमा हामी तपाईंलाई बताउनेछौं किन यो घटना हुन्छ र कसरी समस्या समाधान गर्ने।

कागजात नक्कलको समस्या

हाम्रा परियोजनाहरूमा, Fluentd लाई DaemonSet को रूपमा तैनाथ गरिएको छ (कुबर्नेट्स क्लस्टरको प्रत्येक नोडमा स्वचालित रूपमा सुरु हुन्छ) र /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"

यी चेतावनीहरू तब हुन्छन् जब 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 फिल्ड मानहरू प्रदान गर्दछ। सन्देशहरूको प्रतिलिपिहरू यसरी देखिन्छन्।

Kibana मा यो यस्तो देखिन्छ:

समस्या निवारण

यो समस्या समाधान गर्न धेरै विकल्पहरू छन्। ती मध्ये एउटा प्रत्येक कागजातको लागि एक अद्वितीय ह्यास उत्पन्न गर्नको लागि fluent-plugin-elasticsearch प्लगइनमा निर्मित संयन्त्र हो। यदि तपाइँ यो मेकानिजम प्रयोग गर्नुहुन्छ भने, ElasticSearch ले फर्वार्डिङ चरणमा पुनरावृत्तिहरू पहिचान गर्नेछ र डुप्लिकेट कागजातहरूलाई रोक्नेछ। तर हामीले ध्यानमा राख्नुपर्छ कि समस्या समाधान गर्ने यो विधिले अनुसन्धानको साथ संघर्ष गर्दछ र टाइमआउटको अभावमा त्रुटिलाई हटाउन सक्दैन, त्यसैले हामीले यसको प्रयोग त्याग्यौं।

छोटो अवधिको सञ्जाल समस्या वा लगिङ तीव्रता बढेको अवस्थामा लग हानि रोक्नको लागि हामी फ्लुएन्ट आउटपुटमा बफरिङ प्लगइन प्रयोग गर्छौं। यदि कुनै कारणले 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 साइज chunk_limit_size 32 मेगाबाइट भन्दा बढीमा सेट गर्नुभयो भने, तब ElasticSeacrh ले यसलाई स्वीकार गर्दैन, किनकि आगमन प्याकेट धेरै ठूलो हुनेछ। तसर्थ, यदि तपाईलाई बफर थप बढाउन आवश्यक छ भने, अधिकतम लाम लम्बाइ queue_limit_length बढाउनु राम्रो हुन्छ।

जब बफर ओभरफ्लो बन्द हुन्छ र टाइमआउट अपर्याप्त सन्देश मात्र रहन्छ, तपाईले अनुरोध_टाइमआउट प्यारामिटर बढाउन सुरु गर्न सक्नुहुन्छ। यद्यपि, यदि तपाईंले मानलाई २० सेकेन्डभन्दा बढीमा सेट गर्नुभयो भने, निम्न चेतावनीहरू 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. slow_flush_log_threshold थ्रेसहोल्ड नाघेको सन्देशहरूको लागि पर्खनुहोस्। elapsed_time फिल्डमा रहेको चेतावनी पाठले बफर खाली भएको वास्तविक समय देखाउनेछ।
3. अवलोकन अवधिमा प्राप्त अधिकतम बितेको_समय मान भन्दा ठूलो मानमा 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 लगमा लामो बफर फ्लशको बारेमा सन्देशहरू फर्काउनु हो, अर्थात्, slow_flush_log_threshold थ्रेसहोल्ड नाघेको। यस बिन्दुबाट, अनुरोध_टाइमआउट प्यारामिटर नाघ्नु अघि अझै पनि सानो मार्जिन छ, त्यसैले यी सन्देशहरूलाई समयमै प्रतिक्रिया दिन र माथि वर्णन गरिएको इष्टतम सेटिङहरू चयन गर्ने प्रक्रिया दोहोर्याउन आवश्यक छ।

निष्कर्षमा

Fluentd आउटपुट बफर फाइन-ट्यूनिंग EFK स्ट्याक कन्फिगर गर्ने मुख्य चरणहरू मध्ये एक हो, यसको सञ्चालनको स्थिरता र अनुक्रमणिकाहरूमा कागजातहरूको सही स्थान निर्धारण। वर्णन गरिएको कन्फिगरेसन एल्गोरिथ्मको आधारमा, तपाइँ निश्चित हुन सक्नुहुन्छ कि सबै लगहरू इलास्टिकसर्च अनुक्रमणिकामा सही क्रममा लेखिनेछन्, दोहोरिने वा हानि बिना।

हाम्रो ब्लगमा अन्य लेखहरू पनि पढ्नुहोस्:

• जानुहोस् र Zabbix 5.0 साथी बन्यो
• डाउनटाइम बिना Kubernetes क्लस्टर अपग्रेड गर्दै
• Kubernetes: किन यो प्रणाली संसाधन व्यवस्थापन सेट अप गर्न महत्त्वपूर्ण छ?
• डकर छविहरू संकुचित गर्न तीन सरल चालहरू
• विषम वेब परियोजनाहरूको ठूलो संख्याको ब्याकअप

स्रोत: www.habr.com