మేము CIAN వద్ద టెరాబైట్‌ల లాగ్‌లను ఎలా మచ్చిక చేసుకున్నాము

అందరికీ హలో, నా పేరు అలెగ్జాండర్, నేను CIANలో ఇంజనీర్‌గా పని చేస్తున్నాను మరియు సిస్టమ్ అడ్మినిస్ట్రేషన్ మరియు ఇన్‌ఫ్రాస్ట్రక్చర్ ప్రక్రియల ఆటోమేషన్‌లో పాల్గొంటున్నాను. మునుపటి కథనాలలో ఒకదానికి చేసిన వ్యాఖ్యలలో, మేము రోజుకు 4 TB లాగ్‌లను ఎక్కడ పొందుతాము మరియు వాటితో మనం ఏమి చేస్తాము అని చెప్పమని అడిగాము. అవును, మాకు చాలా లాగ్‌లు ఉన్నాయి మరియు వాటిని ప్రాసెస్ చేయడానికి ఒక ప్రత్యేక ఇన్‌ఫ్రాస్ట్రక్చర్ క్లస్టర్ సృష్టించబడింది, ఇది సమస్యలను త్వరగా పరిష్కరించడానికి అనుమతిస్తుంది. ఈ కథనంలో నేను ఎప్పటికప్పుడు పెరుగుతున్న డేటా ప్రవాహంతో పని చేయడానికి ఒక సంవత్సరం వ్యవధిలో దానిని ఎలా స్వీకరించాము అనే దాని గురించి మాట్లాడుతాను.

మేము ఎక్కడ ప్రారంభించాము?

గత కొన్ని సంవత్సరాలుగా, cian.ru పై లోడ్ చాలా త్వరగా పెరిగింది మరియు 2018 మూడవ త్రైమాసికం నాటికి, వనరుల ట్రాఫిక్ నెలకు 11.2 మిలియన్ల ప్రత్యేక వినియోగదారులకు చేరుకుంది. ఆ సమయంలో, క్లిష్టమైన సమయాల్లో మేము 40% లాగ్‌లను కోల్పోయాము, అందుకే మేము సంఘటనలను త్వరగా ఎదుర్కోలేకపోయాము మరియు వాటిని పరిష్కరించడానికి చాలా సమయం మరియు కృషిని వెచ్చించాము. మేము కూడా తరచుగా సమస్య యొక్క కారణాన్ని కనుగొనలేకపోయాము మరియు కొంత సమయం తర్వాత అది పునరావృతమవుతుంది. ఇది నరకం మరియు దాని గురించి ఏదైనా చేయవలసి వచ్చింది.

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

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

వేగవంతమైన వృద్ధి యొక్క సవాళ్లు

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

స్కేలింగ్ అనేది క్లస్టర్ ఆచరణాత్మకంగా నిర్వహించలేని స్థితికి మమ్మల్ని నడిపించింది. సెకనుకు 20 వేల సందేశాల చొప్పున లాగ్‌లు రావడం ప్రారంభించినప్పుడు, తరచుగా పనికిరాని రొటేషన్‌ల సంఖ్యను 6 వేలకు పెంచింది మరియు నోడ్‌కు 600 కంటే ఎక్కువ ముక్కలు ఉన్నాయి. 

ఇది RAM యొక్క కేటాయింపుతో సమస్యలకు దారితీసింది మరియు నోడ్ క్రాష్ అయినప్పుడు, అన్ని ముక్కలు ఏకకాలంలో కదలడం ప్రారంభించాయి, ట్రాఫిక్‌ను గుణించడం మరియు ఇతర నోడ్‌లను లోడ్ చేయడం ద్వారా క్లస్టర్‌కు డేటాను వ్రాయడం దాదాపు అసాధ్యం. మరియు ఈ కాలంలో మేము లాగ్‌లు లేకుండా మిగిలిపోయాము. మరియు సర్వర్‌తో సమస్య ఉంటే, మేము ప్రాథమికంగా క్లస్టర్‌లో 1/10ని కోల్పోయాము. పెద్ద సంఖ్యలో చిన్న సూచికలు సంక్లిష్టతను జోడించాయి.

