Fluentd: എന്തുകൊണ്ട് ഔട്ട്പുട്ട് ബഫർ കോൺഫിഗർ ചെയ്യേണ്ടത് പ്രധാനമാണ്

ഇക്കാലത്ത്, ELK സ്റ്റാക്ക് ഇല്ലാതെ ഒരു കുബർനെറ്റസ് അധിഷ്ഠിത പ്രോജക്റ്റ് സങ്കൽപ്പിക്കുക അസാധ്യമാണ്, ഇത് ക്ലസ്റ്ററിന്റെ ആപ്ലിക്കേഷനുകളുടെയും സിസ്റ്റം ഘടകങ്ങളുടെയും ലോഗുകൾ സംരക്ഷിക്കുന്നു. ഞങ്ങളുടെ പ്രയോഗത്തിൽ, Logstash-ന് പകരം Fluentd ഉള്ള EFK സ്റ്റാക്ക് ഉപയോഗിക്കുന്നു.

Fluentd ഒരു ആധുനികവും സാർവത്രികവുമായ ലോഗ് കളക്ടറാണ്, അത് കൂടുതൽ കൂടുതൽ ജനപ്രീതി നേടുകയും ക്ലൗഡ് നേറ്റീവ് കമ്പ്യൂട്ടിംഗ് ഫൗണ്ടേഷനിൽ ചേരുകയും ചെയ്തു, അതിനാലാണ് അതിന്റെ വികസന വെക്റ്റർ കുബർനെറ്റുമായി ചേർന്ന് ഉപയോഗത്തിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നത്.

Logstash-ന് പകരം Fluentd ഉപയോഗിക്കുന്നത് സോഫ്‌റ്റ്‌വെയർ പാക്കേജിന്റെ പൊതുവായ സത്തയെ മാറ്റില്ല, എന്നിരുന്നാലും, Fluentd-ന്റെ സവിശേഷത അതിന്റെ വൈവിധ്യത്തിന്റെ ഫലമായ പ്രത്യേക സൂക്ഷ്മതകളാണ്.

ഉദാഹരണത്തിന്, ലോഗിംഗിന്റെ ഉയർന്ന തീവ്രതയുള്ള തിരക്കേറിയ ഒരു പ്രോജക്റ്റിൽ ഞങ്ങൾ EFK ഉപയോഗിക്കാൻ തുടങ്ങിയപ്പോൾ, കിബാനയിൽ ചില സന്ദേശങ്ങൾ പലതവണ ആവർത്തിച്ച് പ്രദർശിപ്പിക്കുന്ന വസ്തുത ഞങ്ങൾ അഭിമുഖീകരിച്ചു. എന്തുകൊണ്ടാണ് ഈ പ്രതിഭാസം സംഭവിക്കുന്നതെന്നും പ്രശ്നം എങ്ങനെ പരിഹരിക്കാമെന്നും ഈ ലേഖനത്തിൽ ഞങ്ങൾ നിങ്ങളോട് പറയും.

ഡോക്യുമെന്റ് ഡ്യൂപ്ലിക്കേഷന്റെ പ്രശ്നം

ഞങ്ങളുടെ പ്രോജക്റ്റുകളിൽ, Fluentd ഒരു DaemonSet ആയി വിന്യസിച്ചിരിക്കുന്നു (കുബർനെറ്റസ് ക്ലസ്റ്ററിന്റെ ഓരോ നോഡിലും ഒരു സന്ദർഭത്തിൽ സ്വയമേവ സമാരംഭിക്കുന്നു) കൂടാതെ /var/log/containers-ൽ stdout കണ്ടെയ്‌നർ ലോഗുകൾ നിരീക്ഷിക്കുന്നു. ശേഖരണത്തിനും പ്രോസസ്സിംഗിനും ശേഷം, പ്രോജക്‌റ്റിന്റെ സ്കെയിലിനെയും പ്രകടനത്തിനും തെറ്റ് സഹിഷ്ണുതയ്‌ക്കുമുള്ള ആവശ്യകതകളെ ആശ്രയിച്ച്, JSON ഡോക്യുമെന്റുകളുടെ രൂപത്തിലുള്ള ലോഗുകൾ ക്ലസ്റ്ററിലോ ഒറ്റപ്പെട്ട രൂപത്തിലോ ഉയർത്തി ElasticSearch-ലേക്ക് അയയ്ക്കുന്നു. കിബാന ഗ്രാഫിക്കൽ ഇന്റർഫേസായി ഉപയോഗിക്കുന്നു.

