యూరీ బుష్మెలెవ్ "లాగ్‌లను సేకరించి పంపిణీ చేసే రంగంలో రేక్ యొక్క మ్యాప్" - నివేదిక యొక్క ట్రాన్స్క్రిప్ట్

సిస్టమ్‌లో లాగ్‌లు ఒక ముఖ్యమైన భాగం, ఇది ఊహించిన విధంగా పని చేస్తుందని (లేదా పని చేయడం లేదని) అర్థం చేసుకోవడానికి మిమ్మల్ని అనుమతిస్తుంది. మైక్రోసర్వీస్ ఆర్కిటెక్చర్‌లో, లాగ్‌లతో పనిచేయడం అనేది ప్రత్యేక ఒలింపియాడ్ కోసం ప్రత్యేక క్రమశిక్షణగా మారుతుంది. అనేక ప్రశ్నలను ఒకేసారి పరిష్కరించాలి:

• అప్లికేషన్ నుండి లాగ్‌లను ఎలా వ్రాయాలి;
• లాగ్లను ఎక్కడ వ్రాయాలి;
• నిల్వ మరియు ప్రాసెసింగ్ కోసం లాగ్‌లను ఎలా పంపిణీ చేయాలి;
• లాగ్‌లను ఎలా ప్రాసెస్ చేయాలి మరియు నిల్వ చేయాలి.

ప్రస్తుతం జనాదరణ పొందిన కంటైనర్ టెక్నాలజీల ఉపయోగం సమస్యను పరిష్కరించడానికి ఎంపికల ఫీల్డ్‌కు రేక్ పైన ఇసుకను జోడిస్తుంది.

యూరి బుష్మెలెవ్ యొక్క నివేదిక "లాగ్‌లను సేకరించి పంపిణీ చేసే రంగంలో రేకుల మ్యాప్" యొక్క ట్రాన్స్క్రిప్ట్ సరిగ్గా ఇదే.

ఆసక్తి ఉన్న ఎవరైనా, దయచేసి పిల్లిని చూడండి.

నా పేరు యూరి బుష్మెలెవ్. నేను Lazadaలో పని చేస్తున్నాను. ఈ రోజు నేను మా లాగ్‌లను ఎలా తయారు చేసాము, వాటిని ఎలా సేకరించాము మరియు అక్కడ ఏమి వ్రాస్తాము అనే దాని గురించి మాట్లాడుతాను.

మనం ఎక్కడి నుండి వచ్చాము? మనం ఎవరం? లజాడా ఆగ్నేయాసియాలోని ఆరు దేశాల్లో నంబర్ 1 ఆన్‌లైన్ రిటైలర్. ఈ దేశాలన్నీ మా డేటా సెంటర్లలో పంపిణీ చేయబడ్డాయి. ప్రస్తుతం మొత్తం 4 డేటా సెంటర్లు ఉన్నాయి. ఇది ఎందుకు ముఖ్యమైనది? ఎందుకంటే కేంద్రాల మధ్య చాలా బలహీనమైన లింక్ ఉన్నందున కొన్ని నిర్ణయాలు తీసుకున్నాయి. మాకు మైక్రోసర్వీస్ ఆర్కిటెక్చర్ ఉంది. మేము ఇప్పటికే 80 మైక్రోసర్వీస్‌లను కలిగి ఉన్నామని నేను ఆశ్చర్యపోయాను. నేను లాగ్‌లతో టాస్క్‌ను ప్రారంభించినప్పుడు, వాటిలో 20 మాత్రమే ఉన్నాయి. ఇంకా చాలా పెద్ద PHP లెగసీ ఉంది, దానితో నేను జీవించాలి మరియు సహించవలసి ఉంటుంది. ఇవన్నీ ప్రస్తుతం మొత్తం సిస్టమ్‌కు నిమిషానికి 6 మిలియన్లకు పైగా సందేశాలను ఉత్పత్తి చేస్తున్నాయి. తర్వాత మనం దీనితో ఎలా జీవించడానికి ప్రయత్నిస్తున్నామో మరియు ఇది ఎందుకు అని నేను చూపిస్తాను.

మీరు ఈ 6 మిలియన్ సందేశాలతో ఎలాగైనా జీవించాలి. వారితో మనం ఏమి చేయాలి? మీకు అవసరమైన 6 మిలియన్ సందేశాలు:

• యాప్ నుండి పంపండి
• డెలివరీ కోసం అంగీకరించండి
• విశ్లేషణ మరియు నిల్వ కోసం పంపిణీ చేయండి.
• విశ్లేషించడానికి
• దానిని ఎలాగైనా నిల్వ చేయండి.

మూడు మిలియన్ల సందేశాలు కనిపించినప్పుడు, నేను దాని గురించి చూశాను. ఎందుకంటే మేము కేవలం కొన్ని పెన్నీలతో ప్రారంభించాము. అప్లికేషన్ లాగ్స్ అక్కడ వ్రాయబడి ఉన్నాయని స్పష్టంగా తెలుస్తుంది. ఉదాహరణకు, నేను డేటాబేస్కు కనెక్ట్ చేయలేకపోయాను, నేను డేటాబేస్కు కనెక్ట్ చేయగలిగాను కానీ నేను ఏమీ చదవలేకపోయాను. కానీ ఇది కాకుండా, మా మైక్రోసర్వీస్‌లు ప్రతి ఒక్కటి యాక్సెస్ లాగ్‌ను కూడా వ్రాస్తాయి. మైక్రోసర్వీస్‌కు వచ్చే ప్రతి అభ్యర్థన లాగ్‌లో నమోదు చేయబడుతుంది. ఎందుకు ఇలా చేస్తున్నాం? డెవలపర్‌లు ట్రేస్ చేయాలనుకుంటున్నారు. ప్రతి యాక్సెస్ లాగ్ ఒక ట్రేసిడ్ ఫీల్డ్‌ను కలిగి ఉంటుంది, దీనిని ఉపయోగించి ప్రత్యేక ఇంటర్‌ఫేస్ మొత్తం గొలుసును విడదీస్తుంది మరియు ట్రేస్‌ను అందంగా ప్రదర్శిస్తుంది. అభ్యర్థన ఎలా జరిగిందో ట్రేస్ చూపిస్తుంది మరియు ఇది ఏదైనా గుర్తించబడని చెత్తతో త్వరగా వ్యవహరించడంలో మా డెవలపర్‌లకు సహాయపడుతుంది.

దీనితో ఎలా జీవించాలి? ఇప్పుడు నేను ఎంపికల రంగాన్ని క్లుప్తంగా వివరిస్తాను - ఈ సమస్య సాధారణంగా ఎలా పరిష్కరించబడుతుంది. లాగ్‌లను సేకరించడం, ప్రసారం చేయడం మరియు నిల్వ చేయడం వంటి సమస్యను ఎలా పరిష్కరించాలి.

అప్లికేషన్ నుండి ఎలా వ్రాయాలి? వివిధ మార్గాలు ఉన్నాయని స్పష్టమైంది. ముఖ్యంగా, మా నాగరీకమైన సహచరులు మాకు చెప్పినట్లు ఉత్తమ అభ్యాసం ఉంది. మా తాతలు చెప్పినట్లు పాత పాఠశాలలు రెండు రకాలు. ఇతర మార్గాలు ఉన్నాయి.

లాగ్‌లను సేకరించే పరిస్థితి దాదాపు అదే. ఈ నిర్దిష్ట భాగాన్ని పరిష్కరించడానికి చాలా ఎంపికలు లేవు. వాటిలో ఇప్పటికే చాలా ఉన్నాయి, కానీ ఇంకా చాలా లేవు.

కానీ డెలివరీ మరియు తదుపరి విశ్లేషణతో, వైవిధ్యాల సంఖ్య పేలడం ప్రారంభమవుతుంది. నేను ఇప్పుడు ప్రతి ఎంపికను వివరించను. అంశంపై ఆసక్తి ఉన్న ప్రతి ఒక్కరికీ ప్రధాన ఎంపికలు బాగా తెలిసినవని నేను భావిస్తున్నాను.

మేము లాజాడాలో దీన్ని ఎలా చేసాము మరియు వాస్తవానికి ఇది ఎలా ప్రారంభించబడింది అని నేను మీకు చూపిస్తాను.

