Fluentd: miks on oluline seadistada väljundpuhver

Tänapäeval on raske ette kujutada Kubernetes'e projekti ilma ELK stack'ita, mis salvestab nii rakenduste kui ka klastrisüsteemi komponentide logisid. Oma praktikas kasutame me EFK stack'i, kus Fluentd on Logstashi asemel.

Fluentd on kaasaegne universaalne logikogujate tööriist, mis on üha populaarsem ja liitunud Cloud Native Computing Foundation'iga, mistõttu on selle arenduse suund suunatud koostöölle Kubernetes'ega.

Fluentdi kasutamine Logstashi asemel ei muuda programmi kompleks üldiselt, kuid Fluentd'il on oma spetsiifilised nüansid, mis tulenevad selle mitmeotstarbelisusest.

Näiteks, alustades EFK kasutamist suure koormusega projektis, kus logide kirjutamise intensiivsus on kõrge, seisime silmitsi probleemiga, et Kibanas kuvatakse mõned sõnumid mitu korda. Käesolevas artiklis räägime teile, miks see nähtus toimub ja kuidas probleemi lahendada.

Dokumentide dubleerimise probleem

Meie projektides on Fluentd juurutatud kui DaemonSet (automaatne käivitamine igas Kubernetes klastrites sõlmes) ja jälgib konteinerite stdout logisid asukohas /var/log/containers. Pärast kogumist ja töötlemist saadetakse logid JSON-dokumentidena ElasticSearchi, mis töötab klastris või iseseisvalt, sõltuvalt projekti ulatusest ja jõudlus- ning talitlushäire nõuetest. Graafilise liidese jaoks kasutatakse Kibanat.

Fluentd kasutamisel puhversüsteemi pistikprogrammiga meil tekkis olukord, kus mõned dokumendid ElasticSearchis omasid täiesti identset sisu, erinedes vaid tuvastamisnumbri poolest. Veenduda, et tegemist on korduva teatega, saab tuua Nginxi logi näite. Logifailis on see teade ainus eksemplar:

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 ElasticSearchis eksisteerivad mitmed dokumendid, mis sisaldavad seda teavet:

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

Kordusa võib olla rohkem kui kaks.

Fluentd logides seda probleemi fikseerides võib näha suurt hulka järgmise sisuga hoiatuseid:

2020-01-16 01:46:46 +0000 [warn]: [test-prod] ei õnnestunud vahemälu tühjendada. retry_time=4 next_retry_seconds=2020-01-16 01:46:53 +0000 chunk="59c37fc3fb320608692c352802b973ce" error_class=Fluent::Plugin::ElasticsearchOutput::RecoverableRequestFailure error="ei suutnud logisid Elasticsearch klastrisse saata ({:host="elasticsearch", :port=9200, :scheme="http", :user="elastic", :password="obfuscated"}): lugemiseks saavutatav aeg ületatud"

Needless warnings occur when ElasticSearch cannot return a response to the request within the configured request_timeout period, which prevents the buffered chunk from being cleared. After this, Fluentd attempts to resend the buffered chunk to ElasticSearch, and after an arbitrary number of attempts, the operation is successful.

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"

However, ElasticSearch treats each of the resent buffer chunks as unique and assigns them unique _id field values upon indexing. This is how message duplicates arise.

In Kibana, it looks like this:

Probleemi lahendamine

Probleemi lahendamiseks on mitu võimalust. Üks neist on pluginas fluent-plugin-elasticsearch sisseehitatud mehhanism, mis genereerib iga dokumendi jaoks unikaalse hash'i. Kui seda mehhanismi kasutada, suudab ElasticSearch tuvastada kordused edastamise etapis ja vältida dokumentide dubleerimist. Kuid tuleb arvestada, et see lahendus tegeleb toime, mitte põhjusega, mistõttu ei kõrvalda see timeout'i puudumise vead ja seetõttu loobusime selle kasutamisest.

Kasutame Fluentd-väljalöögi puhverdamispluginat, et vältida logide kadumist lühikeste võrguprobleemide või logide kirjutamise intensiivsuse suurenemise korral. Kui mingil põhjusel ei suuda ElasticSearch dokumenti indeksisse kohe salvestada, satub dokument järjekorda, mis hoitakse kettal. Seetõttu on meie puhul vajalik, et probleemiallikad, mis põhjustavad eespool kirjeldatud viga, kõrvaldada ja seetõttu määrata puhverdamise parameetritele õiged väärtused, mille korral on Fluentd-väljund puhver piisava mahuga, et selle tühjendamine ära mahuks ettenähtud aja jooksul.

Oluline on märkida, et allpool arutatavate parameetrite väärtused on iga konkreetse pufferdamise kasutusjuhtumi jaoks individuaalsed, kuna need sõltuvad paljuski erinevatest teguritest: teenuste logide kirjutamise intensiivsusest, kettasüsteemi jõudlusest, võrguühenduse koormusest ja selle läbivusest. Seetõttu, et saada iga konkreetse juhtumi jaoks sobivad, kuid mitte liialdavad pufferdusese seadistused, vältides pikka pimemängu, on soovitatav kasutada silumineinfot, mida Fluentd oma logisse kirjutab tööprotsessi käigus, ja võrreldes kiiresti õiged väärtused kätte saada.

