Hodie, impossibile est fingere Kubernetes-substructum consilium sine acervo ELK, qui ligna conservat utriusque applicationis et systematis botri. In usu nostro ACERVUS EFK cum Fluentd loco Logstash utimur.
Fluentd est modernus, collector universalis, qui plus magisque favoris consequitur et fundamentum computationis Cloud Native coniunxit, quam ob causam vector evolutionis eius in usu coniunctionis cum Kubernetes intentus est.
Factum usus Fluentd loco Logstash non mutat essentiam generalem sarcinae software, tamen Fluentd propriis nuances specificis ex sua versatilitate proveniens notatur.
Exempli gratia, cum EFK in negotio negotioso utere coepimus logging intensiore, obvium fuimus quod in Kibana nonnullae epistulae saepius pluries ostensae sunt. In hoc articulo, cur hoc phaenomenon occurrat et quomodo problema solvendum sit, dicamus.
Quaestio documenti duplicationis
In nostris inceptis, Fluentd explicatur ut DaemonSet (automatice in uno instantia in unaquaque nodi Kubernetarum botri) et monitores stdout continentis tigna in /var/log/tabularia. Post collectionem et processus, acta documenta in forma JSON mittuntur ad ElasticSearch, in forma racemo vel standalone elevata, secundum scalam propositi et requisita ad tolerantiam perficiendi et culpae. Kibana pro instrumento graphico adhibetur.
Cum Fluentd utens cum obturatorio buffering plugin, condicionem invenimus ubi quaedam documenta in ElasticSearch eadem prorsus contenta habebant et solum in identificante differebant. Potes cognoscere hoc esse nuntium iterationis utens Nginx log in exemplum. In tabella stipes, nuntius in uno exemplari exstat:
127.0.0.1 192.168.0.1 - [28/Feb/2013:12:00:00 +0900] "GET / HTTP/1.1" 200 777 "-" "Opera/12.0" -Sed exstant multa documenta in ElasticSearch quae hunc nuntium continent:
{
"_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"
}
}Praeterea, plures possunt esse repetitiones quam duae.
Dum hanc quaestionem in Fluentd tigna figens, videre potes permulta admonitiones cum sequenti contento:
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"Hae admonitiones occurrunt, cum ElasticSearch responsionem petitioni reddere non potest intra tempus determinatum ab parametro request_time, quae idcirco quiddam fragmentum transmissum purgari non potest. Post hoc, Fluentd fragmentum quiddam ad ElasticSearch iterum mittere conatur et, postquam arbitrarium numerum attentavit, operatio feliciter perficit;
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"Nihilominus, ElasticSearch singula quiddam fragmentorum translatorum tamquam singulare tractat et attribuit valores singulares _id campi per indexing. Ita apparent exemplaria epistulae.
In Kibana hoc spectat sic:
Oratio
Plures optiones ad hanc solvendam quaestionem sunt. Una earum est mechanisma in plugin investigationis fluenti-plugin-elasticae constructum ad singularem detrahendum pro singulis documentis generandis. Si hac mechanismo uteris, ElasticSearch repetitiones in scaena promovenda cognoscet et documenta duplicata praeveniet. Sed ratio habenda est hanc methodum solvendae quaestionis cum investigatione luctari et errorem temporis defectu non excludere, ut eius usum deseramus.
Plugini buffering in Fluentd output utimur ne iniuriarum iniuriarum in eventu problematum retis brevissimi temporis vel intensio logging augeatur. Si ElasticSearch ob aliquam causam documentum in indicem scribere statim nequit, documentum est amet et in disco reponitur. In nostro igitur casu, ad tollendum fontem problematis, qui errorem supra descriptum ducit, necesse est ponere valores rectos parametri ad buffering, in quibus Fluentd output quiddam satis magnitudinis ac simul curo tempore suo purgatum.
Notatu dignum est valores parametri infra descriptos singulas esse singulas in unoquoque casu utendi buffering in output plugins, sicut pendent ex pluribus factoribus: vehementia nuntiis scribendi ad stipes per operas, orbis systematis effectus, retis. alveum onus et Sedem. Ut igitur uncinis quiddam obtinendum, quod cuique casui conveniat, non tamen redundans, ne multa caeca indagat, uti potes notitias debugging quas Fluentd scribit ad suum stipem in operatione et relative cito rectas valores obtineas.
Cum problema descriptum esset, figura talis erat:
<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>Cum problema solvendum valores sequentium parametri manually delecti sunt;
chunk_limit_size β amplitudo chunkorum in quae nuntii in quiddam dividuntur.
- flush_interval - temporis intervallum quo purgatur quiddam.
- queue_limit_length - maximus numerus chunks in queue.
- request_timeout tempus est ad quod connexio inter Fluentd et ElasticSearch constituitur.
Tota magnitudo quiddam computari potest per multiplicationem parametri queue_limit_length et chunk_limit_size, quae interpretari potest "maximus numerus chunkorum in queue, quorum unumquodque magnitudinem datam habet." Si magnitudo quiddam insufficiens est, haec admonitio in lignis apparebit;
2020-01-21 10:22:57 +0000 [warn]: [test-prod] failed to write data into buffer by buffer overflow action=:blockSignificat quiddam tempus non esse purgatum in tempore sortito, et notitia quae intrat plenum quiddam obstructum, quai ad iacturam partium lignorum.
Duobus modis quiddam augere potes: augendo vel magnitudinem cuiusque fissi in queue, vel numerum chunkorum qui in queue esse possunt.
Si molem chunk_limit_sizes ad plusquam 32 megabytarum pones, tunc ElasticSeacrh eam non accipiet, cum fasciculus advenientis nimis magnus erit. Si ergo quiddam ulterius augere debes, melius est maximam queue longitudinem queue longitudinis augere.
Cum quiddam superfluum subsistit et solum nuntius insufficiens timeo remanet, incipere rogationem_timeout parametri augere. Sed si valorem plusquam XX secundis statuis, incipient sequentes admonitiones in Fluentd trabes apparere;
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" Nuntius hic operationi systematis quoquo modo non afficit et significat tempus quiddam rubenti diutius sumpsisse quam parametri tarda_flush_log_terredi. Hoc est debugging informationes et eo utimur eligendo valorem parametri petitionis_timere.
Electio communis algorithmus talis est:
- Pone request_timeout ad valorem praestatur plus quam necesse est (centum secundus). In statuto, norma principalis ad rectam occasum huius parametri erit monita ablatione propter temporis defectum.
- Exspecta epistulas circa limina pigri_flush_log_ limen superantes. Monitum textum in campo elapso ostendet tempus reale quiddam esse purgatum.
- Pone request_timeout ad valorem maiorem quam maximum valorem elapsum consecutus in periodo observationis. Postulationem_timeout valorem elapsum computamus + 50%.
- Ad admonitiones removendas circa quiddam diu rubet e trunco, valorem tardi_log_trimenti levare potes. Hunc valorem computamus tempore elapso + 25%.
Valores finales horum parametri, ut antea dictum est, singillatim pro quolibet casu obtinentur. Algorithmum superius sequendo, praestatur ad excludendum errorem qui ad iteratas nuntios ducit.
Mensa infra ostendit quomodo numerus errorum per diem, duplicationem nuntiorum ducens, mutationes in via eligendi valores parametri supra descriptos:
nodi-1
nodi-2
nodi-3
nodi-4
Post ante
Post ante
Post ante
Post ante
Defecit solet quiddam
1749/2
694/2
47/0
1121/2
Retry successit
410/2
205/1
24/0
241/2
Notatu praeterea dignum est quod occasus inde consequitur gravitatem suam amittere sicut inceptum crescit et proinde numerus lignorum augetur. Praecipuum signum temporis insufficiens est reditus nuntiorum circa longam quiddam rubore ad trabem Fluentd, id est, limen pigrum superans. Ex hoc puncto, adhuc parva margo est antequam rogatio parametri temporis exceditur, necesse est ut his nuntiis tempestive respondeas et processus meliorum occasus supra descriptos sumendi repetat.
conclusio,
Finis-tuning quiddam Fluentd output est unum e praecipuis gradibus configurandi EFK acervum, stabilitatem operationis suae determinans et rectam collocationem documentorum in indicibus. Fundata ex schematismo algorithmo descripta, certo scire potes omnia ligna scribenda esse indice ElasticSearch recto ordine, sine repetitionibus vel damnis.
Legunt etiam alia capitula in nostro diario:
Source: www.habr.com