ഒരു ഔട്ട്‌പുട്ട് ബഫറിംഗ് പ്ലഗിൻ ഉപയോഗിച്ച് 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"

എന്നിരുന്നാലും, കൈമാറ്റം ചെയ്യപ്പെട്ട ഓരോ ബഫർ ശകലങ്ങളെയും ഇലാസ്റ്റിക് സെർച്ച് അദ്വിതീയമായി കണക്കാക്കുകയും ഇൻഡെക്സിംഗ് സമയത്ത് അവയ്ക്ക് അദ്വിതീയമായ _id ഫീൽഡ് മൂല്യങ്ങൾ നൽകുകയും ചെയ്യുന്നു. ഇങ്ങനെയാണ് സന്ദേശങ്ങളുടെ പകർപ്പുകൾ പ്രത്യക്ഷപ്പെടുന്നത്.

കിബാനയിൽ ഇത് ഇതുപോലെ കാണപ്പെടുന്നു:

ട്രബിൾഷൂട്ട് ചെയ്യുന്നു

ഈ പ്രശ്നം പരിഹരിക്കാൻ നിരവധി ഓപ്ഷനുകൾ ഉണ്ട്. അവയിലൊന്നാണ് ഓരോ ഡോക്യുമെന്റിനും ഒരു തനതായ ഹാഷ് സൃഷ്‌ടിക്കുന്നതിന് ഫ്ലൂന്റ്-പ്ലഗിൻ-ഇലാസ്റ്റിക് സെർച്ച് പ്ലഗിനിൽ നിർമ്മിച്ചിരിക്കുന്ന സംവിധാനം. നിങ്ങൾ ഈ സംവിധാനം ഉപയോഗിക്കുകയാണെങ്കിൽ, ഫോർവേഡിംഗ് ഘട്ടത്തിൽ ഇലാസ്റ്റിക് സെർച്ച് ആവർത്തനങ്ങൾ തിരിച്ചറിയുകയും ഡ്യൂപ്ലിക്കേറ്റ് പ്രമാണങ്ങൾ തടയുകയും ചെയ്യും. എന്നാൽ പ്രശ്നം പരിഹരിക്കുന്നതിനുള്ള ഈ രീതി അന്വേഷണവുമായി മല്ലിടുന്നുവെന്നും സമയപരിധിയുടെ അഭാവത്തിൽ പിശക് ഇല്ലാതാക്കുന്നില്ലെന്നും ഞങ്ങൾ കണക്കിലെടുക്കണം, അതിനാൽ ഞങ്ങൾ അതിന്റെ ഉപയോഗം ഉപേക്ഷിച്ചു.

ഹ്രസ്വകാല നെറ്റ്‌വർക്ക് പ്രശ്‌നങ്ങളോ വർദ്ധിച്ച ലോഗ്ഗിംഗ് തീവ്രതയോ ഉണ്ടായാൽ ലോഗ് നഷ്‌ടമാകുന്നത് തടയാൻ ഞങ്ങൾ Fluentd ഔട്ട്‌പുട്ടിൽ ഒരു ബഫറിംഗ് പ്ലഗിൻ ഉപയോഗിക്കുന്നു. ചില കാരണങ്ങളാൽ ഇലാസ്റ്റിക് സെർച്ചിന് സൂചികയിലേക്ക് ഒരു പ്രമാണം തൽക്ഷണം എഴുതാൻ കഴിയുന്നില്ലെങ്കിൽ, ഡോക്യുമെന്റ് ക്യൂവിൽ നിർത്തി ഡിസ്കിൽ സൂക്ഷിക്കുന്നു. അതിനാൽ, ഞങ്ങളുടെ കാര്യത്തിൽ, മുകളിൽ വിവരിച്ച പിശകിലേക്ക് നയിക്കുന്ന പ്രശ്നത്തിന്റെ ഉറവിടം ഇല്ലാതാക്കുന്നതിന്, ബഫറിംഗ് പാരാമീറ്ററുകൾക്കായി ശരിയായ മൂല്യങ്ങൾ സജ്ജീകരിക്കേണ്ടത് ആവശ്യമാണ്, അതിൽ 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 അത് സ്വീകരിക്കില്ല. അതിനാൽ, നിങ്ങൾക്ക് ബഫർ ഇനിയും വർദ്ധിപ്പിക്കണമെങ്കിൽ, പരമാവധി ക്യൂ ദൈർഘ്യം ക്യൂ_ലിമിറ്റ്_ലെങ്ത് വർദ്ധിപ്പിക്കുന്നതാണ് നല്ലത്.

