निगरानी और अवलोकन: मीट्रिक, लॉग, ट्रेस और अलार्म नियम

लाभ:

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

हालाँकि कोई सिस्टम काम करता हुआ प्रतीत हो सकता है, लेकिन वह अंदर ही अंदर ख़त्म हो रहा हो सकता है: मेमोरी धीरे-धीरे भर रही है, प्रतिक्रिया समय बढ़ रहा है, त्रुटि दर बढ़ती जा रही है। इस पर ध्यान देने का एकमात्र तरीका सिस्टम की लगातार निगरानी करना है। एक अधिक उन्नत अवधारणा अवलोकन क्षमता है: सिस्टम के बाहरी संकेतों को देखकर यह समझने की क्षमता कि उसके अंदर क्या चल रहा है। अवलोकन के तीन स्तंभ हैं, और DevOps पेशेवर तीनों का उपयोग करता है:

• मीट्रिक: समय के साथ मापा गया संख्यात्मक मान - सीपीयू उपयोग, अनुरोधों की संख्या, प्रतिक्रिया समय, त्रुटि दर। "कितना?" प्रश्न का उत्तर देता है.
• लॉग: सिस्टम द्वारा उत्पादित टेक्स्ट ईवेंट रिकॉर्ड - "उपयोगकर्ता लॉग इन", "डेटाबेस कनेक्शन खो गया"। "वास्तव में क्या हुआ?" प्रश्न का उत्तर देता है.
• ट्रेस: ​​सिस्टम के भीतर सेवा से सेवा तक जाते समय अनुरोध का पथ और प्रत्येक चरण की अवधि। “धीमी कहाँ है?” प्रश्न का उत्तर देता है.

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

आइए एक वाक्य में निगरानी और अवलोकन के बीच अंतर को स्पष्ट करें: निगरानी उन प्रश्नों को पूछ रही है जिन्हें आप पहले से जानते हैं ("क्या सीपीयू 90% से अधिक है?"); अवलोकनशीलता उन प्रश्नों को पूछने में सक्षम है जो आप पहले से नहीं जानते थे ("यह अजीब धीमापन केवल एक निश्चित समय पर एक निश्चित ग्राहक के लिए ही क्यों हो रहा है?")। आधुनिक प्रणालियाँ इतनी जटिल हैं कि आप विफलता के सभी तरीकों की भविष्यवाणी नहीं कर सकते; इसलिए, समृद्ध मेट्रिक्स, लॉग और ट्रेस एकत्र करने और फिर उनसे गहराई से पूछताछ करने की क्षमता - यानी, अवलोकन - महत्वपूर्ण हो जाती है। यहीं पर एआई "पहले से अज्ञात प्रश्न" का उत्तर देते समय काम आता है: यह आपके पास मौजूद कच्चे डेटा को तुरंत स्कैन करता है, पैटर्न और विसंगतियों का सुझाव देता है, और आप इन सुरागों को सत्यापित करके मूल कारण तक पहुंचते हैं।

चरण दर चरण: क्या और कैसे निगरानी करें?

1. सही मेट्रिक्स चुनें. उद्योग में, "चार सुनहरे संकेतों" को आधार के रूप में लिया जाता है: विलंबता, यातायात, त्रुटियां, संतृप्ति - संसाधन कितना भरा हुआ है। ये अधिकांश सेवाओं के स्वास्थ्य का सारांश प्रस्तुत करते हैं।
2. मेट्रिक्स एकत्रित करें. एप्लिकेशन को एक समापन बिंदु प्रस्तुत करने दें जिसे प्रोमेथियस पढ़ सकता है।
3. डैशबोर्ड सेट करें. Grafana में इन मेट्रिक्स को विज़ुअलाइज़ करें।
4. अलार्म नियम लिखें. सीमा पार होने पर किसे चेतावनी दी जाएगी और कैसे?
5. लॉग को केंद्रीकृत करें. सभी सेवा लॉग को एक ही स्थान पर खोजने योग्य बनाएं।
6. शोर कम करें. बहुत अधिक अलार्म "चेतावनी थकान" पैदा करता है; महत्वपूर्ण अलार्म गायब हो जाता है.

