ఇది 2019, మరియు కుబెర్నెట్స్‌లో లాగ్ అగ్రిగేషన్ కోసం మా వద్ద ఇప్పటికీ ప్రామాణిక పరిష్కారం లేదు. ఈ కథనంలో, నిజమైన అభ్యాసం నుండి ఉదాహరణలను ఉపయోగించి, మా శోధనలు, ఎదుర్కొన్న సమస్యలు మరియు వాటి పరిష్కారాలను భాగస్వామ్యం చేయాలనుకుంటున్నాము.
అయితే, ముందుగా, లాగ్‌లను సేకరించడం ద్వారా వివిధ కస్టమర్‌లు చాలా భిన్నమైన విషయాలను అర్థం చేసుకునేలా నేను రిజర్వేషన్ చేస్తాను:
- ఎవరైనా భద్రత మరియు ఆడిట్ లాగ్‌లను చూడాలనుకుంటున్నారు;
- ఎవరైనా - మొత్తం అవస్థాపన యొక్క కేంద్రీకృత లాగింగ్;
- మరియు కొంతమందికి, ఉదాహరణకు, బాలన్సర్‌లను మినహాయించి, అప్లికేషన్ లాగ్‌లను మాత్రమే సేకరించడం సరిపోతుంది.
మేము వివిధ "కోరికల జాబితాలను" ఎలా అమలు చేసాము మరియు మేము ఎదుర్కొన్న ఇబ్బందుల గురించి క్రింద కట్ ఉంది.
సిద్ధాంతం: లాగింగ్ సాధనాల గురించి
లాగింగ్ సిస్టమ్ యొక్క భాగాలపై నేపథ్యం
లాగింగ్ చాలా దూరం వచ్చింది, దీని ఫలితంగా లాగ్‌లను సేకరించడం మరియు విశ్లేషించడం కోసం పద్ధతులు అభివృద్ధి చేయబడ్డాయి, ఈ రోజు మనం ఉపయోగిస్తున్నది. 1950లలో, ఫోర్ట్రాన్ స్టాండర్డ్ ఇన్‌పుట్/అవుట్‌పుట్ స్ట్రీమ్‌ల అనలాగ్‌ను ప్రవేశపెట్టింది, ఇది ప్రోగ్రామర్ తన ప్రోగ్రామ్‌ను డీబగ్ చేయడంలో సహాయపడింది. ఆ కాలంలోని ప్రోగ్రామర్‌లకు జీవితాన్ని సులభతరం చేసిన మొదటి కంప్యూటర్ లాగ్‌లు ఇవి. ఈ రోజు మనం వాటిలో లాగింగ్ సిస్టమ్ యొక్క మొదటి భాగాన్ని చూస్తాము - లాగ్ల మూలం లేదా "నిర్మాత".
కంప్యూటర్ సైన్స్ ఇప్పటికీ నిలబడలేదు: కంప్యూటర్ నెట్వర్క్లు కనిపించాయి, మొదటి క్లస్టర్లు ... అనేక కంప్యూటర్లతో కూడిన సంక్లిష్ట వ్యవస్థలు పనిచేయడం ప్రారంభించాయి. ఇప్పుడు సిస్టమ్ నిర్వాహకులు అనేక యంత్రాల నుండి లాగ్‌లను సేకరించవలసి వచ్చింది మరియు ప్రత్యేక సందర్భాలలో వారు సిస్టమ్ వైఫల్యాన్ని పరిశోధించాల్సిన అవసరం ఉన్నట్లయితే వారు OS కెర్నల్ సందేశాలను జోడించవచ్చు. కేంద్రీకృత లాగ్ సేకరణ వ్యవస్థలను వివరించడానికి, 2000ల ప్రారంభంలో ఇది ప్రచురించబడింది , ఇది remote_syslogని ప్రామాణికం చేసింది. ఈ విధంగా మరొక ముఖ్యమైన భాగం కనిపించింది: లాగ్ కలెక్టర్ మరియు వాటి నిల్వ.
లాగ్ల వాల్యూమ్‌లో పెరుగుదల మరియు వెబ్ టెక్నాలజీల విస్తృతమైన పరిచయంతో, వినియోగదారులకు ఏ లాగ్‌లను సౌకర్యవంతంగా చూపించాలనే ప్రశ్న తలెత్తింది. సాధారణ కన్సోల్ సాధనాలు (awk/sed/grep) మరింత అధునాతనమైన వాటితో భర్తీ చేయబడ్డాయి లాగ్ వీక్షకులు - మూడవ భాగం.
లాగ్ల వాల్యూమ్‌లో పెరుగుదల కారణంగా, మరొకటి స్పష్టమైంది: లాగ్‌లు అవసరం, కానీ అవన్నీ కాదు. మరియు వేర్వేరు లాగ్‌లకు వివిధ స్థాయిల సంరక్షణ అవసరం: కొన్ని ఒక రోజులో కోల్పోవచ్చు, మరికొన్ని 5 సంవత్సరాలు నిల్వ చేయాలి. కాబట్టి, డేటా ప్రవాహాలను ఫిల్టర్ చేయడానికి మరియు రూటింగ్ చేయడానికి ఒక భాగం లాగింగ్ సిస్టమ్‌కు జోడించబడింది - దానిని పిలుద్దాం ఫిల్టర్.
స్టోరేజ్ కూడా పెద్ద ఎత్తుకు చేరుకుంది: సాధారణ ఫైల్‌ల నుండి రిలేషనల్ డేటాబేస్‌లకు, ఆపై డాక్యుమెంట్-ఓరియెంటెడ్ స్టోరేజ్‌కి (ఉదాహరణకు, సాగే శోధన). కాబట్టి కలెక్టర్ నుండి నిల్వ వేరు చేయబడింది.
అంతిమంగా, లాగ్ అనే భావన మనం చరిత్ర కోసం భద్రపరచాలనుకుంటున్న సంఘటనల యొక్క ఒక రకమైన వియుక్త స్ట్రీమ్‌కి విస్తరించింది. లేదా బదులుగా, మీరు విచారణ జరపవలసి వస్తే లేదా విశ్లేషణాత్మక నివేదికను రూపొందించాలి...
ఫలితంగా, సాపేక్షంగా తక్కువ వ్యవధిలో, లాగ్ సేకరణ ఒక ముఖ్యమైన ఉపవ్యవస్థగా అభివృద్ధి చెందింది, దీనిని బిగ్ డేటాలోని ఉపవిభాగాలలో ఒకటిగా పేర్కొనవచ్చు.
ఒకప్పుడు "లాగింగ్ సిస్టమ్" కోసం సాధారణ ప్రింట్లు సరిపోతుంటే, ఇప్పుడు పరిస్థితి చాలా మారిపోయింది.
కుబెర్నెట్స్ మరియు లాగ్స్
కుబెర్నెటెస్ మౌలిక సదుపాయాలకు వచ్చినప్పుడు, ఇప్పటికే ఉన్న లాగ్‌లను సేకరించే సమస్య దానిని దాటవేయలేదు. కొన్ని మార్గాల్లో, ఇది మరింత బాధాకరంగా మారింది: మౌలిక సదుపాయాల ప్లాట్‌ఫారమ్‌ను నిర్వహించడం సరళీకృతం చేయడమే కాకుండా, అదే సమయంలో క్లిష్టంగా ఉంటుంది. చాలా పాత సేవలు మైక్రోసర్వీస్‌లకు మారడం ప్రారంభించాయి. లాగ్ల సందర్భంలో, ఇది పెరుగుతున్న లాగ్ మూలాల సంఖ్య, వాటి ప్రత్యేక జీవిత చక్రం మరియు లాగ్ల ద్వారా అన్ని సిస్టమ్ భాగాల సంబంధాలను ట్రాక్ చేయవలసిన అవసరంలో ప్రతిబింబిస్తుంది...
ముందుకు చూస్తే, ఇప్పుడు, దురదృష్టవశాత్తూ, కుబెర్నెట్‌ల కోసం అన్ని ఇతర వాటితో అనుకూలంగా సరిపోలే ప్రామాణిక లాగింగ్ ఎంపిక ఏదీ లేదని నేను చెప్పగలను. సంఘంలో అత్యంత ప్రజాదరణ పొందిన పథకాలు ఈ క్రింది విధంగా ఉన్నాయి:
- ఎవరైనా స్టాక్‌ను విప్పారు EFK (ఎలాస్టిక్ సెర్చ్, ఫ్లూయెంట్, కిబానా);
- ఎవరో ఇటీవల విడుదల చేయడానికి ప్రయత్నిస్తున్నారు లేదా ఉపయోగాలు ;
- нас (మరియు బహుశా మనం మాత్రమే కాదు? ..) నా స్వంత అభివృద్ధితో నేను చాలా సంతృప్తి చెందాను - ...
నియమం ప్రకారం, మేము క్రింది బండిల్‌లను K8s క్లస్టర్‌లలో ఉపయోగిస్తాము (స్వీయ-హోస్ట్ పరిష్కారాల కోసం):
- ;
- .
అయినప్పటికీ, నేను వాటి ఇన్‌స్టాలేషన్ మరియు కాన్ఫిగరేషన్ కోసం సూచనలపై నివసించను. బదులుగా, నేను వారి లోపాలను మరియు సాధారణంగా లాగ్‌లతో పరిస్థితి గురించి మరింత ప్రపంచ ముగింపులపై దృష్టి పెడతాను.
K8sలో లాగ్‌లతో ప్రాక్టీస్ చేయండి
“రోజువారీ చిట్టాలు”, మీలో ఎంతమంది ఉన్నారు?..
చాలా పెద్ద అవస్థాపన నుండి లాగ్ల యొక్క కేంద్రీకృత సేకరణకు గణనీయమైన వనరులు అవసరం, ఇది లాగ్‌లను సేకరించడం, నిల్వ చేయడం మరియు ప్రాసెస్ చేయడం కోసం ఖర్చు చేయబడుతుంది. వివిధ ప్రాజెక్టుల ఆపరేషన్ సమయంలో, మేము వివిధ అవసరాలు మరియు వాటి నుండి ఉత్పన్నమయ్యే కార్యాచరణ సమస్యలను ఎదుర్కొన్నాము.
క్లిక్‌హౌస్‌ని ప్రయత్నిద్దాం
లాగ్‌లను చాలా యాక్టివ్‌గా రూపొందించే అప్లికేషన్‌తో ప్రాజెక్ట్‌లో కేంద్రీకృత నిల్వను చూద్దాం: సెకనుకు 5000 కంటే ఎక్కువ లైన్లు. అతని లాగ్‌లను క్లిక్‌హౌస్‌కి జోడించడం ద్వారా పని చేయడం ప్రారంభిద్దాం.
గరిష్ట నిజ సమయం అవసరమైన వెంటనే, క్లిక్‌హౌస్‌తో 4-కోర్ సర్వర్ ఇప్పటికే డిస్క్ సబ్‌సిస్టమ్‌లో ఓవర్‌లోడ్ చేయబడుతుంది:
మేము వీలైనంత త్వరగా క్లిక్‌హౌస్‌లో వ్రాయడానికి ప్రయత్నిస్తున్నందున ఈ రకమైన లోడ్ అవుతోంది. మరియు డేటాబేస్ పెరిగిన డిస్క్ లోడ్‌తో దీనికి ప్రతిస్పందిస్తుంది, ఇది క్రింది లోపాలను కలిగిస్తుంది:
DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts
పాయింట్ మీరు క్లిక్‌హౌస్‌లో (అవి లాగ్ డేటాను కలిగి ఉంటాయి) వ్రాత కార్యకలాపాల సమయంలో వారి స్వంత ఇబ్బందులను కలిగి ఉంటాయి. వాటిలోకి చొప్పించిన డేటా తాత్కాలిక విభజనను ఉత్పత్తి చేస్తుంది, అది ప్రధాన పట్టికతో విలీనం చేయబడుతుంది. ఫలితంగా, రికార్డింగ్ డిస్క్‌లో చాలా డిమాండ్‌గా మారుతుంది మరియు ఇది పైన పేర్కొన్న నోటీసును అందుకున్న పరిమితికి కూడా లోబడి ఉంటుంది: 1 సెకనులో 300 కంటే ఎక్కువ ఉపవిభజనలు విలీనం చేయబడవు (వాస్తవానికి, ఇది 300 ఇన్‌సర్ట్‌లు సెకనుకు).
ఈ ప్రవర్తనను నివారించడానికి, వీలైనంత పెద్ద ముక్కలుగా మరియు ప్రతి 1 సెకన్లకు 2 సార్లు కంటే ఎక్కువ కాదు. అయినప్పటికీ, పెద్ద పేలుళ్లలో వ్రాయడం వలన మనం క్లిక్‌హౌస్‌లో తక్కువ తరచుగా వ్రాయాలని సూచించింది. ఇది, బఫర్ ఓవర్‌ఫ్లో మరియు లాగ్ల నష్టానికి దారి తీస్తుంది. పరిష్కారం Fluentd బఫర్‌ని పెంచడం, అయితే మెమరీ వినియోగం కూడా పెరుగుతుంది.
వ్యాఖ్య: క్లిక్‌హౌస్‌తో మా పరిష్కారం యొక్క మరొక సమస్యాత్మక అంశం మా విషయంలో (లాగ్హౌస్) విభజన అనుసంధానించబడిన బాహ్య పట్టికల ద్వారా అమలు చేయబడుతుందనే వాస్తవానికి సంబంధించినది. . పెద్ద సమయ విరామాలను శాంపిల్ చేసేటప్పుడు, అధిక RAM అవసరం అనే వాస్తవం ఇది దారితీస్తుంది, ఎందుకంటే మెటాటబుల్ అన్ని విభజనల ద్వారా పునరావృతమవుతుంది - స్పష్టంగా అవసరమైన డేటాను కలిగి ఉండనివి కూడా. అయితే, ఇప్పుడు ఈ విధానం ClickHouse యొక్క ప్రస్తుత వెర్షన్‌ల కోసం సురక్షితంగా వాడుకలో లేదని ప్రకటించవచ్చు (c ).
ఫలితంగా, క్లిక్‌హౌస్‌లో నిజ సమయంలో లాగ్‌లను సేకరించడానికి ప్రతి ప్రాజెక్ట్‌కు తగినంత వనరులు లేవని స్పష్టమవుతుంది (మరింత ఖచ్చితంగా, వాటి పంపిణీ తగినది కాదు). అదనంగా, మీరు ఉపయోగించాల్సి ఉంటుంది аккумулятор, దానికి మేము తరువాత తిరిగి వస్తాము. పైన వివరించిన కేసు వాస్తవమైనది. మరియు ఆ సమయంలో మేము కస్టమర్‌కు సరిపోయే నమ్మకమైన మరియు స్థిరమైన పరిష్కారాన్ని అందించలేకపోయాము మరియు తక్కువ ఆలస్యంతో లాగ్‌లను సేకరించడానికి మమ్మల్ని అనుమతించాము...
సాగే శోధన గురించి ఏమిటి?
సాగే శోధన భారీ పనిభారాన్ని నిర్వహిస్తుంది. అదే ప్రాజెక్ట్‌లో ప్రయత్నిద్దాం. ఇప్పుడు లోడ్ ఇలా కనిపిస్తుంది:
ఎలాస్టిక్‌సెర్చ్ డేటా స్ట్రీమ్‌ను జీర్ణించుకోగలిగింది, అయినప్పటికీ, అటువంటి వాల్యూమ్‌లను దానికి రాయడం CPUని బాగా ఉపయోగించుకుంటుంది. క్లస్టర్‌ను నిర్వహించడం ద్వారా ఇది నిర్ణయించబడుతుంది. సాంకేతికంగా, ఇది సమస్య కాదు, కానీ లాగ్ సేకరణ వ్యవస్థను ఆపరేట్ చేయడానికి మేము ఇప్పటికే సుమారు 8 కోర్లను ఉపయోగిస్తాము మరియు సిస్టమ్‌లో అదనంగా అధికంగా లోడ్ చేయబడిన భాగాన్ని కలిగి ఉన్నాము...
బాటమ్ లైన్: ఈ ఎంపికను సమర్థించవచ్చు, కానీ ప్రాజెక్ట్ పెద్దది మరియు దాని నిర్వహణ కేంద్రీకృత లాగింగ్ సిస్టమ్‌పై గణనీయమైన వనరులను ఖర్చు చేయడానికి సిద్ధంగా ఉంటే మాత్రమే.
అప్పుడు సహజమైన ప్రశ్న తలెత్తుతుంది:
ఏ లాగ్‌లు నిజంగా అవసరం?
విధానాన్ని మార్చడానికి ప్రయత్నిద్దాం: లాగ్‌లు ఏకకాలంలో సమాచారంగా ఉండాలి మరియు కవర్ చేయకూడదు ప్రతి వ్యవస్థలో ఈవెంట్.
మనకు విజయవంతమైన ఆన్‌లైన్ స్టోర్ ఉందని చెప్పండి. ఏ లాగ్‌లు ముఖ్యమైనవి? సాధ్యమైనంత ఎక్కువ సమాచారాన్ని సేకరించడం, ఉదాహరణకు, చెల్లింపు గేట్‌వే నుండి, ఒక గొప్ప ఆలోచన. కానీ ఉత్పత్తి కేటలాగ్‌లోని ఇమేజ్ స్లైసింగ్ సేవ నుండి అన్ని లాగ్‌లు మాకు క్లిష్టమైనవి కావు: లోపాలు మరియు అధునాతన పర్యవేక్షణ మాత్రమే సరిపోతాయి (ఉదాహరణకు, ఈ భాగం ఉత్పత్తి చేసే 500 లోపాల శాతం).
కాబట్టి మేము అనే నిర్ణయానికి వచ్చాము కేంద్రీకృత లాగింగ్ ఎల్లప్పుడూ సమర్థించబడదు. చాలా తరచుగా క్లయింట్ అన్ని లాగ్‌లను ఒకే చోట సేకరించాలని కోరుకుంటారు, అయితే వాస్తవానికి, మొత్తం లాగ్ నుండి, వ్యాపారానికి కీలకమైన షరతులతో కూడిన 5% సందేశాలు మాత్రమే అవసరం:
- కొన్నిసార్లు కంటైనర్ లాగ్ మరియు ఎర్రర్ కలెక్టర్ (ఉదాహరణకు, సెంట్రీ) యొక్క పరిమాణాన్ని మాత్రమే కాన్ఫిగర్ చేయడానికి సరిపోతుంది.
- సంఘటనలను పరిశోధించడానికి ఎర్రర్ నోటిఫికేషన్ మరియు పెద్ద స్థానిక లాగ్ తరచుగా సరిపోవచ్చు.
- మేము ప్రత్యేకంగా ఫంక్షనల్ పరీక్షలు మరియు ఎర్రర్ కలెక్షన్ సిస్టమ్‌లతో రూపొందించిన ప్రాజెక్ట్‌లను కలిగి ఉన్నాము. డెవలపర్‌కు లాగ్‌లు అవసరం లేదు - వారు లోపం జాడల నుండి ప్రతిదీ చూశారు.
జీవితం నుండి ఉదాహరణ
మరొక కథ మంచి ఉదాహరణగా ఉపయోగపడుతుంది. కుబెర్నెటెస్‌ను ప్రవేశపెట్టడానికి చాలా కాలం ముందు అభివృద్ధి చేసిన వాణిజ్య పరిష్కారాన్ని ఇప్పటికే ఉపయోగిస్తున్న మా క్లయింట్‌లలో ఒకరి భద్రతా బృందం నుండి మేము అభ్యర్థనను స్వీకరించాము.
కార్పొరేట్ సమస్య గుర్తింపు సెన్సార్ - క్యూరాడార్‌తో కేంద్రీకృత లాగ్ సేకరణ వ్యవస్థ యొక్క “స్నేహితులను చేసుకోవడం” అవసరం. ఈ సిస్టమ్ సిస్లాగ్ ప్రోటోకాల్ ద్వారా లాగ్‌లను స్వీకరించగలదు మరియు వాటిని FTP నుండి తిరిగి పొందగలదు. అయినప్పటికీ, fluentd కోసం remote_syslog ప్లగ్ఇన్‌తో దీన్ని ఇంటిగ్రేట్ చేయడం తక్షణమే సాధ్యం కాలేదు. (అది తేలింది, ). క్యూరాడార్‌ను సెటప్ చేయడంలో సమస్యలు క్లయింట్ యొక్క భద్రతా బృందం వైపు ఉన్నాయి.
ఫలితంగా, వ్యాపార-క్లిష్టమైన లాగ్‌లలో కొంత భాగం FTP QRadarకి అప్‌లోడ్ చేయబడింది మరియు ఇతర భాగం నేరుగా నోడ్‌ల నుండి రిమోట్ సిస్లాగ్ ద్వారా దారి మళ్లించబడింది. దీని కోసం మేము కూడా వ్రాసాము - బహుశా ఎవరైనా ఇలాంటి సమస్యను పరిష్కరించడంలో సహాయపడవచ్చు... ఫలితంగా వచ్చిన స్కీమ్‌కు ధన్యవాదాలు, క్లయింట్ స్వయంగా క్లిష్టమైన లాగ్‌లను (తనకు ఇష్టమైన సాధనాలను ఉపయోగించి) స్వీకరించారు మరియు విశ్లేషించారు మరియు మేము లాగింగ్ సిస్టమ్ ఖర్చును తగ్గించగలిగాము, కేవలం పోయిన నెల.
మరొక ఉదాహరణ ఏమి చేయకూడదని సూచిస్తుంది. ప్రాసెసింగ్ కోసం మా క్లయింట్‌లలో ఒకరు ప్రతి వినియోగదారు నుండి వచ్చే ఈవెంట్‌లు, మల్టీలైన్‌గా రూపొందించబడ్డాయి నిర్మాణాత్మక అవుట్‌పుట్ లాగ్‌లో సమాచారం. మీరు ఊహించినట్లుగా, అటువంటి లాగ్‌లు చదవడానికి మరియు నిల్వ చేయడానికి చాలా అసౌకర్యంగా ఉన్నాయి.
లాగ్ల కోసం ప్రమాణాలు
ఇటువంటి ఉదాహరణలు లాగ్ సేకరణ వ్యవస్థను ఎంచుకోవడానికి అదనంగా, మీరు అవసరం అని నిర్ధారణకు దారి తీస్తుంది లాగ్‌లను కూడా డిజైన్ చేయండి! ఇక్కడ అవసరాలు ఏమిటి?
- లాగ్‌లు తప్పనిసరిగా మెషిన్-రీడబుల్ ఫార్మాట్‌లో ఉండాలి (ఉదాహరణకు, JSON).
- లాగ్‌లు కాంపాక్ట్‌గా ఉండాలి మరియు సాధ్యమయ్యే సమస్యలను డీబగ్ చేయడానికి లాగింగ్ స్థాయిని మార్చగల సామర్థ్యాన్ని కలిగి ఉండాలి. అదే సమయంలో, ఉత్పత్తి పరిసరాలలో మీరు లాగింగ్ స్థాయి వంటి సిస్టమ్‌లను అమలు చేయాలి హెచ్చరిక లేదా లోపం.
- లాగ్‌లు తప్పనిసరిగా సాధారణీకరించబడాలి, అంటే, లాగ్ ఆబ్జెక్ట్‌లో, అన్ని పంక్తులు ఒకే ఫీల్డ్ రకాన్ని కలిగి ఉండాలి.
నిర్మాణాత్మక లాగ్‌లు నిల్వలోకి లాగ్‌లను లోడ్ చేయడంలో సమస్యలకు దారితీయవచ్చు మరియు వాటి ప్రాసెసింగ్‌లో పూర్తిగా ఆగిపోతుంది. దృష్టాంతంగా, ఇక్కడ లోపం 400తో ఒక ఉదాహరణ ఉంది, ఇది చాలా మంది నిష్ణాతులు లాగ్‌లలో ఖచ్చితంగా ఎదుర్కొన్నారు:
2019-10-29 13:10:43 +0000 [warn]: dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch"
ఎర్రర్ అంటే మీరు రెడీమేడ్ మ్యాపింగ్‌తో ఇండెక్స్‌కు అస్థిరంగా ఉన్న ఫీల్డ్‌ని పంపుతున్నారని అర్థం. వేరియబుల్‌తో nginx లాగ్‌లోని ఫీల్డ్ సరళమైన ఉదాహరణ $upstream_status. ఇది ఒక సంఖ్య లేదా స్ట్రింగ్‌ని కలిగి ఉండవచ్చు. ఉదాహరణకి:
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "17ee8a579e833b5ab9843a0aca10b941", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staffs/265.png", "protocol": "HTTP/1.1", "status": "200", "body_size": "906", "referrer": "https://example.com/staff", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.001", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "127.0.0.1:9000", "upstream_status": "200", "upstream_response_length": "906", "location": "staff"}
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "47fe42807f2a7d8d5467511d7d553a1b", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staff", "protocol": "HTTP/1.1", "status": "200", "body_size": "2984", "referrer": "-", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.010", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "10.100.0.10:9000, 10.100.0.11:9000", "upstream_status": "404, 200", "upstream_response_length": "0, 2984", "location": "staff"}
సర్వర్ 10.100.0.10 404 లోపంతో ప్రతిస్పందించిందని మరియు అభ్యర్థన మరొక కంటెంట్ నిల్వకు పంపబడిందని లాగ్‌లు చూపిస్తున్నాయి. ఫలితంగా, లాగ్‌లలోని విలువ ఇలా మారింది:
"upstream_response_time": "0.001, 0.007"
ఈ పరిస్థితి చాలా సాధారణం, ఇది ప్రత్యేక అర్హత కూడా .
విశ్వసనీయత గురించి ఏమిటి?
మినహాయింపు లేకుండా అన్ని లాగ్‌లు కీలకమైన సందర్భాలు ఉన్నాయి. మరియు దీనితో, పైన ప్రతిపాదించబడిన/చర్చించిన K8ల కోసం సాధారణ లాగ్ సేకరణ పథకాలు సమస్యలను కలిగి ఉన్నాయి.
ఉదాహరణకు, fluentd స్వల్పకాలిక కంటైనర్‌ల నుండి లాగ్‌లను సేకరించదు. మా ప్రాజెక్ట్‌లలో ఒకదానిలో, డేటాబేస్ మైగ్రేషన్ కంటైనర్ 4 సెకన్ల కంటే తక్కువ కాలం జీవించి, ఆపై తొలగించబడింది - సంబంధిత ఉల్లేఖనం ప్రకారం:
"helm.sh/hook-delete-policy": hook-succeeded
దీని కారణంగా, మైగ్రేషన్ ఎగ్జిక్యూషన్ లాగ్ నిల్వలో చేర్చబడలేదు. ఈ విషయంలో రాజకీయాలు సహాయపడతాయి. before-hook-creation.
మరొక ఉదాహరణ డాకర్ లాగ్ రొటేషన్. లాగ్‌లకు యాక్టివ్‌గా వ్రాసే అప్లికేషన్ ఉందని చెప్పండి. సాధారణ పరిస్థితుల్లో, మేము అన్ని లాగ్‌లను ప్రాసెస్ చేస్తాము, కానీ సమస్య కనిపించిన వెంటనే - ఉదాహరణకు, పైన వివరించిన విధంగా తప్పు ఆకృతితో - ప్రాసెసింగ్ ఆగిపోతుంది మరియు డాకర్ ఫైల్‌ను తిప్పుతుంది. ఫలితంగా వ్యాపార-క్లిష్టమైన లాగ్‌లు కోల్పోవచ్చు.
అందుకే లాగ్ స్ట్రీమ్‌లను వేరు చేయడం ముఖ్యం, వాటి భద్రతను నిర్ధారించడానికి అత్యంత విలువైన వాటిని నేరుగా అప్లికేషన్‌లోకి పంపడం పొందుపరచడం. అదనంగా, కొన్ని సృష్టించడానికి ఇది నిరుపయోగంగా ఉండదు లాగ్ల "సంచితం", ఇది క్లిష్టమైన సందేశాలను సేవ్ చేస్తున్నప్పుడు సంక్షిప్త నిల్వ లభ్యతను తట్టుకోగలదు.
చివరగా, మనం దానిని మరచిపోకూడదు ఏదైనా ఉపవ్యవస్థను సరిగ్గా పర్యవేక్షించడం ముఖ్యం. లేకపోతే, ఫ్లూంటెడ్ స్థితిలో ఉన్న పరిస్థితికి వెళ్లడం సులభం CrashLoopBackOff మరియు ఏదైనా పంపదు మరియు ఇది ముఖ్యమైన సమాచారాన్ని కోల్పోతుందని వాగ్దానం చేస్తుంది.
కనుగొన్న
ఈ కథనంలో, మేము డేటాడాగ్ వంటి SaaS పరిష్కారాలను చూడటం లేదు. ఇక్కడ వివరించిన అనేక సమస్యలు లాగ్‌లను సేకరించడంలో ప్రత్యేకత కలిగిన వాణిజ్య సంస్థల ద్వారా ఇప్పటికే ఒక విధంగా లేదా మరొక విధంగా పరిష్కరించబడ్డాయి, అయితే ప్రతి ఒక్కరూ వివిధ కారణాల వల్ల SaaSని ఉపయోగించలేరు. (ప్రధానమైనవి ధర మరియు 152-FZకి అనుగుణంగా ఉంటాయి).
మొదట కేంద్రీకృత లాగ్ సేకరణ సాధారణ పనిలా కనిపిస్తుంది, కానీ ఇది అస్సలు కాదు. గుర్తుంచుకోవడం ముఖ్యం:
- ఇతర సిస్టమ్‌ల కోసం పర్యవేక్షణ మరియు దోష సేకరణను కాన్ఫిగర్ చేయవచ్చు అయితే క్లిష్టమైన భాగాలను మాత్రమే వివరంగా లాగిన్ చేయాలి.
- అనవసరమైన లోడ్‌ను జోడించకుండా ఉత్పత్తిలో లాగ్‌లు కనిష్టంగా ఉంచాలి.
- లాగ్‌లు తప్పనిసరిగా మెషిన్ రీడబుల్‌గా ఉండాలి, సాధారణీకరించబడతాయి మరియు కఠినమైన ఆకృతిని కలిగి ఉండాలి.
- నిజంగా క్లిష్టమైన లాగ్‌లు ప్రత్యేక స్ట్రీమ్‌లో పంపబడాలి, అవి ప్రధాన వాటి నుండి వేరు చేయబడాలి.
- లాగ్ అక్యుమ్యులేటర్‌ను పరిగణనలోకి తీసుకోవడం విలువైనది, ఇది అధిక లోడ్ యొక్క పేలుళ్ల నుండి మిమ్మల్ని కాపాడుతుంది మరియు నిల్వపై లోడ్ని మరింత ఏకరీతిగా చేస్తుంది.
ఈ సాధారణ నియమాలు, ప్రతిచోటా వర్తింపజేస్తే, పైన వివరించిన సర్క్యూట్‌లు పని చేయడానికి అనుమతిస్తాయి - అవి ముఖ్యమైన భాగాలు (బ్యాటరీ) లేనప్పటికీ. మీరు అటువంటి సూత్రాలకు కట్టుబడి ఉండకపోతే, పని మిమ్మల్ని మరియు అవస్థాపనను సిస్టమ్ యొక్క మరొక అత్యంత లోడ్ చేయబడిన (మరియు అదే సమయంలో అసమర్థమైన) భాగానికి సులభంగా దారి తీస్తుంది.
PS
మా బ్లాగులో కూడా చదవండి:
- «";
- «";
- «".
మూలం: www.habr.com