Naha, ne mimkûn e ku meriv projeyek Kubernetes-based bêyî stacka ELK-ê xeyal bike, ku têketinên hem serîlêdanan û hem jî hêmanên pergalê yên komê xilas dike. Di pratîka xwe de, em li şûna Logstash stakê EFK bi Fluentd re bikar tînin.
Fluentd berhevokek têketinê ya nûjen, gerdûnî ye ku her ku diçe populerbûna xwe zêde dike û tevlî Weqfa Cloud Native Computing Cloud Native Cloud Computing Weqfa ye, ji ber vê yekê vektora pêşkeftina wê li ser karanîna bi Kubernetes re balê dikişîne.
Rastiya karanîna Fluentd li şûna Logstash cewhera giştî ya pakêta nermalavê naguhezîne, di heman demê de, Fluentd bi hûrguliyên xwe yên taybetî yên ku ji berhevhatina wê ve têne diyar kirin.
Mînakî, dema ku me dest bi karanîna EFK-ê di projeyek mijûl a bi zexmek têketinek bilind de kir, em bi vê yekê re rû bi rû man ku di Kibana de hin peyam çend caran çend caran hatin xuyang kirin. Di vê gotarê de em ê ji we re vebêjin ka çima ev diyarde çêdibe û meriv çawa pirsgirêkê çareser dike.
Pirsgirêka dubarekirina belgeyan
Di projeyên me de, Fluentd wekî DaemonSet tête bicîh kirin (bixweber di yek nimûneyê de li ser her girêkek koma Kubernetes tê destpêkirin) û têketinên konteynerê stdout di /var/log/konteyner de dişopîne. Piştî berhevkirin û hilgirtinê, têketinên di forma belgeyên JSON de ji ElasticSearch re têne şandin, li gorî pîvana projeyê û hewcedariyên performansê û tolerasyona xeletiyê, bi rengek komik an serbixwe têne rakirin. Kibana wekî navgîniya grafîkî tê bikar anîn.
Dema ku Fluentd bi pêvekek tamponkirina derketinê re bikar anîn, em rastî rewşek hatin ku hin belgeyên di ElasticSearch de tam heman naverok bûn û tenê di nasnavê de ji hev cûda bûn. Hûn dikarin verast bikin ku ev dubarekirina peyamê ye ku têketina Nginx wekî mînak bikar tîne. Di pelê têketinê de, ev peyam di kopiyek yekane de heye:
127.0.0.1 192.168.0.1 - [28/Feb/2013:12:00:00 +0900] "GET / HTTP/1.1" 200 777 "-" "Opera/12.0" -Lêbelê, di ElasticSearch de çend belge hene ku vê peyamê vedigirin:
{
"_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"
}
}Wekî din, dikare ji du dubareyan zêdetir be.
Dema ku vê pirsgirêkê di têketinên Fluentd-ê de rast dikin, hûn dikarin hejmareke mezin ji hişyariyên bi naveroka jêrîn bibînin:
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"Van hişyarî gava ku ElasticSearch nekare bersivek li ser daxwazek vegere di dema ku ji hêla parametreya request_timeout ve hatî destnîşan kirin vegere, ji ber vê yekê perçeya tamponê ya hatî şandin nikare were paqij kirin. Piştî vê yekê, Fluentd hewl dide ku perçeya tamponê dîsa ji ElasticSearch re bişîne û piştî hejmarek hewildanek kêfî, operasyon bi serfirazî qediya:
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"Lêbelê, ElasticSearch her perçeyên tamponê yên veguhestî wekî bêhempa derman dike û wan di dema îndekskirinê de nirxên zeviya _id-a yekta destnîşan dike. Bi vî rengî kopiyên peyaman xuya dibin.
Li Kibana wiha xuya dike:
Troubleshooting
Ji bo çareserkirina vê pirsgirêkê gelek vebijark hene. Yek ji wan mekanîzmaya ku di pêveka fluent-plugin-elasticsearch de hatî çêkirin e ku ji bo her belgeyek hashek bêhempa çêdike. Ger hûn vê mekanîzmayê bikar bînin, ElasticSearch dê di qonaxa şandinê de dubareyan nas bike û pêşî li belgeyên dubare bigire. Lê divê em bihesibînin ku ev rêbaza çareserkirina pirsgirêkê bi lêpirsînê re têdikoşe û xeletiyê bi kêmbûna demê re ji holê ranake, ji ber vê yekê me dev ji karanîna wê berda.
Em pêvekek tamponkirinê li ser derana Fluentd bikar tînin da ku pêşî li windabûna têketinê bigirin di bûyera pirsgirêkên torê yên kurt-kurt an zêdebûna tundiya têketinê de. Ger ji ber hin sedeman ElasticSearch nikaribe tavilê belgeyek li ser îndeksê binivîsîne, belge tê rêz kirin û li ser dîskê tê hilanîn. Ji ber vê yekê, di rewşa me de, ji bo ku çavkaniya pirsgirêka ku dibe sedema xeletiya ku li jor hatî diyar kirin ji holê rakin, pêdivî ye ku meriv nirxên rast ji bo pîvanên tamponê saz bike, ku tê de tampona hilberîna Fluentd dê bi mezinahiya têr be û di heman demê de di dema diyarkirî de têne paqij kirin.
Hêjayî gotinê ye ku nirxên pîvanên ku li jêr têne nîqaş kirin di her rewşek taybetî ya karanîna tampon di pêvekên derketinê de ferdî ne, ji ber ku ew bi gelek faktoran ve girêdayî ne: tundiya nivîsandina peyaman ji têketinê ji hêla karûbaran ve, performansa pergala dîskê, torê. barkirina kanalê û firehiya wê. Ji ber vê yekê, ji bo ku hûn mîhengên tamponê yên ku ji bo her dozek kesane guncan in, lê ne zêde ne, ji lêgerînên dirêj ên kor dûr bixin, hûn dikarin agahdariya debugkirinê ya ku Fluentd di dema xebatê de li têketina xwe dinivîse bikar bînin û bi nisbî zû nirxên rast bistînin.
Di dema ku pirsgirêk hate tomar kirin, veavakirin wiha xuya bû:
<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>Dema ku pirsgirêk çareser kirin, nirxên pîvanên jêrîn bi destan hatin hilbijartin:
chunk_limit_size - mezinahiya perçeyên ku peyamên di tamponê de têne dabeş kirin.
- flush_interval - navbera demê piştî ku tampon tê paqij kirin.
- queue_limit_length - hejmara herî zêde ya perçeyên di dorê de.
- request_timeout dema ku pêwendiya di navbera Fluentd û ElasticSearch de tê damezrandin e.
Mezinahiya tamponê ya tevayî dikare bi zêdekirina parametreyên queue_limit_length û chunk_limit_size, ku dikare wekî "hejmara herî zêde perçeyên di dorê de, ku her yek ji wan xwedan mezinahiyek diyarkirî ye" were şîrove kirin, were hesibandin. Heke mezinahiya tampon têrê nake, dê hişyariya jêrîn di têketinan de xuya bibe:
2020-01-21 10:22:57 +0000 [warn]: [test-prod] failed to write data into buffer by buffer overflow action=:blockEv tê wê wateyê ku tampon wext tune ku di wextê diyarkirî de were paqij kirin û daneyên ku têkevin tampona tevahî têne asteng kirin, ku dê bibe sedema windakirina beşek ji têketinê.
Hûn dikarin tamponê bi du awayan zêde bikin: bi zêdekirina mezinahiya her perçeyek di dorê de, an jî hejmara perçeyên ku dikarin di dorê de bin.
Ger hûn mezinahiya perçeyê chunk_limit_size ji 32 megabyte zêdetir destnîşan bikin, wê hingê ElasticSeacrh wê qebûl nake, ji ber ku pakêta hatî dê pir mezin be. Ji ber vê yekê, heke hûn hewce ne ku tampon bêtir zêde bikin, çêtir e ku hûn dirêjahiya dorê ya herî zêde queue_limit_length zêde bikin.
Dema ku tampon zêde raweste û tenê peyama kêmasiya dema derbasbûnê bimîne, hûn dikarin dest bi zêdekirina parametreya request_timeout bikin. Lêbelê, heke hûn nirxê ji 20 çirkeyan zêdetir destnîşan bikin, dê hişyariyên jêrîn di têketinên Fluentd de dest pê bikin:
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" Ev peyam bi tu awayî bandorê li xebata pergalê nake û tê vê wateyê ku dema paqijkirina tampon ji ya ku ji hêla pîvana slow_flush_log_threshold ve hatî destnîşan kirin dirêjtir girt. Ev agahdariya xeletkirinê ye û dema ku nirxa parametreya request_timeout hilbijêrin em wê bikar tînin.
Algorîtmaya hilbijartinê ya gelemperî wiha ye:
- Set request_timeout li ser nirxek ku garantîkirî ye ku ji pêdivî mezintir be (sed saniye). Di dema sazkirinê de, pîvana sereke ya rastkirina vê parametreyê dê windabûna hişyariyên ji bo kêmbûna demê be.
- Li benda peyamên der barê derbaskirina sînorê slow_flush_log_threshold de bisekinin. Nivîsara hişyariyê ya di qada elapsed_time de dê dema rast a paqijkirina tampon nîşan bide.
- Set request_timeout nirxek ji nirxa dema derbasbûyî ya herî zêde ya ku di heyama çavdêriyê de hatî bidestxistin. Em nirxa request_timeout wekî elapsed_time + 50% hesab dikin.
- Ji bo rakirina hişyariyên li ser rijandina tamponên dirêj ji têketinê, hûn dikarin nirxa slow_flush_log_threshold bilind bikin. Em vê nirxê wekî elapsed_time + 25% hesab dikin.
Nirxên paşîn ên van parameteran, wekî ku berê hate destnîşan kirin, ji bo her rewşê bi rengek kesane têne wergirtin. Bi şopandina algorîtmaya jorîn, em garantî dikin ku em xeletiya ku dibe sedema peyamên dubare ji holê rakin.
Tabloya jêrîn nîşan dide ka çawa hejmara xeletiyên rojane, ku dibe sedema dubarekirina peyaman, di pêvajoya hilbijartina nirxên pîvanên ku li jor hatine destnîşan kirin de diguhezîne:
node-1
node-2
node-3
node-4
Pêşî paşê
Pêşî paşê
Pêşî paşê
Pêşî paşê
nekarî tamponê bişo
1749/2
694/2
47/0
1121/2
dubare bi ser ket
410/2
205/1
24/0
241/2
Hêjayî gotinê ye ku her ku proje mezin dibe û, li gorî vê yekê, hejmara têketin zêde dibe, mîhengên encam dibe ku girîngiya xwe winda bikin. Nîşana serekî ya dema ne bes vegerandina mesajên li ser rijandina tamponek dirêj li têketina Fluentd-ê ye, ango derbaskirina sînorê slow_flush_log_threshold. Ji vê gavê û pê ve, hîna hûrgelek piçûk heye berî ku parametreya request_timeout derbas bibe, ji ber vê yekê pêdivî ye ku meriv di wextê xwe de bersiva van peyaman bide û pêvajoya hilbijartina mîhengên çêtirîn ên ku li jor hatine destnîşan kirin dubare bike.
encamê
Rêzkirina tampona derketinê ya Fluentd yek ji qonaxên sereke yên mîhengkirina stûna EFK-ê ye, destnîşankirina aramiya xebata wê û cîhkirina rast a belgeyan di navnîşan de. Li ser bingeha algorîtmaya vesazkirinê ya diyarkirî, hûn dikarin pê ewle bin ku dê hemî têketin bi rêza rast, bêyî dubarekirin û windahiyan, li ser pêveka ElasticSearch bêne nivîsandin.
Her weha gotarên din ên li ser bloga me bixwînin:
Source: www.habr.com