SRE (సైట్ రిలయబిలిటీ ఇంజనీరింగ్) అనేది వెబ్ ప్రాజెక్ట్‌లను యాక్సెస్ చేయడానికి ఒక విధానం. ఇది DevOps కోసం ఫ్రేమ్‌వర్క్‌గా పరిగణించబడుతుంది మరియు DevOps అభ్యాసాల అనువర్తనంలో ఎలా విజయం సాధించాలో చెబుతుంది. ఈ వ్యాసం అనువదిస్తుంది అధ్యాయాలు 6 మానిటరింగ్ డిస్ట్రిబ్యూటెడ్ సిస్టమ్స్ పుస్తకాలు సైట్ విశ్వసనీయత ఇంజనీరింగ్ Google నుండి. నేనే ఈ అనువాదాన్ని సిద్ధం చేసుకున్నాను మరియు పర్యవేక్షణ ప్రక్రియలను అర్థం చేసుకోవడంలో నా స్వంత అనుభవంపై ఆధారపడి ఉన్నాను. టెలిగ్రామ్ ఛానెల్‌లో @monitorim_it и మీడియంలో బ్లాగ్ నేను సేవా స్థాయి లక్ష్యాలపై అదే పుస్తకంలోని 4వ అధ్యాయం యొక్క అనువాదానికి లింక్‌ను కూడా పోస్ట్ చేసాను.

పిల్లి ద్వారా అనువాదం. చదివి ఆనందించండి!

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

నిర్వచించే

పర్యవేక్షణకు సంబంధించిన అంశాలను చర్చించడానికి ఏ ఒక్క పదజాలం ఉపయోగించబడదు. Googleలో కూడా, దిగువ నిబంధనలు సాధారణ ఉపయోగంలో లేవు, కానీ మేము అత్యంత సాధారణ వివరణలను జాబితా చేస్తాము.

పర్యవేక్షణ

సిస్టమ్ గురించిన నిజ-సమయ పరిమాణాత్మక డేటా సేకరణ, ప్రాసెసింగ్, అగ్రిగేషన్ మరియు ప్రదర్శన: అభ్యర్థనల సంఖ్య మరియు అభ్యర్థనల రకాలు, ఎర్రర్‌ల సంఖ్య మరియు లోపాల రకాలు, అభ్యర్థన ప్రాసెసింగ్ సమయం మరియు సర్వర్ సమయాలు.

వైట్ బాక్స్ పర్యవేక్షణ

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

బ్లాక్ బాక్స్ పర్యవేక్షణ

వినియోగదారు దృక్కోణం నుండి అప్లికేషన్ యొక్క ప్రవర్తనను పరీక్షిస్తోంది.

డాష్‌బోర్డ్ (డ్యాష్‌బోర్డ్‌లు)

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

హెచ్చరిక (నోటిఫికేషన్)

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

మూల కారణం (మూల కారణం)

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

నోడ్ మరియు యంత్రం (నోడ్ మరియు యంత్రం)

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

• ఒకదానికొకటి సంబంధించినవి: ఉదాహరణకు, కాష్ సర్వర్ మరియు వెబ్ సర్వర్;
• ఒకే హార్డ్‌వేర్‌పై సంబంధం లేని సేవలు: ఉదాహరణకు, కోడ్ రిపోజిటరీ మరియు కాన్ఫిగరేషన్ సిస్టమ్ కోసం విజార్డ్, పప్పెట్ లేదా తల.

పుష్

సాఫ్ట్‌వేర్ కాన్ఫిగరేషన్‌లో ఏదైనా మార్పు.

పర్యవేక్షణ ఎందుకు అవసరం

అప్లికేషన్‌లను పర్యవేక్షించడానికి అనేక కారణాలు ఉన్నాయి:

దీర్ఘకాలిక పోకడల విశ్లేషణ

