डैशबोर्ड
डैशबोर्ड आपके ऑब्ज़र्वेबिलिटी समाधान का एक महत्वपूर्ण हिस्सा हैं। वे आपको अपने डेटा का एक क्यूरेटेड विज़ुअलाइज़ेशन बनाने में सक्षम बनाते हैं। वे आपको अपने डेटा का इतिहास देखने और इसे अन्य संबंधित डेटा के साथ देखने में मदद करते हैं। वे आपको संदर्भ प्रदान करने की भी अनुमति देते हैं। वे आपको बड़ी तस्वीर समझने में मद द करते हैं।
अक्सर लोग अपना डेटा एकत्र करते हैं और अलार्म बनाते हैं, और फिर रुक जाते हैं। हालांकि, अलार्म केवल एक समय बिंदु दिखाते हैं, और आमतौर पर एक मेट्रिक या डेटा के छोटे सेट के लिए। डैशबोर्ड आपको समय के साथ व्यवहार देखने में मदद करते हैं।

एक व्यावहारिक उदाहरण: उच्च CPU के लिए अलार्म पर विचार करें
आप जानते हैं कि मशीन वांछित से अधिक CPU के साथ चल रही है। क्या आपको कार्रवाई करनी होगी, और कितनी जल्दी? क्या आपको निर्णय लेने में मदद कर सकता है?
- इस इंस्टेंस/एप्लिकेशन के लिए सामान्य CPU कैसा दिखता है?
- क्या यह एक स्पाइक है, या बढ़ते CPU का एक ट्रेंड?
- क्या यह प्रदर्शन को प्रभावित कर रहा है? यदि नहीं, तो कब तक यह प्रभावित करेगा?
- क्या यह एक नियमित घटना है? और क्या यह आमतौर पर अपने आप ठीक हो जाता है?
डेटा का इतिहास देखें
अब CPU के ऐतिहासिक टाइमचार्ट वाले डैशबोर्ड पर विचार करें। केवल इस एक मेट्रिक के साथ भी, आप देख सकते हैं कि यह एक स्पाइक है या ऊपर की ओर ट्रेंड। आप यह भी देख सकते हैं कि यह कितनी तेज़ी से ऊपर की ओर जा रहा है, और इसलिए कार्रवाई की प्राथमिकता पर कुछ निर्णय ले सकते हैं।
वर ्कफ़्लो पर प्रभाव देखें
लेकिन यह मशीन क्या करती है? हमारे समग्र संदर्भ में यह कितनी महत्वपूर्ण है? कल्पना करें कि हम अब वर्कफ़्लो प्रदर्शन का विज़ुअलाइज़ेशन जोड़ते हैं, चाहे वह रिस्पॉन्स टाइम हो, थ्रूपुट हो, एरर हों, या कोई अन्य माप। अब हम देख सकते हैं कि उच्च CPU इस इंस्टेंस द्वारा समर्थित वर्कफ़्लो या उपयोगकर्ताओं पर प्रभाव डाल रहा है या नहीं।
अलार्म का इतिहास देखें
एक ऐसा विज़ुअलाइज़ेशन जोड़ने पर विचार करें जो दिखाता है कि पिछले महीने में अलार्म कितनी बार ट्रिगर हुआ, और यह देखने के लि ए और पीछे जाएं कि क्या यह एक नियमित घटना है। उदाहरण के लिए, क्या कोई बैकअप जॉब स्पाइक को ट्रिगर कर रहा है? पुनरावृत्ति का पैटर्न जानने से आपको अंतर्निहित समस्या को समझने और अलार्म को पूरी तरह से रोकने के लिए दीर्घकालिक निर्णय लेने में मदद मिल सकती है।
संदर्भ जोड़ें
अंत में, डैशबोर्ड में कुछ संदर्भ जोड़ें। इस डैशबोर्ड के अस्तित्व का कारण, यह किस वर्कफ़्लो से संबंधित है, समस्या होने पर क्या करना है, दस्तावेज़ीकरण के लिंक, और किससे संपर्क करना है, इसका संक्षिप्त विवरण शामिल करें।
अब हमारे पास एक कहानी है, जो डैशबोर्ड उपयोगकर्ता को यह देखने में मदद करती है कि क्या हो रहा है, प्रभाव को समझने और उचित डेटा-संचालित निर्णय लेने में मदद करती है कि क्या कार्रवाई करनी है और इसकी तत्कालता क्या है।
एक साथ सब कुछ विज़ुअलाइज़ करने की कोशिश न करें
हम अक्सर अलार्म थकान के बारे में बात करते हैं। पहचान योग्य कार्रवाइयों और प्राथमिकताओं के बिना बहुत अधिक अलार्म, आपकी टीम को ओवरलोड कर सकते हैं और अक्षमताओं को जन्म दे सकते हैं। अलार्म उन चीज़ों के लिए होने चाहिए जो आपके लिए महत्वपूर्ण हैं और कार्रवाई योग् य हैं।
डैशबोर्ड यहां अधिक लचीले हैं। वे उसी तरह से आपके ध्यान की मांग नहीं करते, इसलिए आपके पास उन चीज़ों को विज़ुअलाइज़ करने की अधिक स्वतंत्रता है जो शायद आपको अभी तक निश्चित नहीं हैं कि महत्वपूर्ण हैं, या जो आपकी खोज का समर्थन करती हैं। फिर भी, इसे ज़्यादा न करें! हर चीज़ अच्छी चीज़ की अधिकता से प्रभावित हो सकती है।
डैशबोर्ड को किसी ऐसी चीज़ की तस्वीर प्रदान करनी चाहिए जो आपके लिए महत्वपूर्ण है। उसी तरह जैसे यह तय करना कि कौन सा डेटा इन्जेस्ट करना है, आपको डैशबोर्ड के लिए सोचना होगा कि आपके लिए क्या मायने रखता है। अपने डैशबोर्ड के लिए, इसके बारे में सोचें
- इसे कौन देखेगा?
- उनकी पृष्ठभूमि और ज्ञान क्या है?
- उन्हें कितने संदर्भ की आवश्यकता है?
- वे किन प्रश्नों का उत्तर देने की कोशिश कर रहे हैं?
- इस डेटा को देखने के परिणामस्वरूप वे क्या कार्रवाई करेंगे?
कभी-कभी यह जानना मुश्किल हो सकता है कि आपके डैशबोर्ड की कहानी क्या होनी चाहिए, और कितना शामिल करना है। तो आप अपना डैशबोर्ड डिज़ाइन करना कहाँ से शुरू कर सकते हैं? आइए दो तरीके देखें: KPI संचालित, या इंसिडेंट संचालित।
अपना डैशबोर्ड डिज़ाइन करें: KPI संचालित
इसे समझने का एक तरीका अपने KPI से पीछे की ओर काम करना है। यह आमतौर पर एक बहुत ही उपयोगकर्ता-संचालित दृष्टिकोण है। लेआउट के लिए, आमतौर पर हम ऊपर से नीचे की ओर काम कर रहे हैं, जैसे-जैसे हम डैशबोर्ड में नीचे जाते हैं या निचले स्तर के डैशबोर्ड पर नेविगेट करते हैं, अधिक विवरण प्राप्त होता है।
सबसे पहले, अपने KPI समझें। उनका क्या मतलब है। इससे आपको यह तय करने में मदद मिलेगी कि आप इन्हें कैसे विज़ुअलाइज़ करना चाहते हैं। कई KPI एक एक संख्या के रूप में दिखाए जाते हैं। उदाहरण के लिए, कितने प्रतिशत ग्राहक एक विशिष्ट वर्कफ़्लो को सफलतापूर्वक पूरा कर रहे हैं, और कितने समय में? लेकिन किस समय अवधि में? यदि आप एक सप्ताह में औसत करें तो आप अपने KPI को पूरा कर सकते हैं, लेकिन फिर भी इसके भीतर छोटी अवधि हो सकती है जो आपके मानकों का उल्लंघन करती है। क्या ये उल्लंघन आपके लिए महत्वपूर्ण हैं? क्या वे आपके ग्राहक अनुभव को प्रभावित करते हैं। यदि हां, तो आप अपने KPI देखने के लिए विभिन्न अवधियों और टाइम चार्ट पर विचार कर सकते हैं। और शायद हर किसी को विवरण देखने की आवश्यकता नहीं है, इसलिए शायद आप KPI के विभाजन को एक अलग दर्शकों के लिए एक अलग डैशबोर्ड पर ले जाएं।
इसके बाद, उन KPI में क्या योगदान देता है? उन कार्यों को करने के लिए कौन से वर्कफ़्लो चलने चाहिए? क्या आप इन्हें माप सकते हैं?
मुख्य घटकों की पहचान करें और उनके प्रदर्शन के विज़ुअलाइज़ेशन जोड़ें। जब कोई KPI उल्लंघन करता है, तो आपको तुरंत देखने में सक्षम होना चाहिए कि वर्कफ़्लो में मुख्य प्रभाव कहाँ है।
और आप नीचे जाते रह सकते हैं - उन वर्कफ़्लो के प्रदर्शन को क्या प्रभावित करता है? गहराई के स्तर का निर्णय लेते समय अपने दर्शकों को याद रखें।
एक ई-कॉमर्स सिस्टम के उदाहरण पर विचार करें जिसमें ऑर्डर की संख्या के लिए KPI है। ऑर्डर देने के लिए, उपयोगकर्ताओं को निम्नलिखित क्रियाएं करने में सक्षम होना चाहिए: उत्पादों की खोज करना, उन्हें अपनी कार्ट में जोड़ना, अपने डिलीवरी विवरण जोड़ना, और ऑर्डर के लिए भुगतान करना। इनमें से प्रत्येक वर्कफ़्लो के लिए, आप प्रमुख घटकों की जांच करने पर विचार कर सकते हैं। उदाहरण के लिए RUM या Synthetics का उपयोग करके एक्शन सक्सेस पर डेटा प्राप्त करना और यह देखना कि क्या उपयोगकर्ता किसी समस्या से प्रभावित हो रहा है। आप थ्रूपुट, लेटेंसी, विफल एक्शन प्रतिशत के माप पर विचार कर सकते हैं ताकि देख सकें कि प्रत्येक एक्शन का प्रदर्शन अपेक्षित है या नहीं। आप अंतर्निहित इन्फ्रास्ट्रक्चर के माप पर विचार कर सकते हैं यह देखने के लिए कि प्रदर्शन को क्या प्रभावित कर रहा है।
हालांकि, अपनी सभी जानकारी एक ही डैशबोर्ड पर न रखें। फिर से, अपने उपयोगकर्ता दर्शकों पर विचार करें।
डैशबोर्ड की परतें बनाएं जो ड्रिलडाउन की अनुमति दें और सही उपयोगकर्ताओं के लिए सही संदर्भ प्रदान करें।
अपना डैशबोर्ड डिज़ाइन करें: इंसिडेंट संचालित
कई लोगों के लिए, इंसिडेंट रिज़ॉल्यूशन ऑब्ज़र्वेबिलिटी के लिए एक प्रमुख चालक है। आपको किसी उपयोगकर्ता द्वारा, या ऑब्ज़र्वेबिलिटी अलार्म द्वारा किसी समस्या के बारे में सूचित किया गया है, और आपको जल्दी से एक समाधान और संभावित रूप से समस्या का मूल कारण खोजने की आवश्यकता है।
अपनी हाल की इंसिडेंट्स को देखकर शुरू करें। क्या सामान्य पैटर्न हैं? आपकी कंपनी के लिए कौन सी सबसे प्रभावशाली थीं? कौन सी दोहराई जाती हैं?
इस मामले में, हम उन लोगों के लिए डैशबोर्ड डिज़ाइन कर रहे हैं जो गंभीरता को समझने, मूल कारण की पहचान करने और इंसिडेंट को ठीक करने की कोशिश कर रहे हैं।
विशिष्ट इंसिडेंट के बारे में सोचें।
- आपने कैसे सत्यापित किया कि इंसिडेंट रिपोर्ट के अनुसार थी?
- आपने क्या जांचा? एंडपॉइंट? एरर?
- आपने प्रभाव, और इसलिए समस्या की प्राथमिकता कैसे समझी?
- आपने समस्या के कारण के लिए क्या देखा?
Application Performance Monitoring (APM) यहां मदद कर सकता है, एंडपॉइंट और वर्कफ़्लो की नियमित बेसलाइन और टेस्टिंग के लिए Synthetics के साथ, और वास्तविक ग्राहक अनुभव के लिए RUM के साथ। आप इस डेटा का उपयोग जल्दी से विज़ुअलाइज़ करने के लिए कर सकते हैं कि कौन से वर्कफ़्लो प्रभावित हैं, और कितने।
विज़ुअलाइज़ेशन जो समय के साथ एरर काउंट और टॉप # एरर दिखाते हैं, आपको सही क्षेत्र पर ध्यान केंद्रित करने में मदद कर सकते हैं, और आपको एरर के विशिष्ट विवरण दिखा सकते हैं। यहीं पर हम अक्सर लॉग डेटा और एरर कोड और कारणों के डायनामिक विज़ुअलाइज़ेशन का उपयोग कर रहे हैं।
यहां किसी प्रकार की फ़िल्टरिंग या ड्रिलडाउन होना बहुत उपयोगी हो सकता है, ताकि जल्द से जल्द विशि ष्टताओं तक पहुंचा जा सके। बिना अधिक ओवरहेड के इसे लागू करने के तरीकों के बारे में सोचें। उदाहरण के लिए, एक एक डैशबोर्ड होना जिसे आप विवरण के करीब जाने के लिए फ़िल्टर कर सकते हैं।
Layout
आपके डैशबोर्ड का लेआउट भी महत्वपूर्ण है।
आमतौर पर आपके उपयोगकर्ता के लिए सबसे महत्वपूर्ण विज़ुअलाइज़ेशन ऊपर बाईं ओर होने चाहिए, या अन्यथा पेज नेविगेशन की प्राकृतिक शुरुआत के अनुरूप होने चाहिए।
आप कहानी बताने में मदद के लिए लेआउट का उपयोग कर सकते हैं। उदाहरण के लिए, आप टॉप-डाउन लेआउट का उपयोग कर सकते हैं, जहां आप जितना नीचे स्क ्रॉल करेंगे, उतने अधिक विवरण दिखाई देंगे। या शायद एक लेफ्ट-राइट डिस्प्ले उपयोगी होगा जिसमें उच्च स्तर की सेवाएं बाईं ओर हों, और उनकी डिपेंडेंसी दाईं ओर जाने पर दिखें।
डायनामिक कंटेंट बनाएं
आपके कई वर्कलोड मांग के अनुसार बढ़ने या सिकुड़ने के लिए डिज़ाइन किए जाएंगे, और आपके डैशबोर्ड को इसे ध्यान में रखना होगा। उदाहरण के लिए, आपके इंस्टेंस एक ऑटोस्केलिंग ग्रुप में हो सकते हैं, और जब आप एक निश्चित लोड तक पहुंचते हैं, तो अतिरिक्त इंस्टेंस जोड़े जाते हैं।
एक डैशबोर्ड जो विशिष्ट इंस्टेंस का डेटा दिखाता है, किसी प्रकार की ID द्वारा निर्दिष्ट, उन नए इंस्टेंस से डेटा देखने की अनुमति नहीं देगा। अपने रिसोर्स और डेटा में मेटाडेटा जोड़ें, ताकि आप एक विशिष्ट मेटाडेटा मान वाले सभी इंस्टेंस को कैप्चर करने के लिए अपने विज़ुअलाइज़ेशन बना सकें। इस तरह वे वास्तविक स्थिति को दर्शाएंगे।
डायनामिक विज़ुअलाइज़ेशन का एक और उदाहरण अभी होने वाली शीर्ष 10 एरर खोजने में सक्षम होना हो सकता है, और हाल के इतिहास में उन्होंने कैसा व्यवहार किया है। आप एक टेबल या चार्ट देखने में सक्षम होना चाहते हैं, बिना यह जाने कि कौन सी एरर हो सकती हैं।
पहले लक्षणों के बारे में सोचें, कारणों से पहले
जब आप लक्षणों का अवलोकन करते हैं, तो आप इस बात पर विचार कर रहे हैं कि इसका आपके उपयोगकर्ताओं और सिस्टम पर क्या प्रभाव पड़ता है। कई अंतर्निहित कारण समान लक्षण दे सकते हैं। यह आपको अज्ञात समस्याओं सहित अधिक समस्याओं को पकड़ने में सक्षम बनाता है। जैसे-जैसे आप कारणों को समझते हैं, आपके निचले स्तर के डैशबोर्ड इन्हें तेज़ी से निदान करने और समस्याओं को ठीक करने में मदद करने के लिए अधिक विशिष्ट हो सकते हैं।
पिछले सप्ताह उपयोगकर्ताओं को प्रभावित करने वाली विशिष्ट JavaScript एरर को कैप्चर न करें। इसके बजाय उस वर्कफ़्लो पर प्रभाव को कैप्चर करें जिसे इसने बाधित किया, और फिर हाल के इतिहास में JavaScript एरर की शीर्ष गिनती दिखाएं, या जो हाल के इतिहास में नाटकीय रूप से बढ़ी हैं।
Top/Bottom N का उपयोग करें
अधिकांश समय आपके सभी ऑपरेशनल मेट्रिक्स को एक ही समय पर विज़ुअलाइज़ करने की कोई आवश्यकता नहीं है। EC2 इंस्टेंस का एक बड़ा फ्लीट इसका एक अच्छा उदाहरण है: सैकड़ों सर्वरों के पूरे फार्म की डिस्क IOPS या CPU उपयोगिता को एक साथ प्रदर्शित करने की कोई आवश्यकता या मूल्य नहीं है। यह एक एंटी-पैटर्न बनाता है जहां आप सबसे अच्छे (या सबसे खराब) प्रदर्शन करने वाले रिसोर्स देखने की बजाय अपने मेट्रिक्स खोजने में अधिक समय बिता सकते हैं।
अपने डैशबोर्ड का उपयोग किसी भी दिए गए मेट्रिक के दस या 20 दिखाने के लिए करें, और फिर इससे सामने आने वाले लक्षणों पर ध्यान केंद्रित करें।
CloudWatch metrics आपको किसी भी टाइम सीरीज़ के लिए शीर्ष N खोजने की अनुमति देता है। उदाहरण के लिए, यह क्वेरी CPU उपयोगिता के आधार पर सबसे व्यस्त 20 EC2 इंस्टेंस लौटाएगी:
SORT(SEARCH('{AWS/EC2,InstanceId} MetricName="CPUUtilization"', 'Average', 300), SUM, DESC, 10)
इस दृष्टिकोण का उपयोग करें, या CloudWatch Metric Insights के साथ समान, अपने डैशबोर्ड में शीर्ष या निचले प्रदर्शन करने वाले मेट्रिक्स की पहचान करने के लिए।
थ्रेशोल्ड के साथ KPI को विज़ुअली दिखाएं
आपके KPI में एक चेतावनी या एरर थ्रेशोल्ड होना चाहिए, और डैशबोर्ड इस े एक क्षैतिज एनोटेशन का उपयोग करके दिखा सकते हैं। यह एक विजेट पर हाई वॉटर मार्क के रूप में दिखाई देगा। इसे विज़ुअली दिखाना मानव ऑपरेटरों को पूर्व चेतावनी दे सकता है यदि व्यावसायिक परिणाम या इन्फ्रास्ट्रक्चर खतरे में है।

