ProHoster > Блог > Administrasi > Fluentd: Apa iku penting kanggo ngatur buffer output

Fluentd: Apa iku penting kanggo ngatur buffer output

Fluentd: Apa iku penting kanggo ngatur buffer output

Saiki, ora bisa mbayangno proyek basis Kubernetes tanpa tumpukan ELK, sing nyimpen log aplikasi lan komponen sistem kluster. Ing praktik kita, kita nggunakake tumpukan EFK karo Fluentd tinimbang Logstash.

Fluentd minangka kolektor log universal modern sing saya tambah populer lan wis gabung karo Cloud Native Computing Foundation, mulane vektor pangembangane fokus ing panggunaan bebarengan karo Kubernetes.

Kasunyatan nggunakake Fluentd tinimbang Logstash ora ngganti inti umum saka paket piranti lunak, nanging Fluentd ditondoi kanthi nuansa spesifik dhewe sing diasilake saka versatility.

Contone, nalika kita miwiti nggunakake EFK ing proyek sibuk karo kakiyatan dhuwur saka logging, kita padha ngadhepi karo kasunyatan sing ing Kibana sawetara pesen ditampilake bola-bali kaping pirang-pirang. Ing artikel iki, kita bakal menehi pitutur marang kowe kenapa fenomena iki kedadeyan lan carane ngatasi masalah kasebut.

Masalah duplikasi dokumen

Ing proyek kita, Fluentd disebarake minangka DaemonSet (diluncurake kanthi otomatis ing siji conto ing saben simpul kluster Kubernetes) lan ngawasi log wadhah stdout ing /var/log/containers. Sawise koleksi lan pangolahan, log ing wangun dokumen JSON dikirim menyang ElasticSearch, diunggahake ing wangun kluster utawa mandiri, gumantung saka skala proyek lan syarat kanggo kinerja lan toleransi kesalahan. Kibana digunakake minangka antarmuka grafis.

Nalika nggunakake Fluentd karo plugin buffering output, kita nemoni kahanan ing ngendi sawetara dokumen ing ElasticSearch nduweni isi sing padha lan mung beda ing pengenal. Sampeyan bisa verifikasi manawa iki minangka pengulangan pesen nggunakake log Nginx minangka conto. Ing file log, pesen iki ana ing salinan siji:

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

Nanging, ana sawetara dokumen ing ElasticSearch sing ngemot pesen iki:

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

Kajaba iku, bisa uga luwih saka rong repetisi.

Nalika ndandani masalah iki ing log Fluentd, sampeyan bisa ndeleng akeh bebaya kanthi isi ing ngisor iki:

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"

Bebaya kasebut kedadeyan nalika ElasticSearch ora bisa nanggapi panjaluk sajrone wektu sing ditemtokake dening parameter request_timeout, mula fragmen buffer sing diterusake ora bisa dibusak. Sawise iki, Fluentd nyoba ngirim fragmen buffer menyang ElasticSearch maneh lan sawise sawetara usaha sing sewenang-wenang, operasi kasebut rampung kanthi sukses:

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"

Nanging, ElasticSearch nganggep saben fragmen buffer sing ditransfer minangka unik lan menehi nilai kolom _id sing unik sajrone ngindeks. Iki carane salinan pesen katon.

Ing Kibana katon kaya iki:

Fluentd: Apa iku penting kanggo ngatur buffer output

Ngatasi masalah

Ana sawetara opsi kanggo ngatasi masalah iki. Salah sijine yaiku mekanisme sing dibangun ing plugin fluent-plugin-elasticsearch kanggo ngasilake hash unik kanggo saben dokumen. Yen sampeyan nggunakake mekanisme iki, ElasticSearch bakal ngenali repetisi ing tahap nerusake lan nyegah duplikat dokumen. Nanging kita kudu nyathet yen cara iki kanggo ngrampungake masalah kasebut berjuang karo penyelidikan lan ora ngilangi kesalahan kanthi wektu entek, mula kita nolak panggunaane.

Kita nggunakake plugin buffering ing output Fluentd kanggo nyegah mundhut log yen ana masalah jaringan jangka pendek utawa tambah intensitas logging. Yen ana alesan ElasticSearch ora bisa langsung nulis dokumen menyang indeks, dokumen kasebut antri lan disimpen ing disk. Mulane, ing kasus kita, kanggo ngilangi sumber masalah sing nyebabake kesalahan kasebut ing ndhuwur, perlu nyetel nilai sing bener kanggo paramèter buffering, ing ngendi buffer output Fluentd bakal cukup ukuran lan ing wektu sing padha ngatur kanggo ngresiki ing wektu sing wis ditemtokake.

Wigati dicathet yen nilai paramèter sing dibahas ing ngisor iki minangka individu ing saben kasus tartamtu saka nggunakake buffering ing plugin output, amarga padha gumantung ing akeh faktor: intensitas nulis pesen menyang log dening layanan, kinerja sistem disk, jaringan. beban saluran lan bandwidth sawijining. Mulane, kanggo entuk setelan buffer sing cocog kanggo saben kasus individu, nanging ora keluwih-luwih, ngindhari telusuran sing dawa kanthi wuta, sampeyan bisa nggunakake informasi debugging sing ditulis Fluentd ing log sajrone operasi lan kanthi cepet entuk nilai sing bener.