డేటాబేస్ ఎంత పెద్దది మరియు ఎంత వేగంగా పెరుగుతోంది? రోజువారీ వినియోగదారుల సంఖ్య ఎలా మారుతుంది?

పనితీరు పోలిక

అజాక్స్ DB 2.72 కంటే Acme బకెట్ ఆఫ్ బైట్స్ 3.14లో ప్రశ్నలు వేగంగా ఉన్నాయా? అదనపు నోడ్ కనిపించిన తర్వాత అభ్యర్థనలు ఎంత మెరుగ్గా కాష్ చేయబడతాయి? సైట్ గత వారం కంటే నెమ్మదిగా మారిందా?

హెచ్చరిక (నోటిఫికేషన్లు)

ఏదో విరిగిపోయింది మరియు ఎవరైనా దాన్ని పరిష్కరించాలి. లేదా ఏదైనా త్వరలో విరిగిపోతుంది మరియు ఎవరైనా దాన్ని త్వరలో తనిఖీ చేయాలి.

డాష్‌బోర్డ్‌లను సృష్టిస్తోంది

డ్యాష్‌బోర్డ్‌లు ప్రాథమిక ప్రశ్నలకు సమాధానమివ్వాలి మరియు వాటి నుండి ఏదైనా చేర్చాలి "4 బంగారు సంకేతాలు" - ఆలస్యం (జాప్యం), ట్రాఫిక్ (ట్రాఫిక్), లోపాలు (లోపాలు) మరియు లోడ్ విలువ (సంతృప్తత).

పునరాలోచన విశ్లేషణ నిర్వహించడం (డీబగ్గింగ్)

అభ్యర్థన ప్రాసెసింగ్ జాప్యం పెరిగింది, అదే సమయంలో ఇంకా ఏమి జరిగింది?
మానిటరింగ్ సిస్టమ్‌లు బిజినెస్ ఇంటెలిజెన్స్ సిస్టమ్‌లకు డేటా సోర్స్‌గా ఉపయోగపడతాయి మరియు భద్రతా సంఘటనల విశ్లేషణను సులభతరం చేస్తాయి. ఈ పుస్తకం SREలు నైపుణ్యం కలిగిన ఇంజినీరింగ్ రంగాలపై దృష్టి సారిస్తుంది కాబట్టి, మేము ఇక్కడ పర్యవేక్షణ పద్ధతులను చర్చించము.

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

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

పర్యవేక్షణ వ్యవస్థ నుండి సహేతుకమైన అంచనాలను నిర్ణయించడం

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

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

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

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

అదేవిధంగా, శబ్దం స్థాయి తక్కువగా మరియు సిగ్నల్ స్థాయిని ఎక్కువగా ఉంచడానికి, అప్రమత్తం చేయబడిన వస్తువులను పర్యవేక్షించే విధానాలు చాలా సరళంగా మరియు నమ్మదగినవిగా ఉండాలి. మానవులకు హెచ్చరికలను రూపొందించే నియమాలు సులభంగా అర్థం చేసుకోవడం మరియు స్పష్టమైన సమస్యను అందించడం.

లక్షణాలు మరియు కారణాలు

మీ పర్యవేక్షణ వ్యవస్థ రెండు ప్రశ్నలకు సమాధానం ఇవ్వాలి: "ఏమి విరిగింది" మరియు "ఎందుకు విరిగింది".
"ఏం విరిగింది" అనేది లక్షణాన్ని సూచిస్తుంది మరియు "ఎందుకు విరిగింది" అనేది కారణాన్ని సూచిస్తుంది. దిగువ పట్టిక అటువంటి లింక్‌ల ఉదాహరణలను చూపుతుంది.

లక్షణం
కారణం

HTTP లోపం 500 లేదా 404ని స్వీకరిస్తోంది
డేటాబేస్ సర్వర్లు కనెక్షన్‌లను నిరాకరిస్తున్నాయి