ബഫർ ഓവർഫ്ലോ ചെയ്യുന്നത് നിർത്തുകയും ടൈംഔട്ട് അപര്യാപ്തമായ സന്ദേശം മാത്രം അവശേഷിക്കുകയും ചെയ്യുമ്പോൾ, നിങ്ങൾക്ക് 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" 

ഈ സന്ദേശം സിസ്റ്റത്തിന്റെ പ്രവർത്തനത്തെ ഒരു തരത്തിലും ബാധിക്കില്ല, ഒപ്പം സ്ലോ_ഫ്ലഷ്_ലോഗ്_ത്രെഷോൾഡ് പാരാമീറ്റർ സജ്ജമാക്കിയതിനേക്കാൾ കൂടുതൽ സമയം ബഫർ ഫ്ലഷ് സമയമെടുത്തു എന്നാണ് അർത്ഥമാക്കുന്നത്. ഇത് ഡീബഗ്ഗിംഗ് വിവരമാണ്, request_timeout പാരാമീറ്ററിന്റെ മൂല്യം തിരഞ്ഞെടുക്കുമ്പോൾ ഞങ്ങൾ ഇത് ഉപയോഗിക്കുന്നു.

പൊതുവായ തിരഞ്ഞെടുക്കൽ അൽഗോരിതം ഇപ്രകാരമാണ്:

1. റിക്വസ്റ്റ്_ടൈംഔട്ട് ആവശ്യത്തേക്കാൾ വലുതാണെന്ന് ഉറപ്പുനൽകുന്ന മൂല്യത്തിലേക്ക് സജ്ജമാക്കുക (നൂറുകണക്കിന് സെക്കൻഡ്). സജ്ജീകരണ സമയത്ത്, ഈ പരാമീറ്ററിന്റെ ശരിയായ ക്രമീകരണത്തിനുള്ള പ്രധാന മാനദണ്ഡം സമയപരിധിയുടെ അഭാവത്തിനായുള്ള മുന്നറിയിപ്പുകൾ അപ്രത്യക്ഷമാകും.
2. slow_flush_log_threshold ത്രെഷോൾഡ് കവിയുന്നതിനെക്കുറിച്ചുള്ള സന്ദേശങ്ങൾക്കായി കാത്തിരിക്കുക. elapsed_time ഫീൽഡിലെ മുന്നറിയിപ്പ് വാചകം, ബഫർ മായ്‌ച്ച യഥാർത്ഥ സമയം കാണിക്കും.
3. നിരീക്ഷണ കാലയളവിൽ ലഭിച്ച പരമാവധി elapsed_time മൂല്യത്തേക്കാൾ വലിയ മൂല്യത്തിലേക്ക് request_timeout സജ്ജമാക്കുക. ഞങ്ങൾ request_timeout മൂല്യം elapsed_time + 50% ആയി കണക്കാക്കുന്നു.
4. ലോംഗ് ബഫർ ഫ്ലഷുകളെക്കുറിച്ചുള്ള മുന്നറിയിപ്പുകൾ ലോഗിൽ നിന്ന് നീക്കം ചെയ്യാൻ, സ്ലോ_ഫ്ലഷ്_ലോഗ്_ത്രഷോൾഡിന്റെ മൂല്യം ഉയർത്താം. ഞങ്ങൾ ഈ മൂല്യം elapsed_time + 25% ആയി കണക്കാക്കുന്നു.

ഈ പരാമീറ്ററുകളുടെ അന്തിമ മൂല്യങ്ങൾ, നേരത്തെ സൂചിപ്പിച്ചതുപോലെ, ഓരോ കേസിനും വ്യക്തിഗതമായി ലഭിക്കുന്നു. മുകളിലുള്ള അൽഗോരിതം പിന്തുടരുന്നതിലൂടെ, ആവർത്തിച്ചുള്ള സന്ദേശങ്ങളിലേക്ക് നയിക്കുന്ന പിശക് ഇല്ലാതാക്കാൻ ഞങ്ങൾക്ക് ഉറപ്പുണ്ട്.

ദിവസേനയുള്ള പിശകുകളുടെ എണ്ണം, സന്ദേശങ്ങളുടെ തനിപ്പകർപ്പിലേക്ക് നയിക്കുന്നത്, മുകളിൽ വിവരിച്ച പാരാമീറ്ററുകളുടെ മൂല്യങ്ങൾ തിരഞ്ഞെടുക്കുന്ന പ്രക്രിയയിൽ എങ്ങനെ മാറുന്നുവെന്ന് ചുവടെയുള്ള പട്ടിക കാണിക്കുന്നു:

