Monitoring & Observability: APM, Logging & Alerting Best Practices

स्प्लंक की स्टेट ऑफ ऑब्जर्वेबिलिटी रिपोर्ट के अनुसार परिपक्व अवलोकन प्रथाओं वाली कंपनियां घटनाओं को 69% तेजी से हल करती हैं। निगरानी आपको बताती है कि कुछ टूटा हुआ है। अवलोकनशीलता आपको बताती है कि यह क्यों टूटा है और कहाँ देखना है। हर उत्पादन समस्या को घंटों तक बुझाने और उन्हें मिनटों में हल करने के बीच का अंतर इस बात पर निर्भर करता है कि आप अपने सिस्टम को कितनी अच्छी तरह से व्यवस्थित करते हैं, अपने लॉग की संरचना करते हैं और अपने अलर्ट डिज़ाइन करते हैं।

मुख्य बातें

• अवलोकन के तीन स्तंभ - मेट्रिक्स, लॉग और ट्रेस - प्रत्येक अलग-अलग प्रश्नों का उत्तर देते हैं और संपूर्ण सिस्टम समझ प्रदान करने के लिए मिलकर काम करते हैं
• लक्षणों पर चेतावनी (उपयोगकर्ता-सामना प्रभाव) चेतावनी थकान को कम करने और उपन्यास विफलता मोड को पकड़ने का कारण नहीं बनता है (आंतरिक मेट्रिक्स)
• सहसंबंध आईडी के साथ संरचित JSON लॉगिंग सेवाओं में खोज करने और अनुरोध प्रवाह का पुनर्निर्माण करने में सक्षम बनाता है
• एसएलओ (सेवा स्तर उद्देश्य) निगरानी को "क्या कुछ टूटा है" से "क्या हम उपयोगकर्ताओं के प्रति अपनी प्रतिबद्धताओं को पूरा कर रहे हैं" में बदल देते हैं

---

अवलोकनशीलता के तीन स्तंभ

अवलोकनशीलता तीन पूरक डेटा प्रकारों पर निर्मित होती है। प्रत्येक स्तंभ आपके सिस्टम के व्यवहार के बारे में अलग-अलग प्रश्नों का उत्तर देता है।

मेट्रिक्स

मेट्रिक्स नियमित अंतराल पर एकत्र किए गए संख्यात्मक माप हैं। वे "क्या हो रहा है" प्रश्नों का उत्तर देते हैं: प्रति सेकंड कितने अनुरोध? औसत प्रतिक्रिया समय क्या है? कितनी मेमोरी उपयोग में है?

विशेषताएँ:

• एकत्रित और संक्षिप्त - लाखों घटनाएँ समय-श्रृंखला काउंटरों में संपीड़ित
• स्टोर करने के लिए सस्ता - ट्रैफ़िक की मात्रा की परवाह किए बिना निश्चित आकार का डेटा
• डैशबोर्ड और अलर्टिंग के लिए आदर्श
• सीमित संदर्भ - आप जानते हैं कि प्रतिक्रिया समय बढ़ गया है लेकिन यह नहीं कि कौन से विशिष्ट अनुरोध धीमे हैं

मुख्य मीट्रिक प्रकार:

• काउंटर - एकरस रूप से बढ़ता मूल्य (कुल अनुरोध, कुल त्रुटियाँ)
• गेज - मान जो ऊपर और नीचे जाता है (वर्तमान सीपीयू उपयोग, सक्रिय कनेक्शन)
• हिस्टोग्राम - मूल्यों का वितरण (प्रतिक्रिया समय प्रतिशत, पेलोड आकार)
• सारांश--ग्राहक पक्ष पर पूर्व-परिकलित प्रतिशत

लॉग

लॉग अलग-अलग घटनाओं के टाइमस्टैम्प्ड टेक्स्ट रिकॉर्ड हैं। वे "क्या हुआ" प्रश्नों का उत्तर देते हैं: उपयोगकर्ता ने कौन सा त्रुटि संदेश देखा? विफल फ़ंक्शन में कौन से पैरामीटर पारित किए गए थे? समस्या उत्पन्न होने पर सिस्टम की स्थिति क्या थी?

विशेषताएँ:

• समृद्ध संदर्भ - व्यक्तिगत घटनाओं के बारे में मनमाना विवरण
• पैमाने पर महँगा - उच्च-यातायात प्रणालियाँ प्रति घंटे गीगाबाइट लॉग उत्पन्न करती हैं
• खोजने योग्य - पूर्ण-पाठ खोज के साथ विशिष्ट घटनाएं ढूंढें
• संरचना की आवश्यकता है - असंरचित लॉग लाइनों को पार्स करना और सहसंबंधित करना कठिन है

निशान

ट्रेस अनेक सेवाओं में एक ही अनुरोध का अनुसरण करते हैं। वे "समय कहाँ व्यतीत होता है" प्रश्नों का उत्तर देते हैं: कौन सी सेवा कॉल धीमी है? अनुरोध पथ कहाँ विभक्त होता है? कौन सी डेटाबेस क्वेरी बाधा है?

विशेषताएँ:

• कार्य-कारण दिखाएं - संचालन के बीच माता-पिता-बच्चे के संबंध
• वितरित सिस्टम व्यवहार को प्रकट करें - सेवा सीमाओं के पार विलंबता
• बड़े पैमाने पर नमूनाकरण आवश्यक है - प्रत्येक अनुरोध का पता लगाना महंगा है
• माइक्रोसर्विसेज के लिए आवश्यक - बिना किसी निशान के, बहु-सेवा प्रवाह को डिबग करना अनुमान का काम है

---

ऑब्जर्वेबिलिटी टूल इकोसिस्टम

स्टैक चुनना

अधिकांश बढ़ते व्यवसायों के लिए, हम इनसे शुरुआत करने की सलाह देते हैं:

1. त्रुटि ट्रैकिंग के लिए संतरी - पूर्ण स्टैक ट्रेस, स्रोत मानचित्र और रिलीज़ ट्रैकिंग के साथ अपवाद पकड़ता है
2. प्रोमेथियस + ग्राफाना मेट्रिक्स के लिए - खुला स्रोत, युद्ध-परीक्षण, व्यापक एकीकरण पारिस्थितिकी तंत्र
3. प्रबंधित सेवा के लिए संरचित लॉगिंग - आपके क्लाउड प्रदाता के आधार पर डेटाडॉग लॉग्स, एडब्ल्यूएस क्लाउडवॉच, या ग्राफाना लोकी
4. इंस्ट्रुमेंटेशन के लिए ओपन टेलीमेट्री - विक्रेता-तटस्थ मानक जो किसी भी बैकएंड के साथ काम करता है

उन टीमों के लिए जो एकल विक्रेता चाहते हैं, डेटाडॉग सर्वोत्तम ऑल-इन-वन अनुभव प्रदान करता है लेकिन बड़े पैमाने पर महत्वपूर्ण लागत पर। ग्राफाना का ओपन-सोर्स स्टैक (प्रोमेथियस, लोकी, टेंपो) कम लाइसेंसिंग लागत लेकिन उच्च परिचालन बोझ के साथ समकक्ष क्षमताएं प्रदान करता है।

---

संरचित लॉगिंग सर्वोत्तम अभ्यास

Error processing order 12345 for user john@example.com जैसी असंरचित लॉग लाइनें मानव-पठनीय लेकिन मशीन-विरोधी हैं। संरचित JSON लॉग विशिष्ट फ़ील्ड पर खोज, फ़िल्टरिंग, एकत्रीकरण और चेतावनी सक्षम करते हैं।

लॉग संरचना

प्रत्येक लॉग प्रविष्टि में शामिल होना चाहिए:

सहसंबंध आईडी

सहसंबंध आईडी एक अद्वितीय पहचानकर्ता है जो प्रत्येक अनुरोध की शुरुआत में उत्पन्न होता है और प्रत्येक डाउनस्ट्रीम सेवा कॉल, डेटाबेस क्वेरी और पृष्ठभूमि कार्य को पास किया जाता है। किसी समस्या की जांच करते समय, सहसंबंध आईडी द्वारा खोज करने पर सभी सेवाओं में उस विशिष्ट अनुरोध से संबंधित प्रत्येक लॉग प्रविष्टि दिखाई देती है।