నెమ్మదిగా సర్వర్ ప్రతిస్పందనలు
అధిక CPU వినియోగం లేదా దెబ్బతిన్న ఈథర్నెట్ కేబుల్

అంటార్కిటికాలోని వినియోగదారులు పిల్లి GIFలను పొందడం లేదు
మీ CDN శాస్త్రవేత్తలు మరియు పిల్లి జాతులను ద్వేషిస్తుంది, కాబట్టి కొన్ని IPలు బ్లాక్‌లిస్ట్ చేయబడ్డాయి

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

గరిష్ట సిగ్నల్ మరియు కనిష్ట శబ్దంతో మంచి పర్యవేక్షణ వ్యవస్థను రూపొందించడానికి "ఏమి" మరియు "ఎందుకు" అత్యంత ముఖ్యమైన బిల్డింగ్ బ్లాక్‌లలో ఒకటి.

బ్లాక్-బాక్స్ వర్సెస్ వైట్-బాక్స్

మేము క్లిష్టమైన కొలమానాల కోసం నిరాడంబరమైన బ్లాక్-బాక్స్ పర్యవేక్షణతో విస్తృతమైన వైట్-బాక్స్ పర్యవేక్షణను మిళితం చేస్తాము. బ్లాక్-బాక్స్‌ను వైట్-బాక్స్‌తో పోల్చడానికి సులభమైన మార్గం ఏమిటంటే, బ్లాక్-బాక్స్ లక్షణ-కేంద్రీకృతమైనది మరియు క్రియాశీల పర్యవేక్షణ కంటే రియాక్టివ్‌గా ఉంటుంది: "సిస్టమ్ ప్రస్తుతం సరిగ్గా పని చేయడం లేదు." వైట్-బాక్స్ సిస్టమ్‌ల అంతర్గత తనిఖీ సామర్థ్యాలపై ఆధారపడి ఉంటుంది: ఈవెంట్ లాగ్‌లు లేదా వెబ్ సర్వర్లు. అందువల్ల, వైట్-బాక్స్ రాబోయే సమస్యలు, అభ్యర్థన యొక్క పునఃప్రసారం వలె కనిపించే లోపాలు మొదలైనవాటిని గుర్తించడానికి మిమ్మల్ని అనుమతిస్తుంది.

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

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

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

నాలుగు బంగారు సంకేతాలు

నాలుగు గోల్డెన్ మానిటరింగ్ సిగ్నల్స్ జాప్యం, ట్రాఫిక్, లోపాలు మరియు సంతృప్తత. మీరు నాలుగు వినియోగదారు సిస్టమ్ మెట్రిక్‌లను మాత్రమే కొలవగలిగితే, ఆ నాలుగింటిపై దృష్టి పెట్టండి.

ఆలస్యం

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

ట్రాఫిక్

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

లోపాలు

ఇది విఫలమైన అభ్యర్థనల రేటు, స్పష్టంగా (ఉదాహరణకు, HTTP 500), పరోక్షంగా (ఉదాహరణకు, HTTP 200 కానీ చెడు కంటెంట్‌తో కలిపి) లేదా విధానం ద్వారా (ఉదాహరణకు, "మీరు ఒక సెకనులో ప్రతిస్పందనను క్యాప్చర్ చేస్తే, ఏదైనా ఒక సెకను ఒక లోపం"). అన్ని వైఫల్య పరిస్థితులను వ్యక్తీకరించడానికి తగినంత HTTP ప్రతిస్పందన కోడ్‌లు లేకుంటే, పాక్షిక వైఫల్యాన్ని గుర్తించడానికి ద్వితీయ (అంతర్గత) ప్రోటోకాల్‌లు అవసరం కావచ్చు. అటువంటి తప్పుడు అభ్యర్థనలన్నింటిని పర్యవేక్షించడం అనేది సమాచారం లేకుండా ఉంటుంది, అయితే ఎండ్-టు-ఎండ్ సిస్టమ్ పరీక్షలు మీరు తప్పు కంటెంట్‌ను ప్రాసెస్ చేస్తున్నాయని కనుగొనడంలో మీకు సహాయపడతాయి.

