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"

આ ચેતવણીઓ ત્યારે થાય છે જ્યારે ElasticSearch વિનંતી_ટાઇમઆઉટ પરિમાણ દ્વારા ઉલ્લેખિત સમયની અંદર વિનંતીનો પ્રતિસાદ પરત કરી શકતું નથી, તેથી જ ફોરવર્ડ કરેલ બફર ફ્રેગમેન્ટને સાફ કરી શકાતું નથી. આ પછી, 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"

જો કે, ઇલાસ્ટીક સર્ચ દરેક ટ્રાન્સફર કરેલ બફર ટુકડાઓને અનન્ય માને છે અને અનુક્રમણિકા દરમિયાન તેમને અનન્ય _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

તેનો અર્થ એ છે કે ફાળવેલ સમયમાં બફરને સાફ કરવાનો સમય નથી અને સંપૂર્ણ બફરમાં પ્રવેશતો ડેટા અવરોધિત છે, જે લોગના ભાગને ગુમાવવા તરફ દોરી જશે.

તમે બફરને બે રીતે વધારી શકો છો: કાં તો કતારમાંના દરેક ભાગનું કદ વધારીને અથવા કતારમાં હોઈ શકે તેવા ભાગોની સંખ્યા વધારીને.

જો તમે 32 મેગાબાઇટ્સ કરતાં વધુ chunk_limit_size chunk size chunk_limit_size સેટ કરો છો, તો 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" 

આ સંદેશ કોઈપણ રીતે સિસ્ટમના સંચાલનને અસર કરતું નથી અને તેનો અર્થ એ છે કે બફર ફ્લશિંગ સમય ધીમા_ફ્લશ_લોગ_થ્રેશોલ્ડ પેરામીટર દ્વારા સેટ કરતાં વધુ સમય લે છે. આ ડીબગીંગ માહિતી છે અને અમે વિનંતી_ટાઇમઆઉટ પેરામીટરની કિંમત પસંદ કરતી વખતે તેનો ઉપયોગ કરીએ છીએ.

સામાન્યકૃત પસંદગી અલ્ગોરિધમ નીચે મુજબ છે:

1. રિક્વેસ્ટ_ટાઇમઆઉટને જરૂરી કરતાં વધુ (સેંકડો સેકંડ)ની ખાતરી આપેલ મૂલ્ય પર સેટ કરો. સેટઅપ દરમિયાન, આ પરિમાણના યોગ્ય સેટિંગ માટેનો મુખ્ય માપદંડ સમયસમાપ્તિના અભાવ માટે ચેતવણીઓનું અદ્રશ્ય હશે.
2. ધીમા_ફ્લશ_લોગ_થ્રેશોલ્ડ થ્રેશોલ્ડને ઓળંગવા વિશેના સંદેશાની રાહ જુઓ. વીતેલા_સમય ફીલ્ડમાં ચેતવણીનો ટેક્સ્ટ બફરને સાફ કરવાનો વાસ્તવિક સમય બતાવશે.
3. વિનંતી_સમય સમાપ્તિને અવલોકન સમયગાળા દરમિયાન મેળવેલા મહત્તમ વીતેલા_સમય મૂલ્ય કરતાં વધુ મૂલ્ય પર સેટ કરો. અમે વિનંતી_સમય સમાપ્તિ મૂલ્યની ગણતરી વીતેલા_સમય + 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 આઉટપુટ બફરને ફાઇન-ટ્યુનિંગ એ EFK સ્ટેકને ગોઠવવાના મુખ્ય તબક્કાઓમાંનું એક છે, તેની કામગીરીની સ્થિરતા અને અનુક્રમણિકાઓમાં દસ્તાવેજોનું યોગ્ય સ્થાન નક્કી કરવું. વર્ણવેલ રૂપરેખાંકન અલ્ગોરિધમના આધારે, તમે ખાતરી કરી શકો છો કે બધા લોગ પુનરાવર્તન અથવા નુકસાન વિના, યોગ્ય ક્રમમાં સ્થિતિસ્થાપક શોધ અનુક્રમણિકા પર લખવામાં આવશે.

અમારા બ્લોગ પર અન્ય લેખો પણ વાંચો:

• જાઓ અને Zabbix 5.0 મિત્રો બન્યા
• ડાઉનટાઇમ વિના કુબરનેટ્સ ક્લસ્ટરને અપગ્રેડ કરવું
• કુબરનેટ્સ: સિસ્ટમ રિસોર્સ મેનેજમેન્ટને ગોઠવવું શા માટે એટલું મહત્વપૂર્ણ છે?
• ડોકર છબીઓને સંકોચવાની ત્રણ સરળ યુક્તિઓ
• મોટી સંખ્યામાં વિજાતીય વેબ પ્રોજેક્ટ્સનો બેકઅપ

સોર્સ: www.habr.com