स्वागत
स्वागत
वेब-चक्र की एक सेना कई मशीनों से बनी होती है। किसी भी समय, कुछ स्वस्थ होते हैं, कुछ शुरू होते हैं, कुछ निर्जल होते हैं, कुछ सामान्य रूप से तोड़े हुए हैं। सेना इसे इस कारण से जीतती है कि हर मशीन को मांग पर दो सरल प्रश्नों का उत्तर देने को कहा जाता है:
- /health — मैं वर्तमान में वास्तविक अनुरोधों को सेव कर सकता हूँ?
- /version — मैं किस कोड को चला रहा हूँ?
साथ ही एक मेट्रिक्स अंतपॉइंट (सामान्य रूप से /metrics ) कि मॉनिटरिंग टूल्स को स्क्रैप करने के लिए गिनती और गेज़ को उजागर करती है।
इस पाठशाला में यह सिखाया जाता है कि इन अंतपॉइंट्स को कैसे डिज़ाइन किया जाए ताकि वे वास्तविकता को वास्तव में दर्शा सकें, चार सोने के संकेतों का मतलब प्रॉक्सी तीर पर क्या है, और देखी गई डेटा क्षमता निर्णयों को पीछे वापस जोड़ें।
इस पाठशाला के अंत में आप:
- एक /health अंतपॉइंट डिज़ाइन करेंगे जो वास्तविक मार्ग विफलता को पकड़े, नहीं कि प्रक्रिया की जीवित रहने की
- एक /version अंतपॉइंट डिज़ाइन करेंगे जो आपको प्रतिबिम्ब की पुष्टि करने देता है कि लैंडिंग हुई
- चार सोने के संकेतों (देरी, ट्रैफिक, त्रुटियाँ, संतृप्ति) को प्रॉक्सी तीर पर लागू करें
- संचयी वृद्धि मापदंडों को देखी गई डेटा के पीछे क्षमता निर्णयों के साथ जोड़ें: जब स्केल अप करना है, जब निर्जल करना है, और जब पेज करना है
- SLOs & त्रुटि बजट की जलन दर के पीछे संचालन अनुशासन के बारे में सोचें: 'हम कितना चिंतित करते हैं?'
दो प्रकार की स्वास्थ्य जाँच
जीवित रहने और तैयार होने की जाँच
जीवित रहने का: प्रक्रिया किसी भी तरह से जीवित है? इसे किसी भी संगठन (Kubernetes, systemd) द्वारा प्रक्रिया को फिर से शुरू करने के लिए निर्णय लेने के लिए उपयोग किया जाता है।
तैयार होने की: प्रक्रिया वर्तमान में वास्तविक ट्रैफिक को संभाल सकती है कि अब? इसे लोड बैलेंसर द्वारा प्रक्रिया को अनुरोध भेजने के लिए निर्णय लेने के लिए उपयोग किया जाता है।
इनके अलग-अलग सवाल हैं। प्रक्रिया जो केवल अपने डेटाबेस तक पहुंच नहीं सकती है, वह जीवित है लेकिन तैयार नहीं है। प्रक्रिया जो शुरू हो रही है, वह जीवित है लेकिन अभी तैयार नहीं है।
सुपाच्य और गहरी स्वास्थ्य जाँच
सुपाच्य: {"status": "ok"} वापस करता है अगर HTTP हैंडलर चले। साधारण। प्रक्रिया के नीचे डिटेक्ट करता है।
गहराई: वास्तविक अनुरोध मार्ग को काम करने की व्याख्या करता है। डेटाबेस कनेक्शन पूल को कनेक्शन वापस करने में सक्षम होना चाहिए, कैश उपलब्ध होना चाहिए, नीचे के निर्भरता उत्तरदायी होने चाहिए। गहरी जाँचें वे विनाश करती हैं जो सुप्त जाँचें नहीं पकड़ती हैं।
व्यापारिक समझ: गहरी जाँचें की लागत अधिक होती है (हर एक को सिंथेटिक अनुरोध माना जाता है) और किसी भी प्रतिनिधि की स्वास्थ्य जाँच से गिरावट पैदा कर सकती हैं (यदि हर एक प्रतिनिधि की स्वास्थ्य जाँच डेटाबेस को प्रहार करती है, तो धीमा डेटाबेस सभी प्रतिनिधियों को स्वस्थ नहीं बना सकता, जो घूर्णन को हटा देता है, जो सभी क्षमता को हटा देता है।)
सही प्रथा: एक सुप्त जाँच लाइवनेस के लिए (तेज, सस्ता, कोई बाह्य निर्भरता नहीं) और एक गहरी जाँच रेडीनेस के लिए (क्यूआर के साथ परिणाम, नीचे के नीचे को टारगेट करने के लिए सीमित करें ताकि वे डाउनस्ट्रीम को नहीं मारते)।
संस्करण एंडपॉइंट्स
/version गिट कॉमिट, बनाने का समय और सेवा का नाम वापस करता है। एक डिप्लॉय के बाद, आप curl https://service.example.com/version और पुश किए गए कॉमिट के बराबर वापस किए गए कॉमिट की पुष्टि करते हैं। यदि यह नहीं होता है, तो डिप्लॉय साइलेंट रूप से विफल हो जाता है।
बिना /version के, एक स्टेले डिप्लॉय दिख सकता है और घंटों तक छिपा रह सकता है।
न्यूनतम प्रतिक्रिया आकार: "service": "my-api", "git_commit": "abc1234", "build_time": "2026-05-19T10:00:00Z"।
विलंब, ट्रैफ़िक, त्रुटियाँ, संतृप्ति
चार संख्याएँ अधिकांश संचालन को कवर करती हैं।
गूगल सीआरई की किताब से। चार संकेतक जिन्हें आप हर सेवा तीर पर मापें। अगर आप इन चार को अच्छी तरह से उपकरण, तो आप अधिकांश प्रोडक्शन समस्याओं को पकड़ लेते हैं जो उपयोगकर्ता करते हैं।
विलंब: एक अनुरोध को कितना समय लेता है? वितरण रिपोर्ट करें, नहीं केवल औसत। p99 (99 वें प्रतिशतिल विलंब) अधिक महत्वपूर्ण है क्योंकि हैंड लैटेंसी उपयोगकर्ता को महसूस होता है 'धीरे। एक सेवा जिसमें 50 मिलीसेकंड का औसत और 5,000 मिलीसेकंड का p99 होता है, उस सेवा में 99% के सबसे पीड़ित 1% को वास्तव में समस्या होती है, लेकिन सबसे पीड़ित 1% को नहीं।
ट्रैफ़िक: प्रति सेकंड कितने अनुरोध होते हैं? कुल अनुरोध, प्रति एंडपॉइंट, प्रति स्थिति कोड, प्रति क्षेत्र। ज्ञात आधार, विचलन पर चेतावनी (अभूत अप्रत्याशित गिरावट = इनग्रेस समस्या; अचानक वृद्धि = सर्ज या हमला)।
त्रुटियाँ: विफल अनुरोधों की दर। 4xx (ग्राहक त्रुटियाँ, आपकी गलती) और 5xx (सर्वर त्रुटियाँ, आपकी गलती) के बीच अंतर रखें। त्रुटि दर को ट्रैफ़िक के रूप में प्रतिशत में ट्रैक करें, नहीं केवल संख्या में स्वतंत्र रूप से, ताकि चेतावनियाँ विभिन्न लोड स्तरों पर काम करें।
संतुलन: सिस्टम कितना भरा हुआ है? CPU उपयोग, मेमोरी, कनेक्शन पूल गहराई, क्यू लेंथ। अग्रिम चिन्हक। संतुलन लेटेंसी या त्रुटियों को गिराने से पहले बढ़ता है। 90% संतुलन की एक स्तर है जो क्यू कोलैप्स से एक बुरा मिनट दूर है।
एक प्रॉक्सी टियर के लिए विशेष रूप से
प्रत्येक संकेत का प्रकाशण किनारी पर होता है:
- प्रॉक्सी में लेटेंसी: TLS हैंडशेक अवधि, उपस्थिति कनेक्ट समय, अनुरोध-उत्तर कुल। विभिन्न भागों के मार्ग पर जीवित अलग से मापा जाते हैं।
- प्रॉक्सी में ट्रैफिक: कुल अनुरोध / सेक, प्रति-बैकएंड वितरण (एक गरम बैकएंड सिग्नल बैलेंस-लोडर के झुकाव को संकेत देता है), प्रति-स्टेटस कोड विभाजन।
- प्रॉक्सी में त्रुटियां: 4xx से ग्राहक (आपके उपयोगकर्ता गलत एंडपॉइंट को हिट करते हैं, 5xx से बैकएंड (आपकी सेवाएं विफल होती हैं), प्रॉक्सी-अंतर्निहित त्रुटियां (502 = बैकएंड पहुंच योग्य नहीं है, 504 = बैकएंड टाइमआउट)।
- प्रॉक्सी में संतुलन: TLS सेशन काउंट, उपस्थिति कनेक्शन पूल गहराई, CPU प्रॉक्सी में ही (TLS समाप्ति भारी CPU है)।
प्रो टिप: 502 की एक अचानक वृद्धि से साथ निम्न बैकएंड लेटेंसी का अर्थ है कि बैकएंड पहले से जवाब देने से पहले हैंग अप हो रहा है (कनेक्शन रीसेट, क्रैश, ओएम)। 504 की एक अचानक वृद्धि से साथ बैकएंड धीरे लेकिन अभी भी जवाब दे रहा है। त्रुटि कोड पढ़ें, यह आपको विफलता की स्थिति के बारे में बताता है।
संकेतों को पढ़ें,
आपका डैशबोर्ड पिछले 10 मिनटों में निम्नलिखित दिखाता है:
- ट्रैफिक: लगभग स्थिर 800 req/s (कोई धमाका नहीं)
- लेटेंसी: प50 स्थिर 40ms, प99 200ms से 2,500ms तक बढ़ा है और पांच मिनट से अब भी बढ़ रहा है।
- त्रुटियां: 4xx दर स्थिर 0.3% (सामान्य पृष्ठभूमि); 5xx दर 0.1% से 1.2% तक बढ़ गई (मुख्यतः 504 Gateway Timeout)
- संतुलन: बैकएंड CPU 45% से 78% तक बढ़ा है; प्रॉक्सी CPU स्थिर 30% है।
когда масштабировать, когда освобождать, когда вызывать
решения по емкости нуждаются в триггерах
मेट्रिक्स देखना आसान है। उनके साथ कार्रवाई करने का समय जानना यह विषय है।
पैमाना बढ़ाएं जब: संतृप्ति एक स्थायी सीमा को पार करती है (उदाहरण के लिए, बैकएंड CPU >70% पांच मिनट तक रहता है), या क्यू डीप्थ बढ़ता है एक लक्ष्य से, या लेटेंसी प99 अपने एसएलओ को पार करता है। ट्रिगर को तोड़ने से पहले फायर होना चाहिए, नहीं कि तोड़ें।
रिप्लिका को खाली करें जब: यह लगातार धीमा / त्रुटिपूर्ण होता है जबकि साथी स्वस्थ हैं (एक रिप्लिका गरम होता है होता है अक्सर एक होस्ट-स्तरीय समस्या है, नहीं कि एक अनुप्रयोग समस्या), या जब नई संस्करण को रोल आउट किया जाता है, या जब एक रिप्लिका सौम्य ढंग से सेव करता है।
एक मानव को पेज करें जब: एसएलओ जल्दी से त्रुटि बजट को स्थिर करने के लिए से जल रहा है, या संतृप्ति ट्रिगर बिना ऑटोस्केलिंग को अवशोषित करते हुए फायर होता है, या केसेड पैटर्न दिखाई देता है (ट्रीटी रेट + रिट्री रेट दोनों चढ़ते हुए)।
नहीं पेज करें जब: एक मिनट में एक बुरा सुलझ जाता है, या पृष्ठभूमि बैच नौकरियां अपेक्षित पериोडिक ब्लिप्स का कारण बनती हैं, या ध्वनि सीमा को पार करती है (सीमा गलत है, नहीं कि प्रणाली)।
एसएलओ और त्रुटि बजट जलाना
एसएलओ (सेविस लेवल ऑब्जेक्टिव) स्वीकार्य प्रदर्शन निर्दिष्ट करते हैं: 'सफल अनुरोधों की दर >= 99.9% 28-दिन के समय स्लाइड'। इसके विपरीत (0.1%) यह त्रुटि बजट है।
जलने की दर: आप किस तरह से त्रुटि बजट को उपभोग कर रहे हैं। अगर आपको 1 घंटे में 10% बजट का उपभोग करना है, तो दर 240x तेज हो जाती है स्थायी (1 घंटा 1/672 एक 28-दिन के समय स्लाइड है; 10% जलाने के लिए उस समय स्लाइड = 10% × 672 = 6720% पूर्ण समय स्लाइड के लिए प्रस्तावित, जब केवल 100% मान्य होता है।
मल्टी-विंडो जलने की दर के अलर्ट: जब दोनों छोटे समय (5 मिनट 14.4x दर) और लंबे समय (1 घंटा 6x दर) त्रुटि बजट को तेजी से उपभोग करते हैं पेज करें। दोनों तेज़ आउटेज और धीरे से गिरावट को पकड़ते हैं।
क्षमता के लिए क्यों महत्वपूर्ण है: 99.9% एसएलओ वाली सेवा के साथ 1% स्लैक कमरे के साथ, छोटे ब्लिप को सोखने में सक्षम होती है। 99.93% (केवल एसएलओ को मिलाने के लिए) की सेवा एक बुरा दिन से होकर गुजरने की एक होती है। क्षमता निर्णय एसएलओ के आरामदायक मार्जिन के लक्ष्य पर नहीं बल्कि उसे मिलाने के लिए बनाते हैं।
एक क्षमता निर्णय की निगरानी में,
आपकी सेवा का एसएलओ 28 दिनों के लिए 99.9% सफल अनुरोध है। पिछले एक घंटे के लिए मॉनिटरिंग से मिल रही जानकारी:
- सफलता दर: 99.5% (पांच मिनट से स्थिर)
- बैकएंड CPU: फ़्लीट के सभी में औसतन 82% ( लक्ष्य 70%)
- p99 लेटेंसी: 800 मिलीसेकंड (एसएलओ लक्ष्य: <500 मिलीसेकंड)
- ट्रैफिक: 1,400 रिक्वेस्ट / सेकंड, बेसलाइन 1,000 रिक्वेस्ट / सेकंड से ऊपर (40% सामान्य से; ट्रेंड अभी भी बढ़ रहा है)
- ऑटोस्केलिंग: CPU 80% स्थायी 5 मिनट के लिए जोड़ने के लिए रेप्लिका कॉन्फ़िगर किया गया; वर्तमान में स्केल-अप के बीच जो 3 रेप्लिका ~90 सेकंड में जोड़ेगा
लॉन्च अवलोकनीयता योजना डिज़ाइन करें
सिंथेसिस
अब आप एक /health डिज़ाइन कर सकते हैं जो वास्तविक विफलताओं को पकड़ सकता है, एक /version जो आप को वेरिफ़ाई करने देता है, चार सोने के सिग्नल डैशबोर्ड प्रॉक्सी टायर पर, और क्षमता ट्रिगर एसएलओ जलन की दर से जुड़े हुए हैं।
सभी चार को लागू करें।
आपकी टीम 'search.example.com' (फेलियर-मोड्स पाठ का खोज सेवा लॉन्च कर रही है। टीम को उसी तरह की दिखाई देने वाली समस्याओं को पकड़ने के लिए अवलोकनीयता को शिप करना है, जो उपयोगकर्ताओं को पहले दिखाई देती है, एक स्पष्ट पेज-या-नहीं निर्णय मैट्रिक्स के साथ। SLO: 99.9% सफल अनुरोध, p99 लेटेंसी < 300 मिलीसेकंड, 28-दिन के समय स्लाइड।
कोर्स को बंद करें
कोर्स को बंद करें
आप ने पांच पाठों को पूरा किया है:
- प्रॉक्सी और मूल स्रोत: लगभग हर पब्लिक वेब सेवा का एज लेयर
- राज्यहीन क्षैतिज स्केलिंग: एक स्टेटलेस टियर को कैसे और क्यों सस्ते में मножित किया जाता है और इसे कैसे साइज़ किया जाता है।
- इनग्रेस और इग्रेस सेपरेशन: एक बॉक्स को क्यों दो बना देता है, और इसे किस विफलता के मोड के कारण मजबूर किया जाता है।
- फेलियर मोड और ब्लास्ट रेडियस: SPOFs, cascades, postmortems, blameless action items
- अवलोकनीयता और क्षमता (यह एक): जिससे समस्याएं उपयोगकर्ता के पहले सामने आती हैं ताकि वह मापा जा सके।
सारांश: एक वेब-स्केल डिस्ट्रीब्यूटेड सिस्टम जादू नहीं है। यह सोच-समझकर बनाई गई एक छोटी सेट ऑफ पैटर्न (रिवर्स प्रॉक्सी, स्टेटलेस रिप्लिका, इंग्रेस/इग्रेस स्प्लिट, बुल्कहेड्स और सर्किट ब्रेकर, चार सोने के संकेत) है। एक बार जब आप पैटर्न को पहचान लेते हैं, तब आप इन्हें प्रत्येक प्रोडक्शन आर्किटेक्चर में देखते हैं।
साथी पाठ: पांच ज्यामिति-of-* पाठों में समान सामग्री ज्यामिति और ज्यामिति के रूप में प्रस्तुत की गई है। वे दोनों क्रम में अच्छी तरह से जाते हैं।
बहुत अच्छा किया गया है।