సంతృప్త

మీ సేవ ఎంత ఎక్కువగా ఉపయోగించబడుతుందో మెట్రిక్ చూపుతుంది. ఇది చాలా పరిమితమైన వనరులను గుర్తించే సిస్టమ్ మానిటరింగ్ కొలత (ఉదాహరణకు, పరిమిత మెమరీ ఉన్న సిస్టమ్‌లో, మెమరీని చూపుతుంది, పరిమిత I / O ఉన్న సిస్టమ్‌లో, I / O సంఖ్యను చూపుతుంది). అనేక సిస్టమ్‌లు 100% వినియోగాన్ని చేరుకోకముందే అధోకరణం చెందుతాయని గమనించండి, కాబట్టి వినియోగ లక్ష్యాన్ని కలిగి ఉండటం చాలా అవసరం.

సంక్లిష్ట వ్యవస్థలలో, అధిక-స్థాయి లోడ్ కొలత ద్వారా సంతృప్తతను భర్తీ చేయవచ్చు: మీ సేవ డబుల్ ట్రాఫిక్‌ను సరిగ్గా నిర్వహించగలదా, 10% ఎక్కువ ట్రాఫిక్‌ను మాత్రమే నిర్వహించగలదా లేదా ప్రస్తుతం దాని కంటే తక్కువ ట్రాఫిక్‌ను నిర్వహించగలదా? అభ్యర్థన యొక్క సంక్లిష్టతను మార్చే పారామీటర్‌లు లేని సాధారణ సేవలకు (ఉదా. "నాకు ఏమీ ఇవ్వండి" లేదా "నాకు ప్రత్యేకమైన ఒక మోనోటోనిక్ పూర్ణాంకం అవసరం") అరుదుగా కాన్ఫిగరేషన్‌ను మార్చవచ్చు, స్టాటిక్ లోడ్ పరీక్ష విలువ సరిపోతుంది. అయితే, మునుపటి పేరాలో చర్చించినట్లుగా, చాలా సేవలు CPU వినియోగం లేదా తెలిసిన ఎగువ సరిహద్దును కలిగి ఉన్న నెట్‌వర్క్ బ్యాండ్‌విడ్త్ వంటి పరోక్ష సంకేతాలను ఉపయోగించాలి. పెరుగుతున్న జాప్యం తరచుగా సంతృప్తత యొక్క ప్రధాన సూచిక. 99వ పర్సంటైల్ ప్రతిస్పందన సమయాన్ని చిన్న విండోలో (ఉదా. ఒక నిమిషం) కొలవడం చాలా ముందస్తు సంతృప్త సంకేతాన్ని ఇస్తుంది.

చివరగా, సంతృప్తత రాబోయే సంతృప్తత యొక్క అంచనాలతో కూడా అనుబంధించబడింది, అవి: "మీ డేటాబేస్ మీ హార్డ్ డ్రైవ్‌ను 4 గంటల్లో నింపినట్లు కనిపిస్తోంది."

మీరు మొత్తం నాలుగు గోల్డెన్ సిగ్నల్‌లను కొలిస్తే మరియు కొలమానాలలో ఒకదానితో సమస్య ఉన్నప్పుడు (లేదా, సంతృప్తత విషయంలో, దాదాపు సమస్య), మీరు వ్యక్తికి తెలియజేస్తే, మీ సేవ ఎక్కువ లేదా తక్కువ పర్యవేక్షణ ద్వారా కవర్ చేయబడుతుంది.

తోక గురించి చింతించండి (లేదా ఇన్స్ట్రుమెంటేషన్ మరియు పనితీరు)

