☃️ 🐖 👰🏾 एसआरई अवलोकन: नाम स्थान और मीट्रिक संरचना 👨‍✈️ 🤽 👴🏼

शोराई-सान

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

यह कई फायदे प्रदान करता है: डेटा के कुछ सबसेट को देखना, अपने बच्चों के संदर्भ में एक मीट्रिक को परिभाषित करना और मैट्रिक्स के बीच संबंध स्थापित करना। Mail.ru क्लाउड सॉल्यूशंस

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

मीट्रिक नामस्थान और उनकी संरचना

मीट्रिक नेमस्पेस वे वैचारिक रिक्त स्थान हैं जिनमें मीट्रिक रहते हैं। वे अक्सर एक डेटाबेस या खाते तक सीमित होते हैं:

मेट्रिक नेमस्पेस नामस्थान के भीतर मेट्रिक्स की संरचना भी है। उचित नाम और संरचना कई बड़े फायदे खोलती है।

ऊपर दिए गए आरेख के नामस्थान में एक स्पष्ट संरचना नहीं है। प्रत्येक मीट्रिक अलग और स्वतंत्र है। मेट्रिक्स के पास इस तथ्य के अलावा कुछ भी नहीं है कि वे एक ही नाम स्थान पर मौजूद हैं। इस असंबंधित संरचना में, प्रत्येक मीट्रिक का उपयोग व्यक्तिगत रूप से किया जाएगा। किसी सेवा के लिए http अनुरोधों की आवृत्ति देखने के लिए, सेवा मीट्रिक को सीधे एक्सेस किया जाना चाहिए - service_N_http_requests_total।

मान लीजिए कि हम सभी सेवाओं के लिए अनुरोधों की कुल संख्या देखना चाहते हैं। यदि हम एक नई सेवा बनाते हैं तो उपरोक्त उदाहरण में क्या होता है?

यदि अनुरोधों की कुल संख्या की गणना सेवा_1 और service_2 के अनुरोधों को संक्षेप में करके की जाती है, तो सेवा_3 जोड़ने से कुल अनुरोधों की संख्या में परिवर्तन नहीं होता है। सही कुल अनुरोधों की गणना करने के लिए, आपको सेवा_3_http_requests_ototal को जोड़कर गणना नियम को बदलना होगा। नीचे दिए गए अनुरोधों की संख्या के ग्राफ पर एक नज़र डालें:

मेट्रिक्स ट्री

एक संरचना रहित नामस्थान का एक वैकल्पिक नाम मीट्रिक के रूप में नाम का उपयोग करके एक स्पष्ट संरचना को स्वीकार करना है। नीचे दिए गए चित्र में, आप इस संरचना को एक पेड़ के रूप में देखते हैं:

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

प्रोमेथियस में, सभी सेवाओं के लिए प्रति सेकंड अनुरोधों की संख्या एक अनुरोध के निर्माण द्वारा देखी जा सकती है, जैसा कि नीचे दी गई तस्वीर में है:

एक संरचित नाम स्थान के साथ, आप पूरे नोड में गतिशील रूप से प्रश्नों के योग की गणना कर सकते हैं। इस मामले में, प्रोमेथियस प्रत्येक सेवा के लिए एक अलग मीट्रिक के रूप में प्रति सेकंड अनुरोधों की संख्या की गणना करता है।

वंशानुक्रम मेट्रिक्स को परिभाषित करना

मैट्रिक्स ट्री का उपयोग करते समय, प्रत्येक मीट्रिक आयाम ("सेवा" लेबल) में किसी विशेष सेवा के अनुरोधों की एक व्यक्तिगत आवृत्ति होती है। मेट्रिक्स नेमस्पेस का उपयोग करके, आप न केवल कुल अनुरोध आवृत्ति, बल्कि प्रत्येक सेवा के लिए अनुरोध आवृत्ति भी प्राप्त कर सकते हैं:

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

नमूने को नीचे गिराना - डेटा का सबसेट

Namespaces डेटा के विशिष्ट सबसेट को पुनः प्राप्त करने के लिए क्वेरी संकीर्णता का भी समर्थन करता है। उदाहरण के लिए, आइए प्रश्न पूछते हैं: "कैनरी परिनियोजन वाले सर्वरों के लिए सफल HTTP अनुरोधों में पी 99 विलंब (99% अनुरोधों को निर्दिष्ट देरी से अधिक तेज है)?"

पेड़ के ऊपर एक नेमस्पेस और वैकल्पिक मॉडल की अवधारणा है कि कैसे डिस्क पर मैट्रिक्स संग्रहीत किए जाते हैं। एक अच्छी तरह से परिभाषित मीट्रिक नेमस्पेस का उपयोग करने से आप किसी भी पैरामीटर में मैट्रिक्स का विस्तार कर सकते हैं।

नीचे दी गई तस्वीर ऊपर मैट्रिक्स के पेड़ से p99 और p50 का एक ग्राफ दिखाती है:

यदि आप अधिक विशिष्ट अनुरोध करते हैं, तो आप उदाहरण के लिए, निम्नलिखित प्रश्न का उत्तर दे सकते हैं: "प्रत्येक सर्वर के संदर्भ में कैनरी परिनियोजन वाले सर्वर के लिए सभी सफल HTTP अनुरोधों में देरी p99 क्या है?"

नीचे machine_id द्वारा चयन के साथ एक मीट्रिक का एक दृश्य है:

चूंकि मीट्रिक में एक अच्छी तरह से परिभाषित संरचना है, इसलिए हम आवश्यक चयन मानदंडों को निर्दिष्ट करके शीर्ष स्तर के मीट्रिक से आवश्यक डेटा का चयन कर सकते हैं - हमारे मामले में, machine_id।

