ProHoster > blog > Amministrazzjoni > Fluentd: Għaliex huwa importanti li jiġi kkonfigurat il-buffer tal-output

Fluentd: Għaliex huwa importanti li jiġi kkonfigurat il-buffer tal-output

Fluentd: Għaliex huwa importanti li jiġi kkonfigurat il-buffer tal-output

Illum il-ġurnata, huwa impossibbli li wieħed jimmaġina proġett ibbażat fuq Kubernetes mingħajr il-munzell ELK, li jiffranka zkuk kemm tal-applikazzjonijiet kif ukoll tal-komponenti tas-sistema tal-cluster. Fil-prattika tagħna, nużaw il-munzell EFK ma 'Fluentd minflok Logstash.

Fluentd huwa kollettur ta 'zkuk modern u universali li qed jikseb aktar u aktar popolarità u ngħaqad mal-Cloud Native Computing Foundation, u huwa għalhekk li l-vettur tal-iżvilupp tiegħu huwa ffukat fuq l-użu flimkien ma' Kubernetes.

Il-fatt li tuża Fluentd minflok Logstash ma jbiddilx l-essenza ġenerali tal-pakkett tas-softwer, madankollu, Fluentd huwa kkaratterizzat minn sfumaturi speċifiċi tiegħu stess li jirriżultaw mill-versatilità tiegħu.

Pereżempju, meta bdejna nużaw l-EFK fi proġett impenjattiv b'intensità għolja ta 'logging, konna ffaċċjati bil-fatt li f'Kibana xi messaġġi ġew murija ripetutament diversi drabi. F'dan l-artikolu aħna ngħidulek għaliex dan il-fenomenu jseħħ u kif issolvi l-problema.

Il-problema tad-duplikazzjoni tad-dokumenti

Fil-proġetti tagħna, Fluentd huwa skjerat bħala DaemonSet (imniedi awtomatikament f'istanza waħda fuq kull nodu tal-cluster Kubernetes) u jimmonitorja z-zkuk tal-kontenituri stdout f'/var/log/containers. Wara l-ġbir u l-ipproċessar, ir-zkuk fil-forma ta 'dokumenti JSON jintbagħtu lil ElasticSearch, imqajma f'forma ta' cluster jew waħedha, skont l-iskala tal-proġett u r-rekwiżiti għall-prestazzjoni u t-tolleranza tal-ħsarat. Kibana jintuża bħala l-interface grafika.

Meta użaw Fluentd ma 'plugin tal-buffering tal-output, iltqajna ma' sitwazzjoni fejn xi dokumenti f'ElasticSearch kellhom eżattament l-istess kontenut u kienu differenti biss fl-identifikatur. Tista 'tivverifika li din hija ripetizzjoni ta' messaġġ billi tuża l-log Nginx bħala eżempju. Fil-log file, dan il-messaġġ jeżisti f'kopja waħda:

127.0.0.1 192.168.0.1 - [28/Feb/2013:12:00:00 +0900] "GET / HTTP/1.1" 200 777 "-" "Opera/12.0" -

Madankollu, hemm diversi dokumenti f'ElasticSearch li fihom dan il-messaġġ:

{
  "_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"
  }
}

Barra minn hekk, jista 'jkun hemm aktar minn żewġ repetizzjonijiet.

Waqt li tirranġa din il-problema fir-reġistri Fluentd, tista' tara numru kbir ta' twissijiet bil-kontenut li ġej:

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"

Dawn it-twissijiet iseħħu meta ElasticSearch ma jistax jirritorna tweġiba għal talba fiż-żmien speċifikat mill-parametru request_timeout, u huwa għalhekk li l-framment tal-buffer mibgħut ma jistax jiġi kklerjat. Wara dan, Fluentd jipprova jibgħat il-framment tal-buffer lil ElasticSearch għal darb'oħra u wara numru arbitrarju ta' tentattivi, l-operazzjoni titlesta b'suċċess:

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"

Madankollu, ElasticSearch jittratta kull wieħed mill-frammenti tal-buffer trasferiti bħala uniku u jassenjahom valuri tal-qasam _id uniċi waqt l-indiċjar. Hekk jidhru kopji tal-messaġġi.

F'Kibana jidher bħal dan:

Fluentd: Għaliex huwa importanti li jiġi kkonfigurat il-buffer tal-output

Is-soluzzjoni

Hemm diversi għażliet biex issolvi din il-problema. Wieħed minnhom huwa l-mekkaniżmu mibni fil-plugin fluent-plugin-elasticsearch biex jiġġenera hash uniku għal kull dokument. Jekk tuża dan il-mekkaniżmu, ElasticSearch jirrikonoxxi repetizzjonijiet fl-istadju ta' trażmissjoni u jipprevjeni dokumenti duplikati. Iżda rridu nqisu li dan il-metodu ta 'soluzzjoni tal-problema tissielet mal-investigazzjoni u ma jeliminax l-iżball b'nuqqas ta' timeout, għalhekk abbandunajna l-użu tiegħu.

Aħna nużaw plugin buffering fuq l-output Fluentd biex nipprevjenu t-telf ta 'log fil-każ ta' problemi tan-netwerk għal żmien qasir jew żieda fl-intensità tal-qtugħ. Jekk għal xi raġuni ElasticSearch ma jistax jikteb dokument istantanjament fl-indiċi, id-dokument jitqiegħed fil-kju u jinħażen fuq disk. Għalhekk, fil-każ tagħna, sabiex jiġi eliminat is-sors tal-problema li jwassal għall-iżball deskritt hawn fuq, huwa meħtieġ li jiġu stabbiliti l-valuri korretti għall-parametri tal-buffering, li fihom il-buffer tal-ħruġ Fluentd ikun ta 'daqs suffiċjenti u fl-istess ħin jirnexxielhom jiġu kklerjati fil-ħin allokat.

Ta 'min jinnota li l-valuri tal-parametri diskussi hawn taħt huma individwali f'kull każ speċifiku ta' użu ta 'buffering fil-plugins tal-output, peress li jiddependu minn ħafna fatturi: l-intensità tal-kitba ta' messaġġi fil-log permezz ta 'servizzi, prestazzjoni tas-sistema tad-disk, netwerk. tagħbija tal-kanal u bandwidth tagħha. Għalhekk, sabiex tikseb settings tal-buffer li huma adattati għal kull każ individwali, iżda mhux żejda, tevita tfittxijiet twal bl-addoċċ, tista 'tuża l-informazzjoni ta' debugging li Fluentd jikteb fil-log tiegħu waqt it-tħaddim u relattivament malajr tikseb il-valuri korretti.

Fiż-żmien li ġiet irreġistrata l-problema, il-konfigurazzjoni kienet tidher bħal din:

 <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>

Meta ssolviet il-problema, il-valuri tal-parametri li ġejjin ġew magħżula manwalment:
chunk_limit_size — id-daqs tal-biċċiet li fihom huma maqsuma l-messaġġi fil-buffer.

  • flush_interval — intervall ta' ħin li warajh il-buffer jitneħħa.
  • queue_limit_length — in-numru massimu ta' biċċiet fil-kju.
  • request_timeout huwa l-ħin li għalih tiġi stabbilita l-konnessjoni bejn Fluentd u ElasticSearch.

Id-daqs totali tal-buffer jista 'jiġi kkalkulat billi jiġu mmultiplikati l-parametri queue_limit_length u chunk_limit_size, li jistgħu jiġu interpretati bħala "in-numru massimu ta' biċċiet fil-kju, li kull wieħed minnhom għandu daqs partikolari." Jekk id-daqs tal-buffer ma jkunx biżżejjed, it-twissija li ġejja tidher fir-reġistru:

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

Ifisser li l-buffer m'għandux ħin biex jiġi kklerjat fiż-żmien allokat u d-dejta li tidħol fil-buffer sħiħ hija mblukkata, li twassal għat-telf ta 'parti mir-zkuk.

Tista 'żżid il-buffer b'żewġ modi: billi żżid jew id-daqs ta' kull biċċa fil-kju, jew in-numru ta 'biċċiet li jistgħu jkunu fil-kju.

Jekk issettja d-daqs tal-biċċa chunk_limit_size għal aktar minn 32 megabytes, allura ElasticSeacrh ma jaċċettahx, peress li l-pakkett li jkun dieħel ikun kbir wisq. Għalhekk, jekk għandek bżonn iżżid aktar il-buffer, huwa aħjar li żżid it-tul massimu tal-kju queue_limit_length.