స్క్రాచ్ నుండి మానిటరింగ్ సిస్టమ్‌ను రూపొందిస్తున్నప్పుడు, సగటు జాప్యం, సగటు నోడ్ CPU వినియోగం లేదా సగటు డేటాబేస్ ఆక్యుపెన్సీ ఆధారంగా సిస్టమ్‌ను అభివృద్ధి చేయడం ఉత్సాహం కలిగిస్తుంది. చివరి రెండు ఉదాహరణల ప్రమాదం స్పష్టంగా ఉంది: ప్రాసెసర్‌లు మరియు డేటాబేస్‌లు చాలా అనూహ్య రీతిలో పారవేయబడతాయి. అదే ఆలస్యం వర్తిస్తుంది. మీరు సెకనుకు 100 అభ్యర్థనల చొప్పున సగటున 1000ms జాప్యంతో వెబ్ సేవను నడుపుతున్నట్లయితే, 1% అభ్యర్థనలకు 5 సెకన్లు పట్టవచ్చు. వినియోగదారులు అటువంటి బహుళ వెబ్ సేవలపై ఆధారపడినట్లయితే, ఒకే బ్యాకెండ్ యొక్క 99వ శాతం సులభంగా ఇంటర్‌ఫేస్ మధ్యస్థ ప్రతిస్పందన సమయం అవుతుంది.

నెమ్మదిగా సగటు మరియు చాలా నెమ్మదిగా ఉండే అభ్యర్థనల మధ్య తేడాను గుర్తించడానికి సులభమైన మార్గం ఏమిటంటే, వాస్తవ ఆలస్యం కాకుండా గణాంకాలలో వ్యక్తీకరించబడిన అభ్యర్థనల కొలతలను సేకరించడం (హిస్టోగ్రామ్‌లు ప్రదర్శించడానికి తగిన సాధనం), తీసుకున్న సేవ ద్వారా ఎన్ని అభ్యర్థనలు అందించబడ్డాయి 0 ms మరియు 10ms మధ్య, 10ms మరియు 30ms మధ్య, 30ms మరియు 100ms మధ్య, 100ms మరియు 300ms మధ్య, మొదలైనవి. హిస్టోగ్రాం సరిహద్దులను సుమారుగా విపరీతంగా విస్తరించడం (సుమారు 3 కారకం ద్వారా) అభ్యర్థనల పంపిణీని దృశ్యమానం చేయడానికి తరచుగా సులభమైన మార్గం.

కొలతల కోసం సరైన గ్రాన్యులారిటీని ఎంచుకోవడం

సిస్టమ్ యొక్క విభిన్న అంశాలను వివిధ స్థాయిల వివరాలతో కొలవాలి. ఉదాహరణకి:

• ఒక నిర్దిష్ట వ్యవధిలో CPU వినియోగ వినియోగాన్ని చూడటం వలన అధిక లేటెన్సీలకు దారితీసే పొడవైన స్పైక్‌లు కనిపించవు.
• మరోవైపు, సంవత్సరానికి 9 గంటల కంటే ఎక్కువ పనికిరాని సమయం (99,9% వార్షిక అప్‌టైమ్) లక్ష్యంగా ఉన్న వెబ్ సేవ కోసం, HTTP 200 ప్రతిస్పందన కోసం నిమిషానికి ఒకటి లేదా రెండు సార్లు కంటే ఎక్కువసార్లు తనిఖీ చేయడం అనవసరంగా తరచుగా జరుగుతుంది.
• అదేవిధంగా, ప్రతి 99,9-1 నిమిషాలకు ఒకసారి కంటే ఎక్కువ 2% లభ్యత కోసం హార్డ్ డ్రైవ్‌లో ఖాళీ స్థలం కోసం తనిఖీ చేయడం బహుశా అనవసరం.

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

1. ప్రతి సెకను CPU వినియోగాన్ని కొలవండి.
2. వివరాలను 5%కి తగ్గించండి.
3. ప్రతి నిమిషం కొలమానాలను సమగ్రపరచండి.

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