ఒక సంవత్సరం క్రితం నేను లాజాడాకు వచ్చాను మరియు లాగ్‌ల గురించి ప్రాజెక్ట్‌కి పంపబడ్డాను. ఇది ఇలాంటిదే. అప్లికేషన్ లాగ్ stdout మరియు stderr లకు వ్రాయబడింది. అంతా ఫ్యాషనబుల్ గా చేశారు. కానీ డెవలపర్లు దానిని ప్రామాణిక ప్రవాహాల నుండి విసిరారు, ఆపై ఏదో ఒకవిధంగా మౌలిక సదుపాయాల నిపుణులు దానిని కనుగొంటారు. ఇన్‌ఫ్రాస్ట్రక్చర్ స్పెషలిస్ట్‌లు మరియు డెవలపర్‌ల మధ్య, విడుదల చేసేవారు కూడా ఉన్నారు: “ఉహ్... సరే, వాటిని షెల్‌తో ఫైల్‌లో చుట్టి చూద్దాం, అంతే.” మరియు ఇదంతా ఒక కంటైనర్‌లో ఉన్నందున, వారు దానిని కంటైనర్‌లోనే చుట్టి, లోపల ఉన్న కేటలాగ్‌ను మ్యాప్ చేసి అక్కడ ఉంచారు. దాని నుండి ఏమి వచ్చిందో అందరికీ చాలా స్పష్టంగా ఉందని నేను భావిస్తున్నాను.

ప్రస్తుతానికి కొంచెం ముందుకు చూద్దాం. మేము ఈ లాగ్‌లను ఎలా పంపిణీ చేసాము? ఎవరో td-ఏజెంట్‌ని ఎంచుకున్నారు, ఇది నిజానికి నిష్ణాతులు, కానీ చాలా నిష్ణాతులు కాదు. ఈ రెండు ప్రాజెక్ట్‌ల మధ్య ఉన్న సంబంధం నాకు ఇప్పటికీ అర్థం కాలేదు, కానీ అవి ఒకే విషయంగా ఉన్నట్లు అనిపిస్తుంది. మరియు రూబీలో వ్రాయబడిన ఈ fluentd, లాగ్ ఫైల్‌లను చదివి, వాటిని కొన్ని రకాల క్రమబద్ధతను ఉపయోగించి JSONలోకి అన్వయించింది. అప్పుడు నేను వారిని కాఫ్కాకు పంపించాను. అంతేకాకుండా, కాఫ్కాలో మేము ప్రతి APIకి 4 ప్రత్యేక అంశాలను కలిగి ఉన్నాము. ఎందుకు 4? ప్రత్యక్షంగా ఉన్నందున, స్టేజింగ్ ఉంది మరియు stdout మరియు stderr ఉన్నందున. డెవలపర్లు వాటిని సృష్టిస్తారు మరియు అవస్థాపన డెవలపర్లు వాటిని తప్పనిసరిగా కాఫ్కాలో సృష్టించాలి. అంతేకాకుండా, కాఫ్కాను మరొక విభాగం నియంత్రించింది. అందువల్ల, ప్రతి ఏపీకి 4 టాపిక్‌లను రూపొందించే విధంగా టిక్కెట్‌ను రూపొందించడం అవసరం. అందరూ దాని గురించి మర్చిపోయారు. సాధారణంగా, చెత్త మరియు ఫస్ ఉంది.

దీనితో మేము తరువాత ఏమి చేసాము? మేము దానిని కాఫ్కాకు పంపాము. కాఫ్కా నుండి సగం లాగ్‌లు లాగ్‌స్టాష్‌కు వెళ్లాయి. మిగిలిన సగం లాగ్లను విభజించారు. కొందరు ఒక గ్రేలాగ్‌కి, కొందరు మరొక గ్రేలాగ్‌కి వెళ్లారు. ఫలితంగా, ఇవన్నీ ఒక సాగే శోధన క్లస్టర్‌లోకి వెళ్లాయి. అంటే, ఈ గందరగోళమంతా అక్కడితో ముగిసింది. అలా చేయవద్దు!

పై నుంచి చూస్తే ఇదే అనిపిస్తుంది. అలా చేయవద్దు! ఇక్కడ సమస్య ప్రాంతాలు వెంటనే సంఖ్యలతో గుర్తించబడతాయి. వాస్తవానికి వాటిలో చాలా ఉన్నాయి, కానీ 6 నిజంగా సమస్యాత్మకమైనవి, వాటి గురించి ఏదైనా చేయాలి. వాటి గురించి ఇప్పుడు విడిగా చెబుతాను.

ఇక్కడ (1,2,3) మేము ఫైళ్లను వ్రాస్తాము మరియు తదనుగుణంగా, ఇక్కడ ఒకేసారి మూడు రేక్‌లు ఉన్నాయి.

మొదటిది (1) మనం వాటిని ఎక్కడో వ్రాయాలి. ఫైల్‌కి నేరుగా వ్రాయగల సామర్థ్యాన్ని APIకి ఇవ్వడం ఎల్లప్పుడూ కోరదగినది కాదు. APIని కంటైనర్‌లో వేరుచేయడం లేదా మరింత మెరుగ్గా చదవడం మాత్రమే అవసరం. నేను సిస్టమ్ అడ్మినిస్ట్రేటర్‌ని, కాబట్టి ఈ విషయాలపై నాకు కొంచెం ప్రత్యామ్నాయ వీక్షణ ఉంది.

రెండవ అంశం (2,3) మనకు APIకి చాలా అభ్యర్థనలు వస్తున్నాయి. API ఫైల్‌కి చాలా డేటాను వ్రాస్తుంది. ఫైళ్లు పెరుగుతున్నాయి. మనం వాటిని తిప్పాలి. ఎందుకంటే లేకపోతే మీరు అక్కడ ఏ డిస్క్‌లను నిల్వ చేయలేరు. వాటిని తిప్పడం చెడ్డది ఎందుకంటే అవి షెల్ ద్వారా డైరెక్టరీకి దారి మళ్లించడం ద్వారా తయారు చేయబడ్డాయి. మేము దానిని సవరించడానికి మార్గం లేదు. హ్యాండిల్‌లను మళ్లీ తెరవమని మీరు అప్లికేషన్‌కు చెప్పలేరు. ఎందుకంటే డెవలపర్‌లు మిమ్మల్ని మూర్ఖుడిలా చూస్తారు: “ఏం వివరణలు? మేము సాధారణంగా stdoutకి వ్రాస్తాము." ఇన్‌ఫ్రాస్ట్రక్చర్ డెవలపర్‌లు లాగ్రోటేట్ చేయడానికి కాపీ ట్రంక్‌ని తయారు చేశారు, ఇది ఫైల్‌ను కాపీ చేస్తుంది మరియు అసలైనదాన్ని లిప్యంతరిస్తుంది. దీని ప్రకారం, ఈ కాపీ ప్రక్రియల మధ్య డిస్క్ ఖాళీ సాధారణంగా అయిపోతుంది.

(4) మేము వేర్వేరు APIలలో వేర్వేరు ఫార్మాట్‌లను కలిగి ఉన్నాము. అవి కొద్దిగా భిన్నంగా ఉన్నాయి, కానీ regexp భిన్నంగా వ్రాయవలసి వచ్చింది. ఇవన్నీ పప్పెట్‌చే నియంత్రించబడినందున, వారి స్వంత బొద్దింకలతో పెద్ద సంఖ్యలో తరగతులు ఉన్నాయి. అదనంగా, ఎక్కువ సమయం td-ఏజెంట్ జ్ఞాపకశక్తిని తినవచ్చు, తెలివితక్కువది కావచ్చు, అది పని చేస్తున్నట్లు నటిస్తుంది మరియు ఏమీ చేయదు. బయటి నుండి అతను ఏమీ చేయడం లేదని అర్థం చేసుకోవడం అసాధ్యం. ఉత్తమంగా, అతను పడిపోతాడు మరియు ఎవరైనా అతనిని తర్వాత తీసుకుంటారు. మరింత ఖచ్చితంగా, ఒక హెచ్చరిక వస్తుంది, మరియు ఎవరైనా వెళ్లి దానిని తమ చేతులతో పెంచుతారు.

