Karong panahona, imposible nga mahanduraw ang usa ka proyekto nga nakabase sa Kubernetes nga wala ang ELK stack, nga nagtipig mga log sa parehas nga aplikasyon ug mga sangkap sa sistema sa cluster. Sa among praktis, among gigamit ang EFK stack sa Fluentd imbes sa Logstash.
Ang Fluentd usa ka moderno, unibersal nga tigkolekta sa log nga nagkaanam ug mas popular ug miapil sa Cloud Native Computing Foundation, mao nga ang development vector niini naka-focus sa paggamit kauban sa Kubernetes.
Ang kamatuoran sa paggamit sa Fluentd imbes sa Logstash wala magbag-o sa kinatibuk-ang esensya sa software package, bisan pa, ang Fluentd gihulagway sa kaugalingon nga piho nga mga nuances nga resulta sa versatility niini.
Pananglitan, sa dihang nagsugod kami sa paggamit sa EFK sa usa ka busy nga proyekto nga adunay taas nga intensity sa pag-log, nag-atubang kami sa kamatuoran nga sa Kibana ang pipila ka mga mensahe gibalik-balik nga gipakita sa daghang mga higayon. Sa niini nga artikulo kami mosulti kaninyo kon ngano nga kini nga panghitabo mahitabo ug sa unsa nga paagi sa pagsulbad sa problema.
Ang problema sa pagdoble sa dokumento
Sa among mga proyekto, ang Fluentd gi-deploy isip DaemonSet (awtomatikong gilunsad sa usa ka higayon sa matag node sa Kubernetes cluster) ug gimonitor ang stdout container logs sa /var/log/containers. Pagkahuman sa pagkolekta ug pagproseso, ang mga troso sa porma sa mga dokumento sa JSON ipadala sa ElasticSearch, gipataas sa cluster o standalone nga porma, depende sa sukod sa proyekto ug sa mga kinahanglanon alang sa pasundayag ug pagtugot sa sayup. Ang Kibana gigamit isip graphical interface.
Kung gigamit ang Fluentd nga adunay usa ka plugin nga buffering sa output, nasugatan namon ang usa ka sitwasyon diin ang pipila ka mga dokumento sa ElasticSearch adunay parehas nga sulud ug lahi ra sa identifier. Mahimo nimong pamatud-an nga kini usa ka pagbalik-balik sa mensahe gamit ang Nginx log ingon usa ka pananglitan. Sa log file, kini nga mensahe anaa sa usa ka kopya:
127.0.0.1 192.168.0.1 - [28/Feb/2013:12:00:00 +0900] "GET / HTTP/1.1" 200 777 "-" "Opera/12.0" -Bisan pa, adunay daghang mga dokumento sa ElasticSearch nga adunay kini nga mensahe:
{
"_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"
}
}Dugang pa, mahimong adunay labaw pa sa duha nga pagsubli.
Samtang giayo kini nga problema sa mga log sa Fluentd, makita nimo ang daghang mga pasidaan nga adunay mosunod nga sulud:
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"Kini nga mga pasidaan mahitabo kung ang ElasticSearch dili makabalik sa tubag sa usa ka hangyo sulod sa oras nga gitakda sa request_timeout parameter, mao nga ang gipasa nga buffer fragment dili ma-clear. Human niini, ang Fluentd mosulay sa pagpadala sa buffer fragment sa ElasticSearch pag-usab ug human sa usa ka arbitraryong gidaghanon sa mga pagsulay, ang operasyon makompleto:
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"Bisan pa, ang ElasticSearch nagtratar sa matag usa sa gibalhin nga mga tipik sa buffer ingon nga talagsaon ug naghatag kanila og talagsaon nga _id field values panahon sa pag-indeks. Ingon niini ang hitsura sa mga kopya sa mga mensahe.
Sa Kibana ingon niini:
Pag-troubleshoot
Adunay daghang mga kapilian aron masulbad kini nga problema. Ang usa niini mao ang mekanismo nga gitukod sa fluent-plugin-elasticsearch plugin alang sa pagmugna og usa ka talagsaon nga hash alang sa matag dokumento. Kung gamiton nimo kini nga mekanismo, ang ElasticSearch makaila sa mga pagsubli sa yugto sa pagpasa ug mapugngan ang mga doble nga dokumento. Apan kinahanglan natong tagdon nga kini nga pamaagi sa pagsulbad sa problema nakigbisog sa imbestigasyon ug wala magwagtang sa sayup nga adunay kakulang sa timeout, mao nga gibiyaan nato ang paggamit niini.
Naggamit kami og buffering plugin sa Fluentd output aron malikayan ang pagkawala sa log kung adunay mga problema sa network nga mubo nga panahon o pagtaas sa intensity sa pag-log. Kung tungod sa pipila ka rason ang ElasticSearch dili makahimo sa pagsulat dayon sa usa ka dokumento ngadto sa index, ang dokumento gipila ug gitipigan sa disk. Busa, sa among kaso, aron mawagtang ang tinubdan sa problema nga mosangpot sa sayop nga gihulagway sa ibabaw, gikinahanglan nga itakda ang husto nga mga bili alang sa mga parameter sa buffering, diin ang Fluentd output buffer adunay igo nga gidak-on ug sa samang higayon nakahimo nga ma-clear sa gitakda nga oras.
Angay nga matikdan nga ang mga kantidad sa mga parameter nga gihisgutan sa ubos mga indibidwal sa matag piho nga kaso sa paggamit sa buffering sa output plugins, tungod kay nagdepende kini sa daghang mga hinungdan: ang intensity sa pagsulat sa mga mensahe ngadto sa log pinaagi sa mga serbisyo, performance sa disk system, network. channel load ug ang bandwidth niini. Busa, aron makuha ang mga setting sa buffer nga angay alang sa matag indibidwal nga kaso, apan dili sobra, paglikay sa taas nga pagpangita nga buta, mahimo nimong gamiton ang impormasyon sa pag-debug nga gisulat sa Fluentd sa log niini sa panahon sa operasyon ug dali nga makuha ang husto nga mga kantidad.
Sa panahon nga ang problema natala, ang pagsumpo ingon niini:
<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>Kung gisulbad ang problema, ang mga kantidad sa mga mosunud nga mga parameter gipili nga mano-mano:
chunk_limit_size — ang gidak-on sa mga tipik diin ang mga mensahe sa buffer gibahin.
- flush_interval — agwat sa oras pagkahuman matangtang ang buffer.
- queue_limit_length — ang pinakataas nga gidaghanon sa mga tipik sa pila.
- request_timeout mao ang panahon diin ang koneksyon tali sa Fluentd ug ElasticSearch natukod.
Ang kinatibuk-ang gidak-on sa buffer mahimong kalkulado pinaagi sa pagpadaghan sa mga parameter queue_limit_length ug chunk_limit_size, nga mahimong hubaron nga "ang pinakataas nga gidaghanon sa mga tipik sa pila, ang matag usa adunay gihatag nga gidak-on." Kung ang gidak-on sa buffer dili igo, ang mosunod nga pasidaan makita sa mga log:
2020-01-21 10:22:57 +0000 [warn]: [test-prod] failed to write data into buffer by buffer overflow action=:blockKini nagpasabot nga ang buffer walay panahon nga ma-clear sa gitakda nga oras ug ang data nga mosulod sa bug-os nga buffer gibabagan, nga mosangpot sa pagkawala sa bahin sa mga troso.
Mahimo nimong madugangan ang buffer sa duha ka paagi: pinaagi sa pagdugang sa bisan unsang gidak-on sa matag tipik sa pila, o ang gidaghanon sa mga tipik nga mahimong naa sa pila.
Kung imong ibutang ang chunk size nga chunk_limit_size ngadto sa labaw sa 32 megabytes, nan ang ElasticSeacrh dili modawat niini, tungod kay ang umaabot nga pakete dako kaayo. Busa, kung kinahanglan nimo nga dugangan pa ang buffer, mas maayo nga dugangan ang labing taas nga gitas-on sa pila queue_limit_length.
Kung ang buffer mihunong sa pag-awas ug ang timeout nga dili igo nga mensahe nagpabilin, mahimo nimong sugdan ang pagdugang sa parameter sa request_timeout. Bisan pa, kung imong ibutang ang kantidad sa sobra sa 20 segundos, ang mosunod nga mga pasidaan magsugod sa pagpakita sa Fluentd logs:
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" Kini nga mensahe dili makaapekto sa operasyon sa sistema sa bisan unsa nga paagi ug nagpasabot nga ang buffer flushing nga panahon mas dugay kay sa gitakda sa slow_flush_log_threshold parameter. Kini ang impormasyon sa pag-debug ug gigamit namo kini sa pagpili sa bili sa request_timeout nga parameter.
Ang kinatibuk-ang algorithm sa pagpili mao ang mosunod:
- Ibutang ang request_timeout sa usa ka bili nga gigarantiyahan nga mas dako pa kay sa gikinahanglan (gatusan ka segundos). Atol sa pag-setup, ang nag-unang sukdanan alang sa husto nga setting niini nga parameter mao ang pagkawala sa mga pasidaan tungod sa kakulang sa timeout.
- Paghulat sa mga mensahe bahin sa pagsobra sa slow_flush_log_threshold threshold. Ang pasidaan nga teksto sa elapsed_time nga field magpakita sa tinuod nga panahon nga ang buffer natangtang.
- Itakda ang request_timeout sa usa ka bili nga labaw pa sa kinatas-ang elapsed_time nga bili nga nakuha sa panahon sa obserbasyon. Among kuwentahon ang request_timeout value isip elapsed_time + 50%.
- Aron matangtang ang mga pasidaan bahin sa taas nga buffer flushes gikan sa log, mahimo nimong ipataas ang kantidad sa slow_flush_log_threshold. Among kuwentahon kini nga bili isip elapsed_time + 25%.
Ang katapusan nga mga kantidad sa kini nga mga parameter, ingon sa nahisgutan sa sayo pa, nakuha nga tinagsa alang sa matag kaso. Pinaagi sa pagsunod sa algorithm sa ibabaw, gigarantiyahan namon nga mawagtang ang sayup nga nagdala sa gibalikbalik nga mga mensahe.
Ang lamesa sa ubos nagpakita kung giunsa ang gidaghanon sa mga sayup matag adlaw, nga nagdala sa pagdoble sa mga mensahe, mga pagbag-o sa proseso sa pagpili sa mga kantidad sa mga parameter nga gihulagway sa ibabaw:
node-1
node-2
node-3
node-4
Sa wala pa pagkahuman
Sa wala pa pagkahuman
Sa wala pa pagkahuman
Sa wala pa pagkahuman
napakyas sa pag-flush sa buffer
1749/2
694/2
47/0
1121/2
milampos ang pagsulay pag-usab
410/2
205/1
24/0
241/2
Angay usab nga hinumdoman nga ang resulta nga mga setting mahimong mawad-an sa ilang kalabutan samtang ang proyekto motubo ug, sumala niana, ang gidaghanon sa mga troso nagdugang. Ang nag-unang timailhan sa dili igo nga timeout mao ang pagbalik sa mga mensahe mahitungod sa taas nga buffer flush sa Fluentd log, nga mao, milapas sa slow_flush_log_threshold threshold. Gikan niining puntoha, aduna pa'y gamay nga margin sa dili pa molapas ang request_timeout nga parameter, mao nga gikinahanglan ang pagtubag niini nga mga mensahe sa tukma sa panahon nga paagi ug sublion ang proseso sa pagpili sa labing maayo nga mga setting nga gihulagway sa ibabaw.
konklusyon
Ang pag-ayo sa Fluentd output buffer usa sa mga nag-unang yugto sa pag-configure sa EFK stack, pagtino sa kalig-on sa operasyon niini ug ang husto nga pagbutang sa mga dokumento sa mga indeks. Pinasukad sa gihulagway nga algorithm sa pag-configure, makasiguro ka nga ang tanan nga mga troso isulat sa indeks sa ElasticSearch sa husto nga pagkasunod-sunod, nga wala’y mga pagsubli o pagkawala.
Basaha usab ang ubang mga artikulo sa among blog:
Source: www.habr.com