Nalika masalah direkam, konfigurasi katon kaya iki:

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

Nalika ngrampungake masalah, nilai paramèter ing ngisor iki dipilih kanthi manual:
chunk_limit_size - ukuran potongan menyang pesen ing buffer dibagi.

  • flush_interval - interval wektu sawise buffer dibusak.
  • queue_limit_length - jumlah maksimum potongan ing antrian.
  • request_timeout iku wektu sing sambungan antarane Fluentd lan ElasticSearch ditetepake.

Ukuran buffer total bisa diwilang kanthi nambahake parameter queue_limit_length lan chunk_limit_size, sing bisa diinterpretasikake minangka "jumlah maksimum potongan ing antrian, sing saben duwe ukuran tartamtu." Yen ukuran buffer ora cukup, bebaya ing ngisor iki bakal katon ing log:

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

Iku tegese buffer ora duwe wektu kanggo ngankat ing wektu diparengake lan data sing lumebu buffer lengkap diblokir, kang bakal mimpin kanggo mundhut bagean saka log.

Sampeyan bisa nambah buffer kanthi rong cara: kanthi nambah ukuran saben potongan ing antrian, utawa jumlah potongan sing bisa ana ing antrian.

Yen sampeyan nyetel ukuran chunk_limit_size luwih saka 32 megabyte, banjur ElasticSeacrh ora bakal nampa, amarga paket mlebu bakal gedhe banget. Mulane, yen sampeyan kudu nambah buffer luwih, iku luwih apik kanggo nambah dawa antrian maksimum queue_limit_length.

Nalika buffer mandheg kebanjiran lan mung pesen wektu entek ora cukup, sampeyan bisa miwiti nambah parameter request_timeout. Nanging, yen sampeyan nyetel nilai luwih saka 20 detik, bebaya ing ngisor iki bakal katon ing log 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"

Pesen iki ora mengaruhi operasi sistem ing sembarang cara lan tegese wektu flush buffer njupuk maneh saka disetel dening parameter slow_flush_log_threshold. Iki minangka informasi debugging lan digunakake nalika milih nilai parameter request_timeout.

Algoritma pilihan umum kaya ing ngisor iki:

  1. Setel request_timeout menyang nilai sing dijamin luwih gedhe tinimbang sing dibutuhake (ratusan detik). Sajrone persiyapan, kritéria utama kanggo setelan sing bener saka parameter iki bakal ilang saka bebaya kanggo lack wektu entek.
  2. Ngenteni pesen babagan ngluwihi ambang slow_flush_log_threshold. Teks bebaya ing kolom elapsed_time bakal nuduhake wektu nyata buffer wis dibusak.
  3. Setel request_timeout menyang nilai sing luwih gedhe tinimbang nilai elapsed_time maksimum sing dipikolehi sajrone periode pengamatan. Kita ngetung nilai request_timeout minangka elapsed_time + 50%.
  4. Kanggo mbusak bebaya babagan flushes buffer dawa saka log, sampeyan bisa ngunggahake nilai slow_flush_log_threshold. Kita ngetung nilai iki minangka elapsed_time + 25%.

Nilai akhir paramèter kasebut, kaya sing wis kasebut sadurungé, dipikolehi kanthi individu kanggo saben kasus. Kanthi ngetutake algoritma ing ndhuwur, kita dijamin bakal ngilangi kesalahan sing ndadékaké pesen sing bola-bali.

Tabel ing ngisor iki nuduhake carane jumlah kesalahan saben dina, anjog kanggo duplikasi pesen, owah-owahan ing proses milih nilai paramèter kasebut ing ndhuwur:

simpul-1
simpul-2
simpul-3
simpul-4

Sadurunge sawise
Sadurunge sawise
Sadurunge sawise
Sadurunge sawise

gagal kanggo flush buffer
1749/2
694/2
47/0
1121/2

nyoba maneh kasil
410/2
205/1
24/0
241/2

Wigati uga dicathet yen setelan sing diasilake bisa ilang relevansi nalika proyèk mundhak lan, kanthi mangkono, jumlah log mundhak. Tandha utama wektu entek ora cukup yaiku bali pesen babagan flush buffer dawa menyang log Fluentd, yaiku, ngluwihi ambang slow_flush_log_threshold. Saka titik iki, isih ana wates cilik sadurunge parameter request_timeout ngluwihi, mula kudu nanggapi pesen kasebut kanthi pas wektune lan mbaleni proses milih setelan optimal sing kasebut ing ndhuwur.

kesimpulan

Fine-tuning buffer output Fluentd minangka salah sawijining tahap utama konfigurasi tumpukan EFK, nemtokake stabilitas operasi lan panggonan sing bener saka dokumen ing indeks. Adhedhasar algoritma konfigurasi sing diterangake, sampeyan bisa yakin manawa kabeh log bakal ditulis ing indeks ElasticSearch kanthi urutan sing bener, tanpa pengulangan utawa kerugian.

Uga maca artikel liyane ing blog kita:

Source: www.habr.com

Add a comment