(6) మరియు అత్యంత చెత్త మరియు వ్యర్థాలు సాగే శోధన. ఎందుకంటే అది పాత వెర్షన్. ఎందుకంటే ఆ సమయంలో మాకు అంకితభావంతో కూడిన మాస్టర్లు లేరు. ఫీల్డ్‌లు అతివ్యాప్తి చెందగల వైవిధ్య లాగ్‌లను మేము కలిగి ఉన్నాము. వేర్వేరు అప్లికేషన్‌ల నుండి వేర్వేరు లాగ్‌లను ఒకే ఫీల్డ్ పేర్లతో వ్రాయవచ్చు, కానీ లోపల వేరే డేటా ఉండవచ్చు. అంటే, ఒక లాగ్ ఫీల్డ్‌లో పూర్ణాంకంతో వస్తుంది, ఉదాహరణకు, స్థాయి. లెవెల్ ఫీల్డ్‌లో స్ట్రింగ్‌తో మరొక లాగ్ వస్తుంది. స్టాటిక్ మ్యాపింగ్ లేనప్పుడు, ఇది చాలా అద్భుతమైన విషయం. ఒకవేళ, ఎలాస్టిక్‌సెర్చ్‌లో సూచికను తిప్పిన తర్వాత, ముందుగా స్ట్రింగ్‌తో సందేశం వస్తే, మనం సాధారణంగా జీవిస్తాము. అయితే మొదటిది పూర్ణాంకం నుండి వచ్చినట్లయితే, స్ట్రింగ్ నుండి వచ్చిన అన్ని తదుపరి సందేశాలు విస్మరించబడతాయి. ఎందుకంటే ఫీల్డ్ రకం సరిపోలలేదు.

మేము ఈ ప్రశ్నలు అడగడం ప్రారంభించాము. నిందించే వారి కోసం చూడకూడదని మేము నిర్ణయించుకున్నాము.

కానీ ఏదో ఒకటి చేయాలి! స్పష్టమైన విషయం ఏమిటంటే, మనం ప్రమాణాలను ఏర్పాటు చేయాలి. మేము ఇప్పటికే కొన్ని ప్రమాణాలను కలిగి ఉన్నాము. మేము కొంచెం తరువాత కొన్ని ప్రారంభించాము. అదృష్టవశాత్తూ, ఆ సమయంలో అన్ని APIల కోసం ఒకే లాగ్ ఫార్మాట్ ఇప్పటికే ఆమోదించబడింది. ఇది సేవల మధ్య పరస్పర చర్య కోసం నేరుగా ప్రమాణాలలో వ్రాయబడింది. దీని ప్రకారం, లాగ్‌లను స్వీకరించాలనుకునే వారు వాటిని ఈ ఫార్మాట్‌లో వ్రాయాలి. ఎవరైనా ఈ ఫార్మాట్‌లో లాగ్‌లను వ్రాయకపోతే, మేము దేనికీ హామీ ఇవ్వము.

తరువాత, నేను లాగ్‌లను రికార్డ్ చేయడం, పంపిణీ చేయడం మరియు సేకరించడం వంటి పద్ధతుల కోసం ఏకీకృత ప్రమాణాన్ని సృష్టించాలనుకుంటున్నాను. వాస్తవానికి, వాటిని ఎక్కడ వ్రాయాలి మరియు వాటిని ఎలా అందించాలి. ప్రాజెక్ట్‌లు ఒకే లైబ్రరీని ఉపయోగించినప్పుడు అనువైన పరిస్థితి. Go కోసం ప్రత్యేక లాగింగ్ లైబ్రరీ మరియు PHP కోసం ప్రత్యేక లైబ్రరీ ఉన్నాయి. మన దగ్గర ఉన్న ప్రతి ఒక్కరూ వాటిని ఉపయోగించాలి. ప్రస్తుతానికి ఇందులో 80 శాతం సక్సెస్ అయ్యామని చెప్పొచ్చు. కానీ కొంతమంది కాక్టి తినడం కొనసాగిస్తారు.

మరియు అక్కడ (స్లయిడ్‌లో) "లాగ్‌ల డెలివరీ కోసం SLA" కేవలం కనిపించడం ప్రారంభమవుతుంది. ఇది ఇంకా ఉనికిలో లేదు, కానీ మేము దానిపై పని చేస్తున్నాము. ఎందుకంటే మీరు సెకనుకు N సందేశాల కంటే ఎక్కువ కాకుండా అటువంటి మరియు అటువంటి ప్రదేశానికి అటువంటి ఆకృతిలో వ్రాసినట్లయితే, మేము దానిని అటువంటి మరియు అటువంటి ప్రదేశానికి బట్వాడా చేస్తాము అని ఇన్‌ఫ్రాస్ట్రక్చర్ చెప్పినప్పుడు ఇది చాలా సౌకర్యవంతంగా ఉంటుంది. ఇది చాలా తలనొప్పిని తగ్గిస్తుంది. SLA ఉంటే, ఇది ఖచ్చితంగా అద్భుతమైనది!

మేము సమస్యను ఎలా పరిష్కరించడం ప్రారంభించాము? ప్రధాన సమస్య td-agentతో ఉంది. మా చిట్టాలు ఎక్కడికి పోయాయో స్పష్టంగా తెలియలేదు. అవి డెలివరీ అయ్యాయా? వారు వెళ్తున్నారా? ఏమైనప్పటికీ వారు ఎక్కడ ఉన్నారు? అందువలన, మొదటి పాయింట్ td-agent స్థానంలో నిర్ణయించబడింది. నేను ఇక్కడ దేనితో భర్తీ చేయాలనే ఎంపికలను క్లుప్తంగా వివరించాను.

నిష్ణాతులు. మొదట, నేను అతనిని మునుపటి ఉద్యోగంలో ఎదుర్కొన్నాను మరియు అతను కూడా క్రమానుగతంగా అక్కడ పడిపోయాడు. రెండవది, ఇది అదే విషయం, ప్రొఫైల్‌లో మాత్రమే.

ఫైల్‌బీట్. ఇది మాకు ఎలా సౌకర్యవంతంగా ఉంది? ఎందుకంటే ఇది గోలో ఉంది మరియు మాకు గోలో చాలా నైపుణ్యం ఉంది. తదనుగుణంగా, ఏదైనా జరిగితే, మనం ఏదో ఒకవిధంగా దానిని మన కోసం జోడించవచ్చు. అందుకే మేం తీసుకోలేదు. కాబట్టి మీ కోసం తిరిగి వ్రాయడం ప్రారంభించడానికి ఎటువంటి టెంప్టేషన్ కూడా లేదు.

సిస్టమ్ అడ్మినిస్ట్రేటర్‌కు స్పష్టమైన పరిష్కారం ఈ పరిమాణంలోని అన్ని రకాల సిస్లాగ్‌లు (syslog-ng/rsyslog/nxlog).

లేదా మీ స్వంతంగా ఏదైనా వ్రాయండి, కానీ మేము దీన్ని అలాగే ఫైల్‌బీట్‌ను విస్మరించాము. మీరు ఏదైనా వ్రాస్తే, వ్యాపారానికి ఉపయోగపడేవి రాయడం మంచిది. లాగ్‌లను పంపిణీ చేయడానికి, ఏదైనా రెడీమేడ్ తీసుకోవడం మంచిది.

కాబట్టి, ఎంపిక వాస్తవానికి syslog-ng మరియు rsyslog మధ్య ఎంపికకు వచ్చింది. మేము పప్పెట్‌లో rsyslog కోసం ఇప్పటికే తరగతులు కలిగి ఉన్నందున నేను rsyslog వైపు మొగ్గు చూపాను మరియు వాటి మధ్య స్పష్టమైన తేడా కనిపించలేదు. సిస్లాగ్ అంటే ఏమిటి, సిస్లాగ్ అంటే ఏమిటి. అవును, కొన్ని అధ్వాన్నమైన డాక్యుమెంటేషన్ కలిగి ఉన్నాయి, కొన్ని మెరుగ్గా ఉన్నాయి. ఇతడు ఈ విధంగా చేయవచ్చు, మరొకరు భిన్నంగా చేయవచ్చు.

