ПроХостер > блог > Администрација > Флуентд: Зашто је важно конфигурисати излазни бафер

Флуентд: Зашто је важно конфигурисати излазни бафер

Флуентд: Зашто је важно конфигурисати излазни бафер

Данас је немогуће замислити пројекат заснован на Кубернетесу без ЕЛК стека, који чува евиденције апликација и системских компоненти кластера. У нашој пракси користимо ЕФК стек са Флуентд-ом уместо Логстасх-ом.

Флуентд је модеран, универзални сакупљач дневника који добија све већу популарност и придружио се Цлоуд Нативе Цомпутинг Фоундатион, због чега је његов вектор развоја фокусиран на коришћење у комбинацији са Кубернетес-ом.

Чињеница да се Флуентд користи уместо Логстасх-а не мења општу суштину софтверског пакета, међутим, Флуентд карактеришу своје специфичне нијансе које произилазе из његове свестраности.

На пример, када смо почели да користимо ЕФК у заузетом пројекту са великим интензитетом логовања, суочили смо се са чињеницом да су се у Кибани неке поруке приказивале више пута. У овом чланку ћемо вам рећи зашто се овај феномен јавља и како да решите проблем.

Проблем умножавања докумената

У нашим пројектима, Флуентд се примењује као ДаемонСет (аутоматски се покреће у једној инстанци на сваком чвору Кубернетес кластера) и прати евиденције контејнера стдоут у /вар/лог/цонтаинерс. Након прикупљања и обраде, дневници у облику ЈСОН докумената се шаљу у ЕластицСеарцх, подигнути у кластер или самосталан облик, у зависности од обима пројекта и захтева за перформансе и толеранцију грешака. Кибана се користи као графички интерфејс.

Када смо користили Флуентд са додатком за баферовање излаза, наишли смо на ситуацију да неки документи у ЕластицСеарцх-у имају потпуно исти садржај и разликују се само по идентификатору. Можете да проверите да ли је ово понављање поруке користећи Нгинк дневник као пример. У датотеци евиденције ова порука постоји у једној копији:

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

Међутим, постоји неколико докумената у ЕластицСеарцх-у који садрже ову поруку:

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

Штавише, може бити више од два понављања.

Док решавате овај проблем у Флуентд евиденцијама, можете видети велики број упозорења са следећим садржајем:

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"

Ова упозорења се јављају када ЕластицСеарцх не може да врати одговор на захтев унутар времена које је специфицирао параметар рекуест_тимеоут, због чега се проследени фрагмент бафера не може обрисати. Након овога, Флуентд поново покушава да пошаље фрагмент бафера у ЕластицСеарцх и након произвољног броја покушаја, операција се успешно завршава:

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"

Међутим, ЕластицСеарцх третира сваки од пренетих фрагмената бафера као јединствен и додељује им јединствене вредности поља _ид током индексирања. Овако се појављују копије порука.

У Кибани то изгледа овако:

Флуентд: Зашто је важно конфигурисати излазни бафер

Решење

Постоји неколико опција за решавање овог проблема. Један од њих је механизам уграђен у додатак флуент-плугин-еластицсеарцх за генерисање јединственог хеша за сваки документ. Ако користите овај механизам, ЕластицСеарцх ће препознати понављања у фази прослеђивања и спречити дуплирање докумената. Али морамо узети у обзир да се овај метод решавања проблема бори са истрагом и не отклања грешку недостатком тајм-аута, па смо напустили његову употребу.

Користимо додатак за баферовање на Флуентд излазу да спречимо губитак евиденције у случају краткорочних проблема са мрежом или повећаног интензитета евидентирања. Ако из неког разлога ЕластицСеарцх не може тренутно да упише документ у индекс, документ се ставља у ред чекања и чува на диску. Стога, у нашем случају, да би се елиминисао извор проблема који доводи до грешке описане изнад, потребно је поставити исправне вредности за параметре баферовања, при чему ће излазни бафер Флуентд бити довољне величине и у исто време успети да се очисти у задатом времену.