विषम नियम

गुणांक डेटा (सहसंबंध) की संरचना करने का एक और तरीका है। यह एक बहुत ही शक्तिशाली तंत्र है और SLO की उपलब्धता और त्रुटि दर की गणना के लिए आधार है (ये संकेतक Google SRE विशेषज्ञों द्वारा लोकप्रिय थे)।

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

आइए इसे स्पष्ट करें और मान लें कि एक ऐसा आवेदन है जो अनुरोध को निष्पादित करता है, और अनुरोध दो राज्यों में से एक को जन्म दे सकता है: कैश से लिया गया डेटा (cache_hit: true) या मुख्य स्रोत से लिया गया डेटा (cache_hit: false)। कैश हिट अनुपात देखने के लिए, डेटा को इस प्रकार संरचित किया जाना चाहिए:

नीचे दिया गया ग्राफ हिट और मिस कैश की आवृत्ति को दर्शाता है। प्रत्येक अनुरोध या तो कैश में मिलता है या नहीं मिलता है। कुल में, प्रति सेकंड लगभग 160 अनुरोध होते हैं:

निम्न ग्राफ़ कुल अनुरोधों के सापेक्ष कैश हिट अनुपात दिखाता है। हिट गुणांक 0.5 (50%) है:

तो आप किसी भी दो मैट्रिक्स से संबंधित कर सकते हैं। डेटाडॉग और प्रोमेथियस में, यह संबंध एक साधारण अंकगणितीय ऑपरेशन द्वारा व्यक्त किया गया है।

डेटा द्वारा उत्तर दिए गए प्रश्न

उन सवालों के माध्यम से सोचना महत्वपूर्ण है जो डेटा को जवाब देना चाहिए। पहले उदाहरण में, डेटा नमूनाकरण वास्तव में इस सवाल का जवाब नहीं दे सकता है: "प्रति सेकंड कितने प्रश्न सभी उदाहरणों की प्रक्रिया करते हैं?", लेकिन नाम स्थान का पेड़ उत्तर प्राप्त करने में मदद करेगा।

एक और आम मामला क्लाइंट मेट्रिक्स के नामस्थान का है जिसमें सेवा का नाम है, न कि क्लाइंट लाइब्रेरी के नाम के साथ। नाम में क्लाइंट लाइब्रेरी का नाम जोड़ने से सवाल का जवाब मिल जाएगा: "सभी ग्राहकों से अनुरोधों की कुल संख्या?"।

सामान्य उपयोगी प्रश्न Google के चार सुनहरे संकेतों का उत्तर देते हैं । प्रत्येक प्रश्न को सामान्य तरीके से प्रस्तुत किया जाता है, और फिर इसे निर्दिष्ट किया जाता है:

सभी ग्राहक कुल कितने अनुरोध करते हैं?
प्रत्येक ग्राहक कितने अनुरोध करता है?
प्रत्येक ग्राहक प्रत्येक नोड के लिए कितने अनुरोध करता है?
प्रत्येक RPC के सफल सर्वर अनुरोधों का प्रतिशत क्या है?

एक ही रणनीति देरी, त्रुटि दर और संसाधन संतृप्ति पर लागू होती है।

जेनेरिक टैग मेट्रिक्स

यहां मैंने दत्ताडोग और प्रोमेथियस के लिए क्वेरी ऑप्टिमाइज़ेशन और डेटा स्टोरेज के लिए सर्वोत्तम प्रथाओं को पढ़ा है।

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

कार्डिनलिटी से सावधान रहें

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

, , , . , .

, 10. , , . .

, 100 , , .

, node_exporter. . , , node_filesystem_avail. 10 000 , 100 000 node_filesystem_avail, Prometheus.

यदि आप प्रति उपयोगकर्ता एफएस कोटा जोड़ते हैं, तो आप जल्दी से 10,000 उपयोगकर्ता प्रति 10,000 नोड्स से लाखों समय श्रृंखला तक पहुंच जाएंगे। यह प्रोमेथियस के वर्तमान कार्यान्वयन के लिए बहुत अधिक है। कम संख्या के साथ भी, अब आपके पास इस निगरानी में अन्य, संभावित रूप से अधिक उपयोगी, संकेतक नहीं होंगे।

बिना टैग के शुरू करें और आवश्यकतानुसार समय के साथ और टैग जोड़ें।

सुविधाजनक उपयोगकर्ता-स्तरीय निगरानी अक्सर वितरित अनुरेखण के माध्यम से बेहतर हासिल की जाती है । वितरित अनुरेखण का अपना मैट्रिक्स स्थान और सर्वोत्तम अभ्यास हैं।

निष्कर्ष

यह समझना महत्वपूर्ण है कि मेट्रिक्स को संरचित करके किन सवालों के जवाब दिए जा सकते हैं। एक गलत संरचना उत्तर प्राप्त करने में कठिनाइयों का कारण बनती है। यद्यपि मीट्रिक स्थान को संरचित करना जटिल नहीं है, इसके लिए डेटा का अधिकतम लाभ उठाने के लिए पूर्व नियोजन की आवश्यकता होती है।

जब समस्याएं उत्पन्न होती हैं, तो सभी राज्यों को देखने के लिए मीट्रिक को मैन्युअल रूप से विस्तारित करने की क्षमता महत्वपूर्ण है, और यह महत्वपूर्ण है कि नामस्थान इसमें हस्तक्षेप नहीं करता है।

सौभाग्य!

और क्या पढ़ें :

एसआरई अवलोकन: नाम स्थान और मीट्रिक संरचना