మరియు rsyslog గురించి కొంచెం. అన్నింటిలో మొదటిది, ఇది చాలా మాడ్యూల్‌లను కలిగి ఉన్నందున ఇది బాగుంది. ఇది మానవులు చదవగలిగే రైనర్‌స్క్రిప్ట్‌ను కలిగి ఉంది (ఆధునిక కాన్ఫిగరేషన్ భాష). ఇది మేము ప్రామాణిక సాధనాలను ఉపయోగించి td-agent యొక్క ప్రవర్తనను అనుకరించగల అద్భుతమైన బోనస్, మరియు అప్లికేషన్‌ల కోసం ఏమీ మారలేదు. అంటే, మేము td-agentని rsyslogకి మారుస్తాము మరియు ప్రస్తుతానికి మిగతావన్నీ వదిలివేస్తాము. మరియు మేము వెంటనే వర్కింగ్ డెలివరీని అందుకుంటాము. తర్వాత, mmnormalize అనేది rsyslogలో ఒక అద్భుతమైన విషయం. ఇది లాగ్‌లను అన్వయించడానికి మిమ్మల్ని అనుమతిస్తుంది, కానీ Grok మరియు regexpతో కాదు. ఇది ఒక వియుక్త సింటాక్స్ చెట్టును చేస్తుంది. కంపైలర్ మూలాలను అన్వయించే విధంగానే ఇది లాగ్‌లను అన్వయిస్తుంది. ఇది చాలా త్వరగా పని చేయడానికి, తక్కువ CPUని వినియోగించుకోవడానికి మిమ్మల్ని అనుమతిస్తుంది మరియు సాధారణంగా, ఇది నిజంగా మంచి విషయం. ఇతర బోనస్‌ల సమూహం ఉన్నాయి. నేను వాటిపై నివసించను.

rsyslog అనేక ఇతర నష్టాలను కలిగి ఉంది. అవి బోనస్‌ల మాదిరిగానే ఉంటాయి. ప్రధాన సమస్యలు ఏమిటంటే, మీరు దీన్ని ఎలా ఉడికించాలో తెలుసుకోవాలి మరియు మీరు సంస్కరణను ఎంచుకోవాలి.

మేము unix సాకెట్‌కు లాగ్‌లను వ్రాయాలని నిర్ణయించుకున్నాము. మరియు /dev/logలో కాదు, ఎందుకంటే అక్కడ మనకు సిస్టమ్ లాగ్‌ల గందరగోళం ఉంది, జర్నాల్డ్ ఈ పైప్‌లైన్‌లో ఉంది. కాబట్టి కస్టమ్ సాకెట్‌కి వ్రాద్దాం. మేము దానిని ప్రత్యేక నియమావళికి జత చేస్తాము. మనం దేనిలోనూ జోక్యం చేసుకోం. ప్రతిదీ పారదర్శకంగా మరియు అర్థమయ్యేలా ఉంటుంది. మేము సరిగ్గా అదే చేసాము. ఈ సాకెట్‌లతో ఉన్న డైరెక్టరీ ప్రమాణీకరించబడింది మరియు అన్ని కంటైనర్‌లకు ఫార్వార్డ్ చేయబడింది. కంటైనర్లు తమకు అవసరమైన సాకెట్‌ను చూడవచ్చు, తెరవవచ్చు మరియు దానికి వ్రాయవచ్చు.

ఫైల్ ఎందుకు కాదు? ఎందుకంటే అందరూ చదివారు Badushechka గురించి వ్యాసం, ఇది ఫైల్‌ను డాకర్‌కు ఫార్వార్డ్ చేయడానికి ప్రయత్నించింది మరియు rsyslogని పునఃప్రారంభించిన తర్వాత, ఫైల్ డిస్క్రిప్టర్ మారిందని మరియు డాకర్ ఈ ఫైల్‌ను కోల్పోయిందని కనుగొనబడింది. ఇది మరేదైనా తెరిచి ఉంచుతుంది, కానీ వారు వ్రాసే సాకెట్ కాదు. మేము ఈ సమస్యను పరిష్కరించాలని నిర్ణయించుకున్నాము మరియు అదే సమయంలో, మేము నిరోధించే సమస్య చుట్టూ పని చేస్తాము.

Rsyslog స్లయిడ్‌పై సూచించిన చర్యలను చేస్తుంది మరియు రిలే లేదా కాఫ్కాకు లాగ్‌లను పంపుతుంది. కాఫ్కా పాత మార్గాన్నే అనుసరిస్తాడు. రిలే - నేను లాగ్‌లను అందించడానికి స్వచ్ఛమైన rsyslogని ఉపయోగించడానికి ప్రయత్నించాను. మెసేజ్ క్యూ లేకుండా, ప్రామాణిక rsyslog సాధనాలను ఉపయోగించడం. సాధారణంగా, ఇది పనిచేస్తుంది.

కానీ వాటిని ఈ భాగం (లాగ్‌స్టాష్/గ్రేలాగ్/ఇఎస్)లోకి ఎలా నెట్టాలి అనే విషయంలో సూక్ష్మ నైపుణ్యాలు ఉన్నాయి. ఈ భాగం (rsyslog-rsyslog) డేటా కేంద్రాల మధ్య ఉపయోగించబడుతుంది. ఇక్కడ కంప్రెస్ చేయబడిన tcp లింక్ ఉంది, ఇది బ్యాండ్‌విడ్త్‌ను సేవ్ చేయడానికి అనుమతిస్తుంది మరియు తదనుగుణంగా, ఛానెల్ అడ్డుపడినప్పుడు మేము మరొక డేటా సెంటర్ నుండి కొన్ని లాగ్‌లను స్వీకరించే సంభావ్యతను పెంచుతుంది. ఎందుకంటే మనకు ఇండోనేషియా ఉంది, ఇక్కడ ప్రతిదీ చెడ్డది. ఇక్కడే నిరంతర సమస్య ఉంది.

అప్లికేషన్ నుండి మేము రికార్డ్ చేసిన లాగ్‌లు ముగింపుకు చేరుకునే అవకాశం ఎంతవరకు ఉందో మనం ఎలా పర్యవేక్షించగలమో ఆలోచించాము? మేము కొలమానాలను రూపొందించాలని నిర్ణయించుకున్నాము. rsyslog దాని స్వంత గణాంకాల సేకరణ మాడ్యూల్‌ను కలిగి ఉంది, ఇది కొన్ని రకాల కౌంటర్‌లను కలిగి ఉంటుంది. ఉదాహరణకు, ఇది మీకు క్యూ యొక్క పరిమాణాన్ని చూపుతుంది లేదా అలాంటి మరియు అటువంటి చర్యలో ఎన్ని సందేశాలు వచ్చాయి. మీరు ఇప్పటికే వారి నుండి ఏదైనా తీసుకోవచ్చు. అదనంగా, ఇది కాన్ఫిగర్ చేయగల అనుకూల కౌంటర్‌లను కలిగి ఉంది మరియు ఇది మీకు చూపుతుంది, ఉదాహరణకు, కొన్ని API రికార్డ్ చేసిన సందేశాల సంఖ్య. తరువాత, నేను పైథాన్‌లో rsyslog_exporter అని వ్రాసాను మరియు మేము అన్నింటినీ ప్రోమేథియస్‌కు పంపాము మరియు గ్రాఫ్‌లను నిర్మించాము. మేము నిజంగా గ్రేలాగ్ మెట్రిక్‌లను కోరుకుంటున్నాము, కానీ వాటిని సెటప్ చేయడానికి మాకు ఇంకా సమయం లేదు.

సమస్యలు ఏమిటి? మా ప్రత్యక్ష ప్రసార APIలు సెకనుకు 50k సందేశాలను వ్రాస్తున్నాయని మేము కనుగొన్నప్పుడు (అకస్మాత్తుగా!) సమస్యలు తలెత్తాయి. ఇది స్టేజింగ్ లేకుండా లైవ్ API మాత్రమే. మరియు గ్రేలాగ్ మాకు సెకనుకు 12 వేల సందేశాలను మాత్రమే చూపుతుంది. మరియు ఒక సహేతుకమైన ప్రశ్న తలెత్తింది: అవశేషాలు ఎక్కడ ఉన్నాయి? దీని నుండి గ్రేలాగ్ కేవలం భరించలేదని మేము నిర్ధారించాము. మేము చూశాము మరియు, నిజానికి, గ్రేలాగ్ మరియు ఎలాస్టిక్‌సెర్చ్ ఈ ప్రవాహాన్ని నిర్వహించలేకపోయాము.