कार्यान्वयन: एपीआई गेटवे या लोड बैलेंसर पर एक यूयूआईडी उत्पन्न करें, इसे X-Request-ID हेडर में पास करें, और इसे प्रत्येक लॉग प्रविष्टि में शामिल करें। NestJS में, एक मिडलवेयर का उपयोग करें जो सहसंबंध आईडी को निकालता या उत्पन्न करता है और इसे async स्थानीय भंडारण संदर्भ में संग्रहीत करता है।

लॉग स्तर

लॉग स्तरों का लगातार उपयोग करें:

• डीबग -- विस्तृत नैदानिक जानकारी, सक्रिय रूप से डिबगिंग होने तक उत्पादन में अक्षम
• जानकारी--महत्वपूर्ण व्यावसायिक घटनाएँ (आदेश दिया गया, उपयोगकर्ता पंजीकृत, भुगतान संसाधित)
• चेतावनी--अप्रत्याशित स्थितियाँ जिन्हें सिस्टम ने संभाल लिया है लेकिन उनकी जांच की जानी चाहिए (पुनः प्रयास सफल हुआ, कैश छूट गया, अप्रचलित एपीआई कॉल)
• त्रुटि--विफलताएँ जिसने उपयोगकर्ता अनुभव को प्रभावित किया (अनुरोध विफल, भुगतान अस्वीकृत, बाह्य सेवा अनुपलब्ध)
• घातक -- एप्लिकेशन जारी नहीं रह सकता (डेटाबेस पहुंच योग्य नहीं है, आवश्यक कॉन्फ़िगरेशन अनुपलब्ध है)

लॉग प्रतिधारण और लागत प्रबंधन

लॉग संग्रहीत करने के लिए सबसे महंगा अवलोकन डेटा है। स्तरीय प्रतिधारण लागू करें:

• हॉट स्टोरेज (30 दिन) -- पूर्ण-पाठ खोजने योग्य, तेज़ क्वेरी, उच्च लागत
• गर्म भंडारण (90 दिन) -- संपीड़ित, धीमी क्वेरी, मध्यम लागत
• कोल्ड स्टोरेज (1 वर्ष+) -- संग्रहीत, क्वेरी-ऑन-डिमांड, कम लागत
• डीबग लॉग -- सक्रिय रूप से समस्या निवारण होने तक उत्पादन में संग्रहीत न करें

---

चेतावनी देने वाला डिज़ाइन

ख़राब अलर्ट अलर्ट थकान पैदा करता है - टीमें अलर्ट पर प्रतिक्रिया देना बंद कर देती हैं क्योंकि अधिकांश गलत सकारात्मक या कम-प्राथमिकता वाले शोर होते हैं। अच्छी चेतावनी वास्तविक मुद्दों को सामने लाती है जिनमें मानवीय हस्तक्षेप की आवश्यकता होती है।

लक्षणों पर सतर्क रहें, कारणों पर नहीं

लक्षण-आधारित चेतावनी (अच्छा): "/एपीआई/ऑर्डर पर त्रुटि दर 5 मिनट के लिए 1% से अधिक हो गई" - यह अंतर्निहित कारण की परवाह किए बिना सीधे उपयोगकर्ता प्रभाव को इंगित करता है।

कारण-आधारित चेतावनी (खराब): "डेटाबेस सीपीयू 90% से अधिक हो गया" - यह उपयोगकर्ताओं को प्रभावित कर भी सकता है और नहीं भी। डेटाबेस 95% सीपीयू को ठीक से संभाल सकता है, या यह 50% सीपीयू पर हो सकता है लेकिन पूरी तरह से गतिरोधित हो सकता है।

कारण-आधारित मेट्रिक्स जांच के लिए डैशबोर्ड पर होते हैं, चेतावनी नियमों में नहीं।

चेतावनी गंभीरता स्तर

चेतावनी शोर को कम करना

