ProHoster > Blog > Administrasi > Fluentd: Naha éta penting pikeun ngonpigurasikeun panyangga kaluaran

Fluentd: Naha éta penting pikeun ngonpigurasikeun panyangga kaluaran

Fluentd: Naha éta penting pikeun ngonpigurasikeun panyangga kaluaran

Kiwari, mustahil pikeun ngabayangkeun proyék basis Kubernetes tanpa tumpukan ELK, anu ngahémat log boh aplikasi sareng komponén sistem kluster. Dina prakték urang, urang ngagunakeun tumpukan EFK kalawan Fluentd tinimbang Logstash.

Fluentd mangrupikeun kolektor log universal modéren anu beuki populer sareng parantos ngagabung sareng Cloud Native Computing Foundation, naha éta vektor pamekaran fokus kana dianggo babarengan sareng Kubernetes.

Kanyataan ngagunakeun Fluentd tinimbang Logstash henteu ngarobih hakekat umum tina pakét parangkat lunak, kumaha oge, Fluentd dicirikeun ku nuansa spésifik sorangan anu hasilna tina versatility na.

Salaku conto, nalika urang mimiti nganggo EFK dina proyék anu sibuk kalayan inténsitas logging anu luhur, kami disanghareupan kanyataan yén di Kibana sababaraha pesen ditampilkeun sababaraha kali. Dina artikel ieu kami baris ngabejaan Anjeun naha fenomena ieu lumangsung sarta kumaha carana ngajawab masalah.

Masalah duplikasi dokumén

Dina proyék kami, Fluentd disebarkeun salaku DaemonSet (otomatis diluncurkeun dina hiji conto dina unggal titik klaster Kubernetes) sareng ngawas log wadah stdout dina /var/log/containers. Saatos ngumpulkeun sareng ngolah, log dina bentuk dokumén JSON dikirim ka ElasticSearch, digedékeun dina bentuk klaster atanapi mandiri, gumantung kana skala proyék sareng sarat pikeun pagelaran sareng kasabaran kasalahan. Kibana dipaké salaku panganteur grafis.

Nalika nganggo Fluentd sareng plugin panyangga kaluaran, kami mendakan kaayaan dimana sababaraha dokumén dina ElasticSearch ngagaduhan eusi anu sami sareng ngan ukur béda dina identifier. Anjeun tiasa pariksa yén ieu mangrupikeun pangulangan pesen nganggo log Nginx salaku conto. Dina file log, pesen ieu aya dina salinan tunggal:

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, aya sababaraha dokumén dina ElasticSearch anu ngandung pesen ieu:

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

Leuwih ti éta, bisa aya leuwih ti dua pangulangan.

Nalika ngalereskeun masalah ieu dina log Fluentd, anjeun tiasa ningali sajumlah ageung peringatan kalayan eusi ieu:

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"

warnings ieu lumangsung nalika ElasticSearch teu bisa balik respon kana pamundut dina jangka waktu nu ditangtukeun ku parameter request_timeout, naha éta fragmen panyangga diteruskeun teu bisa diberesihan. Saatos ieu, Fluentd nyobian ngirim fragmen panyangga ka ElasticSearch deui sareng saatos sababaraha usaha anu sawenang, operasi parantos suksés:

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 ngarawat unggal fragmen panyangga anu ditransfer salaku unik sareng masihan aranjeunna nilai-nilai lapangan _id anu unik salami indéks. Ieu kumaha salinan pesen muncul.

Di Kibana sigana kieu:

Fluentd: Naha éta penting pikeun ngonpigurasikeun panyangga kaluaran

alamat

Aya sababaraha pilihan pikeun ngajawab masalah ieu. Salah sahijina nyaéta mékanisme anu diwangun kana plugin fluent-plugin-elasticsearch pikeun ngahasilkeun hash unik pikeun unggal dokumén. Upami anjeun nganggo mékanisme ieu, ElasticSearch bakal ngakuan pangulangan dina tahap diteruskeun sareng nyegah duplikat dokumén. Tapi urang kudu tumut kana akun nu metoda ieu ngarengsekeun masalah struggles kalawan panalungtikan sarta henteu ngaleungitkeun kasalahan jeung kurangna timeout, jadi urang ditinggalkeun pamakéan na.

Kami nganggo plugin buffering dina kaluaran Fluentd pikeun nyegah leungitna log upami aya masalah jaringan jangka pondok atanapi ningkat inténsitas logging. Upami kusabab sababaraha alesan ElasticSearch henteu tiasa langsung nyerat dokumén kana indéks, dokumen éta antrian sareng disimpen dina disk. Kukituna, dina kasus urang, pikeun ngaleungitkeun sumber masalah anu nyababkeun kasalahan anu dijelaskeun di luhur, perlu pikeun nyetél nilai anu leres pikeun parameter panyangga, dimana panyangga kaluaran Fluentd bakal ukuran anu cekap sareng dina waktos anu sareng ngatur pikeun diberesihan dina waktos allotted.

Perlu dicatet yén nilai parameter anu dibahas di handap ieu mangrupikeun individu dina unggal kasus khusus pikeun ngagunakeun panyangga dina plugins kaluaran, sabab gumantung kana sababaraha faktor: inténsitas nyerat pesen ka log ku jasa, kinerja sistem disk, jaringan. beban saluran sareng rubakpita na. Ku alatan éta, dina urutan pikeun ménta setélan panyangga anu cocog pikeun tiap kasus individu, tapi teu kaleuleuwihan, Ngahindarkeun maluruh lengthy ambing, anjeun tiasa nganggo informasi debugging nu Fluentd nyerat log na salila operasi sarta rélatif gancang ménta nilai bener.