లాగ్‌లు లేకుండా, మేము సంఘటనకు గల కారణాలను అర్థం చేసుకోలేకపోయాము మరియు త్వరగా లేదా తరువాత మళ్లీ అదే రేక్‌పై అడుగు పెట్టగలము మరియు మా బృందం యొక్క భావజాలంలో ఇది ఆమోదయోగ్యం కాదు, ఎందుకంటే మా పని యంత్రాంగాలన్నీ దీనికి విరుద్ధంగా రూపొందించబడ్డాయి - ఎప్పుడూ పునరావృతం కాదు అదే సమస్యలు. దీన్ని చేయడానికి, ఆన్-డ్యూటీ ఇంజనీర్ల బృందం మెట్రిక్‌ల నుండి మాత్రమే కాకుండా లాగ్‌ల నుండి కూడా హెచ్చరికలను పర్యవేక్షిస్తుంది కాబట్టి, లాగ్‌ల పూర్తి వాల్యూమ్ మరియు వాటి డెలివరీ దాదాపు నిజ సమయంలో మాకు అవసరం. సమస్య స్థాయిని అర్థం చేసుకోవడానికి, ఆ సమయంలో లాగ్‌ల మొత్తం వాల్యూమ్ రోజుకు 2 TB. 

లాగ్‌ల నష్టాన్ని పూర్తిగా తొలగించడానికి మరియు ELK క్లస్టర్‌కు వాటి డెలివరీ సమయాన్ని ఫోర్స్ మేజ్యూర్ సమయంలో గరిష్టంగా 15 నిమిషాలకు తగ్గించడానికి మేము ఒక లక్ష్యాన్ని నిర్దేశించాము (మేము తర్వాత ఈ సంఖ్యపై అంతర్గత KPIగా ఆధారపడతాము).

కొత్త రొటేషన్ మెకానిజం మరియు హాట్-వార్మ్ నోడ్స్

మేము సాగే శోధన సంస్కరణను 5.5.2 నుండి 6.4.3కి నవీకరించడం ద్వారా క్లస్టర్ మార్పిడిని ప్రారంభించాము. మరోసారి మా వెర్షన్ 5 క్లస్టర్ మరణించింది, మరియు మేము దాన్ని ఆపివేయాలని మరియు పూర్తిగా నవీకరించాలని నిర్ణయించుకున్నాము - ఇప్పటికీ లాగ్‌లు లేవు. కాబట్టి మేము ఈ పరివర్తనను కేవలం రెండు గంటల్లో చేసాము.

ఈ దశలో అత్యంత పెద్ద-స్థాయి పరివర్తన ఏమిటంటే, అపాచీ కాఫ్కాను మూడు నోడ్‌లలో కోఆర్డినేటర్‌తో ఇంటర్మీడియట్ బఫర్‌గా అమలు చేయడం. ElasticSearchతో సమస్యల సమయంలో లాగ్‌లను కోల్పోకుండా సందేశ బ్రోకర్ మమ్మల్ని రక్షించారు. అదే సమయంలో, మేము క్లస్టర్‌కు 2 నోడ్‌లను జోడించాము మరియు డేటా సెంటర్‌లోని వేర్వేరు రాక్‌లలో ఉన్న మూడు "హాట్" నోడ్‌లతో హాట్-వార్మ్ ఆర్కిటెక్చర్‌కు మారాము. మేము ఎట్టి పరిస్థితుల్లోనూ కోల్పోకూడని మాస్క్‌ని ఉపయోగించి వారికి లాగ్‌లను దారి మళ్లించాము - nginx, అలాగే అప్లికేషన్ ఎర్రర్ లాగ్‌లు. చిన్న లాగ్‌లు మిగిలిన నోడ్‌లకు పంపబడ్డాయి - డీబగ్, హెచ్చరిక మొదలైనవి, మరియు 24 గంటల తర్వాత, “హాట్” నోడ్‌ల నుండి “ముఖ్యమైన” లాగ్‌లు బదిలీ చేయబడ్డాయి.

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

క్లస్టర్ ఆప్టిమైజేషన్

అయినా సమస్యల నుంచి పూర్తిగా బయటపడలేదు. దురదృష్టవశాత్తు, చిన్న సూచికలు ఇప్పటికీ కనిపించాయి: అవి పేర్కొన్న వాల్యూమ్‌ను చేరుకోలేదు, తిప్పబడలేదు మరియు మూడు రోజుల కంటే పాత ఇండెక్స్‌లను గ్లోబల్ క్లీనింగ్ చేయడం ద్వారా తొలగించబడ్డాయి, ఎందుకంటే మేము తేదీ ద్వారా భ్రమణాన్ని తీసివేసాము. క్లస్టర్ నుండి ఇండెక్స్ పూర్తిగా అదృశ్యం కావడం మరియు ఉనికిలో లేని ఇండెక్స్‌కు వ్రాయడానికి చేసిన ప్రయత్నం మేము నిర్వహణ కోసం ఉపయోగించిన క్యూరేటర్ యొక్క తర్కాన్ని విచ్ఛిన్నం చేయడం వల్ల ఇది డేటా నష్టానికి దారితీసింది. వ్రాయడానికి అలియాస్ ఒక సూచికగా మార్చబడింది మరియు రోల్‌ఓవర్ లాజిక్‌ను విచ్ఛిన్నం చేసింది, దీని వలన కొన్ని ఇండెక్స్‌లు 600 GB వరకు అనియంత్రిత పెరుగుదలకు కారణమయ్యాయి. 

