🥇Fluentd: miks on oluline seadistada väljundpuhver

Tänapäeval on võimatu ette kujutada Kubernetesel põhinevat projekti ilma ELK tech-stackita, millega salvestatakse logid nii rakendustest kui ka klastrikomponentide süsteemidest. Oma praktikas kasutame me EFK stacki, asendades Logstashiga Fluentdi.

Fluentd on kaasaegne universaalne logikogumise tööriist, mis muutub üha populaarsemaks ja on liitunud Cloud Native Computing Foundationiga, mistõttu on selle arenduse suund suunatud koostööle Kubernetesega.

Fakt, et kasutame Fluentdi Logstash'i asemel, ei muuda programmi kompleksiosaduse üldiselt, kuid Fluentdi'l on siiski omad spetsiifilised nüansid, mis tulenevad tema mitmekesistest funktsioonidest.

Näiteks, kui hakkasime EFK't kasutama suure koormusega projektis, kus logide kirjutamise intensiivsus on kõrge, siis kohtasime Kibanas olukorda, kus mõned sõnumid kuvatakse mitu korda. Käesolevas artiklis selgitame teile, miks see nähtus toimub ja kuidas probleemi lahendada.

Dokumentide dubleerimise probleem

Meie projektides on Fluentd kasutusel kui DaemonSet (automaatselt käivitatakse igas sõlmes Kubernetes klastris) ning jälgib konteinerite stdout logisid aadressil /var/log/containers. Pärast kogumist ja töötlemist saadetakse logid JSON-dokumentidena ElasticSearch'i, mis on üles tõstetud kas klastris või iseseisvas režiimis, sõltuvalt projekti mahust ja toimivuse ja talitlushäirete nõuetest. Graafilise liidese jaoks kasutatakse Kibana't.

Fluentdi kasutamisel väljundpuffri plugiga seisime silmitsi olukorraga, kus mõned dokumendid ElasticSearch'is sisaldavad täiesti sama sisu ja erinevad vaid identifikaatori poolest. Veenduda, et see on tõepoolest sõnumite duplikaat, saab Nginxi logi näitele toetudes. Logifailis esindab see sõnum ennast ainus eksemplaris:

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

Kuid ElasticSearch'is on mitu dokumenti, mis sisaldavad seda sõnumit:

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

Kuid kordusi võib olla rohkem kui kaks.

Fluentd logides selle probleemi fikseerimise ajal on palju järgmise sisuga hoiatuseid:

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"

Need hoiatused tekivad siis, kui ElasticSearch ei suuda vastata päringule seadistatud request_timeout aja jooksul, mistõttu edastatav puhvri fragment ei saa kustutada. Pärast seda üritab Fluentd saata puhvri fragmendi ElasticSearchile uuesti ja pärast arbitraarset arvu katseid operation lõpuks õnnestub:

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"

Siiski, ElasticSearch käsitleb iga edastatud puhvri fragmenti unikaalsena ja määrab neile unikaalsed _id väljad indekseerimise ajal. Niisiis tekivadki sõnumite koopiad.

Kibanas näeb see välja nii:

Probleemi lahendus

On olemas mitu võimalust selle probleemi lahendamiseks. Üks neist on pluginasse fluent-plugin-elasticsearch integreeritud mehhanism, mis genereerib iga dokumendi jaoks unikaalse hash'i. Kui seda mehhanismi kasutada, tuvastab ElasticSearch dublikaadid edastamise etapis ja ei luba dokumentide dubleerimist. Kuid tuleb arvestada, et see probleemilahendus tegeleb sümptomite, mitte põhjuse, lahendamisega, mistõttu loobusime selle kasutamisest.

Kasutame Fluentd väljundis puhverdamise plugina, et vältida logide kadumist lühiajaliste võrguhäirete või suurenenud logimistintensiivsuse korral. Kui mingil põhjusel ei saa ElasticSearch dokumenti indeksi koheselt salvestada, satub dokument järjekorda, mis salvestatakse kettale. Seetõttu tuleb meie olukorras selle probleemi põhjuse kõrvaldamiseks määrata õiged puhverdamise parameetrite väärtused, mille korral on Fluentd väljundpuhver piisava suurusega ja suudab end samas ettenähtud ajaks puhastada.

Tuleb märkida, et allpool käsitletud parameetrite väärtused on iga konkreetse puhverdamise kasutusjuhtumi puhul individuaalsed, kuna need sõltuvad paljusid teguritest: teenuste logisõnumite salvestamise intensiivsusest, ketta süsteemi sooritusvõimest, võrgu koormatusest ja selle läbilaskevõimest. Seetõttu, et saada igale individuaalsele juhtumile sobivad, kuid mitte ülemäärased puhverdusseaded, vältides pikaajalist pimedat katsetamist, võib kasutada silumisinfot, mida Fluentd töö käigus oma logisse kirjutab ja suhteliselt kiiresti õigeid väärtusi saada.

Probleemi fikseerimise hetkel nägi konfiguratsioon välja järgmine:

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