Meta l-buffer jieqaf ifur u jibqa' biss il-messaġġ ta' timeout insuffiċjenti, tista' tibda żżid il-parametru request_timeout. Madankollu, jekk issettja l-valur għal aktar minn 20 sekonda, it-twissijiet li ġejjin jibdew jidhru fir-reġistri 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"

Dan il-messaġġ ma jaffettwa l-operat tas-sistema bl-ebda mod u jfisser li l-ħin tal-flushing tal-buffer ħa aktar minn dak stabbilit mill-parametru slow_flush_log_threshold. Din hija informazzjoni ta' debugging u nużawha meta nagħżlu l-valur tal-parametru request_timeout.

L-algoritmu tal-għażla ġeneralizzat huwa kif ġej:

  1. Issettja request_timeout għal valur garantit li jkun akbar milli meħtieġ (mijiet ta' sekondi). Matul is-setup, il-kriterju ewlieni għall-issettjar korrett ta 'dan il-parametru se jkun l-għajbien ta' twissijiet għal nuqqas ta 'timeout.
  2. Stenna għal messaġġi dwar il-qbiż tal-limitu slow_flush_log_threshold. It-test ta' twissija fil-qasam elapsed_time se juri l-ħin reali li fih il-buffer ġie mneħħi.
  3. Issettja request_timeout għal valur akbar mill-valur massimu elapsed_time miksub matul il-perjodu ta' osservazzjoni. Aħna nikkalkulaw il-valur request_timeout bħala elapsed_time + 50%.
  4. Biex tneħħi t-twissijiet dwar il-buffer flushes twal mil-log, tista 'tgħolli l-valur ta' slow_flush_log_threshold. Aħna nikkalkulaw dan il-valur bħala elapsed_time + 25%.

Il-valuri finali ta 'dawn il-parametri, kif innutat qabel, jinkisbu individwalment għal kull każ. Billi ssegwi l-algoritmu ta 'hawn fuq, aħna ggarantiti li neliminaw l-iżball li jwassal għal messaġġi ripetuti.

It-tabella hawn taħt turi kif in-numru ta 'żbalji kuljum, li jwassal għal duplikazzjoni ta' messaġġi, jinbidel fil-proċess tal-għażla tal-valuri tal-parametri deskritti hawn fuq:

nodu-1
nodu-2
nodu-3
nodu-4

Qabel wara
Qabel wara
Qabel wara
Qabel wara

naqas milli jiflaħ il-buffer
1749/2
694/2
47/0
1121/2

ipprova mill-ġdid irnexxielu
410/2
205/1
24/0
241/2

Ta 'min jinnota wkoll li s-settings li jirriżultaw jistgħu jitilfu r-rilevanza tagħhom hekk kif il-proġett jikber u, għaldaqstant, in-numru ta' zkuk jiżdied. Is-sinjal primarju ta' timeout insuffiċjenti huwa r-ritorn ta' messaġġi dwar buffer flush twil fil-log Fluentd, jiġifieri, jaqbeż il-limitu slow_flush_log_threshold. Minn dan il-punt 'il quddiem, għad hemm marġni żgħir qabel ma jinqabeż il-parametru request_timeout, għalhekk huwa meħtieġ li tirrispondi għal dawn il-messaġġi fil-ħin u rrepeti l-proċess tal-għażla tal-aħjar settings deskritti hawn fuq.

Konklużjoni

L-irfinar tal-buffer tal-ħruġ Fluentd huwa wieħed mill-istadji ewlenin tal-konfigurazzjoni tal-munzell EFK, li jiddetermina l-istabbiltà tat-tħaddim tiegħu u t-tqegħid korrett tad-dokumenti fl-indiċi. Ibbażat fuq l-algoritmu ta 'konfigurazzjoni deskritt, tista' tkun ċert li r-zkuk kollha se jinkitbu fl-indiċi ElasticSearch fl-ordni korretta, mingħajr ripetizzjonijiet jew telf.

Aqra wkoll artikli oħra fuq il-blog tagħna:

Sors: www.habr.com

Żid kumment