स्वागत है
स्वागत है
एक वेब-स्केल फ्लीट में कई मशीनें होती हैं। किसी भी क्षण, कुछ स्वस्थ होती हैं, कुछ शुरू हो रही होती हैं, कुछ ड्रेनिंग होती हैं, और कुछ चुपचाप टूटी हुई होती हैं। फ्लीट इससे इसलिए बचती है क्योंकि हर मशीन मांग पर दो सरल प्रश्नों का उत्तर देती है:
- /health — क्या मैं वर्तमान में वास्तविक अनुरोधों का सेवा देने में सक्षम हूँ?
- /version — मैं कौन सा कोड चला रहा हूँ?
साथ ही एक मेट्रिक्स एंडपॉइंट (आमतौर पर /metrics) जो मॉनिटरिंग टूल्स के लिए काउंटर्स और गेजेस को एक्सपोज़ करता है ताकि वे उन्हें स्क्रैप कर सकें।
यह पाठ आपको सिखाता है कि इन एंडपॉइंट्स को ऐसे डिज़ाइन किया जाए कि वे वास्तविकता को प्रतिबिंबित करें, प्रॉक्सी टियर पर चार गोल्डन सिग्नल का क्या अर्थ है, और देखा गया डेटा कैपैसिटी निर्णयों को कैसे प्रभावित करता है।
अंत तक आप:
- /health एंडपॉइंट डिज़ाइन करें जो वास्तविक पथ विफलता का पता लगाए, न कि केवल प्रोसेस लाइवनेस
- /version एंडपॉइंट डिज़ाइन करें जिससे आप सत्यापित कर सकें कि कोई डेप्लॉय सफलतापूर्वक पूरा हुआ है
- प्रॉक्सी टियर पर चार गोल्डन सिग्नल (लेटेंसी, ट्रैफिक, एरर्स, सैचुरेशन) लागू करें
- देखा गया सर्ज मेट्रिक्स को कैपैसिटी निर्णयों से जोड़ें: कब स्केल अप करना है, कब ड्रेन करना है, और कब पेज करना है
- SLOs और एरर बजट बर्न रेट के बारे में सोचें, जो 'हमें कितना ध्यान देना चाहिए?' के पीछे की संचालनात्मक अनुशासा है।
स्वास्थ्य जांच के दो प्रकार
लिवनेस बनाम रेडीनेस
लिवनेस (Liveness): क्या प्रक्रिया (process) बिल्कुल जीवित है? इसका उपयोग ऑर्केस्ट्रेटर्स (जैसे कि Kubernetes, systemd) द्वारा यह तय करने के लिए किया जाता है कि क्या प्रक्रिया को पुनः आरंभ (restart) किया जाना चाहिए।
रेडीनेस (Readiness): क्या प्रक्रिया अभी वास्तविक ट्रैफ़िक को संभालने के लिए तैयार है? इसका उपयोग लोड बैलेंसर (load balancers) द्वारा यह तय करने के लिए किया जाता है कि क्या अनुरोध (requests) भेजे जाने चाहिए।
ये अलग-अलग प्रश्न हैं। एक ऐसी प्रक्रिया जो जीवित है लेकिन अपने डेटाबेस तक नहीं पहुंच पा रही है, वह जीवित है लेकिन तैयार नहीं है। एक प्रक्रिया जो आरंभ हो रही है, वह जीवित है लेकिन अभी तक तैयार नहीं है।
शैथल बनाम गहरी स्वास्थ्य जांच
शैथल (Shallow): यदि HTTP हैंडलर चला रहा है, तो {"status": "ok"} लौटाता है। यह सरल है। यह केवल प्रक्रिया-निर्गम (process-down) का पता लगाता है।
गहरी (Deep): वास्तव में वास्तविक अनुरोध पथ (request path) का परीक्षण करता है। यह जांचता है कि डेटाबेस कनेक्शन पूल (connection pool) एक कनेक्शन लौटा सकता है, कैश (cache) तक पहुंचा जा सकता है, और डाउनस्ट्रीम निर्भरताएं (downstream dependencies) प्रतिक्रिया दे रही हैं। यह उन कार्यात्मक विफलताओं (functional outages) का पता लगाता है जो शैथल जांच से छूट जाती हैं।
ट्रेडऑफ: गहरी जाँचें अधिक खर्चीड़ी होती हैं (प्रत्येक जाँच मूल रूप से एक सिंथेटिक अनुरोध है) & यह कैस्केडिंग फेलियर का कारण बन सकती है (यदि हर रिप्लिका की हेल्थ चेक डेटाबेस पर हमला करती है, तो एक धीमा डेटाबेस सभी रिप्लिकाओं को अस्वस्थ बना देगा, जिससे उन्हें रोटेशन से हटा दिया जाएगा, जिससे सारा क्षमता हट जाएगा)।
सर्वोत्तम प्रथा: लाइवनेस के लिए एक उथली जाँच (तेज़, सस्ती, कोई बाहरी निर्भरता नहीं) & रेडीनेस के लिए एक गहरी जाँच (कैश्ड परिणाम, डाउनस्ट्रीम पर हमले से बचने के लिए थ्रॉटल्ड)।
वर्ज़न एंडपॉइंट्स
/version git commit, build time, & सेवा का नाम लौटाता है। डेप्लॉय के बाद, आप curl https://service.example.com/version चलाते हैं & पुष्टि करते हैं कि लौटाया गया commit उससे मेल खाता है जिसे आपने पश किया था। यदि ऐसा नहीं है, तो डेप्लॉय चुपचाप विफल हो गया है।
/version के बिना, एक पुराना डेप्लॉय सफल दिख सकता है & घंटों तक छुपा रह सकता है।
न्यूनतम रिस्पॉन्स आकार: {"service": "my-api", "git_commit": "abc1234", "build_time": "2026-05-19T10:00:00Z"}।
विलंबता (Latency), ट्रैफ़िक, त्रुटियाँ, संतृप्ति (Saturation)
चार संख्याएं ऑपरेशंस का अधिकांश हिस्सा कवर करती हैं
गूगल SRE पुस्तक से। चार संकेत जो आप हर सेवा टियर पर मापते हैं। यदि आप इन चार को अच्छी तरह से इंस्ट्रूमेंट करते हैं, तो आप उपयोगकर्ताओं से पहले अधिकांश प्रोडक्शन समस्याओं को पकड़ लेते हैं।
लेटेंसी: एक अनुरोध को पूरा होने में कितना समय लगता है? केवल औसत के बजाय वितरण (distributions) रिपोर्ट करें। p99 (99वाँ प्रतिशत लेटेंसी) माध्य (mean) से अधिक महत्वपूर्ण है, क्योंकि टेल लेटेंसी (tail latency) ही वह है जिसे उपयोगकर्ता 'धीमा' अनुभव करते हैं। एक सेवा जिसका औसत 50 ms और p99 5,000 ms है, उसमें एक वास्तविक समस्या है जिसे अधिकांश उपयोगकर्ता कभी नहीं देखते, लेकिन सबसे अधिक प्रभावित 1% उपयोगकर्ता इसे ज़रूर महसूस करते हैं।
ट्रैफ़िक: प्रति सेकंड कितने अनुरोध आ रहे हैं? कुल अनुरोध, प्रति-एंडपॉइंट, प्रति-स्टेटस-कोड, प्रति-क्षेत्र। बेसलाइन ज्ञात है; असामान्यताओं (anomalies) पर अलर्ट दें (अचानक गिरावट = इंग्रेस समस्या; अचानक उछाल = सर्ज या हमला)।
त्रुटियाँ: विफल अनुरोधों की दर। 4xx (क्लाइंट त्रुटियाँ, आपकी गलती नहीं) और 5xx (सर्वर त्रुटियाँ, आपकी गलती) के बीच अंतर करें। त्रुटि दर को ट्रैफ़िक का एक प्रतिशत के रूप में ट्रैक करें, निरपेक्ष गणनाओं (absolute counts) के रूप में नहीं, ताकि अलर्ट लोड स्तरों के पार काम करें।
संतृप्ति (Saturation): सिस्टम कितना भरा हुआ है? CPU उपयोग, मेमोरी, कनेक्शन पूल गहराई, कतार की लंबाई। यह एक अग्रसूचक (leading indicator) है। संतृप्ति लेटेंसी या त्रुटियों के बिगड़ने से पहले बढ़ती है। 90% संतृप्ति पर एक टियर एक बुरी मिनट की दूरी पर कतार के पतन (queue collapse) से है।
विशेष रूप से एक प्रॉक्सी टियर पर
प्रत्येक संकेत किनारे की परत (edge layer) पर प्रकाशित होता है:
- प्रॉक्सी पर लेटेंसी: TLS हैंडशेक अवधि, अपस्ट्रीम कनेक्ट समय, अनुरोध-प्रतिक्रिया कुल। उन्हें अलग-अलग मापा जाता है क्योंकि वे पथ के अलग-अलग हिस्सों पर मौजूद होते हैं।
- प्रॉक्सी पर ट्रैफ़िक: कुल अनुरोध/सेकंड, प्रति-बैकएंड वितरण (एक गर्म बैकएंड लोड-बैलेंसर विकृति का संकेत देता है), प्रति-स्टेटस-कोड विभाजन।
- प्रॉक्सी पर त्रुटियाँ: क्लाइंट्स (आपके उपयोगकर्ता गलत एंडपॉइंट्स पर पहुँच रहे हैं) से 4xx, बैकएंड्स (आपके सेवाएँ विफल हो रही हैं) से 5xx, और प्रॉक्सी-आंतरिक त्रुटियाँ (502 = बैकएंड अप्राप्य, 504 = बैकएंड टाइमआउट)।
- प्रॉक्सी पर संतृप्ति (Saturation): TLS सत्र की संख्या, अपस्ट्रीम कनेक्शन पूल की गहराई, और प्रॉक्सी पर CPU (TLS टर्मिनेशन CPU-गहन है)।
प्रो टिप: 502 में अचानक वृद्धि और कम बैकएंड लेटेंसी का अर्थ है कि बैकएंड प्रतिक्रिया देने से पहले ही कट रहा है (कनेक्शन रीसेट, क्रैश, OOM)। 504 में वृद्धि का अर्थ है कि बैकएंड धीमा है लेकिन फिर भी जवाब दे रहा है। त्रुटि कोड को पढ़ें; यह आपको बताता है कि विफलता कहाँ है।
संकेतों को पढ़ें
आपका डैशबोर्ड पिछले 10 मिनट के लिए निम्नलिखित दिखा रहा है:
- ट्रैफिक: लगभग स्थिर 800 req/s पर (कोई अचानक वृद्धि नहीं)
- लेटेंसी: p50 40ms पर स्थिर है, p99 5 मिनट में 200ms से बढ़कर 2,500ms हो गया है और अभी भी बढ़ रहा है
- त्रुटियाँ: 4xx दर 0.3% पर स्थिर है (सामान्य पृष्ठभूमि); 5xx दर 0.1% से बढ़कर 1.2% हो गई है (जो मुख्य रूप से 504 Gateway Timeout हैं)
- संतृप्ति (Saturation): पिछले 5 मिनट के दौरान बैकएंड CPU 45% से बढ़कर 78% हो गया; प्रॉक्सी CPU 30% पर स्थिर है
कब स्केल करें, कब ड्रेन करें, कब पेज करें
क्षमता निर्णयों को ट्रिगर्स की आवश्यकता होती है
मेट्रिक्स का अवलोकन करना आसान है। उन पर कब कार्रवाई करनी है, यह अनुशासन है।
कब स्केल अप करें: जब सैचुरेशन एक सतत सीमा (जैसे, बैकएंड CPU >70% 5 मिनट के लिए) को पार करता है, या क्यू डेप्थ एक लक्ष्य से आगे बढ़ जाता है, या लेटेंसी p99 SLO से अधिक हो जाता है। ट्रिगर तब फायर होना चाहिए जब चीज़ें टूटने से पहले हों, न कि टूटने के समय।
कब रिप्लिका को ड्रेन करें: जब यह लगातार धीमा / त्रुटिपूर्ण हो जबकि साथी स्वस्थ हों (एक रिप्लिका का गर्म चलना अक्सर होस्ट-स्तर की समस्या होती है, न कि एप्लिकेशन की), या नए संस्करण को रोल आउट करते समय, या रिप्लिका को सभ्यता से रिटायर करते समय।
कब मानव को पेज करें: जब SLO त्रुटि बजट की तुलना में तेजी से जल रहा हो, या सैचुरेशन ट्रिगर फायर हो लेकिन ऑटोस्केलिंग इसे अवशोषित न करे, या एक कैस्केड पैटर्न दिखाई दे (त्रुटि दर + पुनर्चयन दर दोनों बढ़ रही हों)।
कब पेज न करें: जब एक अकेला बुरा मिनट अपने आप हल हो जाए, या बैकग्राउंड बैच जॉब्स अपेक्षित आवधिक ब्लिप्स का कारण बनें, या शोर सीमा को पार कर जाए (सीमा गलत है, न कि सिस्टम)।
SLOs और Error Budget Burn
SLO (service level objective) स्वीकार्य प्रदर्शन को परिभाषित करता है: '28 दिनों के विंडो में सफलता दर >= 99.9%'। पूरक (0.1%) error budget है।
Burn rate: आप error budget को कितनी तेजी से खर्च कर रहे हैं। यदि आप 1 घंटे में बजट का 10% जलाते हैं, तो दर टिकाऊ (sustainable) से 240x तेज है (1 घंटा 28-दिन के विंडो का 1/672 हिस्सा है; उस विंडो में 10% जलाना = 10% × 672 = पूर्ण विंडो के लिए 6720% की प्रक्षेपणा, जबकि केवल 100% की अनुमति है)।
Multi-window burn-rate alerts: जब एक छोटा विंडो (14.4x दर पर 5 मिनट) और एक लंबा विंडो (6x दर पर 1 घंटा) दोनों टिकाऊ से तेज जलते हैं, तब page करें। यह तेज outages और धीमे degradations दोनों को पकड़ता है।
यह capacity के लिए क्यों महत्वपूर्ण है: 99.9% SLO पर चलने वाला सेवा, जिसमें 1% की slack room है, छोटी बड़ी उतार-चढ़ाव (blips) को सोख सकती है। 99.93% पर (SLO को बस-बस पूरा करने वाला) सेवा एक बुरे दिन से उल्लंघन (violation) के कगार पर है। Capacity निर्णयों का लक्ष्य SLO की आरामदायक margin होनी चाहिए, न कि उसे पूरा करने वाली न्यूनतम सीमा।
निरीक्षण के तहत एक Capacity निर्णय
आपकी सेवा का SLO 28 दिनों में 99.9% सफल अनुरोध है। पिछले एक घंटे के दौरान monitoring से वर्तमान स्थिति:
- सफलता दर: 99.5% (30 मिनट तक बनाए रखा गया)
- बैकएंड CPU: फ्लीट में औसतन 82% (लक्ष्य 70%)
- p99 लेटेंसी: 800 ms (SLO लक्ष्य: <500 ms)
- ट्रैफिक: 1,400 req/s, बेसलाइन 1,000 req/s से बढ़कर (सामान्य से 40% ऊपर; रुझान अभी भी बढ़ रहा है)
- ऑटोस्केलिंग: कॉन्फ़िगर किया गया है कि CPU > 80% होकर 5 मिनट तक बना रहे तो रिप्लिका जोड़े जाएं; वर्तमान में एक स्केल-अप के बीच है जो ~90 सेकंड में 3 रिप्लिका जोड़ेगा
एक लॉन्च ऑब्ज़र्वेबिलिटी योजना का डिज़ाइन करें
संश्लेषण
अब आप /health का डिज़ाइन कर सकते हैं जो वास्तविक विफलताओं को पकड़ता है, /version जो आपको डेप्लॉयमेंट्स को सत्यापित करने देता है, प्रॉक्सी टियर पर चार-गोल्डन-सिग्नल डैशबोर्ड, और SLO बर्न रेट से जुड़े क्षमता ट्रिगर।
सभी चारों का प्रयोग करें।
आपकी टीम search.example.com (विफलता-मोड्स पाठ से खोज सेवा) को लॉन्च कर रही है। टीम को ऐसी ऑब्ज़र्वेबिलिटी शिप करनी है जो उपयोगकर्ताओं से पहले समस्याओं को पकड़ ले, और एक स्पष्ट पेज-या-नहीं निर्णय मैट्रिक्स के साथ। SLO: 99.9% सफल अनुरोध, p99 लेटेंसी < 300 ms, 28-दिन के विंडो में।
कोर्स का समापन
कोर्स का समापन
आपने सभी पाँच पाठ पूरे कर लिए हैं:
- प्रॉक्सियाँ और ओरिजिन्स: वह एज-लेयर आकार जो लगभग हर सार्वजनिक वेब सेवा उपयोग करती है
- स्टेटलेस हॉरिज़ॉन्टल स्केलिंग: यह कि एक स्टेटलेस टियर सस्ती कीमत पर कैसे गुणा होता है और इसे कैसे साइज़ किया जाए
- इंग्रेस और एज्रेस अलगाव: यह कि एक बॉक्स दो क्यों बन जाता है, और वह फेलियर मोड जो इसे ज़रूरी बनाता है
- फेलियर मोड्स और ब्लास्ट रेडियस: SPOFs, कैस्केड्स, पोस्टमॉर्टम्स, ब्लेमलेस एक्शन आइटम्स
- ओब्ज़र्वेबिलिटी और कैपैसिटी (यह एक): उपयोगकर्ताओं को पता चलने से पहले समस्याओं को सतह पर लाने के लिए क्या मापना है
मुख्य धागा: एक वेब-स्केल वितरित प्रणाली जादू नहीं है। यह एक छोटा सा पैटर्न सेट (रिवर्स प्रॉक्सी, स्टेटलेस रिप्लिका, इंग्रेस/एज्रेस स्प्लिट, बल्कहेड्स और सर्किट ब्रेकर, चार गोल्डन सिग्नल) है जिसे विचारपूर्वक संयोजित किया गया है। एक बार जब आप पैटर्न पहचान लेते हैं, तो आप उन्हें हर प्रोडक्शन आर्किटेक्चर में देखते हैं।
संगत पाठ: पाँच ज्यामिति-आधारित पाठ उसी सामग्री को ग्राफ थ्योरी और ज्यामिति के रूप में पुनर्निर्मित करते हैं। वे किसी भी क्रम में अच्छे लगते हैं।
बहुत अच्छा किया।