వీలైనంత సులభం, కానీ సులభం కాదు

ఒకదానిపై ఒకటి వేర్వేరు అవసరాలను పేర్చడం చాలా క్లిష్టమైన పర్యవేక్షణ వ్యవస్థకు దారి తీస్తుంది. ఉదాహరణకు, మీ సిస్టమ్ కింది సంక్లిష్ట అంశాలను కలిగి ఉండవచ్చు:

• అభ్యర్థన జాప్యం కోసం వివిధ థ్రెషోల్డ్‌ల ప్రకారం, వివిధ పర్సంటైల్‌లలో, అన్ని రకాల విభిన్న కొలమానాలలో హెచ్చరికలు.
• సాధ్యమయ్యే కారణాలను గుర్తించడానికి మరియు గుర్తించడానికి అదనపు కోడ్ రాయడం.
• సమస్యలకు గల ప్రతి కారణాల కోసం సంబంధిత డాష్‌బోర్డ్‌లను సృష్టించండి.

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

అందువల్ల, మీ పర్యవేక్షణ వ్యవస్థను వీలైనంత సులభతరం చేయడానికి రూపకల్పన చేయండి. ఏది ట్రాక్ చేయాలో ఎంచుకున్నప్పుడు, ఈ క్రింది వాటిని గుర్తుంచుకోండి:

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

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

సూత్రాలను ఒకదానితో ఒకటి అనుసంధానించడం

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

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

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

ఈ ప్రశ్నలు హెచ్చరికలు మరియు హెచ్చరిక వ్యవస్థలపై ప్రాథమిక తత్వశాస్త్రాన్ని ప్రతిబింబిస్తాయి:

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

ఈ విధానం నిర్దిష్ట వ్యత్యాసాలను అస్పష్టం చేస్తుంది: హెచ్చరిక మునుపటి నాలుగు షరతులను సంతృప్తిపరిచినట్లయితే, హెచ్చరికను వైట్-బాక్స్ మానిటరింగ్ సిస్టమ్ లేదా బ్లాక్-బాక్స్ నుండి పంపినా పర్వాలేదు. ఈ విధానం కొన్ని వ్యత్యాసాలను కూడా బలపరుస్తుంది: కారణాల కంటే లక్షణాలను గుర్తించడంలో ఎక్కువ కృషి చేయడం మంచిది; కారణాల విషయానికి వస్తే, మీరు అనివార్య కారణాల గురించి మాత్రమే ఆందోళన చెందాలి.

దీర్ఘకాలిక పర్యవేక్షణ

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

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

బిగ్ టేబుల్ SRE: ఓవర్ అలర్ట్ గురించిన కథ

Google యొక్క అంతర్గత మౌలిక సదుపాయాలు సాధారణంగా అందించబడతాయి మరియు సేవా స్థాయి (SLO) పరంగా కొలుస్తారు. సంవత్సరాల క్రితం, Bigtable సేవ యొక్క SLO అనేది నడుస్తున్న క్లయింట్‌ను అనుకరించే సింథటిక్ లావాదేవీ యొక్క సగటు పనితీరుపై ఆధారపడింది. బిగ్‌టేబుల్‌లో సమస్యలు మరియు నిల్వ స్టాక్‌లోని దిగువ స్థాయిల కారణంగా, సగటు పనితీరు "పెద్ద" తోకతో నడపబడింది: చెత్త 5% ప్రశ్నలు తరచుగా మిగిలిన వాటి కంటే గణనీయంగా నెమ్మదిగా ఉంటాయి.

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