Вреди напоменути да су вредности параметара о којима се говори у наставку индивидуалне у сваком конкретном случају коришћења баферовања у излазним додацима, јер зависе од многих фактора: интензитета писања порука у дневник по услугама, перформанси диск система, мреже оптерећење канала и његов пропусни опсег. Стога, да бисте добили подешавања бафера која су прикладна за сваки појединачни случај, али не и редундантна, избегавајући слепо дуготрајна претраживања, можете користити информације за отклањање грешака које Флуентд уписује у свој дневник током рада и релативно брзо добити тачне вредности.

У време када је проблем забележен, конфигурација је изгледала овако:

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

Приликом решавања проблема ручно су изабране вредности следећих параметара:
цхунк_лимит_сизе — величина делова на које су поруке у баферу подељене.

  • флусх_интервал — временски интервал након којег се бафер брише.
  • куеуе_лимит_ленгтх — максимални број комада у реду.
  • рекуест_тимеоут је време за које се успоставља веза између Флуентд-а и ЕластицСеарцх-а.

Укупна величина бафера се може израчунати множењем параметара куеуе_лимит_ленгтх и цхунк_лимит_сизе, што се може тумачити као „максимални број комада у реду, од којих сваки има дату величину“. Ако величина бафера није довољна, у евиденцији ће се појавити следеће упозорење:

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

То значи да бафер нема времена да се обрише у додељеном времену и да су подаци који улазе у пун бафер блокирани, што ће довести до губитка дела дневника.

Можете повећати бафер на два начина: повећањем величине сваког дела у реду или броја делова који могу бити у реду.

Ако подесите величину комада цхунк_лимит_сизе на више од 32 мегабајта, ЕластицСеацрх то неће прихватити, пошто ће долазни пакет бити превелик. Због тога, ако треба додатно да повећате бафер, боље је повећати максималну дужину реда куеуе_лимит_ленгтх.

Када бафер престане да се прекорачи и остане само порука о недостатку временског ограничења, можете почети да повећавате параметар рекуест_тимеоут. Међутим, ако подесите вредност на више од 20 секунди, следећа упозорења ће почети да се појављују у Флуентд евиденцијама:

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. Да бисте уклонили упозорења о дугим испуштањима бафера из евиденције, можете повећати вредност слов_флусх_лог_тхресхолд. Ову вредност израчунавамо као протекло_време + 25%.

Коначне вредности ових параметара, као што је раније наведено, добијају се појединачно за сваки случај. Пратећи горе наведени алгоритам, гарантовано ћемо елиминисати грешку која доводи до поновљених порука.

Табела испод показује како се број грешака дневно, које доводе до дуплирања порука, мења у процесу одабира вредности горе описаних параметара:

чвор-1
чвор-2
чвор-3
чвор-4

Пре после
Пре после
Пре после
Пре после

није успело да испразни бафер
1749/2
694/2
47/0
1121/2

поновни покушај је успео
410/2
205/1
24/0
241/2

Вреди додатно напоменути да резултујућа подешавања могу изгубити своју релевантност како пројекат расте и, сходно томе, повећава се број дневника. Примарни знак недовољног временског ограничења је враћање порука о дугом пражњењу бафера у Флуентд дневник, односно прекорачење прага слов_флусх_лог_тхресхолд. Од овог тренутка, још увек постоји мала маргина пре него што се прекорачи параметар рекуест_тимеоут, па је потребно благовремено одговорити на ове поруке и поновити горе описани процес одабира оптималних подешавања.

Закључак

Фино подешавање излазног бафера Флуентд-а је једна од главних фаза конфигурисања ЕФК стека, одређивање стабилности његовог рада и правилног постављања докумената у индексе. На основу описаног конфигурационог алгоритма, можете бити сигурни да ће сви логови бити уписани у ЕластицСеарцх индекс у исправном редоследу, без понављања и губитака.

Прочитајте и друге чланке на нашем блогу:

Извор: ввв.хабр.цом

Додај коментар