चाहे आप एक DevOps, SRE, या सिर्फ एक डेटा-संचालित व्यक्ति हों, आप शायद डैशबोर्ड और मेट्रिक्स के आदी हैं। हम यह देखने के लिए अपने मेट्रिक्स देखते हैं कि हमारा सिस्टम कैसा प्रदर्शन कर रहा है, चाहे इंफ्रास्ट्रक्चर, एप्लिकेशन या व्यावसायिक स्तर पर। हम अपने मेट्रिक्स पर भरोसा करते हैं जो हमें हमारे सिस्टम की स्थिति और यह कहां गलत व्यवहार करता है, दिखाने के लिए है। लेकिन क्या हमारे मेट्रिक्स हमें दिखाते हैं कि वास्तव में क्या हुआ था? आपको आश्चर्य होगा कि कितनी बार ऐसा नहीं होता है। इस पोस्ट में मैं मेट्रिक्स के पीछे के गणित और यांत्रिकी, कुछ सामान्य गलत धारणाओं, सटीक मेट्रिक्स के लिए क्या आवश्यक है, और अगर ऐसी कोई बात है, पर गौर करूंगा। मेट्रिक्स अनिवार्य मेट्रिक्स अनिवार्य रूप से कच्चे ईवेंट के रोल-अप हैं। इस रोल-अप प्रक्रिया के दौरान, घटनाओं को संख्यात्मक डेटा बिंदुओं में अनुवादित किया जाता है। एक साधारण उदाहरण सिस्टम में होने वाली त्रुटियां हैं, त्रुटियों की गणना करने के लिए एक साधारण मीट्रिक के साथ। मेट्रिक्स में कई चर शामिल हो सकते हैं, जैसे कि 1 सेकंड से अधिक प्रतिक्रिया समय वाले अनुरोधों की संख्या। जब समय के साथ मापा जाता है, तो ये डेटा बिंदु एक बनाते हैं। समय श्रृंखला मेट्रिक्स विभिन्न प्रकार के हो सकते हैं, जैसे काउंटर, गेज और हिस्टोग्राम। उपयोग घटनाओं की संचयी गिनती के लिए किया जाता है, जैसा कि हमने उपरोक्त उदाहरणों में देखा। आमतौर पर माप के नवीनतम मूल्य का प्रतिनिधित्व करते हैं। और फिर जैसे अधिक विस्तृत प्रकार हैं जो कॉन्फ़िगर करने योग्य "बाल्टी" या "डिब्बे" में घटनाओं की गणना करके मीट्रिक मानों के का नमूना ले सकते हैं। उदाहरण के लिए, आप समय में दिए गए बिंदुओं में अपने क्लस्टर में पॉड्स द्वारा खंडित मेमोरी उपयोग प्रतिशत को समझना चाह सकते हैं। काउंटरों का गेज हिस्टोग्राम वितरण मेट्रिक्स के यांत्रिकी एक आदर्श दुनिया में, हम सभी कच्ची घटनाओं को निगलेंगे और संग्रहीत करेंगे, और फिर क्वेरी समय पर मेट्रिक्स की गणना करेंगे। यह हमें किसी भी तरह से घटनाओं को स्लाइस और डाइस करने की अनुमति देगा, और हम जो भी तदर्थ प्रश्न पूछना चाहते हैं, पूछ सकते हैं। वास्तविक दुनिया में, हालांकि, डेटा की उच्च मात्रा के कारण, सभी कच्ची घटनाओं को विस्तारित अवधि के लिए रखना निषेधात्मक रूप से महंगा हो सकता है। इसे दूर करने के लिए, घटनाओं को संग्रह पाइपलाइन में मेट्रिक्स में अक्सर रोल अप किया जाता है, जबकि कच्ची घटनाओं को छोड़ दिया जाता है या उन्हें केवल छोटी अवधि के लिए बनाए रखा जाता है। यह अक्सर आपके मेट्रिक्स कलेक्टर एजेंट में एक साधारण कॉन्फ़िगरेशन का मामला होता है। लागत कम करने के अलावा, संग्रह पर एकत्रीकरण उच्च आवृत्ति पर उच्च मीट्रिक संचरण और अंतर्ग्रहण दरों के साथ वास्तविक समय के विश्लेषण के प्रदर्शन में सुधार कर सकता है, और क्वेरी समय पर भारी एकत्रीकरण और गणना से बच सकता है। मेट्रिक्स का गणित संक्षेप में इस रोलिंग-अप प्रक्रिया में कुछ गणित शामिल है। हम प्रतिक्रिया समय के माध्य या माध्यिका की गणना करना चाहते हैं, या शायद एक प्रतिशतक, या एक समय खिड़की पर एकत्रीकरण। हो सकता है कि हम अनेक ईवेंट को एक समग्र मीट्रिक में रोल अप करना चाहें. उदाहरण के लिए, मैं अपने क्लस्टर में एक विशिष्ट सेवा के सभी पॉड्स के 95वें प्रतिशतक (आमतौर पर P95 के रूप में जाना जाता है) की गणना करना चाह सकता हूं। अगर आपको गणित पसंद नहीं है, तो भी आप इसे मेट्रिक्स से नहीं टाल सकते। आपको विभिन्न एकत्रीकरण कार्यों को समझने की आवश्यकता है, और उस प्रश्न के बीच संबंध जो आप पूछना चाहते हैं और इसका उत्तर देने के लिए आपको जिस मीट्रिक और कुल की आवश्यकता है। आइए औसत फ़ंक्शन को एक उदाहरण के रूप में देखें, क्योंकि कई वहां से शुरू होते हैं। औसत, परिभाषा के अनुसार, चीजों को सुचारू करता है और विषम व्यवहार और आउटलेयर को दूर करने के लिए कम उपयुक्त होगा। विलंबता समस्याओं की जांच करते समय, उदाहरण के लिए, औसत मीट्रिक मानों को देखना काफी बेकार होगा, और आप प्रतिशतकों को देखना बेहतर समझेंगे। अपने प्रश्नों का निर्धारण करें, तदनुसार अपनी मीट्रिक डिज़ाइन करें एक तरह से, आप इन मेट्रिक्स को हानिपूर्ण संपीड़न के रूप में सोच सकते हैं, जिसके दौरान हम कच्चे घटनाओं से डेटा और संदर्भ खो देते हैं। यदि हम अपरिष्कृत घटनाओं को नहीं रखते हैं, तो हमें पहले ही यह निर्धारित करना होगा कि हमारे लिए क्या महत्वपूर्ण है। उदाहरण के लिए, यदि मैं केवल डेटा पर औसत मान की गणना करता हूं, तो मैं बाद में पूर्व-समेकित डेटा पर P95 (95वां प्रतिशतक) के बारे में नहीं पूछ पाऊंगा। आपको यह निर्धारित करने की आवश्यकता है कि आप किन प्रश्नों का उत्तर देना चाहते हैं, आपके लिए क्या महत्वपूर्ण है, और तदनुसार अपनी मीट्रिक और एकत्रीकरण डिज़ाइन करें। एक सामान्य गलती यह है कि लोग इस डिज़ाइन चरण से बचते हैं, और अपनी पसंद के मेट्रिक्स कलेक्टर के साथ बॉक्स से बाहर दिए गए प्रीसेट मेट्रिक्स और डिफ़ॉल्ट मानों का उपयोग करते हैं। जबकि आप सोच सकते हैं कि ये डिफ़ॉल्ट कुछ उद्योग मानक का प्रतिनिधित्व करते हैं, ये अक्सर काफी विरासत होते हैं, और ज्यादातर मामलों में आपकी विशिष्ट आवश्यकताओं के अनुरूप नहीं होंगे। https://youtu.be/t9hpWv7fVSK?t=555?embedable=true माप की समस्या भौतिकी की तरह ही, माप की समस्या तब होती है जब हम असतत अंतराल पर एक (प्रतीत होता है) निरंतर संपत्ति को मापते हैं, जिसे अक्सर कहा जाता है, जो यह एक विकृत प्रतिनिधित्व बनाता है, जहाँ मीट्रिक वास्तव में मूल रूप से मापी गई संपत्ति को प्रतिबिंबित नहीं कर सकता है। उदाहरण के लिए, यदि हम प्रत्येक 60 सेकंड में CPU उपयोग को मापते हैं, तो इन नमूनाकरण बिंदुओं के बीच होने वाला कोई भी CPU बाहरी रूप से हमारे लिए अदृश्य होगा। नमूनाकरण अंतराल नमूनाकरण दर निर्धारित करता है। इसके अलावा, एक लगातार रेखा खींचने के लिए, विज़ुअलाइज़ेशन टूल अक्सर लगातार डेटा बिंदुओं पर औसत होता है, जो एक चिकनी रेखा का भ्रामक रूप देता है। कुछ अवसरों पर इसके विपरीत हो सकता है, जहां आप अपने मीट्रिक में ऐसी कलाकृतियां प्राप्त कर सकते हैं जो वास्तविक नहीं हैं, जैसे आपके मीट्रिक में शिखर जो वास्तव में मौजूद नहीं हैं। यह स्टोरेज बैकएंड के भीतर एकत्रीकरण चलाते समय हो सकता है, जिसके कारण गणना की जा रही है। पता लगाने का औसत समय नमूने की अवधि यह भी प्रभावित करती है कि मेट्रिक्स में सिस्टम में बदलाव कितनी तेजी से दिखाई देगा। प्रवृत्ति का पता लगाने के लिए अधिकांश एल्गोरिदम को पांच डेटा बिंदुओं की आवश्यकता होती है। यदि नमूनाकरण अंतराल 60 सेकंड है, तो सरल गणित निर्धारित करता है कि कुछ गलत होने से पहले इसमें पाँच मिनट (अर्थात, 60 सेकंड X 5 डेटा बिंदु) लगेंगे। क्या आप यह जानने के लिए 5 मिनट प्रतीक्षा कर सकते हैं कि आपका सिस्टम क्रैश हो गया है? कम नमूना अंतराल (यानी उच्च नमूनाकरण दर) का उपयोग करने से यह अवधि कम हो जाएगी और हम तेजी से पता लगाने और प्रतिक्रिया करने में सक्षम होंगे। बेशक, उच्च नमूनाकरण दर सीपीयू और स्टोरेज में ओवरहेड लगाती है, इसलिए हमें उस कॉन्फ़िगरेशन को खोजने की आवश्यकता है जो हमारी आवश्यकताओं के लिए सही संतुलन बनाता है। भिन्न संकल्प और डाउनस्केलिंग लागत को कम करने के लिए एक सामान्य अभ्यास मेट्रिक्स को अलग-अलग संकल्पों में एक स्तरीय दृष्टिकोण में सहेजना है। उदाहरण के लिए, हो सकता है कि आप पहले दिन के लिए हर 10 सेकंड में मीट्रिक को सहेजना चाहें, लेकिन फिर अगले सप्ताह के लिए हर 5 मिनट में और शायद महीने या उससे अधिक समय के लिए हर 1 घंटे में सहेजना चाहें। यह अभ्यास मानता है कि हमें निकट वास्तविक समय की अवधि के लिए बेहतरीन ग्रैन्युलैरिटी की आवश्यकता है, जिसकी हमें आवश्यकता हो सकती है यदि सिस्टम में कोई समस्या है, जबकि लंबी अवधि की जांच के लिए बड़े पैमाने पर रुझान की आवश्यकता होती है। विभिन्न ग्रैन्युलैरिटी को मेट्रिक्स को डाउनस्केल करके प्राप्त किया जा सकता है, अर्थात् उच्च ग्रैन्युलैरिटी के कम ग्रैन्युलर मीट्रिक की गणना करना। हालांकि यह पूरी तरह से उचित लगता है, गणित यहाँ हस्तक्षेप कर सकता है, क्योंकि कुछ एकत्रीकरण कार्य कुछ संगणनाओं के साथ संगत नहीं हैं, और इसलिए बाद में एकत्र नहीं किए जा सकते हैं। उदाहरण के लिए, शतमक योज्य नहीं होते हैं और उनका योग नहीं किया जा सकता है। इसलिए, उपरोक्त उदाहरण का अनुसरण करते हुए, यदि आपके पास 10 सेकंड के रिज़ॉल्यूशन वाला P99 प्रतिशतक नमूना है, तो आप उन्हें 5-मिनट के रिज़ॉल्यूशन तक रोल नहीं कर सकते। एकत्रीकरण कार्यों की संगतता के बारे में जागरूक होना महत्वपूर्ण है, और गैर-संगत कार्यों जैसे कि प्रतिशतक का उपयोग करते समय, डिजाइन निर्णय लेने के लिए कि हमें किन संकल्पों की आवश्यकता है, और इन समय श्रृंखलाओं की अग्रिम गणना करें। अलग-अलग संकल्प केवल समय कारक तक ही सीमित नहीं है। एक अन्य उदाहरण प्रति-पॉड डेटा को सहेज रहा है, और फिर नोड्स या क्लस्टर्स को "ग्रुप बाय" करना चाहता है। यहां वही बाधा लागू होती है, जिसका अर्थ है कि यदि हम प्रति नोड, प्रति क्षेत्र, प्रति नामस्थान या पूरे क्लस्टर में प्रतिशतक-आधारित मीट्रिक को स्लाइस करने और डाइस करने में रुचि रखने की अपेक्षा करते हैं, तो हमें तदनुसार पूर्व-एकत्रीकरण करने की आवश्यकता है। एक अन्य दृष्टिकोण हिस्टोग्राम का उपयोग करके गणना में अनुकूलता प्राप्त करने के लिए माप की सटीकता को छोड़ना है। आप कुछ सर्वरों के हिस्टोग्राम ले सकते हैं और उन्हें जोड़ सकते हैं, या कई बार विंडो के हिस्टोग्राम और उन्हें जोड़ सकते हैं, और फिर डाउनस्केल कर सकते हैं। समस्या यह है कि इस मामले में प्रतिशतक सटीक होने के बजाय अनुमान होंगे। यह भी ध्यान रखना महत्वपूर्ण है कि हिस्टोग्राम भंडारण और थ्रूपुट में अधिक समय लेने वाले होते हैं, क्योंकि प्रत्येक नमूना केवल एक संख्या नहीं बल्कि कुछ नमूने (प्रति बकेट) होते हैं। सारांश मेट्रिक्स हमारे अनुप्रयोगों की निगरानी करने का एक शक्तिशाली तरीका है। लेकिन जरूरी नहीं कि वे वास्तविक प्रणाली की स्थिति के प्रतिनिधि हों। यह सुनिश्चित करने के लिए मेट्रिक्स के गणित और प्रकृति, साथ ही सावधान डिजाइन की समझ की आवश्यकता है, यह सुनिश्चित करने के लिए कि हमारे मेट्रिक्स वास्तव में हमारे लिए आवश्यक प्रश्नों का उत्तर देने के लिए उपयोगी हैं। मेट्रिक्स के अलावा कच्चे डेटा तक पहुंच हमेशा अच्छी होती है, क्योंकि यह अंततः सत्य का स्रोत है। और जानना चाहते हैं? OpenObservability Talks एपिसोड देखें: , या पर उपयोगी हैं। सभी मेट्रिक्स गलत हैं, कुछ Spotify Apple पॉडकास्ट अन्य पॉडकास्ट ऐप्स यह लेख मूल रूप से था। यहाँ