युक्ति: एक अच्छा अलार्म दो चीजों को पूरा करता है: यह कार्रवाई योग्य है और इसकी सही तात्कालिकता है। एक अलार्म जो किसी को सुबह 3 बजे जगाता है वह कुछ ऐसा होना चाहिए जिसके लिए वास्तव में रात के समय हस्तक्षेप की आवश्यकता होती है। किसी को ऐसी किसी चीज़ के लिए न जगाएं जिसके लिए स्वयं कार्रवाई की आवश्यकता नहीं है, जैसे "सीपीयू 70%"; इसे बोर्ड पर प्रदर्शित करें.

अलार्म नियम कैसे लिखें?

एक अलर्ट में तीन घटक होते हैं: स्थिति (कौन सी मीट्रिक किस सीमा से अधिक है और कितनी देर तक), अवधि (क्षणिक उतार-चढ़ाव से बचने के लिए "5 मिनट के लिए"), और महत्व/कार्रवाई (किसको, किस चैनल के माध्यम से)। एआई इन तीनों को सही संदर्भ में कुशलतापूर्वक स्थापित करता है। उदाहरण के लिए, "5 मिनट के लिए त्रुटि दर 5% से अधिक होने पर गंभीर अलार्म" जैसे नियम का प्रोमक्यूएल में अनुवाद करना एआई के लिए एक सेकंड का काम है - लेकिन आप तय करते हैं कि सीमा आपके सिस्टम के लिए सही है या नहीं।

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

लॉग गोपनीयता: गंभीर चेतावनी

लॉग लीक का सबसे अधिक अनदेखा स्रोत हैं। लॉग लाइन में गलती से पासवर्ड, क्रेडिट कार्ड नंबर या व्यक्तिगत डेटा (केवीकेके/जीडीपीआर के तहत) हो सकता है। विश्लेषण के लिए एआई में लॉग चिपकाते समय:

1. संवेदनशील क्षेत्रों को ढकें। टोकन, पासवर्ड, ईमेल, आईडी नंबर जैसे मानों को <REDACTED> से बदलें।
2. उदाहरण दीजिए, सभी नहीं। दस लाख पंक्तियों के बजाय, कुछ सौ प्रतिनिधि पंक्तियाँ अक्सर पर्याप्त होती हैं।
3. संस्थान द्वारा अनुमोदित वाहन चुनें। विशेष रूप से उत्पादन लॉग के लिए, ऐसे टूल का उपयोग करें जिसका डेटा प्रशिक्षण के लिए नहीं जाता है।

चार सुनहरे सिग्नल और अलार्म टेबल

संकेत

द्वारा मापा गया

उदाहरण अलार्म सीमा

अत्यावश्यकता

विलंबता

प्रतिक्रिया समय

पी95 > 800 एमएस, 5 मिनट

उच्च

यातायात

अनुरोध/सेकंड

अचानक 300% वृद्धि/कमी

मध्यम

त्रुटि

विफल अनुरोध दर

> 5%, 5 मिनट

आलोचनात्मक

संतृप्ति

संसाधन अधिभोग

डिस्क > 85%

उच्च

तीन मिनी मामले

केस 1 - लॉग की 400 पंक्तियों का सारांश 30 सेकंड में। एक सेवा धीमी हो गई थी. इंजीनियर ने एआई को लॉग की छिपी हुई 400 पंक्तियाँ दीं और कहा, "आवर्ती त्रुटि पैटर्न और समय की तीव्रता को संक्षेप में प्रस्तुत करें।" एआई ने दिखाया कि एक विशेष बाहरी एपीआई कॉल हर 30 सेकंड में समाप्त हो जाती है। 30 सेकंड में मूल कारण का पता चला; लॉग को मैन्युअल रूप से स्कैन करने में आधा घंटा लगेगा।

केस 2 - अलार्म थकान का समाधान। एक टीम को एक दिन में 200 अलार्म मिल रहे थे और वह उन सभी को नजरअंदाज कर रही थी - जब तक कि वास्तविक आउटेज अलार्म को भी नजरअंदाज नहीं किया गया। एआई को सभी सतर्क नियम बताएं और पूछें "कौन सा कार्रवाई योग्य नहीं है और कौन सा जोड़ा जा सकता है?" उन्होंने पूछा. अलार्म की संख्या घटकर प्रति दिन 12 हो गई; अब हर अलार्म को गंभीरता से लिया जाने लगा।