ఉదాహరణకు, భ్రమణ కాన్ఫిగరేషన్ కోసం:

сurator-elk-rollover.yaml

---
actions:
  1:
    action: rollover
    options:
      name: "nginx_write"
      conditions:
        max_docs: 100000000
  2:
    action: rollover
    options:
      name: "python_error_write"
      conditions:
        max_docs: 10000000

రోల్‌ఓవర్ అలియాస్ లేకపోతే, లోపం సంభవించింది:

ERROR     alias "nginx_write" not found.
ERROR     Failed to complete action: rollover.  <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".

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

మేము క్లస్టర్‌ను మెరుగుపరుస్తున్నప్పుడు, cian.ru యొక్క ట్రాఫిక్ నెలకు 12,8 మిలియన్ల ప్రత్యేక వినియోగదారులకు పెరిగింది. తత్ఫలితంగా, మా పరివర్తనలు ఉత్పత్తిలో మార్పుల కంటే కొంచెం వెనుకబడి ఉన్నాయని తేలింది మరియు "వెచ్చని" నోడ్‌లు లోడ్‌ను తట్టుకోలేవు మరియు లాగ్‌ల మొత్తం డెలివరీని మందగించాయని మేము ఎదుర్కొన్నాము. మేము వైఫల్యాలు లేకుండా "హాట్" డేటాను అందుకున్నాము, కానీ మిగిలిన వాటి పంపిణీలో మేము జోక్యం చేసుకోవాలి మరియు సూచికలను సమానంగా పంపిణీ చేయడానికి మాన్యువల్ రోల్‌ఓవర్ చేయాలి. 

అదే సమయంలో, క్లస్టర్‌లోని లాగ్‌స్టాష్ ఉదంతాల సెట్టింగ్‌లను స్కేలింగ్ చేయడం మరియు మార్చడం అనేది స్థానిక డాకర్-కంపోజ్ కావడం వల్ల సంక్లిష్టంగా ఉంటుంది మరియు అన్ని చర్యలు మాన్యువల్‌గా నిర్వహించబడ్డాయి (కొత్త చివరలను జోడించడానికి, అన్నింటిని మాన్యువల్‌గా చేయడం అవసరం. సర్వర్లు మరియు డాకర్-కంపోజ్ అప్ -d ప్రతిచోటా చేయండి).

లాగ్ పునఃపంపిణీ

ఈ సంవత్సరం సెప్టెంబరులో, మేము ఇప్పటికీ ఏకశిలాను కత్తిరించాము, క్లస్టర్‌పై లోడ్ పెరుగుతోంది మరియు లాగ్‌ల ప్రవాహం సెకనుకు 30 వేల సందేశాలను చేరుకుంటుంది. 

మేము హార్డ్‌వేర్ అప్‌డేట్‌తో తదుపరి పునరావృతాన్ని ప్రారంభించాము. మేము ఐదు కోఆర్డినేటర్‌ల నుండి ముగ్గురికి మారాము, డేటా నోడ్‌లను భర్తీ చేసాము మరియు డబ్బు మరియు నిల్వ స్థలం పరంగా గెలిచాము. నోడ్స్ కోసం మేము రెండు కాన్ఫిగరేషన్లను ఉపయోగిస్తాము: 

• "హాట్" నోడ్‌ల కోసం: E3-1270 v6 / 960Gb SSD / 32 Gb x 3 x 2 (Hot3 కోసం 1 మరియు Hot3 కోసం 2).
• "వెచ్చని" నోడ్‌ల కోసం: E3-1230 v6 / 4Tb SSD / 32 Gb x 4.