क्षैतिज एनोटेशन एक अच्छी तरह से विकसित डैशबोर्ड का एक महत्वपूर्ण हिस्सा हैं।
संदर्भ का महत्व
लोग आसानी से डेटा की गलत व्याख्या कर सकते हैं। उनकी पृष्ठभूमि और वर्तमान संदर्भ इस बात को प्रभावित करेगा कि वे डेटा को कैसे देखते हैं।
इसलिए सुनिश्चित करें कि आप अपने डैशबोर्ड में टेक्स्ट शामिल करें। यह डेटा किसके लिए है, और किसके लिए? इसका क्या मतलब है? एप्लिकेशन पर दस्तावेज़ीकरण, इसे कौन सपोर्ट करता है, ट्रबलशूटिंग डॉक्स के लिंक। आप अपने डैशबोर्ड डिस्प्ले को विभाजित करने के लिए टेक्स्ट डिस्प्ले का भी उपयोग कर सकते हैं। लेफ्ट-राइट संदर्भ सेट करने के लिए उन्हें बाईं ओर उपयोग करें। अपने डैशबोर्ड को लंबवत रूप से विभाजित करने के लिए उन्हें पूर्ण क्षैतिज डिस्प्ले के रूप में उपयोग करें।
IT सपोर्ट, ऑपरेशंस ऑन-कॉल, या बिज़नेस ओनर्स के लि ंक होने से टीमों को समस्या होने पर मदद कर सकने वाले लोगों से संपर्क करने का तेज़ रास्ता मिल सकता है।
टिकटिंग सिस्टम के हाइपरलिंक भी डैशबोर्ड के लिए एक बहुत उपयोगी अतिरिक्त हैं।