తరువాత, మేము మార్గంలో చేసిన ఇతర ఆవిష్కరణలు.

సాకెట్‌కి వ్రాతలు నిరోధించబడ్డాయి. అది ఎలా జరిగింది? నేను డెలివరీ కోసం rsyslogని ఉపయోగిస్తున్నప్పుడు, ఏదో ఒక సమయంలో డేటా కేంద్రాల మధ్య ఛానెల్ విచ్ఛిన్నమైంది. డెలివరీ ఒక చోట, డెలివరీ మరొక చోట ఆగిపోయింది. ఇవన్నీ rsyslog సాకెట్‌కు వ్రాసే APIలతో మెషీన్‌కు చేరాయి. అక్కడ క్యూ కట్టింది. అప్పుడు unix సాకెట్‌కు వ్రాయడానికి క్యూ, డిఫాల్ట్‌గా 128 ప్యాకెట్‌లు నిండిపోయింది. మరియు అప్లికేషన్‌లోని తదుపరి వ్రాత() బ్లాక్ చేయబడింది. మనం గో అప్లికేషన్స్‌లో ఉపయోగించే లైబ్రరీని చూసినప్పుడు, సాకెట్‌కు రాయడం నాన్-బ్లాకింగ్ మోడ్‌లో జరుగుతుందని అక్కడ వ్రాయబడింది. ఏమీ నిరోధించబడలేదని మేము నిర్ధారించుకున్నాము. ఎందుకంటే మనం చదువుతాం Badushechka గురించి వ్యాసందాని గురించి ఎవరు వ్రాసారు. కానీ ఒక క్షణం ఉంది. ఈ కాల్ చుట్టూ అనంతమైన లూప్ కూడా ఉంది, దీనిలో సందేశాన్ని సాకెట్‌లోకి నెట్టడానికి నిరంతరం ప్రయత్నం జరిగింది. మేము అతనిని గమనించలేదు. నేను లైబ్రరీని తిరిగి వ్రాయవలసి వచ్చింది. అప్పటి నుండి ఇది చాలా సార్లు మార్చబడింది, కానీ ఇప్పుడు మేము అన్ని సబ్‌సిస్టమ్‌లలో నిరోధించడాన్ని వదిలించుకున్నాము. అందువల్ల, మీరు rsyslogని ఆపవచ్చు మరియు ఏదీ క్రాష్ అవ్వదు.

క్యూల పరిమాణాన్ని పర్యవేక్షించడం అవసరం, ఇది ఈ రేక్‌పై అడుగు పెట్టకుండా ఉండటానికి సహాయపడుతుంది. ముందుగా, మేము సందేశాలను కోల్పోవడం ప్రారంభించినప్పుడు మనం పర్యవేక్షించవచ్చు. రెండవది, డెలివరీలో మాకు సమస్యలు ఉన్నాయని మేము పర్యవేక్షించగలము.

మరియు మరొక అసహ్యకరమైన క్షణం - మైక్రోసర్వీస్ ఆర్కిటెక్చర్లో 10 రెట్లు విస్తరించడం చాలా సులభం. మాకు చాలా ఇన్‌కమింగ్ అభ్యర్థనలు లేవు, కానీ ఈ సందేశాలు మరింత ముందుకు ప్రయాణించే గ్రాఫ్ కారణంగా, యాక్సెస్ లాగ్‌ల కారణంగా, మేము వాస్తవానికి లాగ్ లోడ్‌ను దాదాపు పది రెట్లు పెంచుతాము. దురదృష్టవశాత్తూ, ఖచ్చితమైన సంఖ్యలను లెక్కించడానికి నాకు సమయం లేదు, కానీ మైక్రోసర్వీస్‌లు అంటే అవి. ఇది మనసులో ఉంచుకోవాలి. ప్రస్తుతానికి లాగ్ కలెక్షన్ సబ్‌సిస్టమ్ లాజాడాలో ఎక్కువగా లోడ్ చేయబడిందని తేలింది.

సాగే శోధన సమస్యను ఎలా పరిష్కరించాలి? మీరు త్వరగా ఒకే చోట లాగ్‌లను పొందాలంటే, అన్ని మెషీన్‌ల చుట్టూ పరిగెత్తకుండా మరియు వాటిని అక్కడ సేకరించకుండా, ఫైల్ నిల్వను ఉపయోగించండి. ఇది పనికి హామీ ఇవ్వబడుతుంది. ఇది ఏదైనా సర్వర్ నుండి చేయవచ్చు. మీరు అక్కడ డిస్క్‌లను అతికించి, సిస్లాగ్‌ను ఇన్‌స్టాల్ చేయాలి. దీని తర్వాత, మీరు అన్ని లాగ్‌లను ఒకే చోట కలిగి ఉంటారని హామీ ఇవ్వబడుతుంది. అప్పుడు మీరు సాగే శోధన, గ్రేలాగ్ మరియు మరేదైనా నెమ్మదిగా కాన్ఫిగర్ చేయవచ్చు. కానీ మీరు ఇప్పటికే అన్ని లాగ్‌లను కలిగి ఉంటారు, అంతేకాకుండా, తగినంత డిస్క్ శ్రేణులు ఉన్నంత వరకు మీరు వాటిని నిల్వ చేయవచ్చు.

నా నివేదిక సమయంలో, పథకం ఇలా కనిపించడం ప్రారంభించింది. మేము ఆచరణాత్మకంగా ఫైల్‌కు రాయడం మానేశాము. ఇప్పుడు, ఎక్కువగా, మేము మిగిలిన వాటిని ఆఫ్ చేస్తాము. APIని అమలు చేస్తున్న స్థానిక మెషీన్‌లలో, మేము ఫైల్‌లకు వ్రాయడం ఆపివేస్తాము. మొదట, ఫైల్ నిల్వ ఉంది, ఇది చాలా బాగా పనిచేస్తుంది. రెండవది, ఈ యంత్రాలు నిరంతరం ఖాళీగా ఉంటాయి; ఇది నిరంతరం పర్యవేక్షించబడాలి.

లాగ్‌స్టాష్ మరియు గ్రేలాగ్‌తో కూడిన ఈ భాగం, ఇది నిజంగా బయలుదేరుతుంది. అందువల్ల, మనం దానిని వదిలించుకోవాలి. మీరు ఒక విషయం ఎంచుకోవాలి.

మేము లాగ్‌స్టాష్ మరియు కిబానాను తొలగించాలని నిర్ణయించుకున్నాము. ఎందుకంటే మనకు భద్రతా విభాగం ఉంది. ఏ కనెక్షన్? కనెక్షన్ ఏమిటంటే X-ప్యాక్ లేకుండా మరియు షీల్డ్ లేకుండా కిబానా లాగ్‌లకు యాక్సెస్ హక్కులను వేరు చేయడానికి మిమ్మల్ని అనుమతించదు. అందుకే గ్రేలాగ్ తీసుకున్నాం. ఇందులో అన్నీ ఉన్నాయి. నాకు ఇది ఇష్టం లేదు, కానీ అది పని చేస్తుంది. మేము కొత్త హార్డ్‌వేర్‌ను కొనుగోలు చేసాము, అక్కడ తాజా గ్రేలాగ్‌ని ఇన్‌స్టాల్ చేసాము మరియు కఠినమైన ఫార్మాట్‌లతో ఉన్న అన్ని లాగ్‌లను ప్రత్యేక గ్రేలాగ్‌కు బదిలీ చేసాము. మేము సంస్థాగతంగా వివిధ రకాల ఒకేలాంటి ఫీల్డ్‌లతో సమస్యను పరిష్కరించాము.

కొత్త గ్రేలాగ్‌లో సరిగ్గా ఏమి చేర్చబడింది. మేము డాకర్‌లో ప్రతిదీ వ్రాసాము. మేము సర్వర్‌ల సమూహాన్ని తీసుకున్నాము, మూడు కాఫ్కా ఉదంతాలు, 7 గ్రేలాగ్ సర్వర్‌ల వెర్షన్ 2.3 (ఎలాస్టిక్‌సెర్చ్ వెర్షన్ 5 కావాలనుకున్నాము). ఇదంతా హెచ్‌డిడి నుండి దాడుల సమయంలో సేకరించబడింది. మేము సెకనుకు 100 వేల సందేశాల ఇండెక్సింగ్ రేటును చూశాము. వారానికి 140 టెరాబైట్‌ల డేటాను మేము చూశాము.

