𝗕𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗮 𝗠𝘂𝗹𝘁𝗶-𝗥𝗲𝗴𝗶𝗼𝗻 𝗛𝗲𝗮𝗹𝘁𝗵-𝗖𝗵𝗲𝗰𝗸 𝗔𝗴𝗴𝗿𝗲𝗴𝗮𝘁𝗼𝗿
సావో పాలో (São Paulo) లోని ఒక వినియోగదారుడు పనిచేయని ఎడ్జ్ నోడ్ను (edge node) ఎదుర్కొంటారు. వారు బగ్ రిపోర్ట్ చేయరు. ట్యాబ్ను మూసివేసి వేరే ఏదో చూస్తారు.
సాధారణ అప్టైమ్ మానిటర్ (uptime monitor) దీనిని గమనించలేదు. చాలా మానిటర్లు ఒకే ప్రదేశం నుండి ప్రోబ్ (probe) చేస్తాయి. ఆ ఒక్క ప్రదేశం నుండి చూస్తే అంతా బాగున్నట్లుగానే (green) కనిపిస్తుంది.
నిజమైన వినియోగదారులు టైమ్-అవుట్లను (timeouts) ఎదుర్కొంటుంటే, మా స్టేటస్ పేజీ 100% అప్టైమ్ను చూపిస్తూ ఉండేది. ఒకే ఒక గ్లోబల్ హెల్త్ చెక్ మాకు తప్పుడు సమాచారాన్ని ఇస్తోంది.
నిజమైన సమాచారాన్ని అందించే వ్యవస్థను మేము ఎలా నిర్మించామో ఇక్కడ చూడండి.
The Problem: Sampling Bias మీ మానిటర్ ఒకే డేటా సెంటర్లో ఉంటే, అది కేవలం ఒకే వాస్తవాన్ని మాత్రమే చూడగలదు. మీ సింగపూర్ మరియు సావో పాలో ఎడ్జ్లు కనెక్షన్లను కోల్పోతున్నప్పటికీ, మీరు అంతా బాగుందని (green) నివేదించవచ్చు.
వీడియో ట్రాఫిక్ దీనిని మరింత తీవ్రం చేస్తుంది. సాధారణ ప్రాంతీయ వైఫల్యాలలో ఇవి ఉంటాయి:
- ఒక ఖండంపై ప్రభావం చూపే తప్పు BGP రూట్లు.
- నెమ్మదైన ఓరిజిన్ ఫాల్బ్యాక్లకు (origin fallbacks) దారితీసే క్యాచీ ఎవిక్షన్స్ (Cache evictions).
- TLS హ్యాండ్షేక్ టైమ్-అవుట్లకు కారణమయ్యే డిస్క్ ఎర్రర్స్.
- నిర్దిష్ట లోకల్ రిజాల్వర్లలో (local resolvers) DNS సమస్యలు.
కేవలం ఒక "200 OK" రెస్పాన్స్ మీకు దాదాపు ఏమీ చెప్పదు.
Our Three Rules for Health: మేము కేవలం స్టేటస్ కోడ్లకే పరిమితం కాలేదు. మేము మూడు మెట్రిక్లను ఉపయోగించి హెల్త్ను నిర్వచిస్తాము:
- Reachability: TCP మరియు TLS హ్యాండ్షేక్లు 800ms లోపు పూర్తి కావాలి.
- Latency: మేము p95 Time-to-First-Byte (TTFB)ని ట్రాక్ చేస్తాము. సగటులు (Averages) వినియోగదారులను విసిగించే నెమ్మదైన 'టెయిల్' (slow tail) డేటాను దాచిపెడతాయి.
- Correctness: రెస్పాన్స్ బాడీలో ఆశించిన మార్కర్ ఉండాలి. ఎర్రర్ పేజీని తిరిగి ఇచ్చే 200 OK అనేది వైఫల్యమే.
The Solution: Multi-Region Probing మేము ఒకే పెద్ద మానిటర్ను ఉపయోగించడం మానేసాము. దానికి బదులుగా, తక్కువ ధర కలిగిన ప్రాంతీయ VPS ఇన్స్టెన్స్లకు చిన్న చిన్న Go బైనరీలను (Go binaries) డిప్లాయ్ చేస్తాము.
ప్రతి ప్రోబర్ (prober):
- స్థానిక ప్రాంతం నుండి ఎడ్జ్లను తనిఖీ చేస్తుంది.
- నిజమైన TTFB డేటాను పొందడానికి
httptraceని ఉపయోగిస్తుంది. - ఫలితాలను సెంట్రల్ అగ్రిగేటర్కు పంపుతుంది.
మేము స్టోరేజ్ కోసం SQLiteని ఉపయోగిస్తాము. ఇది సరళమైనది మరియు ఎటువంటి ఓవర్హెడ్ (overhead) లేకుండా మా వర్క్లోడ్ను నిర్వహిస్తుంది. మేము ప్రీ-అగ్రిగేటెడ్ డేటాకు బదులుగా రా (raw) శాంపిల్స్ను నిల్వ చేస్తాము. ఇది చరిత్రను మళ్ళీ స్కోర్ చేయడానికి లేదా తర్వాత నిర్దిష్ట వైఫల్యాలను డీబగ్ చేయడానికి మాకు అనుమతిస్తుంది.
The Secret: Quorum నెట్వర్క్లు అస్థిరంగా (noisy) ఉంటాయి. ఒక ప్యాకెట్ డ్రాప్ అయినంత మాత్రాన అది అవుటేజ్ (outage) కాదు.
తప్పుడు అలారాలను నివారించడానికి మేము క్వోరం (quorum) సిస్టమ్ను ఉపయోగిస్తాము. బహుళ ప్రాంతాలు ఏకీభవించినప్పుడు మాత్రమే మేము ఒక ఎడ్జ్ "డౌన్" అని ప్రకటిస్తాము. ఒక ప్రాంతం వైఫల్యాన్ని చూసి, మిగిలినవి చూడకపోతే, మేము టీమ్కు పేజ్ (page) చేయము. ఈ డిజైన్ నిర్ణయం మా తప్పుడు అలర్ట్లను 90% తగ్గించింది.
Key Lessons:
- వినియోగదారులు దేనిని ఉపయోగిస్తున్నారో దానిని ప్రోబ్ చేయండి, సింథటిక్ పాత్ను (synthetic path) కాదు.
- సగటులను కాకుండా, టెయిల్ లేటెన్సీ (tail latency - p95)ని ట్రాక్ చేయండి.
- అనేక ప్రాంతాలలో తక్కువ ధర కలిగిన, డిస్పోజబుల్ ప్రోబర్లను ఉపయోగించండి.
- పేజర్ అలసటను (pager fatigue) నివారించడానికి క్వోరమ్ను ఉపయోగించండి.
- మీ స్టోరేజ్ స్టాక్ను సరళంగా ఉంచండి.
మీకు భారీ అబ్జర్వబిలిటీ ప్లాట్ఫారమ్ అవసరం లేదు. మీకు కావాల్సింది లోకల్ ప్రోబ్స్, ముడి డేటా మరియు అనవసరమైన నాయిస్ (noise) వల్ల కంగారు పడకుండా ఉండే ఒక నియమం.