Nalika masalahna dirékam, konfigurasina sapertos kieu:

 <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 ngarengsekeun masalah, nilai parameter di handap ieu dipilih sacara manual:
chunk_limit_size - ukuran sakumpulan nu pesen dina panyangga dibagi.

  • flush_interval - interval waktu sanggeus éta panyangga diberesihan.
  • queue_limit_length - jumlah maksimum sakumpulan dina antrian.
  • request_timeout mangrupikeun waktos dimana sambungan antara Fluentd sareng ElasticSearch ditetepkeun.

Ukuran panyangga total tiasa diitung ku cara ngalikeun parameter queue_limit_length sareng chunk_limit_size, anu tiasa diinterpretasi salaku "jumlah maksimum potongan dina antrian, anu masing-masing gaduh ukuran anu ditangtukeun." Upami ukuran panyangga henteu cekap, peringatan ieu bakal muncul dina log:

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

Ieu ngandung harti yén panyangga teu boga waktu pikeun diberesihan dina waktos allotted jeung data nu asup ka panyangga pinuh diblokir, nu bakal ngakibatkeun leungitna bagian tina log.

Anjeun tiasa ningkatkeun panyangga ku dua cara: ku cara ningkatkeun ukuran unggal sakumpulan dina antrian, atanapi jumlah sakumpulan anu tiasa aya dina antrian.

Upami anjeun nyetél ukuran chunk_limit_size ka langkung ti 32 megabyte, maka ElasticSeacrh moal nampi, sabab pakét anu asup bakal ageung teuing. Ku alatan éta, lamun perlu ningkatkeun panyangga salajengna, éta hadé pikeun ngaronjatkeun antrian panjangna maksimum queue_limit_length.

Nalika panyangga eureun overflowing sarta ngan talatah timeout cukup tetep, Anjeun bisa ngamimitian ngaronjatkeun parameter request_timeout. Nanging, upami anjeun nyetél nilai langkung ti 20 detik, peringatan di handap ieu bakal mimiti muncul dina 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 ieu henteu mangaruhan operasi sistem dina cara naon waé sareng hartosna waktos panyangga siram langkung lami tibatan anu diatur ku parameter slow_flush_log_threshold. Ieu mangrupikeun inpormasi debugging sareng kami nganggo nalika milih nilai parameter request_timeout.

Algoritma pamilihan umum nyaéta kieu:

  1. Setel request_timeout ka nilai dijamin leuwih gede ti diperlukeun (ratusan detik). Salila setelan, kriteria utama pikeun setelan bener tina parameter ieu bakal leungit warnings pikeun kurangna timeout.
  2. Antosan pesen ngeunaan ngaleuwihan ambang slow_flush_log_threshold. Téks peringatan dina widang elapsed_time bakal nunjukkeun waktos nyata panyangga dibersihkeun.
  3. Setel request_timeout ka nilai leuwih gede ti nilai elapsed_time maksimum diala salila periode observasi. Urang ngitung nilai request_timeout sakumaha elapsed_time + 50%.
  4. Pikeun miceun warnings ngeunaan flushes panyangga panjang tina log, anjeun tiasa ngangkat nilai slow_flush_log_threshold. Urang ngitung nilai ieu salaku elapsed_time + 25%.

Nilai ahir parameter ieu, sakumaha dicatet saméméhna, dicandak individual pikeun tiap kasus. Ku nuturkeun algoritma di luhur, kami dijamin ngaleungitkeun kasalahan anu nyababkeun pesen anu diulang.

Tabel di handap ieu nunjukkeun kumaha jumlah kasalahan per dinten, ngarah kana duplikasi pesen, parobihan dina prosés milih nilai parameter anu dijelaskeun di luhur:

titik-1
titik-2
titik-3
titik-4

Sateuacan saatosna
Sateuacan saatosna
Sateuacan saatosna
Sateuacan saatosna

gagal siram panyangga
1749/2
694/2
47/0
1121/2

usaha deui suksés
410/2
205/1
24/0
241/2

Perlu ogé dicatet yén setélan anu dihasilkeun tiasa leungit relevansina nalika proyékna ningkat sareng, sasuai, jumlah log naék. Tanda utama waktu béakna teu cukup nyaéta mulangkeun pesen ngeunaan panyangga panjang siram kana log Fluentd, nyaéta, ngaleuwihan ambang slow_flush_log_threshold. Ti titik ieu, masih aya margin leutik saméméh parameter request_timeout ngaleuwihan, jadi perlu ngabales pesen ieu dina ragam timely tur ngulang prosés milih setélan optimal ditétélakeun di luhur.

kacindekan

Fine-tuning panyangga kaluaran Fluentd mangrupakeun salah sahiji tahapan utama ngonpigurasikeun tumpukan EFK, nangtukeun stabilitas operasi sarta panempatan bener tina dokumén dina indéks. Dumasar kana algoritma konfigurasi anu dijelaskeun, anjeun tiasa mastikeun yén sadaya log bakal diserat kana indéks ElasticSearch dina urutan anu leres, tanpa pangulangan atanapi karugian.

Baca ogé artikel séjén dina blog urang:

sumber: www.habr.com

Tambahkeun komentar