మరియు మళ్ళీ రేక్! మాకు రెండు విక్రయాలు వస్తున్నాయి. మేము 6 మిలియన్ సందేశాలకు మించి తరలించాము. గ్రేలాగ్‌కి నమలడానికి సమయం లేదు. మళ్లీ ఎలాగోలా బతకాలి.

ఇలా బతికాం. మేము మరికొన్ని సర్వర్‌లు మరియు SSDలను జోడించాము. ప్రస్తుతానికి మనం ఈ విధంగా జీవిస్తున్నాం. ఇప్పుడు మేము ఇప్పటికే సెకనుకు 160k సందేశాలను నమిలేస్తున్నాము. మేము ఇంకా పరిమితిని చేరుకోలేదు, కాబట్టి దీని నుండి మనం ఎంత వరకు బయటపడగలమో అస్పష్టంగా ఉంది.

ఇవే మన భవిష్యత్తు ప్రణాళికలు. వీటిలో, అతి ముఖ్యమైనది బహుశా అధిక లభ్యత. మా దగ్గర అది ఇంకా లేదు. అనేక కార్లు ఒకే విధంగా కాన్ఫిగర్ చేయబడ్డాయి, కానీ ఇప్పటివరకు ప్రతిదీ ఒక కారు ద్వారానే జరుగుతోంది. వారి మధ్య ఫెయిల్‌ఓవర్‌ను సెటప్ చేయడానికి సమయం పడుతుంది.

గ్రేలాగ్ నుండి కొలమానాలను సేకరించండి.

మా బ్యాండ్‌విడ్త్ మరియు మిగతావన్నీ నాశనం చేయని ఒక క్రేజీ APIని కలిగి ఉండేలా రేటు పరిమితిని చేయండి.

చివరకు, డెవలపర్‌లతో ఒక రకమైన SLAకి సంతకం చేయండి, తద్వారా మేము ఇంత ఎక్కువ సేవ చేయవచ్చు. మీరు ఇంకా ఎక్కువ వ్రాస్తే, నన్ను క్షమించండి.

మరియు డాక్యుమెంటేషన్ వ్రాయండి.

క్లుప్తంగా, మేము అనుభవించిన ప్రతిదాని ఫలితాలు. మొదట, ప్రమాణాలు. రెండవది, సిస్లాగ్ కేక్. మూడవదిగా, rsyslog స్లయిడ్‌పై వ్రాసినట్లుగానే పనిచేస్తుంది. మరియు ప్రశ్నలకు వెళ్దాం.

మీ ప్రశ్నలు.

మీ ప్రశ్న: ఎందుకు తీసుకోకూడదని నిర్ణయించుకున్నారు... (ఫైల్‌బీట్?)

సమాధానం: మనం ఒక ఫైల్‌కి వ్రాయాలి. నేను నిజంగా కోరుకోలేదు. మీ API సెకనుకు వేలకొద్దీ సందేశాలను వ్రాసినప్పుడు, మీరు దానిని గంటకు ఒకసారి తిప్పినప్పటికీ, ఇది ఇప్పటికీ ఎంపిక కాదు. మీరు పైపులో వ్రాయవచ్చు. దానికి డెవలపర్లు నన్ను అడిగారు: "మేము వ్రాసే ప్రక్రియ క్రాష్ అయినట్లయితే ఏమి జరుగుతుంది?" నేను వారికి ఏమి సమాధానం చెప్పాలో కనుగొనలేదు మరియు ఇలా అన్నాను: "సరే, సరే, మనం అలా చేయము."

మీ ప్రశ్న: మీరు HDFSకి లాగ్‌లను ఎందుకు వ్రాయకూడదు?

సమాధానం: ఇది తదుపరి దశ. మేము చాలా ప్రారంభంలో దాని గురించి ఆలోచించాము, కానీ ప్రస్తుతానికి దీన్ని చేయడానికి వనరులు లేనందున, ఇది మా దీర్ఘకాలిక పరిష్కారంలో వేలాడుతోంది.

మీ ప్రశ్న: కాలమ్ ఫార్మాట్ మరింత అనుకూలంగా ఉంటుంది.

సమాధానం: నాకు అర్థమైనది. మేము రెండు చేతులతో దాని కోసం ఉన్నాము.

మీ ప్రశ్న: మీరు rsyslogకి వ్రాస్తున్నారు. అక్కడ మీరు TCP మరియు UDP రెండింటినీ ఉపయోగించవచ్చు. అయితే UDP అయితే, మీరు డెలివరీకి ఎలా హామీ ఇస్తారు?

సమాధానం: రెండు పాయింట్లు ఉన్నాయి. ముందుగా, లాగ్‌ల డెలివరీకి మేము హామీ ఇవ్వలేమని నేను వెంటనే అందరికీ చెబుతున్నాను. ఎందుకంటే డెవలపర్లు వచ్చి ఇలా చెప్పినప్పుడు: “అక్కడ ఆర్థిక డేటా రాయడం ప్రారంభిద్దాం మరియు ఏదైనా జరిగితే మీరు దానిని మా కోసం ఎక్కడైనా ఉంచుతారు” అని మేము వారికి సమాధానం ఇస్తాము, “అద్భుతం! సాకెట్‌కు వ్రాయడాన్ని నిరోధించడాన్ని ప్రారంభిద్దాం మరియు లావాదేవీలలో దీన్ని చేయండి, తద్వారా మీరు దానిని మా కోసం సాకెట్‌లో ఉంచుతారని మరియు మేము దానిని అవతలి వైపు నుండి అందుకుంటామని నిర్ధారించుకోండి. మరియు ఈ సమయంలో, ప్రతి ఒక్కరికి వెంటనే ఇది అవసరం లేదు. ఇది అవసరం లేకపోతే, మనం ఏ ప్రశ్నలు అడగాలి? మీరు సాకెట్‌కు వ్రాయడానికి హామీ ఇవ్వకూడదనుకుంటే, మేము డెలివరీకి ఎందుకు హామీ ఇవ్వాలి? మా వంతు ప్రయత్నం చేస్తున్నాం. మేము నిజంగా సాధ్యమైనంత ఎక్కువ మరియు ఉత్తమమైన మార్గంలో బట్వాడా చేయడానికి ప్రయత్నిస్తాము, కానీ మేము 100% హామీని ఇవ్వము. అందువల్ల, అక్కడ ఆర్థిక డేటాను వ్రాయవలసిన అవసరం లేదు. దీని కోసం లావాదేవీలతో కూడిన డేటాబేస్‌లు ఉన్నాయి.

మీ ప్రశ్న: API లాగ్‌లో కొంత సందేశాన్ని రూపొందించి, నియంత్రణను మైక్రోసర్వీస్‌లకు బదిలీ చేసినప్పుడు, వివిధ మైక్రోసర్వీస్‌ల నుండి సందేశాలు తప్పు క్రమంలో వచ్చే సమస్యను మీరు ఎదుర్కొన్నారా? దీనివల్ల గందరగోళం ఏర్పడుతుంది.

సమాధానం: అవి వేర్వేరు ఆర్డర్‌లలో రావడం సాధారణం. దీనికి మీరు సిద్ధం కావాలి. ఎందుకంటే ఏదైనా నెట్‌వర్క్ డెలివరీ ఆర్డర్‌కు హామీ ఇవ్వదు లేదా మీరు దీనిపై ప్రత్యేక వనరులను ఖర్చు చేయాలి. మేము ఫైల్ నిల్వలను తీసుకుంటే, ప్రతి API దాని స్వంత ఫైల్‌లో లాగ్‌లను సేవ్ చేస్తుంది. లేదా బదులుగా, rsyslog వాటిని డైరెక్టరీలుగా క్రమబద్ధీకరిస్తుంది. ప్రతి APIకి దాని స్వంత లాగ్‌లు ఉన్నాయి, మీరు ఇక్కడకు వెళ్లి చూడవచ్చు, ఆపై మీరు ఈ లాగ్‌లోని టైమ్‌స్టాంప్‌ని ఉపయోగించి వాటిని పోల్చవచ్చు. వారు గ్రేలాగ్‌లో చూసేందుకు వెళితే, అవి అక్కడ టైమ్‌స్టాంప్ ద్వారా క్రమబద్ధీకరించబడతాయి. అక్కడ అంతా బాగానే ఉంటుంది.