ఈ పునరుక్తిలో, మేము మైక్రోసర్వీస్‌ల యాక్సెస్ లాగ్‌లతో ఇండెక్స్‌ను తరలించాము, ఇది ఫ్రంట్-లైన్ nginx లాగ్‌ల వలె అదే స్థలాన్ని తీసుకుంటుంది, ఇది మూడు "హాట్" నోడ్‌ల రెండవ సమూహానికి. మేము ఇప్పుడు 20 గంటలపాటు "హాట్" నోడ్‌లలో డేటాను నిల్వ చేస్తాము, ఆపై వాటిని మిగిలిన లాగ్‌లకు "వెచ్చని" నోడ్‌లకు బదిలీ చేస్తాము. 

చిన్న సూచికలు వాటి భ్రమణాన్ని పునర్నిర్మించడం ద్వారా అదృశ్యమయ్యే సమస్యను మేము పరిష్కరించాము. ఇప్పుడు ఇండెక్స్‌లు ప్రతి 23 గంటలకు ఏ సందర్భంలోనైనా తిప్పబడతాయి, అక్కడ తక్కువ డేటా ఉన్నప్పటికీ. ఇది ముక్కల సంఖ్యను కొద్దిగా పెంచింది (వాటిలో సుమారు 800 ఉన్నాయి), కానీ క్లస్టర్ పనితీరు దృష్ట్యా ఇది సహించదగినది. 

ఫలితంగా, క్లస్టర్‌లో ఆరు "వేడి" మరియు నాలుగు "వెచ్చని" నోడ్‌లు మాత్రమే ఉన్నాయి. ఇది దీర్ఘకాల వ్యవధిలో అభ్యర్థనలపై స్వల్ప జాప్యాన్ని కలిగిస్తుంది, అయితే భవిష్యత్తులో నోడ్‌ల సంఖ్యను పెంచడం ఈ సమస్యను పరిష్కరిస్తుంది.

ఈ పునరావృతం సెమీ ఆటోమేటిక్ స్కేలింగ్ లేకపోవడం సమస్యను కూడా పరిష్కరించింది. దీన్ని చేయడానికి, మేము ఇన్‌ఫ్రాస్ట్రక్చర్ నోమాడ్ క్లస్టర్‌ను అమలు చేసాము - మేము ఇప్పటికే ఉత్పత్తిలో అమలు చేసిన దానిలాగే. ప్రస్తుతానికి, లోడ్‌ను బట్టి లాగ్‌స్టాష్ మొత్తం స్వయంచాలకంగా మారదు, కానీ మేము దీనికి వస్తాము.

భవిష్యత్తు కోసం ప్రణాళికలు

అమలు చేయబడిన కాన్ఫిగరేషన్ స్కేల్స్ సంపూర్ణంగా, మరియు ఇప్పుడు మేము 13,3 TB డేటాను నిల్వ చేస్తాము - అన్ని లాగ్‌లు 4 రోజులు, ఇది హెచ్చరికల యొక్క అత్యవసర విశ్లేషణ కోసం అవసరం. మేము కొన్ని లాగ్‌లను మెట్రిక్‌లుగా మారుస్తాము, వీటిని మేము గ్రాఫైట్‌కి జోడిస్తాము. ఇంజనీర్ల పనిని సులభతరం చేయడానికి, మేము మౌలిక సదుపాయాల క్లస్టర్‌కు కొలమానాలు మరియు సాధారణ సమస్యల సెమీ ఆటోమేటిక్ రిపేర్ కోసం స్క్రిప్ట్‌లను కలిగి ఉన్నాము. వచ్చే ఏడాదికి ప్లాన్ చేయబడిన డేటా నోడ్‌ల సంఖ్యను పెంచిన తర్వాత, మేము 4 నుండి 7 రోజుల వరకు డేటా నిల్వకు మారుస్తాము. మేము ఎల్లప్పుడూ సాధ్యమైనంత త్వరగా సంఘటనలను పరిశోధించడానికి ప్రయత్నిస్తాము మరియు దీర్ఘకాలిక పరిశోధనల కోసం టెలిమెట్రీ డేటా ఉన్నందున ఇది కార్యాచరణ పనికి సరిపోతుంది. 

అక్టోబర్ 2019లో, cian.ruకి ట్రాఫిక్ ఇప్పటికే నెలకు 15,3 మిలియన్ల ప్రత్యేక వినియోగదారులకు పెరిగింది. ఇది లాగ్‌లను పంపిణీ చేయడానికి నిర్మాణ పరిష్కారానికి తీవ్రమైన పరీక్షగా మారింది. 

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

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

మూలం: www.habr.com