നോഡ്-1
നോഡ്-2
നോഡ്-3
നോഡ്-4

മുമ്പ് ശേഷം
മുമ്പ് ശേഷം
മുമ്പ് ശേഷം
മുമ്പ് ശേഷം

ബഫർ ഫ്ലഷ് ചെയ്യുന്നതിൽ പരാജയപ്പെട്ടു
1749/2
694/2
47/0
1121/2

വീണ്ടും ശ്രമം വിജയിച്ചു
410/2
205/1
24/0
241/2

പ്രോജക്റ്റ് വളരുന്നതിനനുസരിച്ച് തത്ഫലമായുണ്ടാകുന്ന ക്രമീകരണങ്ങൾക്ക് അവയുടെ പ്രസക്തി നഷ്‌ടപ്പെടാമെന്നതും അതിനനുസരിച്ച് ലോഗുകളുടെ എണ്ണം വർദ്ധിക്കുന്നതും ശ്രദ്ധിക്കേണ്ടതാണ്. ദൈർഘ്യമേറിയ ബഫർ ഫ്ലഷിനെക്കുറിച്ചുള്ള സന്ദേശങ്ങൾ Fluentd ലോഗിലേക്ക് മടങ്ങുന്നതാണ്, അതായത് സ്ലോ_ഫ്ലഷ്_ലോഗ്_ത്രെഷോൾഡ് ത്രെഷോൾഡ് ത്രെഷോൾഡ് കവിയുന്നതാണ് അപര്യാപ്തമായ സമയപരിധിയുടെ പ്രാഥമിക അടയാളം. ഈ ഘട്ടം മുതൽ, request_timeout പാരാമീറ്റർ കവിയുന്നതിന് മുമ്പായി ഇപ്പോഴും ഒരു ചെറിയ മാർജിൻ ഉണ്ട്, അതിനാൽ ഈ സന്ദേശങ്ങളോട് സമയബന്ധിതമായി പ്രതികരിക്കുകയും മുകളിൽ വിവരിച്ച ഒപ്റ്റിമൽ ക്രമീകരണങ്ങൾ തിരഞ്ഞെടുക്കുന്ന പ്രക്രിയ ആവർത്തിക്കുകയും ചെയ്യേണ്ടത് ആവശ്യമാണ്.

തീരുമാനം

Fluentd ഔട്ട്‌പുട്ട് ബഫർ ഫൈൻ-ട്യൂണുചെയ്യുന്നത് EFK സ്റ്റാക്ക് കോൺഫിഗർ ചെയ്യുന്നതിന്റെ പ്രധാന ഘട്ടങ്ങളിലൊന്നാണ്, അതിന്റെ പ്രവർത്തനത്തിന്റെ സ്ഥിരതയും സൂചികകളിലെ പ്രമാണങ്ങളുടെ ശരിയായ സ്ഥാനവും നിർണ്ണയിക്കുന്നു. വിവരിച്ച കോൺഫിഗറേഷൻ അൽഗോരിതം അടിസ്ഥാനമാക്കി, ആവർത്തനങ്ങളോ നഷ്ടങ്ങളോ ഇല്ലാതെ എല്ലാ ലോഗുകളും ശരിയായ ക്രമത്തിൽ ഇലാസ്റ്റിക് സെർച്ച് സൂചികയിലേക്ക് എഴുതുമെന്ന് നിങ്ങൾക്ക് ഉറപ്പിക്കാം.

ഞങ്ങളുടെ ബ്ലോഗിലെ മറ്റ് ലേഖനങ്ങളും വായിക്കുക:

• Go and Zabbix 5.0 സുഹൃത്തുക്കളായി
• പ്രവർത്തനരഹിതമായ ഒരു കുബർനെറ്റസ് ക്ലസ്റ്റർ അപ്‌ഗ്രേഡുചെയ്യുന്നു
• കുബെർനെറ്റസ്: സിസ്റ്റം റിസോഴ്‌സ് മാനേജ്‌മെന്റ് കോൺഫിഗർ ചെയ്യേണ്ടത് എന്തുകൊണ്ട്?
• ഡോക്കർ ഇമേജുകൾ ചുരുക്കുന്നതിനുള്ള മൂന്ന് ലളിതമായ തന്ത്രങ്ങൾ
• ധാരാളം വൈവിധ്യമാർന്ന വെബ് പ്രോജക്റ്റുകളുടെ ബാക്കപ്പ്

അവലംബം: www.habr.com