हाइब्रिड और मल्टीक्लाउड के लिए बेस्ट प्रैक्टिसेज़
परिचय
हम मल्टीक्लाउड को अपने स्वयं के वर्कलोड संचालित करने के लिए एक से अधिक क्लाउड सेवा प्रदाता के समवर्ती उपयोग के रूप में मानते हैं, और हाइब्रिड ऑन-प्रेमिस और क्लाउड दोनों एनवायरनमेंट में आपके वर्कलोड का विस्तार है। हाइब्रिड और मल्टीक्लाउड एनवायरनमेंट में ऑब्ज़र्वेबिलिटी टूल विविधता, लेटेंसी और विषम वर्कलोड के कारण महत्वपूर्ण जटिलता जोड़ सकती है। भले ही, यह विकास और व्यावसायिक उपयोगकर्ताओं दोनों के लिए एक सामान्य लक्ष्य बनी हुई है। उत्पादों और सेवाओं का एक समृद्ध इकोसिस्टम इसे संबोधित करता है।
हालांकि, क्लाउड-नेटिव वर्कलोड के लिए ऑब्ज़र्वेबिलिटी टूल्स की उपयोगिता नाटकीय रूप से भिन्न हो सकती है। एक कंटेनरीकृत बैच प्रोसेसिंग वर्कलोड की निगरानी की विभिन्न आवश्यकताओं पर विचार करें, सर्वरलेस फ्रेमवर्क का उपयोग करने वाले रीयल-टाइम बैंकिंग एप्लिकेशन की तुलना में।
इसमें मल्टीक्लाउड और हाइब्रिड की जटिलता जोड़ें, और आपके एप्लिकेशन्स से अंतर्दृष्टि प्राप्त करना काफी कठिन हो जाता है।
इन अतिरिक्त आयामों से निपटने और ऑब्ज़र्वेबिलिटी के लिए दृष्टिकोणों को सुविधाजनक बनाने के लिए, ग्राहक एकीकृत interface के साथ एक एक टूलचेन में निवेश करते हैं। आखिरकार, सिग्नल-टू-नॉइज़ अनुपात को कम करना आमतौर पर अच्छी बात है! हालांकि, एक एक दृष्टिकोण सभी उपयोग मामलों के लिए काम नहीं करता है। हमारा लक्ष्य आपको सूचित निर्णय लेने में मदद करना है जो आपकी आवश्यकताओं की प्रशंसा करते हैं और समस्याएं होने पर आपके mean time to remediation को कम करते हैं।
ये बेस्ट प्रैक्टिसेज़ भूमिकाओं के एक व्यापक सेट के लिए हैं: एंटरप्राइज़ आर्किटेक्ट, डेवलपर, DevOps, और अधिक। हम सुझाव देते हैं कि आप इनका मूल्यांकन अपने ऑर्गनाइज़ेशन की व्यावसायिक आवश्यकताओं के लेंस से करें, और यह कि वितरित एनवायरनमेंट में ऑब्ज़र्वेबिलिटी कैसे अधिक से अधिक मूल्य प्रदान कर सकती है।
अपने टूल्स को अपने निर्णय तय न करने दें
आपके एप्लिकेशन, टूल और प्रक्रियाएं व्यावसायिक परिणाम प्राप्त करने में मदद करने के लिए मौजूद हैं, जैसे बिक्री और ग्राहक संतुष्टि बढ़ाना। एक सुविज्ञ टेक्नोलॉजी नीति वह है जो आपको उन व्यावसायिक लक्ष्यों को प्राप्त करने में मदद करने के लिए सब कुछ संभव करती है। लेकिन जो चीज़ें आपको वहां पहुंचने में मदद करती हैं वे बस टूल हैं, और वे आपकी नीति का समर्थन करने के लिए हैं - नीति नहीं।
एक एक, सजातीय एनवायरनमेंट में, टूल के बारे में निर्णय आसान हैं। लेकिन हाइब्रिड और मल्टीक्लाउड एनवायरनमेंट के लिए चीज़ें कम स्पष्ट हैं, और अपने व्यावसायिक परिणामों पर नज़र रखना - और इन एनवायरनमेंट्स में अपने वर्कलोड को observe करने से जोड़ा गया मूल्य - महत्वपूर्ण है।
सिर्फ इसलिए कि आप कई एनवायरनमेंट्स में संचालित करते हैं इसका मतलब यह नहीं है कि हर वर्कलोड के लिए एक ही टूल सलाह योग्य या अनुशंसित है। टूल लागू करते समय, "टू-वे डोर्स" बनाना याद रखें ताकि आप भविष्य में अपने ऑब्ज़र्वेबिलिटी समाधान को विकसित कर सकें।
यहां बचने के लिए "tool-first" परिणामों के कुछ उदाहरण हैं:
- भविष्य में इसे अपग्रेड करने या नए समाधान पर जाने क े लिए टू-वे डोर्स के बिना एक ही टूल के कार्यान्वयन पर ध्यान केंद्रित करना तकनीकी ऋण बना सकता है।
- वॉल्यूम डिस्काउंट के कारण एक ही टूल का उपयोग करने का कंपनी मानक उन सुविधाओं के बिना हो सकता है जिनसे उन्हें लाभ होगा।
- मौजूदा ट्रेस संग्रह इंफ्रास्ट्रक्चर की कमी के कारण पूरे प्रकार की टेलीमेट्री (आमतौर पर ट्रेसेस) एकत्र नहीं करना एक अपूर्ण ऑब्ज़र्वेबिलिटी समाधान बना सकता है।
- श्रम और प्रशिक्षण लागत कम करने की इच्छा में सपोर्ट स्टाफ को केवल एक ही टूलचेन पर प्रशिक्षित किया जाना।
यदि आपके टूल आपकी ऑब्ज़र्वेबिलिटी नीति तय कर रहे हैं, तो आपको दृष्टिकोण को उलटने की आवश्यकता है। टूल ऑब्ज़र्वेबिलिटी को सक्षम और सशक्त बनाने के लिए हैं, आपकी पसंद को सीमित करने के लिए नहीं।
टूल स्प्रॉल एक बहुत वास्तविक समस्या है जिससे कंपनियां जूझती हैं, हालांकि एक एक टूलचेन में कट्टर बदलाव भी आपके ऑब्ज़र्वेबिलिटी समाधान की उपयोगिता को कम कर सकता है। हाइब्रिड और मल्टीक्लाउड वर्कलोड में ऐसी टेक्नोलॉजीज़ हैं जो प्रत्येक प्लेटफ़ॉर्म के लिए अद्वितीय हैं। "OpenTelemetry में निवेश करें" एक दृष्टिकोण के लिए देखें जो इनमें से कुछ जोखिमों को कम करता है।
(ऑब्ज़र्वेबिलिटी) डेटा में गुरुत्व है
सभी डेटा में गुरुत्व होता है - जिसका अर्थ है कि यह वर्कलोड, समाधान, टूल, लोगों, प्रक्रियाओं और प्रोजेक्ट को अपनी ओर आकर्षित करता है। यह इस बात पर सीधा प्रभाव डालता है कि आप अपने वर्कलोड कहां रखते हैं, किस एनवायरनमेंट में, और आप उन्हें आगे कैसे संचालित करते हैं।
ऑब्ज़र्वेबिलिटी डेटा का समय के साथ मूल्य अधिकांश अन्य डेटा प्रकारों से काफी कम है। आप इसे ऑब्ज़र्वेबिलिटी डेटा का "अर्ध-जीवन" कह सकते हैं। टेलीमेट्री को दूसरे एनवायरनमेंट में रिले करने में अतिरिक्त लेटेंसी पर विचार करें।
बेस्ट प्रैक्टिस यह है कि एनवायरनमेंट्स के बीच डेटा केवल तभी उत्सर्जित करें जब इस एग्रीगेशन से व्यावसायिक मूल्य प्राप्त हो।
एक सिंगल पेन ऑफ़ ग्लास आपके वर्कलोड के संदर्भ से कम महत्वपूर्ण है
एक सामान्य अनुरोध आपके सभी वर्कलोड को observe करने के लिए "सिंगल पेन ऑफ़ ग्लास" का है। यह जितना संभव हो उतना डेटा देखने की स्वाभाविक इच्छा से उत्पन्न होता है, लेकिन जितना सरल हो सके।
उदाहरण के लिए, सौ सर्वरों के CPU उपयोग वाला एक डैशबोर्ड खपत में कुछ असामान्य स्पाइक दिखा सकता है, लेकिन यह यह समझाने के लिए कुछ नहीं करता कि ऐसा क्यों हुआ।
ऑब्ज़र्वेबिलिटी डेटा का मूल्य उस एप्लिकेशन में गहराई से एकीकृत है जिससे यह आया है। आपकी टेलीमेट्री को संदर्भगत जागरूकता की आवश्यकता है जो इसके एनवायरनमेंट से आती है।
वितरित प्रणाली के लिए सिंगल पेन ऑफ़ ग्लास बनाते समय, अन्य डेटा (जैसे इंफ्रास्ट्रक्चर मेट्रिक्स) के समान दृश्य में अपने व्यावसायिक मेट्रिक्स और Service Level Objectives (SLOs) प्रदर्शित करें।
एक सिंगल पेन ऑफ़ ग्लास समस्याओं का तेजी से निदान करने और Time to Detection (MTTD) और Mean Time to Resolution (MTTR) को कम करने में मदद कर सकता है, लेकिन केवल तभी जब टेलीमेट्री डेटा का अर्थ संरक्षित किया जा सके।
यदि सिंगल पेन ऑफ़ ग्लास का मूल्य निर्धारित नहीं किया जा सकता, तो केवल शीर्ष-स्तरीय व्यावसायिक मेट्रिक्स को सिंगल पेन ऑफ़ ग्लास तक रोल-अप करने पर विचार करें, कच्चे मेट्रिक्स और अन्य योगदान कारकों को उनके मूल एनवायरनमेंट में छोड़ दें।
OpenTelemetry में निवेश करें
ऑब्ज़र्वेबिलिटी विक्रेता परिदृश्य में, OpenTelemetry (OTel) डी-फ़ैक्टो मानक बन गया है। OTel आपके प्रत्येक टेलीमेट्री प्रकार को एक या कई कलेक्टर्स में marshal कर सकता है, जिसमें क् लाउड-नेटिव सेवाएं, या SaaS और ISV उत्पादों की एक विस्तृत विविधता शामिल हो सकती है।
सबसे अधिक मूल्य के साथ transaction traces एकत्र करने के लिए, आपको अपने एप्लिकेशन में trace संग्रह को एकीकृत करने की आवश्यकता होगी। कुछ ऑटो-इंस्ट्रुमेंटेशन agents लगभग बिना प्रयास के यह कर सकते हैं।
OTel एक span की अवधारणा का उपयोग करके लॉग्स, मेट्रिक्स और ट्रेसेस कैप्चर करता है। Spans में एक ही transaction से इन सिग्नल को एक साथ समूहीकृत किया जाता है, उन्हें एक संदर्भगत, खोजने योग्य ऑब्जेक्ट में पैकेज किया जाता है।
OTel एप्लिकेशन ट्रेसेस तक सीमित नहीं है, और लॉग्स और मेट्रिक्स के लिए व्यापक रूप से उपयोग किया जाता है। और कई ISV उत्पाद आज सीधे OTLP स्वीकार करते हैं।
OTel का उपयोग करके अपने एप्लिकेशन्स को इंस्ट्रूमेंट करके, आप भविष्य में एप्लिकेशन परत पर इस इंस्ट्रूमेंटेशन को बदलने की आवश्यकता को हटा देते हैं, क्या आपको एक ऑब्ज़र्वेबिलिटी प्लेटफ़ॉर्म से दूसरे में जाने का चुनाव करना चाहिए। यह आपके ऑब्ज़र्वेबिलिटी समाधान के हिस्से को टू-वे डोर्स में बदल देता है।
OTel भविष्य-प्रूफिंग, स्केलेबल है, और एप्लिकेशन कोड बदले बिना भविष्य में अपने संग्रह और एनालिसिस प्रणालियों को बदलना आसान बनाता है, जो इसे एक कुशल शिफ़्ट टू द लेफ़्ट बनाता है।