ఈ రోజుల్లో, ELK స్టాక్ లేకుండా కుబెర్నెట్స్ ఆధారిత ప్రాజెక్ట్‌ను ఊహించడం అసాధ్యం, ఇది క్లస్టర్ యొక్క అప్లికేషన్‌లు మరియు సిస్టమ్ కాంపోనెంట్స్ రెండింటి లాగ్‌లను సేవ్ చేస్తుంది. మా ఆచరణలో, మేము Logstashకు బదులుగా Fluentdతో EFK స్టాక్‌ని ఉపయోగిస్తాము.
Fluentd అనేది ఆధునిక, సార్వత్రిక లాగ్ కలెక్టర్, ఇది మరింత ప్రజాదరణ పొందుతోంది మరియు క్లౌడ్ నేటివ్ కంప్యూటింగ్ ఫౌండేషన్‌లో చేరింది, అందుకే దాని డెవలప్‌మెంట్ వెక్టర్ కుబెర్నెట్స్‌తో కలిసి ఉపయోగించడంపై దృష్టి పెట్టింది.
Logstashకు బదులుగా Fluentdని ఉపయోగించడం అనేది సాఫ్ట్‌వేర్ ప్యాకేజీ యొక్క సాధారణ సారాన్ని మార్చదు, అయినప్పటికీ, Fluentd దాని బహుముఖ ప్రజ్ఞ కారణంగా దాని స్వంత నిర్దిష్ట సూక్ష్మ నైపుణ్యాల ద్వారా వర్గీకరించబడుతుంది.
ఉదాహరణకు, మేము లాగింగ్ యొక్క అధిక తీవ్రతతో బిజీగా ఉన్న ప్రాజెక్ట్‌లో EFKని ఉపయోగించడం ప్రారంభించినప్పుడు, కిబానాలో కొన్ని సందేశాలు అనేకసార్లు పదేపదే ప్రదర్శించబడే వాస్తవాన్ని మేము ఎదుర్కొన్నాము. ఈ దృగ్విషయం ఎందుకు సంభవిస్తుంది మరియు సమస్యను ఎలా పరిష్కరించాలో ఈ వ్యాసంలో మేము మీకు చెప్తాము.
డాక్యుమెంట్ డూప్లికేషన్ సమస్య
మా ప్రాజెక్ట్‌లలో, Fluentd డెమోన్‌సెట్‌గా అమలు చేయబడింది (కుబెర్నెట్స్ క్లస్టర్‌లోని ప్రతి నోడ్‌లో ఒక సందర్భంలో స్వయంచాలకంగా ప్రారంభించబడింది) మరియు /var/log/containersలో stdout కంటైనర్ లాగ్‌లను పర్యవేక్షిస్తుంది. సేకరణ మరియు ప్రాసెసింగ్ తర్వాత, ప్రాజెక్ట్ యొక్క స్థాయి మరియు పనితీరు మరియు తప్పును సహించే ఆవశ్యకతలను బట్టి, JSON డాక్యుమెంట్‌ల రూపంలోని లాగ్‌లు క్లస్టర్ లేదా స్వతంత్ర రూపంలో పెంచబడిన ElasticSearchకి పంపబడతాయి. కిబానా గ్రాఫికల్ ఇంటర్‌ఫేస్‌గా ఉపయోగించబడుతుంది.
అవుట్‌పుట్ బఫరింగ్ ప్లగ్‌ఇన్‌తో Fluentdని ఉపయోగిస్తున్నప్పుడు, ElasticSearchలోని కొన్ని పత్రాలు సరిగ్గా ఒకే కంటెంట్‌ను కలిగి ఉన్న మరియు ఐడెంటిఫైయర్‌లో మాత్రమే విభిన్నంగా ఉండే పరిస్థితిని మేము ఎదుర్కొన్నాము. Nginx లాగ్‌ను ఉదాహరణగా ఉపయోగించి ఇది సందేశ పునరావృతమని మీరు ధృవీకరించవచ్చు. లాగ్ ఫైల్‌లో, ఈ సందేశం ఒకే కాపీలో ఉంది:
127.0.0.1 192.168.0.1 - [28/Feb/2013:12:00:00 +0900] "GET / HTTP/1.1" 200 777 "-" "Opera/12.0" -అయితే, ఈ సందేశాన్ని కలిగి ఉన్న అనేక పత్రాలు ElasticSearchలో ఉన్నాయి:
{
"_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"
}
}అంతేకాకుండా, రెండు కంటే ఎక్కువ పునరావృత్తులు ఉండవచ్చు.
Fluentd లాగ్‌లలో ఈ సమస్యను పరిష్కరిస్తున్నప్పుడు, మీరు క్రింది కంటెంట్‌తో పెద్ద సంఖ్యలో హెచ్చరికలను చూడవచ్చు:
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"రిక్వెస్ట్_టైమ్‌అవుట్ పరామితి ద్వారా నిర్దేశించబడిన సమయంలోగా సాగే శోధన అభ్యర్థనకు ప్రతిస్పందనను అందించలేనప్పుడు ఈ హెచ్చరికలు జరుగుతాయి, అందుకే ఫార్వార్డ్ చేయబడిన బఫర్ ఫ్రాగ్మెంట్ క్లియర్ చేయబడదు. దీని తర్వాత, Fluentd బఫర్ భాగాన్ని మళ్లీ ఎలాస్టిక్ శోధనకు పంపడానికి ప్రయత్నిస్తుంది మరియు ఏకపక్ష ప్రయత్నాల తర్వాత, ఆపరేషన్ విజయవంతంగా పూర్తవుతుంది:
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"అయితే, ElasticSearch బదిలీ చేయబడిన ప్రతి బఫర్ శకలాలను ప్రత్యేకంగా పరిగణిస్తుంది మరియు ఇండెక్సింగ్ సమయంలో వాటికి ప్రత్యేకమైన _id ఫీల్డ్ విలువలను కేటాయిస్తుంది. సందేశాల కాపీలు ఇలా కనిపిస్తాయి.
కిబానాలో ఇది ఇలా కనిపిస్తుంది:
ప్రసంగిస్తూ
ఈ సమస్యను పరిష్కరించడానికి అనేక ఎంపికలు ఉన్నాయి. వాటిలో ఒకటి ప్రతి పత్రానికి ప్రత్యేకమైన హాష్‌ను రూపొందించడానికి ఫ్లూయెంట్-ప్లగ్ఇన్-ఎలాస్టిక్‌సెర్చ్ ప్లగ్‌ఇన్‌లో నిర్మించబడిన మెకానిజం. మీరు ఈ మెకానిజంను ఉపయోగిస్తే, ఎలాస్టిక్‌సెర్చ్ ఫార్వార్డింగ్ దశలో పునరావృతాలను గుర్తిస్తుంది మరియు నకిలీ పత్రాలను నిరోధిస్తుంది. కానీ సమస్యను పరిష్కరించే ఈ పద్ధతి విచారణతో పోరాడుతుందని మరియు గడువు లేకపోవడంతో లోపాన్ని తొలగించదని మేము పరిగణనలోకి తీసుకోవాలి, కాబట్టి మేము దాని ఉపయోగాన్ని విడిచిపెట్టాము.
స్వల్పకాలిక నెట్‌వర్క్ సమస్యలు లేదా పెరిగిన లాగింగ్ తీవ్రత సంభవించినప్పుడు లాగ్ నష్టాన్ని నిరోధించడానికి మేము Fluentd అవుట్‌పుట్‌పై బఫరింగ్ ప్లగ్ఇన్‌ని ఉపయోగిస్తాము. కొన్ని కారణాల వల్ల ElasticSearch ఒక పత్రాన్ని తక్షణమే ఇండెక్స్‌కు వ్రాయలేకపోతే, పత్రం క్యూలో ఉంచబడుతుంది మరియు డిస్క్‌లో నిల్వ చేయబడుతుంది. అందువల్ల, మా విషయంలో, పైన వివరించిన లోపానికి దారితీసే సమస్య యొక్క మూలాన్ని తొలగించడానికి, బఫరింగ్ పారామితుల కోసం సరైన విలువలను సెట్ చేయడం అవసరం, దీనిలో ఫ్లూయెంట్ అవుట్‌పుట్ బఫర్ తగినంత పరిమాణంలో ఉంటుంది మరియు అదే సమయంలో నిర్ణీత సమయంలో క్లియర్ అయ్యేలా నిర్వహించండి.
అవుట్‌పుట్ ప్లగిన్‌లలో బఫరింగ్‌ని ఉపయోగించే ప్రతి నిర్దిష్ట సందర్భంలో దిగువ చర్చించబడిన పారామితుల విలువలు వ్యక్తిగతమైనవి అని గమనించాలి, ఎందుకంటే అవి అనేక అంశాలపై ఆధారపడి ఉంటాయి: సేవల ద్వారా లాగ్‌కు సందేశాలను వ్రాయడం యొక్క తీవ్రత, డిస్క్ సిస్టమ్ పనితీరు, నెట్‌వర్క్. ఛానెల్ లోడ్ మరియు దాని బ్యాండ్‌విడ్త్. అందువల్ల, ప్రతి ఒక్క సందర్భానికి సరిపోయే బఫర్ సెట్టింగ్‌లను పొందడం కోసం, కానీ అనవసరమైన, సుదీర్ఘ శోధనలను గుడ్డిగా తప్పించడం కోసం, మీరు ఆపరేషన్ సమయంలో Fluentd దాని లాగ్‌కు వ్రాసే డీబగ్గింగ్ సమాచారాన్ని ఉపయోగించవచ్చు మరియు సాపేక్షంగా త్వరగా సరైన విలువలను పొందవచ్చు.
సమస్య రికార్డ్ చేయబడిన సమయంలో, కాన్ఫిగరేషన్ ఇలా ఉంది:
<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>సమస్యను పరిష్కరించేటప్పుడు, కింది పారామితుల విలువలు మానవీయంగా ఎంపిక చేయబడ్డాయి:
chunk_limit_size — బఫర్‌లోని సందేశాలు విభజించబడిన భాగాల పరిమాణం.
- flush_interval — బఫర్ క్లియర్ చేయబడిన సమయ విరామం.
- queue_limit_length — క్యూలో ఉన్న భాగాల గరిష్ట సంఖ్య.
- request_timeout అనేది Fluentd మరియు ElasticSearch మధ్య కనెక్షన్ ఏర్పాటు చేయబడిన సమయం.
క్యూ_లిమిట్_లెంగ్త్ మరియు చంక్_లిమిట్_సైజ్ అనే పారామితులను గుణించడం ద్వారా మొత్తం బఫర్ పరిమాణాన్ని లెక్కించవచ్చు, దీనిని "క్యూలో ఉన్న గరిష్ట సంఖ్యలో భాగాలు, ప్రతి ఒక్కటి ఇచ్చిన పరిమాణాన్ని కలిగి ఉంటాయి" అని అర్థం చేసుకోవచ్చు. బఫర్ పరిమాణం సరిపోకపోతే, కింది హెచ్చరిక లాగ్‌లలో కనిపిస్తుంది:
2020-01-21 10:22:57 +0000 [warn]: [test-prod] failed to write data into buffer by buffer overflow action=:blockబఫర్‌కు కేటాయించిన సమయంలో క్లియర్ చేయడానికి సమయం లేదని మరియు పూర్తి బఫర్‌లోకి ప్రవేశించే డేటా బ్లాక్ చేయబడిందని దీని అర్థం, ఇది లాగ్‌లలో కొంత భాగాన్ని కోల్పోయేలా చేస్తుంది.
మీరు బఫర్‌ను రెండు విధాలుగా పెంచవచ్చు: క్యూలో ఉన్న ప్రతి భాగం యొక్క పరిమాణాన్ని లేదా క్యూలో ఉండే భాగాల సంఖ్యను పెంచడం ద్వారా.
మీరు భాగం పరిమాణం chunk_limit_sizeని 32 మెగాబైట్‌ల కంటే ఎక్కువ సెట్ చేస్తే, ఇన్‌కమింగ్ ప్యాకెట్ చాలా పెద్దదిగా ఉన్నందున ElasticSeacrh దానిని అంగీకరించదు. అందువల్ల, మీరు బఫర్‌ను మరింత పెంచాల్సిన అవసరం ఉన్నట్లయితే, గరిష్ట క్యూ పొడవు క్యూ_లిమిట్_లెంగ్త్‌ని పెంచడం మంచిది.
బఫర్ ఓవర్‌ఫ్లో అవడం ఆగిపోయినప్పుడు మరియు సమయం ముగిసినంత సందేశం మాత్రమే మిగిలి ఉంటే, మీరు request_timeout పరామితిని పెంచడం ప్రారంభించవచ్చు. అయితే, మీరు విలువను 20 సెకన్ల కంటే ఎక్కువ సెట్ చేస్తే, క్రింది హెచ్చరికలు 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" ఈ సందేశం సిస్టమ్ యొక్క ఆపరేషన్‌ను ఏ విధంగానూ ప్రభావితం చేయదు మరియు బఫర్ ఫ్లషింగ్ సమయం slow_flush_log_threshold పరామితి ద్వారా సెట్ చేయబడిన దానికంటే ఎక్కువ సమయం పట్టిందని అర్థం. ఇది డీబగ్గింగ్ సమాచారం మరియు మేము request_timeout పరామితి యొక్క విలువను ఎంచుకున్నప్పుడు దీనిని ఉపయోగిస్తాము.
సాధారణ ఎంపిక అల్గోరిథం క్రింది విధంగా ఉంది:
- రిక్వెస్ట్_టైమ్‌అవుట్‌ని అవసరమైన దానికంటే ఎక్కువగా ఉండేలా హామీనిచ్చే విలువకు సెట్ చేయండి (వందల సెకన్లు). సెటప్ సమయంలో, ఈ పరామితి యొక్క సరైన సెట్టింగ్‌కు ప్రధాన ప్రమాణం సమయం ముగియకపోవడం గురించి హెచ్చరికల అదృశ్యం.
- స్లో_ఫ్లష్_లాగ్_థ్రెషోల్డ్ థ్రెషోల్డ్‌ను అధిగమించడం గురించి సందేశాల కోసం వేచి ఉండండి. elapsed_time ఫీల్డ్‌లోని హెచ్చరిక వచనం బఫర్ క్లియర్ చేయబడిన నిజ సమయాన్ని చూపుతుంది.
- పరిశీలన వ్యవధిలో పొందబడిన గరిష్ట గడిచిన_సమయం విలువ కంటే ఎక్కువ విలువకు అభ్యర్థన_సమయం సెట్ చేయండి. మేము అభ్యర్థన_సమయం ముగిసిన విలువను elapsed_time + 50%గా గణిస్తాము.
- లాగ్ నుండి పొడవైన బఫర్ ఫ్లష్‌ల గురించి హెచ్చరికలను తీసివేయడానికి, మీరు slow_flush_log_threshold విలువను పెంచవచ్చు. మేము ఈ విలువను elapsed_time + 25%గా గణిస్తాము.
ఈ పారామితుల యొక్క తుది విలువలు, ముందుగా గుర్తించినట్లుగా, ప్రతి సందర్భంలోనూ ఒక్కొక్కటిగా పొందబడతాయి. పై అల్గారిథమ్‌ని అనుసరించడం ద్వారా, పునరావృత సందేశాలకు దారితీసే లోపాన్ని తొలగిస్తామని మేము హామీ ఇస్తున్నాము.
దిగువన ఉన్న పట్టిక రోజుకు లోపాల సంఖ్య, సందేశాల నకిలీకి దారి తీస్తుంది, పైన వివరించిన పారామితుల విలువలను ఎంచుకునే ప్రక్రియలో ఎలా మారుతుందో చూపిస్తుంది:
నోడ్-1
నోడ్-2
నోడ్-3
నోడ్-4
ముందు తరువత
ముందు తరువత
ముందు తరువత
ముందు తరువత
బఫర్‌ను ఫ్లష్ చేయడంలో విఫలమైంది
1749/2
694/2
47/0
1121/2
పునఃప్రయత్నం విజయవంతమైంది
410/2
205/1
24/0
241/2
ప్రాజెక్ట్ పెరిగేకొద్దీ ఫలిత సెట్టింగ్‌లు వాటి ఔచిత్యాన్ని కోల్పోవచ్చని మరియు తదనుగుణంగా, లాగ్‌ల సంఖ్య పెరుగుతుందని గమనించడం విలువ. తగినంత సమయం ముగియకపోవడానికి ప్రాథమిక సంకేతం ఫ్లూయెంట్ లాగ్‌కు సుదీర్ఘ బఫర్ ఫ్లష్ గురించి సందేశాలు తిరిగి రావడం, అంటే, స్లో_ఫ్లష్_లాగ్_థ్రెషోల్డ్ థ్రెషోల్డ్‌ను మించిపోవడం. ఈ పాయింట్ నుండి, రిక్వెస్ట్_టైమ్‌అవుట్ పరామితిని అధిగమించే ముందు ఇంకా చిన్న మార్జిన్ ఉంది, కాబట్టి ఈ సందేశాలకు సకాలంలో ప్రతిస్పందించడం మరియు పైన వివరించిన సరైన సెట్టింగ్‌లను ఎంచుకునే విధానాన్ని పునరావృతం చేయడం అవసరం.
తీర్మానం
Fluentd అవుట్‌పుట్ బఫర్‌ను ఫైన్-ట్యూనింగ్ చేయడం అనేది EFK స్టాక్‌ను కాన్ఫిగర్ చేయడంలో ప్రధాన దశల్లో ఒకటి, దాని ఆపరేషన్ యొక్క స్థిరత్వం మరియు సూచికలలో డాక్యుమెంట్‌ల సరైన ప్లేస్‌మెంట్‌ను నిర్ణయించడం. వివరించిన కాన్ఫిగరేషన్ అల్గోరిథం ఆధారంగా, పునరావృత్తులు లేదా నష్టాలు లేకుండా, అన్ని లాగ్‌లు సరైన క్రమంలో సాగే శోధన సూచికకు వ్రాయబడతాయని మీరు అనుకోవచ్చు.
మా బ్లాగ్‌లోని ఇతర కథనాలను కూడా చదవండి:
మూలం: www.habr.com