పరిస్థితిని సరిచేయడానికి, బృందం త్రిముఖ విధానాన్ని ఉపయోగించింది: బిగ్‌టేబుల్ పనితీరును మెరుగుపరచడానికి తీవ్రంగా కృషి చేస్తున్నప్పుడు, ప్రశ్న ప్రతిస్పందన ఆలస్యం కోసం మేము తాత్కాలికంగా మా SLO లక్ష్యంగా 75వ శాతాన్ని సెట్ చేసాము. మేము ఇమెయిల్ హెచ్చరికలను కూడా ఆఫ్ చేసాము, ఎందుకంటే వాటిలో చాలా ఉన్నాయి కనుక వాటిని నిర్ధారించడంలో సమయాన్ని వృథా చేయడం అసాధ్యం.

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

Gmail: ఊహించదగిన, అల్గారిథమిక్ మానవ ప్రతిస్పందనలు

ప్రారంభంలో, Gmail అనేది సవరించిన వర్క్‌క్యూ ప్రాసెస్ కంట్రోల్ సిస్టమ్‌లో నిర్మించబడింది, ఇది ప్రక్రియ శోధన సూచిక భాగాలను బ్యాచ్ చేయడానికి సృష్టించబడింది. వర్క్‌క్యూ దీర్ఘకాలిక ప్రక్రియలకు అనుగుణంగా మార్చబడింది మరియు తదనంతరం Gmailకి వర్తింపజేయబడింది, అయితే అపారదర్శక షెడ్యూలర్ కోడ్‌లోని కొన్ని బగ్‌లను పరిష్కరించడం చాలా కష్టమని నిరూపించబడింది.

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

ఈ సమస్యను పరిష్కరించడానికి, Gmail SRE వినియోగదారులపై ప్రభావాన్ని తగ్గించడానికి వీలైనంత ఉత్తమంగా షెడ్యూలర్‌ను డీబగ్ చేయడంలో సహాయపడటానికి ఒక సాధనాన్ని సృష్టించింది. సమస్యను కనుగొనడం నుండి దాన్ని పరిష్కరించడం వరకు దీర్ఘకాలిక పరిష్కారం కనుగొనబడే వరకు మొత్తం చక్రాన్ని స్వయంచాలకంగా మార్చాలా వద్దా అనే దాని గురించి బృందం అనేక చర్చలు చేసింది, అయితే అలాంటి పరిష్కారం సమస్య యొక్క వాస్తవ పరిష్కారాన్ని ఆలస్యం చేస్తుందని కొందరు ఆందోళన చెందారు.

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

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

దీర్ఘకాలిక

ఒక సాధారణ థీమ్ బిగ్‌టేబుల్ మరియు Gmail ఉదాహరణలను లింక్ చేస్తుంది: స్వల్పకాలిక మరియు దీర్ఘకాలిక లభ్యత మధ్య పోటీ. తరచుగా బలమైన ప్రయత్నం పెళుసైన వ్యవస్థ అధిక లభ్యతను సాధించడంలో సహాయపడుతుంది, అయితే ఈ మార్గం సాధారణంగా స్వల్పకాలికం, జట్టు బర్న్‌అవుట్‌తో నిండి ఉంటుంది మరియు ఇదే వీరోచిత జట్టులోని తక్కువ సంఖ్యలో సభ్యులపై ఆధారపడుతుంది.

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

తీర్మానం

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

దీర్ఘకాలికంగా, రోగలక్షణ హెచ్చరికలు మరియు ఆసన్న నిజమైన సమస్యల మధ్య విజయవంతమైన ప్రత్యామ్నాయాన్ని సాధించాల్సిన అవసరం ఉంది మరియు పర్యవేక్షణ వేగవంతమైన రోగనిర్ధారణకు మద్దతునిస్తుందని నిర్ధారించడానికి లక్ష్యాలను స్వీకరించడం అవసరం.

అనువాదాన్ని చివరి వరకు చదివినందుకు ధన్యవాదాలు. పర్యవేక్షణ గురించి నా టెలిగ్రామ్ ఛానెల్‌కు సభ్యత్వాన్ని పొందండి @monitorim_it и మీడియంలో బ్లాగ్.

మూలం: www.habr.com