Probleemi lahendamisel valiti käsitsi järgmiste parameetrite väärtused:
chunk_limit_size — chunk'ide suurus, milleks jagatakse sõnumid puhveres.

flush_interval — ajavahemik, mille jooksul puhastatakse puhver.
queue_limit_length — maksimaalne chunkide arv järjekorras.
request_timeout — aeg, mille jooksul luuakse ühendus Fluentd ja ElasticSearch'i vahel.

Puhvri kogusuurus arvutatakse, korrutades queue_limit_length ja chunk_limit_size, mida võib tõlgendada kui "maksimaalne chunkide arv järjekorras, igaühel on määratud maht". Kui puhversuure ei ole piisav, ilmub logides järgmine hoiatus:

2020-01-21 10:22:57 +0000 [warn]: [test-prod] ei õnnestunud kirjutada andmeid puhvri ülevoolu toimingu tõttu action=:block

See tähendab, et puhver ei jõua ette nähtud ajaks puhastuda ja andmed, mis tulevad täidetud puhvrisse, blokeeritakse, mis viib logide osa kadumiseni.

Puhvrit saab suurendada kahel viisil: suurendades kas iga chunk'i suurust järjekorras või chunkide arvu, mis võivad järjekorras olla.

Kui chunk'i suurus chunk_limit_size on suurem kui 32 megabaiti, siis ElasticSearch ei aktsepteeri seda, kuna sissetulev pakett muutub liiga suureks. Seega, kui on vajalik puhvrimahu veelgi suurendamine, on parem suurendada maksimaalset järjekorra pikkust queue_limit_length.

Kui puhver ei hakka enam ülevoolama ja alles jääb ainult teade ajakuupäeva puudumisest, võib alustada request_timeout parameetri suurendamist. Kuid kui seatakse väärtus suurem kui 20 sekundit, hakkavad Fluentd logides ilmuma järgmised hoiatused:

2020-01-21 09:55:33 +0000 [warn]: [test-dev] puhvri puhastamine võttis rohkem aega kui slow_flush_log_threshold: elapsed_time=20.85753920301795 slow_flush_log_threshold=20.0 plugin_id="postgresql-dev"

See sõnum ei mõjuta süsteemi tööd ja tähendab, et puhvri puhastamine kestis kauem, kui slow_flush_log_threshold parameetriga on seadistatud. See on silumisinfo ja me kasutame seda request_timeout parameetri väärtuse valimisel.

Üldine algoritm väärtuse valimiseks näeb välja järgmine:

Seada request_timeout väärtus garantii alusel oluliselt suuremaks, kui vajalik (sajad sekundi). Seadistamise ajal on peamine kriteerium selle parameetri õige seadistamise osas hoiatused ajakuupäeva puudumisest.
Oodata sõnumeid, mis ületavad slow_flush_log_threshold piiri. Hoiatuses olevas lõigus elapsed_time on kirjas tegelik puhvri puhastamise aeg.
Seada request_timeout väärtus peab olema suurem kui maksimaalne elapsed_time väärtus, mis on saadud jälgimisperioodi jooksul. Me arvutame request_timeout väärtuse kui elapsed_time + 50%.
Omandamaks logi teateid pika puhastusprotsessi kohta, saab suurendada slow_flush_log_threshold väärtust. Me arvutame selle väärtuse kui elapsed_time + 25%.

Nende parameetrite lõppväärtused, nagu eelnevalt märgitud, on iga juhtumi jaoks individuaalsed. Järgides ülaltoodud algoritmi, saame kindlasti kõrvaldada vea, mis põhjustab teatiste kordumist.

Allolevas tabelis on näidatud kuidas veade koguarv muutub päeva jooksul, mis põhjustab teatiste dubleerimist, kui määrata ülaltoodud parameetrite väärtuseid:

node-1
node-2
node-3
node-4

Enne/Pärast
Enne/Pärast
Enne/Pärast
Enne/Pärast

puudus puhastamine puhvrist
1749/2
694/2
47/0
1121/2

kordus õnnestus
410/2
205/1
24/0
241/2

Tuleb täiendavalt märkida, et saadud seaded võivad projektide kasvu käigus kaotada oma asjakohasuse ja seega logide arvu suurenemise tõttu. Peamine märk puuduvast seadistatud ajaülesandest on Fluentd logisse naasmine pika puhastamise teated, see tähendab ületamine slow_flush_log_threshold piiri. Sellest hetkest on veel väike varu enne request_timeout piiri ületamist, seega on oluline reageerida nendele teadetele õigeaegselt ja uuesti läbi viia optimaalse seadistamise protsess, nagu eelnevalt kirjeldatud.

Kokkuvõte

Fluentd väljundpuhvri peenhäälestamine on üks peamisi etappe EFK silmuste seadistamisel, mis määrab kindlaks selle stabiilsuse ja dokumentide korrektse paigutamise indeksitesse. Järgides kirjeldatud seadistamise algoritmi, võib olla kindel, et kõik logid salvestatakse ElasticSearch indeksisse õiges järjekorras, ilma kordusteta ja kaotusteta.

Vaata ka teisi artikleid meie blogis:

Allikas: habr.com