Metrics
Metrics न्यूमेरिकल वैल्यूज़ की एक टाइम-ऑर्डर्ड सीरीज़ है। इनका इस्तेमाल आपके एनवायरनमेंट में सर्वर की संख्या, उनका डिस्क यूसेज, प्रति सेकंड हैंडल किए गए रिक्वेस्ट्स, या इन रिक्वेस्ट्स को पूरा करने में लगी लेटेंसी — सब कुछ ट्रैक करने के लिए होता है।
लेकिन metrics सिर्फ़ इंफ्रास्ट्रक्चर या एप्लिकेशन मॉनिटरिंग तक सीमित नहीं हैं। इनका इस ्तेमाल बिक्री, कॉल क्यू और कस्टमर सैटिस्फ़ैक्शन ट्रैक करने के लिए किसी भी बिज़नेस या वर्कलोड में हो सकता है। असल में, metrics तब सबसे ज़्यादा काम के होते हैं जब ऑपरेशनल डेटा और बिज़नेस मेट्रिक्स दोनों को मिलाकर एक बैलेंस्ड और ऑब्ज़र्वेबल सिस्टम बनाया जाए।
और जानकारी के लिए OpenTelemetry डॉक्यूमेंटेशन पेज देखें।
अपने Key Performance Indicators (KPI) जानें और उन्हें मापें!
Metrics में सबसे ज़रूरी बात है सही चीज़ें मापना। और वो क्या हैं — यह सबके लिए अलग होगा। एक ई-कॉमर्स ऐप में प्रति घंटे बिक्री एक अहम KPI हो सकता है, जबकि एक बेकरी शायद प्रत िदिन बनाए गए क्रोसाँ की संख्या में ज़्यादा इंटरेस्टेड होगी।
आपके बिज़नेस KPI के लिए कोई एक कम्पलीट सोर्स नहीं है। आपको अपने प्रोजेक्ट या एप्लिकेशन को इतना अच्छी तरह समझना होगा कि आप जान सकें कि आपके आउटपुट गोल्स क्या हैं।
पहला कदम है अपने हाई-लेवल गोल्स को नाम देना। ये गोल्स शायद किसी एक इंफ्रास्ट्रक्चर मेट्रिक से एक्सप्रेस नहीं हो सकते। ऊपर के ई-कॉमर्स उदाहरण में, जब आप प्रति घंटे बिक्री मापने का गोल पहचान लेते हैं, तो आप इससे पीछे जाकर डिटेल्ड metrics तक पहुँच सकते हैं — जैसे खरीदारी से पहले प्रोडक्ट खोजने में लगा समय, चेकआउट पूरा करने में लगा समय, प्रोडक्ट सर्च रिज़ल्ट्स की लेटेंसी आदि। इससे पता चलता है कि सिस्टम ऑब्ज़र्व करने के लिए कौन सी जानकारी इकट्ठा करनी है।
अपने KPI पहचानने के बाद, अब आप पीछे की ओर काम करके देख सकते हैं कि आपके वर्कलोड में कौन से metrics इन्हें प्रभावित करते हैं।
ऑपरेशनल मेट्रिक डेटा के साथ correlate करें
अगर आपके वेब सर्वर पर हाई CPU यूसेज स्लो रिस्पॉन्स टाइम का कारण बनता है, जो फिर नाखुश कस्टमर्स और कम रेवेन्यू की वज ह बनता है — तो CPU यूसेज मापना सीधे आपके बिज़नेस आउटकम पर असर डालता है और इसे ज़रूर मापा जाना चाहिए!
या इसके उल्टा — अगर आपके पास एक ऐप है जो एफ़ेमरल क्लाउड रिसोर्सेज़ (जैसे Amazon EC2 fleet) पर बैच प्रोसेसिंग करता है, तो हो सकता है आप CPU को मैक्सिमम पर रखना चाहें ताकि बैच सबसे कॉस्ट-इफ़ेक्टिव तरीके से पूरा हो।
दोनों मामलों में, आपका ऑपरेशनल डेटा (जैसे CPU यूसेज) और बिज़नेस metrics एक ही सिस्टम में होने चाहिए ताकि आप दोनों को कोरिलेट कर सकें।
अपने बिज़नेस metrics और ऑपरेशनल metrics को एक ऐसे सिस्टम में रखें जहाँ आप इन्हें एक साथ कोरिलेट कर सकें और दोनों पर देखे गए इफ़ेक्ट्स से कंक्लूज़न निकाल सकें।
जानें कि "अच्छा" कैसा दिखता है!
एक हेल्दी baseline क्या है — यह समझना मुश्किल हो सकता है। कई लोगों को अपने वर्कलोड पर स्ट्रेस टेस्ट करना पड़ता है ताकि पता चले कि हेल्दी metrics कैसे दिखते हैं। हालाँकि, आपकी ज़रूरतों के हिसाब से आप मौजूदा ऑपरेशनल metrics देखकर भी हेल्दी threshold के बारे में सही अंदाज़ा लगा सकते हैं।
एक हेल्दी वर्कलोड वो है जो आपके KPI गोल्स पूरे करने और रेज़िलिएंट, अवेलेबल और कॉस्ट-इफ़ेक्टिव बने रहने के बीच बैलेंस रखता है।
आपके KPI में ज़रूर एक पहचानी गई हेल्दी रेंज होनी चाहिए ताकि जब परफ़ॉर्मेंस ज़रूरी लेवल से नीचे या ऊपर जाए तो आप alarms बना सकें।
एनोमली डिटेक्शन एल्गोरिदम इस्तेमाल करें
जानें कि "अच्छा" कैसा दिखता है की चुनौती यह है कि आपके सिस्टम की हर मेट्रिक के लिए हेल्दी threshold जानना प्रैक्टिकल नहीं हो सकता। एक RDBMS दर्जनों परफ़ॉर्मेंस metrics देता है, और microservices आर्किटेक्चर के साथ मिलकर आपके पास संभावित रूप से सैकड़ों metrics हो सकते हैं जो आपके KPI को प्रभावित करें।
इतने सारे डेटा पॉइंट्स देखना और इंडिविजुअली उनके ऊपरी-निचले thresholds पहचानना इंसानों के लिए हमेशा प्रैक्टिकल नहीं। लेकिन मशीन लर्निंग इस तरह के रिपीटिटिव काम में बहुत अच्छी है। जहाँ मुमकिन हो ऑटोमेशन और ML का फ़ायदा उठाएँ — यह उन प्रॉब्लम्स को पकड़ने में मदद कर सकती है जिनके बारे में आप शायद जान भी नहीं पाते!
अपने वर्कलोड के परफ़ॉर्मेंस thresholds ऑटोमैटिकली कैलकुलेट करने के लिए ML एल्गोरिदम और एनोमली डिटेक्शन मॉडल इस्तेमाल करें।