మీ ప్రశ్న: టైమ్‌స్టాంప్ మిల్లీసెకన్ల వారీగా మారవచ్చు.

సమాధానం: టైమ్‌స్టాంప్ API ద్వారానే రూపొందించబడింది. ఇది నిజానికి, మొత్తం పాయింట్. మాకు NTP ఉంది. API సందేశంలోనే టైమ్‌స్టాంప్‌ను రూపొందిస్తుంది. rsyslog దీన్ని జోడించదు.

మీ ప్రశ్న: డేటా సెంటర్ల మధ్య పరస్పర చర్య చాలా స్పష్టంగా లేదు. డేటా సెంటర్‌లో, లాగ్‌లను ఎలా సేకరించి ప్రాసెస్ చేశారో స్పష్టంగా తెలుస్తుంది. డేటా సెంటర్ల మధ్య పరస్పర చర్య ఎలా జరుగుతుంది? లేదా ప్రతి డేటా సెంటర్ దాని స్వంత జీవితాన్ని గడుపుతుందా?

సమాధానం: దాదాపు. మన దేశంలో ఒక్కో దేశం ఒక్కో డేటా సెంటర్‌లో ఉంటుంది. ప్రస్తుతానికి, ఒక దేశం వేర్వేరు డేటా సెంటర్‌లలో ఉండేలా మాకు స్ప్రెడ్ అవుట్ లేదు. అందువల్ల, వాటిని కలపడం అవసరం లేదు. ప్రతి కేంద్రం లోపల లాగ్ రిలే ఉంటుంది. ఇది Rsyslog సర్వర్. నిజానికి రెండు నిర్వహణ యంత్రాలు. వారిదీ అదే వైఖరి. కానీ ప్రస్తుతానికి, ట్రాఫిక్ వాటిలో ఒకటి గుండా వెళుతుంది. ఇది అన్ని లాగ్‌లను కలుపుతుంది. ఆమెకు ఒక డిస్క్ క్యూ ఉంది. ఇది లాగ్‌లను డౌన్‌లోడ్ చేసి, వాటిని సెంట్రల్ డేటా సెంటర్ (సింగపూర్)కి పంపుతుంది, అక్కడ అవి గ్రేలాగ్‌కు పంపబడతాయి. మరియు ప్రతి డేటా సెంటర్ దాని స్వంత ఫైల్ నిల్వను కలిగి ఉంటుంది. ఒకవేళ మా కనెక్షన్ పోయినట్లయితే, మా వద్ద అన్ని లాగ్‌లు ఉన్నాయి. వారు అక్కడే ఉంటారు. అవి అక్కడే నిల్వ చేయబడతాయి.

మీ ప్రశ్న: అసాధారణ పరిస్థితుల విషయంలో, మీరు అక్కడి నుండి లాగ్‌లను స్వీకరిస్తారా?

సమాధానం: మీరు అక్కడికి (ఫైల్ నిల్వకు) వెళ్లి చూడవచ్చు.

మీ ప్రశ్న: మీరు లాగ్‌లను కోల్పోకుండా ఎలా పర్యవేక్షిస్తారు?

సమాధానం: మేము నిజంగా వాటిని కోల్పోతున్నాము మరియు మేము దానిని పర్యవేక్షిస్తున్నాము. నెల రోజుల క్రితమే పర్యవేక్షణ ప్రారంభించారు. Go APIలు ఉపయోగించే లైబ్రరీలో కొలమానాలు ఉన్నాయి. ఆమె సాకెట్‌కు ఎన్నిసార్లు వ్రాయలేకపోయిందో ఆమె లెక్కించవచ్చు. ప్రస్తుతం అక్కడ ఒక తెలివైన హ్యూరిస్టిక్ ఉంది. అక్కడ బఫర్ ఉంది. ఇది దాని నుండి సాకెట్‌కు సందేశాన్ని వ్రాయడానికి ప్రయత్నిస్తుంది. బఫర్ పొంగిపొర్లితే, అది వాటిని వదలడం ప్రారంభిస్తుంది. మరియు అతను వాటిలో ఎన్ని పడిపోయాడో లెక్కించాడు. అక్కడ మీటర్లు పొంగిపొర్లడం మొదలెడితే మనకే తెలుస్తుంది. వారు ఇప్పుడు ప్రోమేథియస్‌కి కూడా వస్తున్నారు మరియు మీరు గ్రాఫానాలో గ్రాఫ్‌లను చూడవచ్చు. మీరు హెచ్చరికలను సెటప్ చేయవచ్చు. అయితే వాటిని ఎవరికి పంపాలనే దానిపై ఇంకా స్పష్టత రాలేదు.

మీ ప్రశ్న: సాగే శోధనలో మీరు రిడెండెన్సీతో లాగ్‌లను నిల్వ చేస్తారు. మీ వద్ద ఎన్ని ప్రతిరూపాలు ఉన్నాయి?

సమాధానం: ఒక్క గీత.

మీ ప్రశ్న: ఇది కేవలం ఒక లైన్ మాత్రమేనా?

సమాధానం: ఇది మాస్టర్ మరియు ప్రతిరూపం. డేటా రెండు కాపీలలో నిల్వ చేయబడుతుంది.

మీ ప్రశ్న: మీరు rsyslog బఫర్ పరిమాణాన్ని ఎలాగైనా సర్దుబాటు చేసారా?

సమాధానం: మేము కస్టమ్ యునిక్స్ సాకెట్‌కు డేటాగ్రామ్‌లను వ్రాస్తాము. ఇది వెంటనే మనపై 128 కిలోబైట్ల పరిమితిని విధిస్తుంది. మేము దీనికి ఎక్కువ వ్రాయలేము. మేము దీన్ని ప్రామాణికంగా వ్రాసాము. స్టోరేజీలోకి రావాలనుకునే వారు 128 కిలోబైట్లు రాస్తారు. లైబ్రరీలు, అంతేకాకుండా, కత్తిరించబడతాయి మరియు సందేశం కత్తిరించబడిందని జెండా ఉంచబడుతుంది. సందేశం కోసం మా ప్రమాణం ఒక ప్రత్యేక ఫీల్డ్‌ని కలిగి ఉంది, అది రికార్డింగ్ సమయంలో కత్తిరించబడిందో లేదో చూపిస్తుంది. కాబట్టి ఈ క్షణాన్ని కూడా ట్రాక్ చేయడానికి మాకు అవకాశం ఉంది.

ప్రశ్న: మీరు విరిగిన JSON అని వ్రాస్తారా?

సమాధానం: ప్యాకెట్ చాలా పెద్దదిగా ఉన్నందున విరిగిన JSON రిలే సమయంలో అయినా విస్మరించబడుతుంది. లేదా JSONని అన్వయించలేనందున గ్రేలాగ్ విస్మరించబడుతుంది. కానీ పరిష్కరించాల్సిన సూక్ష్మ నైపుణ్యాలు ఉన్నాయి మరియు అవి ఎక్కువగా rsyslogతో ముడిపడి ఉంటాయి. నేను ఇప్పటికే అక్కడ అనేక సమస్యలను పూరించాను, ఇంకా పని చేయాల్సి ఉంది.

ప్రశ్న: కాఫ్కా ఎందుకు? మీరు RabbitMQని ప్రయత్నించారా? అటువంటి లోడ్ల క్రింద గ్రేలాగ్ విఫలమవుతుందా?

సమాధానం: ఇది గ్రేలాగ్‌తో మాకు పని చేయడం లేదు. మరియు గ్రేలాగ్ మా కోసం రూపుదిద్దుకుంటోంది. అతను నిజంగా సమస్యాత్మకుడు. అతను ఒక విచిత్రమైన విషయం. మరియు, వాస్తవానికి, ఇది అవసరం లేదు. నేను rsyslog నుండి నేరుగా సాగే శోధనకు వ్రాసి, ఆపై కిబానా వైపు చూడాలనుకుంటున్నాను. అయితే సెక్యూరిటీ గార్డులతో సమస్యను పరిష్కరించుకోవాలి. మేము గ్రేలాగ్‌ని విసిరివేసి, కిబానాను ఉపయోగించినప్పుడు ఇది మన అభివృద్ధికి సాధ్యమయ్యే ఎంపిక. లాగ్‌స్టాష్‌ని ఉపయోగించడంలో అర్థం లేదు. ఎందుకంటే నేను rsyslogతో కూడా అదే పని చేయగలను. మరియు అది సాగే శోధనకు వ్రాయడానికి ఒక మాడ్యూల్‌ను కలిగి ఉంది. మేము గ్రేలాగ్‌తో ఎలాగైనా జీవించాలని ప్రయత్నిస్తున్నాము. మేము దానిని కొద్దిగా ట్యూన్ చేసాము. కానీ ఇంకా మెరుగుదల కోసం స్థలం ఉంది.