केस 3 - गलत सीमा जल्दी पकड़ी गई। YZ ने डिस्क के लिए "95% पूर्ण होने पर चेतावनी" का सुझाव दिया। इंजीनियर ने ऐतिहासिक डेटा को देखा: एक बार जब डिस्क 95% तक पहुंच गई तो हस्तक्षेप के लिए बहुत कम समय था। इसने सीमा को 80% तक कम कर दिया और "विकास दर" के आधार पर दूसरा अलार्म जोड़ा। सत्यापन ने वास्तविक मध्यरात्रि आउटेज को रोक दिया।

चार प्रतिलिपि योग्य टेम्पलेट

1) लॉग सारांश (नकाबपोश):

नीचे दिए गए लॉग उदाहरण का विश्लेषण करें (मैंने संवेदनशील मानों को <REDACTED> से छिपा दिया है)। मुझे बताएं: (1) आवर्ती त्रुटि पैटर्न, (2) समय के साथ एकाग्रता, (3) सबसे संभावित मूल कारण, और (4) 3 मीट्रिक जिन्हें मैं सत्यापित करने के लिए देखूंगा। लॉग: [लाइनें]

2) अलार्म नियम निर्माण:

प्रोमेथियस/अलर्टमैनेजर के लिए एक अलार्म नियम लिखें: यदि [थ्रेशोल्ड] [मेट्रिक] [अवधि] से अधिक हो तो [गंभीरता] अलार्म उत्पन्न करें। नियम क्रिया-उन्मुख होना चाहिए और इसमें एक एनोटेशन और रनबुक लिंक फ़ील्ड शामिल होना चाहिए। PromQL को समझाइए और लिखिए कि यह सीमा उचित क्यों है।

3) PromQL क्वेरी लिखना/घोषित करना:

एक PromQL क्वेरी लिखें जो मापती हो: [EX. पिछले 5 मिनट में 5xxत्रुटि दर प्रतिशत]। प्रश्न को चरण दर चरण समझाएँ। तो फिर मुझे बताएं कि इस मान के लिए स्वस्थ सीमा क्या होनी चाहिए।

4) डैशबोर्ड डिज़ाइन:

[सेवा] के लिए एक ग्राफाना डैशबोर्ड डिज़ाइन करें: मुझे किस पैनल के साथ चार सुनहरे सिग्नल (विलंबता, ट्रैफ़िक, त्रुटि, संतृप्ति) प्रदर्शित करने चाहिए? प्रत्येक पैनल के लिए मीट्रिक, विज़ुअलाइज़ेशन प्रकार और उचित सीमा का सुझाव दें। उद्देश्य: 10 सेकंड में गार्ड की स्वास्थ्य स्थिति देखना।

कमजोर संकेत/मजबूत संकेत

कमज़ोर: "उस लॉग में क्या है?" (इसके बाद कच्चे लॉग की 5000 पंक्तियाँ, इसमें टोकन)

परिणाम: आप रहस्य लीक करते हैं और एआई एक अलक्षित, सतही सारांश देता है।

स्ट्रॉन्ग: "नीचे दिए गए 300-लाइन मास्क्ड लॉग उदाहरण में आवर्ती त्रुटि पैटर्न और समय की तीव्रता ढूंढें; मुझे सबसे संभावित मूल कारण और वे मेट्रिक्स बताएं जिन्हें मैं सत्यापित करने के लिए देखूंगा। मैंने टोकन <REDACTED> बनाए हैं।"

अंतर: दूसरा संकेत एक स्पष्ट विश्लेषण आउटपुट के लिए पूछते हुए एक छिपा हुआ और केंद्रित उदाहरण देता है; यह सुरक्षित और उपयोगी दोनों है.

सामान्य गलतियाँ

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

सारांश

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

आवेदन कार्य

किसी सेवा (या नमूना सेवा) के लिए: (1) "अलार्म नियम पीढ़ी" टेम्पलेट के साथ त्रुटि दर के लिए एक अलार्म नियम तैयार करें और सुझाई गई सीमा को "अतीत में कितनी बार ट्रिगर किया गया है?" पर सेट करें। प्रश्न के साथ इसका परीक्षण करें; (2) आपके पास जो लॉग नमूना है उसे छुपाएं और उसका "लॉग सारांश" टेम्पलेट के साथ विश्लेषण करें; (3) ध्यान दें कि सबसे संभावित मूल कारण की पुष्टि के लिए आप किस मीट्रिक को देखेंगे।

चेकलिस्ट

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