1. समूह संबंधी अलर्ट -- यदि डेटाबेस डाउन हो जाता है, तो आपको एक "डेटाबेस अनुपलब्ध" अलर्ट मिलता है, न कि उस पर निर्भर प्रत्येक सेवा से 50 अलर्ट
2. निरंतर उल्लंघन की आवश्यकता है - क्षणिक स्पाइक्स से बचने के लिए "5 मिनट के लिए 90% से ऊपर सीपीयू" न कि "1 सेकंड के लिए 90% से ऊपर सीपीयू"
3. स्वत:-समाधान -- स्थिति का समाधान होने पर अलर्ट स्वचालित रूप से साफ़ हो जाना चाहिए
4. साप्ताहिक अलर्ट समीक्षा -- उन सभी अलर्ट की समीक्षा करें जो सक्रिय हुए, उन अलर्ट की पहचान करें और उन्हें ठीक करें या चुप करा दें जिनके लिए मानवीय कार्रवाई की आवश्यकता नहीं है
5. ऑन-कॉल फीडबैक लूप - प्रत्येक ऑन-कॉल रोटेशन के बाद, इंजीनियर दस्तावेज करता है कि कौन से अलर्ट कार्रवाई योग्य थे और जिन्हें ट्यूनिंग की आवश्यकता है

---

एसएलओ: सेवा स्तर के उद्देश्य

एसएलओ निगरानी को प्रतिक्रियाशील ("कुछ टूट गया, उसे ठीक करें") से सक्रिय में बदल देता है ("हम अपने त्रुटि बजट का उपभोग कर रहे हैं, आइए उपयोगकर्ताओं के ध्यान देने से पहले जांच करें")।

एसएलओ को परिभाषित करना

एसएलओ किसी सेवा के लिए लक्ष्य विश्वसनीयता को परिभाषित करता है। इसमें शामिल हैं:

• एसएलआई (सेवा स्तर संकेतक) - मापी जा रही मीट्रिक (अनुरोध सफलता दर, विलंबता प्रतिशत)
• लक्ष्य - वह सीमा जो स्वीकार्य प्रदर्शन को परिभाषित करती है (99.9% सफलता दर, 200 एमएस के तहत पी95)
• विंडो - वह समयावधि जिस पर लक्ष्य का मूल्यांकन किया जाता है (30 दिन चल रहा है)

ईकॉमर्स प्लेटफॉर्म के लिए उदाहरण एसएलओ

त्रुटि बजट

त्रुटि बजट आपके SLO लक्ष्य का व्युत्क्रम है। 99.9% एसएलओ 0.1% त्रुटियों की अनुमति देता है - प्रति माह लगभग 43 मिनट का डाउनटाइम। जब त्रुटि बजट समाप्त हो जाता है, तो टीम सुविधाओं से विश्वसनीयता कार्य पर ध्यान केंद्रित करती है।

त्रुटि बजट इंजीनियरिंग और उत्पाद टीमों के बीच एक साझा भाषा प्रदान करते हैं। इस बात पर बहस करने के बजाय कि क्या कोई सेवा "पर्याप्त रूप से विश्वसनीय" है, दोनों टीमें यह देख सकती हैं कि कितना त्रुटि बजट बचा है और नई सुविधाओं को शिपिंग बनाम स्थिरता में निवेश करने के बारे में डेटा-संचालित निर्णय ले सकती हैं।

---

अक्सर पूछे जाने वाले प्रश्न

पैमाने पर अवलोकन की लागत कितनी है?

ओपन-सोर्स स्टैक (प्रोमेथियस, ग्राफाना, लोकी) के लिए अवलोकन लागत $10-50 प्रति होस्ट प्रति माह से लेकर वाणिज्यिक समाधान (डेटाडॉग, न्यू रेलिक) के लिए $30-100+ प्रति होस्ट तक होती है। सबसे बड़ी लागत चालक लॉग वॉल्यूम है - डिबग लॉग का नमूना लेकर, संग्रहीत लॉग को संपीड़ित करके और उचित अवधारण अवधि निर्धारित करके अनुकूलित करें। 50 सर्वर से कम के अधिकांश व्यवसायों के लिए, लागत $500-2,000 प्रति माह है।

क्या मुझे ओपनटेलीमेट्री या विक्रेता-विशिष्ट एजेंटों का उपयोग करना चाहिए?

ओपनटेलीमेट्री का प्रयोग करें. यह इंस्ट्रुमेंटेशन के लिए उद्योग मानक है, जो प्रत्येक प्रमुख अवलोकन विक्रेता द्वारा समर्थित है, और विक्रेता लॉक-इन को रोकता है। आप अपने कोड को दोबारा इंस्ट्रुमेंट किए बिना बैकएंड (उदाहरण के लिए डेटाडॉग से ग्राफाना तक) स्विच कर सकते हैं। विक्रेता-विशिष्ट एजेंट कभी-कभी गहन एकीकरण की पेशकश करते हैं, लेकिन पोर्टेबिलिटी समझौता इसके लायक नहीं है।