Probleemi fikseerimise hetkel nägi konfigureerimine välja järgmiselt:

 @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

Probleemi lahendamise käigus valiti käsitsi järgmiste parameetrite väärtused:
chunk_limit_size — pufferis sõnumid, millesse jagatakse.

• flush_interval — ajakava, mille möödumisel toimub puhverdamise puhastus.
• queue_limit_length — maksimaalne chunks arv järjekorras.
• request_timeout — aeg, mille jooksul luuakse ühendus Fluentd ja ElasticSearch vahel.

Puhversuuruse arvutamiseks tuleb korrutada parameetrid queue_limit_length ja chunk_limit_size, mida saab tõlgendada kui «maksimaalne chunks arv järjekorras, igaühel on määratud maht». Kui puhver on liiga väike, ilmub logides järgmine hoiatusteade:

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

See tähendab, et puhver ei suuda ettenähtud ajaks kustuda ja täidetud puhvri sisse tulevad andmed blokeeritakse, mis toob kaasa osa logide kadumise.

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

Kui chunk_limit_size seadistada üle 32 megabaiti, siis ElasticSearch ei aktsepteeri seda, kuna sissetulev pakett oleks liiga suur. Seetõttu, kui puhvrit on vaja veelgi suurendada, on parem suurendada maksimaalset järjekorra pikkust queue_limit_length.

Kui puhver enam ei ületa piiri ja alles on vaid teade ajavahemiku vähenemisest, saab hakata suurendama parameetrit request_timeout. Siiski, kui seadistada väärtus üle 20 sekundi, hakkavad Fluentd logides ilmuma järgmised hoiatusteated:

2020-01-21 09:55:33 +0000 [warn]: [test-dev] puhvri tühjendamine võttis kaua aega, kui on ületatud slow_flush_log_threshold:elapsed_time=20.85753920301795 slow_flush_log_threshold=20.0 plugin_id="postgresql-dev" 

See teade ei mõjuta süsteemi toimimist ja tähendab, et puhvri tühjendamise aeg ületas slow_flush_log_threshold parameetriga määratud väärtuse. See on silumisinfo, mille kasutame request_timeout parameetri väärtuse määramisel.

Üldine algoritm määramiseks näeb välja järgmiselt:

1. Seada request_timeout väärtus kindlasti suuremaks kui vajalik (sajaid sekundeid). Seadistamise ajal on peamine kriteerium, kas see parameeter on õigesti seadistatud, hoiatuste kadumine ajavahemiku vähenemisest.
2. Oodata sõnumeid, mis ületavad slow_flush_log_threshold-i piiri. Hoiatuste tekstis, välja elapsed_time, on näidatud puhvri tühjendamise tegelik aeg.
3. Seadmise request_timeout väärtus peab olema suurem kui perioodi jooksul saadud maksimaalne elapsed_time väärtus. Arvutame request_timeout väärtuse kui elapsed_time + 50%.
4. Logi pika puhastusprotsessi hoiatustest vabanemiseks on võimalik tõsta slow_flush_log_threshold väärtust. Arvutame selle väärtuse kui elapsed_time + 25%.

Nende parameetrite lõppväärtused, nagu eelnevalt mainitud, on igas üksikjuhus isikupärased. Järgides eespool toodud algoritmi, kõrvaldame vead, mis põhjustavad sõnumite kordumist.

Allolevas tabelis on näidatud, kuidas muutub vead päevas, mis toovad kaasa sõnumite dubleerimise, kõigi eespool mainitud parameetrite väärtuste valimise protsessis:

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

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

puhastamise ebaõnnestumine
1749/2
694/2
47/0
1121/2

katsed õnnestusid
410/2
205/1
24/0
241/2

Oluline on märkida, et saadud seaded võivad projekti kasvu ja logide arvu suurenemise tõttu kaotada oma aktuaalsuse. Esmane märk seadistustest, kus puudub ajapiirang, on Fluentd logides pikka puhastusprotsessi käsitlevad teated, see tähendab, et on ületatud slow_flush_log_threshold künnis. Alates sellest hetkest on tõeliselt väike varu kuni request_timeout ületamiseni, seetõttu tuleb nendele sõnumitele õigel ajal reageerida ja korrata eelpool toodud optimaalse seadistuse otsimise protsessi.

Kokkuvõte

Fluentd väljundpuhvri täpne seadistamine on üks peamisi EFK steki konfigureerimise etappe, mis määrab selle toimimise stabiilsuse ja dokumendi korrektse paigutamise indeksitesse. Järgides kirjeldatud seadistamisalgoritmi, võib olla kindel, et kõik logid salvestatakse ElasticSearchi indeksi õiges järjestuses, ilma kordusteta ja kaotusteta.

Vaata ka teisi artikleid meie blogis:

• Go ja Zabbix 5.0 said sõbraks
• Kubernetes klastrite uuendamine ilma seisakuta
• Kubernetes: miks on süsteemi ressursihalduse seadistamine nii oluline?
• Kolm lihtsat näpunäidet Docker-piltide vähendamiseks
• Suurte ja erinevate veebiprojektide varundamine

Allikas: habr.com