కాఫ్కా గురించి. చారిత్రాత్మకంగా ఇలా జరిగింది. నేను వచ్చినప్పుడు, అది అప్పటికే ఉంది మరియు దానికి లాగ్‌లు ఇప్పటికే వ్రాయబడ్డాయి. మేము కేవలం మా క్లస్టర్‌ను పెంచాము మరియు దానిలోకి లాగ్‌లను తరలించాము. మేము అతని నిర్వహణ, అతను ఎలా భావిస్తున్నాడో మాకు తెలుసు. RabbitMQ విషయానికొస్తే... RabbitMQతో ఇది మాకు పని చేయదు. మరియు RabbitMQ మన కోసం రూపుదిద్దుకుంటోంది. మేము దానిని ఉత్పత్తిలో కలిగి ఉన్నాము మరియు దానితో సమస్యలు ఉన్నాయి. ఇప్పుడు, అమ్మకానికి ముందు, వారు అతనిని ఆకర్షించారు మరియు అతను సాధారణంగా పని చేయడం ప్రారంభించాడు. కానీ అంతకు ముందు నేను దానిని ప్రొడక్షన్‌లోకి విడుదల చేయడానికి సిద్ధంగా లేను. ఇంకొక పాయింట్ ఉంది. గ్రేలాగ్ AMQP 0.9 సంస్కరణను చదవగలదు మరియు rsyslog సంస్కరణ AMQP 1.0ని వ్రాయగలదు. మరియు మధ్యలో ఒక పరిష్కారం లేదు, ఇది రెండింటినీ చేయగలదు. ఇది ఒకటి లేదా మరొకటి. అందువల్ల, ప్రస్తుతానికి కాఫ్కా మాత్రమే. కానీ దాని స్వంత సూక్ష్మ నైపుణ్యాలు కూడా ఉన్నాయి. ఎందుకంటే మనం ఉపయోగించే rsyslog వెర్షన్ యొక్క omkafka rsyslog నుండి తీసివేసిన మొత్తం సందేశ బఫర్‌ను కోల్పోతుంది. ప్రస్తుతానికి మేము దానిని సహించాము.

ప్రశ్న: మీరు ఇప్పటికే కాఫ్కాని కలిగి ఉన్నందున దాన్ని ఉపయోగిస్తున్నారా? ఇకపై ఏ ప్రయోజనం కోసం ఉపయోగించబడదు?

సమాధానం: కాఫ్కా, ఇది డేటా సైన్స్ బృందంచే ఉపయోగించబడుతుంది. ఇది పూర్తిగా ప్రత్యేకమైన ప్రాజెక్ట్, దీని గురించి, దురదృష్టవశాత్తు, నేను ఏమీ చెప్పలేను. నాకు తెలియదు. ఇది డేటా సైన్స్ బృందంచే నిర్వహించబడింది. లాగ్‌లు సృష్టించబడినప్పుడు, మా స్వంతంగా ఇన్‌స్టాల్ చేయకూడదని మేము దానిని ఉపయోగించాలని నిర్ణయించుకున్నాము. ఇప్పుడు మేము గ్రేలాగ్‌ని అప్‌డేట్ చేసాము మరియు అది కాఫ్కా యొక్క పాత వెర్షన్‌ను కలిగి ఉన్నందున మేము అనుకూలతను కోల్పోయాము. మేము మా స్వంతంగా ప్రారంభించవలసి వచ్చింది. అదే సమయంలో, మేము ప్రతి API కోసం ఈ నాలుగు అంశాలను వదిలించుకున్నాము. మేము అందరి కోసం ఒక విస్తృతమైన అంశాన్ని, అన్ని స్టేజింగ్ కోసం ఒక విస్తృతమైన అంశాన్ని రూపొందించాము మరియు అన్నింటినీ అక్కడ ఉంచాము. గ్రేలాగ్ ఇవన్నీ సమాంతరంగా స్క్రాప్ చేస్తుంది.

ప్రశ్న: సాకెట్లతో మనకు ఈ షమానిజం ఎందుకు అవసరం? మీరు కంటైనర్ల కోసం syslog లాగ్ డ్రైవర్‌ని ఉపయోగించేందుకు ప్రయత్నించారా?

సమాధానం: మేము ఈ ప్రశ్న అడిగిన సమయంలో, డాకర్‌తో మా సంబంధం ఉద్రిక్తంగా ఉంది. ఇది డాకర్ 1.0 లేదా 0.9. డాకర్ కూడా వింతగా ఉంది. రెండవది, మీరు దానిలోకి లాగ్‌లను కూడా పుష్ చేస్తే... అది డాకర్ డెమన్ ద్వారా అన్ని లాగ్‌లను తన ద్వారానే పాస్ చేస్తుందనే ధృవీకరించబడని అనుమానం. ఒక API క్రేజీగా మారితే, మిగిలిన APIలు stdout మరియు stderrలను పంపలేని వాస్తవంలో చిక్కుకుపోతాయి. ఇది ఎక్కడికి దారితీస్తుందో నాకు తెలియదు. ఈ స్థలంలో Docker syslog డ్రైవర్‌ని ఉపయోగించాల్సిన అవసరం లేదనే ఫీలింగ్ స్థాయిలో నాకు అనుమానం ఉంది. మా ఫంక్షనల్ టెస్టింగ్ డిపార్ట్‌మెంట్ లాగ్‌లతో దాని స్వంత గ్రేలాగ్ క్లస్టర్‌ని కలిగి ఉంది. వారు డాకర్ లాగ్ డ్రైవర్‌లను ఉపయోగిస్తున్నారు మరియు అక్కడ అంతా బాగానే ఉంది. కానీ వారు వెంటనే GELFని గ్రేలాగ్‌కి వ్రాస్తారు. మేము ఇవన్నీ ప్రారంభించిన సమయంలో, పని చేయడానికి మాకు ఇది అవసరం. బహుశా తరువాత, ఎవరైనా వచ్చి వంద సంవత్సరాలుగా బాగా పనిచేస్తుందని చెప్పినప్పుడు, మేము ప్రయత్నిస్తాము.

ప్రశ్న: మీరు rsyslogని ఉపయోగించి డేటా సెంటర్ల మధ్య డెలివరీ చేస్తారు. కాఫ్కా ఎందుకు కాదు?

సమాధానం: వాస్తవానికి మేము రెండింటినీ చేస్తాము. రెండు కారణాల వల్ల. ఛానెల్ పూర్తిగా చనిపోయినట్లయితే, మా అన్ని లాగ్‌లు, కంప్రెస్డ్ రూపంలో కూడా దాని ద్వారా క్రాల్ చేయబడవు. మరియు కాఫ్కా ప్రక్రియలో వాటిని కోల్పోవడానికి మిమ్మల్ని అనుమతిస్తుంది. ఈ లాగ్‌లు చిక్కుకుపోవడాన్ని మనం ఎలా వదిలించుకుంటాము. మేము ఈ సందర్భంలో నేరుగా కాఫ్కాను ఉపయోగిస్తున్నాము. మన దగ్గర మంచి ఛానెల్ ఉంటే మరియు దానిని ఖాళీ చేయాలనుకుంటే, మేము వారి rsyslogని ఉపయోగిస్తాము. కానీ వాస్తవానికి, మీరు దీన్ని కాన్ఫిగర్ చేయవచ్చు, తద్వారా అది సరిపోని వాటిని పడిపోతుంది. ప్రస్తుతానికి, మేము నేరుగా ఎక్కడో rsyslog డెలివరీని మరియు కాఫ్కాను ఎక్కడో ఉపయోగిస్తాము.

మూలం: www.habr.com