मैं NestJS एप्लिकेशन के लिए निगरानी कैसे स्थापित करूं?

NestJS में, अनुरोध समय के लिए इंटरसेप्टर, त्रुटि ट्रैकिंग के लिए अपवाद फ़िल्टर और सहसंबंध आईडी प्रसार के लिए मिडलवेयर का उपयोग करें। त्रुटि ट्रैकिंग के लिए सेंट्री को @sentry/nestjs के साथ एकीकृत करें। /मेट्रिक्स एंडपॉइंट पर प्रदर्शित prom-client लाइब्रेरी के साथ प्रोमेथियस मेट्रिक्स निर्यात करें। JSON आउटपुट के लिए कॉन्फ़िगर किए गए nestjs-pino या winston के साथ संरचित लॉगिंग का उपयोग करें।

निगरानी और अवलोकन के बीच क्या अंतर है?

मॉनिटरिंग आपको बताती है कि पूर्वनिर्धारित चीजें कब गलत होती हैं (सीपीयू उच्च, त्रुटि दर ऊपर, डिस्क पूर्ण)। अवलोकनशीलता आपको नए उपकरण तैनात किए बिना सिस्टम व्यवहार के बारे में नए प्रश्न पूछने की सुविधा देती है। एक सिस्टम तब देखने योग्य होता है जब आप उसकी आंतरिक स्थिति को उसके बाहरी आउटपुट (मेट्रिक्स, लॉग, ट्रेस) से समझ सकते हैं। व्यवहार में, अच्छी निगरानी अवलोकन क्षमता का एक उपसमूह है।

मैं अपनी टीम को अवलोकनीयता में निवेश करने के लिए कैसे मनाऊं?

अवलोकनीयता में सुधार से पहले और बाद में उत्पादन घटनाओं के लिए मीन टाइम टू रेजोल्यूशन (एमटीटीआर) ट्रैक करें। अच्छी अवलोकन क्षमता वाली टीमें आमतौर पर एमटीटीआर को 60-70% तक कम कर देती हैं। आरओआई दिखाने के लिए बचाए गए समय को इंजीनियरिंग लागत से गुणा करें। मॉनिटरिंग बनाम उपयोगकर्ता रिपोर्ट द्वारा पता लगाई गई घटनाओं की संख्या को भी ट्रैक करें - सक्रिय पहचान से ग्राहक का विश्वास बढ़ता है।

---

आगे क्या है

यदि आपके पास कुछ नहीं है तो त्रुटि ट्रैकिंग (सेंट्री) से शुरुआत करें - यह उत्पादन त्रुटियों को पकड़कर और सचेत करके सबसे तत्काल मूल्य प्रदान करता है। इसके बाद, सहसंबंध आईडी के साथ संरचित लॉगिंग जोड़ें। फिर प्रोमेथियस और ग्राफाना डैशबोर्ड के साथ मेट्रिक्स संग्रह लागू करें। अंत में, जब आपके पास एकाधिक सेवाएँ हों तो वितरित ट्रेसिंग जोड़ें।

संपूर्ण प्रदर्शन इंजीनियरिंग संदर्भ के लिए, आपके व्यवसाय प्लेटफ़ॉर्म को स्केल करना पर हमारी स्तंभ मार्गदर्शिका देखें। आपकी निगरानी द्वारा देखे जाने वाले बुनियादी ढांचे को अनुकूलित करने के लिए, हमारी बुनियादी ढांचा स्केलिंग गाइड पढ़ें।

ECOSIRE Odoo ERP और कस्टम आर्किटेक्चर पर चलने वाले व्यावसायिक प्लेटफार्मों के लिए अवलोकनीयता स्टैक लागू करता है। निगरानी और अवलोकन मूल्यांकन के लिए हमारी DevOps टीम से संपर्क करें।

---

ECOSIRE द्वारा प्रकाशित - Odoo ERP, Shopify eCommerce, और OpenClaw AI में AI-संचालित समाधानों के साथ व्यवसायों को बढ़ाने में मदद करना।