इस श्रृंखला के पिछले लेख में - DevSecOps में डेटा संग्रह के लिए सब कुछ गाइड - हमने डेटा संग्रह के महत्व पर चर्चा की। इस लेख में, हम पर्यवेक्षण में निगरानी की भूमिका का पता लगाएंगे, विशेष रूप से यह सुरक्षा, प्रदर्शन और विश्वसनीयता से संबंधित है।
मुद्दों और आउटलेयर का पता लगाने के लिए निगरानी आवश्यक है क्योंकि वे उत्पादन में होते हैं और DevSecOps टीमों को गंभीर नुकसान होने से पहले मुद्दों की पहचान करने और उनका पता लगाने की अनुमति देते हैं। प्रदर्शन में गिरावट या संदिग्ध गतिविधि की निगरानी के परिणामस्वरूप संभावित समस्याओं या हमलों को अलग करने के लिए अलर्ट और स्वचालित प्रतिक्रिया हो सकती है।
इस लेख में, हम निगरानी को विस्तार से देखेंगे, कई उपयोग के मामले और सर्वोत्तम अभ्यास प्रदान करेंगे, और चर्चा करेंगे कि कैसे निगरानी विशेष रूप से निगरानी के माध्यम से सुरक्षा, प्रदर्शन और विश्वसनीयता में सुधार कर सकती है।
अवलोकन योग्य प्रणाली में, हम लॉग, मेट्रिक्स और वितरित ट्रेस से डेटा एकत्र करते हैं। और जबकि बहुत छोटी प्रणालियों के लिए आप मैन्युअल रूप से लॉग ब्राउज़ और खोज सकते हैं, मेट्रिक्स को चार्ट के रूप में देख सकते हैं, और आरेखों के माध्यम से पता लगा सकते हैं कि समस्याओं की पहचान करने के लिए सिस्टम के माध्यम से ट्रैफ़िक कैसे बहता है - पैमाने पर, यह पर्याप्त नहीं है। आपको निगरानी की आवश्यकता है, एक स्वचालित प्रक्रिया जो इस डेटा पर नज़र रखती है और आपको उचित रूप से सचेत करती है। (निगरानी और प्रेक्षणीयता के बीच अंतर पर अधिक विस्तृत उपचार के लिए, आपइस संसाधन को देख सकते हैं।)
एक उद्यम में, आपको इस सभी डेटा को फ़िल्टर करने, एकत्रित करने, समृद्ध करने और विश्लेषण करने के लिए स्वचालित तरीकों की आवश्यकता होती है। कुछ असामान्य पाए जाने पर उद्यमों को कार्रवाई करने के लिए स्वचालित तरीकों की भी आवश्यकता होती है। स्वचालित प्रतिक्रिया जिम्मेदार टीम को सूचित कर सकती है या सीधे उपचारात्मक कार्रवाई भी कर सकती है।
चिकित्सा जैसे अन्य क्षेत्रों में, रोगियों के महत्वपूर्ण संकेतों की निगरानी करना एक महत्वपूर्ण गतिविधि है, जो जीवन को बचाती है। सॉफ्टवेयर सिस्टम की निगरानी करना बहुत समान है, और हम स्वास्थ्य जांच करते समय और विभिन्न घटकों के स्वास्थ्य पर चर्चा करते समय भी उसी पद्धति का उपयोग करते हैं।
बहुत हो गया सिद्धांत, आइए निगरानी के कुछ ठोस उदाहरण देखें।
यहां कुछ विशिष्ट उपयोग मामले हैं जो निगरानी का लाभ उठाते हैं:
4xx
या 5xx
) की अत्यधिक उपस्थिति के लिए कुबेरनेट्स कंटेनरीकृत अनुप्रयोगों या बस वेब सर्वर लॉग की निगरानी करना टीम के प्रदर्शन और विश्वसनीयता के मुद्दों को महत्वपूर्ण समस्या बनने से पहले हल करने में मदद कर सकता है।
ध्यान दें कि मॉनिटरिंग एक साधारण स्थिति सेट करने की तुलना में बहुत अधिक शामिल है (जैसे "दो मिनट के भीतर orders
डेटाबेस में पांच से अधिक INSERT
क्वेरीज़") और उस स्थिति के पूरा होने पर अलर्ट को सक्रिय करना। उपयोग के पैटर्न के साथ सीज़नलिटी खेल में हो सकती है जो दिन, सप्ताह या वर्ष के निश्चित समय पर स्पाइक्स का कारण बनती है। अप्रत्याशित व्यवहार का पता लगाने वाली प्रभावी निगरानी संदर्भ को ध्यान में रखती है और पिछले डेटा के आधार पर रुझानों को पहचान सकती है।
इस प्रकार की निगरानी, विशेष रूप से जब एक उपकरण के साथ कार्यान्वित की जाती है जो बड़े पैमाने पर निगरानी, निगरानी और सुरक्षा को जोड़ती है, तो यह बहुत प्रभावी हो सकता है, जैसे कि सूमो लॉजिक और इन्फोर से इस मामले का अध्ययन , जहां इंफोर 5,000 घंटे खर्च किए गए समय को बचाने में सक्षम था घटनाओं।
मॉनिटरिंग खराब होने से बचने के लिए समस्याओं का जल्द पता लगाकर सिस्टम के प्रदर्शन और विश्वसनीयता में सुधार करता है। प्रदर्शन समस्याएं अक्सर उपलब्धता और विश्वसनीयता की समस्याएं बन जाती हैं। टाइमआउट की उपस्थिति में यह विशेष रूप से सच है। उदाहरण के लिए, मान लें कि 60 सेकंड के बाद कोई एप्लिकेशन टाइम आउट हो जाता है। हाल के प्रदर्शन के मुद्दे के कारण, कई अनुरोधों को संसाधित होने में अचानक 60 सेकंड से अधिक समय लगता है। ये सभी अनुरोध अब विफल हो जाएंगे, और आवेदन अब अविश्वसनीय है।
इसे संबोधित करने के लिए एक सामान्य सर्वोत्तम अभ्यास उच्च-प्राथमिकता वाली सेवाओं और अनुप्रयोगों के महत्वपूर्ण पथ में किसी भी घटक के चार सुनहरे संकेतों की निगरानी करना है: विलंबता, ट्रैफ़िक, त्रुटियाँ और संतृप्ति।
अनुरोध को संसाधित करने में कितना समय लगता है? ध्यान दें कि सफल अनुरोधों की विलंबता विफल अनुरोधों से भिन्न हो सकती है। विलंबता में कोई महत्वपूर्ण वृद्धि अपमानजनक प्रणाली के प्रदर्शन का संकेत दे सकती है। दूसरी ओर, कोई महत्वपूर्ण कमी इस बात का संकेत हो सकती है कि कुछ प्रसंस्करण छोड़ दिया गया है। किसी भी तरह से, निगरानी संभावित मुद्दे पर ध्यान देगी।
ट्रैफ़िक की निगरानी करने से आपको प्रत्येक घटक पर कुल भार की समझ मिलती है। ट्रैफ़िक को विभिन्न घटकों के लिए अलग-अलग तरीकों से मापा जा सकता है। उदाहरण के लिए:
ट्रैफ़िक में वृद्धि जैविक व्यवसाय वृद्धि के कारण हो सकती है, जो एक अच्छी बात है। हालाँकि, यह अपस्ट्रीम सिस्टम में एक समस्या की ओर भी इशारा कर सकता है जो पहले की तुलना में असामान्य रूप से अधिक ट्रैफ़िक उत्पन्न करता है।
किसी भी घटक की त्रुटि दर में वृद्धि सीधे सिस्टम की विश्वसनीयता और उपयोगिता को प्रभावित करती है। इसके अलावा, यदि असफल विकल्प स्वचालित रूप से समाप्त हो जाते हैं, तो इससे ट्रैफ़िक में वृद्धि हो सकती है, और इसके परिणामस्वरूप प्रदर्शन संबंधी समस्याएं हो सकती हैं।
उपलब्ध संसाधनों में से, सेवा या एप्लिकेशन कितना उपयोग कर रहा है? यह संतृप्ति निगरानी आपको बताती है। उदाहरण के लिए, यदि एक डिस्क भरी हुई है, तो उस डिस्क पर लॉग लिखने वाली सेवा बाद के प्रत्येक अनुरोध पर विफल हो जाएगी। उच्च स्तर पर, यदि कुबेरनेट्स क्लस्टर के पास अपने नोड्स पर स्थान उपलब्ध नहीं है, तो नए पॉड लंबित होंगे और शेड्यूल नहीं किए जाएंगे, जिससे विलंबता की समस्या हो सकती है।
जैसा कि आप देखते हैं, चार सुनहरे संकेत एक दूसरे से संबंधित हैं। समस्याएँ अक्सर कई संकेतों में प्रकट होती हैं।
जबकि कोई भी सिस्टम स्वास्थ्य समस्या प्रत्यक्ष या अप्रत्यक्ष रूप से सुरक्षा को प्रभावित कर सकती है, कुछ प्रत्यक्ष खतरे हैं जिनका पता लगाने और उन्हें कम करने में निगरानी मदद कर सकती है।
एक प्रणाली कई घटकों से बनी होती है, लेकिन यह इसके भागों के योग से अधिक होती है। बुनियादी स्तर पर, आपको चार सुनहरे संकेतों के लिए अपने सिस्टम के प्रत्येक घटक (कम से कम महत्वपूर्ण पथों पर) की निगरानी करनी चाहिए। अभ्यास में इसका क्या मतलब है?
आपको बाहरी निर्भरताओं पर भी पूरा ध्यान देना चाहिए। उदाहरण के लिए, यदि आप क्लाउड में चलते हैं या किसी तृतीय-पक्ष सेवा प्रदाता के साथ एकीकृत होते हैं, तो आपको उन सार्वजनिक समापन बिंदुओं की निगरानी करनी चाहिए जिन पर आप निर्भर हैं और समस्याओं का पता लगाने के लिए अलर्ट सेट करें। यदि कोई तीसरा पक्ष नीचे है या उसका प्रदर्शन खराब है, तो यह आपके सिस्टम में व्यापक विफलता का कारण बन सकता है।
100% विश्वसनीय घटक होना संभव नहीं है। हालांकि, निगरानी आपको गैर-भरोसेमंद घटकों से एक विश्वसनीय प्रणाली बनाने में मदद कर सकती है - घटकों के साथ समस्याओं का पता लगाकर - आंतरिक और बाहरी दोनों - और या तो उन्हें प्रतिस्थापित कर सकती है या सेवा को खराब कर सकती है। उदाहरण के लिए, यदि आप अपने सिस्टम को मल्टी-ज़ोन कॉन्फ़िगरेशन में चला रहे हैं और एक ज़ोन में कोई समस्या है, तो निगरानी इसका पता लगा सकती है और अन्य ज़ोन के लिए सभी ट्रैफ़िक को री-रूटिंग (मैन्युअल या स्वचालित रूप से) ट्रिगर कर सकती है।
सुरक्षा के लिए, चार संकेत किसी समझौते के सहायक संकेतक भी हो सकते हैं । यह विशेष रूप से मामला है, उदाहरण के लिए, यदि आप अपने एंडपॉइंट डिवाइस या क्लाउड वर्कलोड सीपीयू में स्पाइक देखते हैं, या असफल लॉगिन प्रयासों की संख्या में वृद्धि देखते हैं। हालाँकि, सुरक्षा निगरानी बहुत सोच-समझकर होनी चाहिए क्योंकि आप दुर्भावनापूर्ण विरोधियों से निपटते हैं। आपको प्रत्येक घटक और संपूर्ण सिस्टम की आक्रमण सेवा को परिभाषित करना होगा और यह सुनिश्चित करना होगा कि आप जो जानकारी एकत्र कर रहे हैं वह मुद्दों का पता लगाने के लिए पर्याप्त है । उदाहरण के लिए, डेटा एक्सफिल्ट्रेशन का पता लगाने के लिए, आप विभिन्न एप्लिकेशन और सेवाओं द्वारा अपने आंतरिक नेटवर्क के बाहर भेजे गए आईपी पतों और डेटा की मात्रा की निगरानी कर सकते हैं। यदि आपके पास वह डेटा नहीं है, तो आप उस हमले की पद्धति से अंधे होंगे।
एक बार जब आप अपना डेटा संग्रह सेट कर लेते हैं, तो आप एक मजबूत और प्रभावी निगरानी रणनीति तैयार करने के लिए नीचे दिए गए चरणों का पालन कर सकते हैं।
आपने पहले ही डेटा संग्रह के भाग के रूप में अपनी सभी संपत्तियों की एक व्यापक सूची बना ली है। अब, आपका काम उन महत्वपूर्ण संपत्तियों की पहचान करना है जिनकी आपदाओं को रोकने और कम करने के लिए बारीकी से निगरानी की जानी चाहिए। यह कहना आसान है, "बस हर चीज की निगरानी करें," लेकिन निगरानी के साथ विचार करने की लागतें हैं। आपके मंचन और विकासशील परिवेशों या प्रयोगात्मक सेवाओं के लिए निगरानी और चेतावनी देना आपके इंजीनियरों पर बहुत अधिक अनावश्यक तनाव डाल सकता है। महत्वहीन मुद्दों के लिए बार-बार सुबह 3 बजे की चेतावनी सतर्क थकान का कारण बनेगी, जब यह वास्तव में मायने रखती है तो समस्या को हल करने के लिए आपकी टीम की ड्राइव को पंगु बना देगी।
एक बार जब आप महत्वपूर्ण संपत्तियों की पहचान कर लेते हैं, तो आपको प्रत्येक के लिए एक स्पष्ट स्वामी की आवश्यकता होती है। मालिक एक व्यक्ति या एक टीम हो सकता है। किसी व्यक्ति के मामले में, कमबैक की पहचान करना भी सुनिश्चित करें। संपत्ति के स्वामित्व को बनाए रखना भी महत्वपूर्ण है क्योंकि लोग संगठन में शामिल होते हैं और छोड़ते हैं या अन्य भूमिकाओं और टीमों में जाते हैं।
आखिरकार, आपकी निगरानी रणनीति इस आधार पर जीवित या मर जाएगी कि आप अस्वास्थ्यकर या संभावित रूप से समझौता किए गए संपत्तियों के लिए अलर्ट कैसे परिभाषित करते हैं। आपको यह समझने की आवश्यकता है कि प्रत्येक संपत्ति के लिए क्या सामान्य है।
यदि आप मेट्रिक्स की निगरानी कर रहे हैं, तो "सामान्य" को परिभाषित करने का अर्थ है एक विशेषता (जैसे सीपीयू उपयोग) को मानों की श्रेणी (जैसे "50% -80%") से जोड़ना। सामान्य बैंड व्यवसाय के साथ गतिशील रूप से बदल सकता है और अलग-अलग समय और अलग-अलग स्थानों पर भिन्न हो सकता है। कुछ मामलों में, आपके पास केवल छतें या फर्श हो सकते हैं। सामान्य श्रेणियों को परिभाषित करके, आप संपत्ति के मालिक को सूचित करने के लिए अलर्ट बनाते हैं जब उनकी संपत्ति सामान्य सीमा से बाहर चल रही हो।
यदि आप लॉग की निगरानी कर रहे हैं, तो अलर्ट आमतौर पर कुछ लॉग क्वेरी के परिणाम के आधार पर परिभाषित किए जाते हैं (जैसे "पिछले पांच मिनट में सभी एपीआई सेवाओं में लॉग की गई 404 त्रुटियों की संख्या") किसी शर्त को संतुष्ट या विफल करना (जैसे "है 10 से कम")। लॉग प्रबंधन और विश्लेषिकी उपकरण मदद कर सकते हैं।
जब कोई गंभीर अलर्ट सक्रिय होता है, तो आप क्या करते हैं? आप जो नहीं करना चाहते हैं वह मौके पर ही अपनी रणनीति का पता लगाने की कोशिश कर रहा है, जबकि ग्राहक आपकी कंपनी के अविश्वसनीय उत्पादों के बारे में ट्वीट कर रहे हैं और प्रबंधन घबरा रहा है।
एक रनबुक आसान-से-अनुसरण करने वाले चरणों का एक नुस्खा है जिसे आप अतिरिक्त जानकारी एकत्र करने में मदद करने के लिए समय से पहले तैयार करते हैं और परीक्षण करते हैं (उदाहरण के लिए, कौन से डैशबोर्ड को देखना है और मूल कारण का निदान करने के लिए कौन सी कमांड-लाइन स्क्रिप्ट चलाना है) और कार्रवाइयों को कम करें (उदाहरण के लिए, एप्लिकेशन के पिछले संस्करण को परिनियोजित करें)। आपकी रनबुक को किसी विशिष्ट मुद्दे पर समस्या को तुरंत इंगित करने और इसे संभालने के लिए सर्वश्रेष्ठ व्यक्ति की पहचान करने में आपकी सहायता करनी चाहिए।
आपके पास मालिक, अलर्ट और रनबुक हैं। अक्सर, अलर्ट सीधे स्वामियों को मैप करने के लिए पर्याप्त विशिष्ट नहीं होते हैं। व्यवसाय के विभिन्न क्षेत्रों में ऑन-कॉल इंजीनियरों को नियुक्त करना सबसे अच्छा अभ्यास है। यह ऑन-कॉल इंजीनियर अलर्ट प्राप्त करेगा, रनबुक का पालन करेगा, डैशबोर्ड को देखेगा और मूल कारण को समझने की कोशिश करेगा। यदि वे समस्या को समझ या ठीक नहीं कर सकते हैं, तो वे इसे स्वामी तक बढ़ाएँगे। ध्यान रखें कि यह प्रक्रिया जटिल हो सकती है; अक्सर, विफलताओं की एक श्रृंखला के कारण समस्या उत्पन्न होती है जिसके लिए समस्या को हल करने के लिए कई हितधारकों को सहयोग करने की आवश्यकता होती है।
रनबुक महान हैं, लेकिन जटिल रनबुक बनाए रखना और ऑन-कॉल इंजीनियरों को उनका अनुसरण करने के लिए प्रशिक्षित करना बहुत प्रयास करता है। और अंत में, आपकी सुधारात्मक प्रक्रिया अभी भी धीमी और त्रुटि-प्रवण मानव पर निर्भर करती है। यदि आपकी रनबुक अप टू डेट नहीं है, तो इसका अनुसरण करने से संकट और भी बढ़ सकता है।
सैद्धांतिक रूप से, एक रनबुक को प्रोग्रामेटिक रूप से निष्पादित किया जा सकता है। यदि रनबुक कहती है, "जब अलर्ट एक्स फायर करता है, तो प्रक्रिया वाई को पुनरारंभ करना चाहिए", तो एक स्क्रिप्ट या प्रोग्राम अलर्ट एक्स की अधिसूचना प्राप्त कर सकता है और प्रक्रिया वाई को पुनरारंभ कर सकता है। वही प्रोग्राम प्रक्रिया वाई पोस्ट-रीस्टार्ट की निगरानी कर सकता है, सुनिश्चित करें कि सब कुछ ठीक है, और अंततः घटना की एक रिपोर्ट तैयार करते हैं — बिना ऑन-कॉल इंजीनियर को जगाए। यदि स्व-उपचार क्रिया विफल हो जाती है, तो ऑन-कॉल इंजीनियर से संपर्क किया जा सकता है।
स्व-उपचार बहुत बढ़िया है, हालांकि, रोकथाम का एक औंस इलाज के लायक है, इसलिए सबसे पहले समस्याओं को रोकना सबसे अच्छा है। हर घटना सीखने का एक अवसर है और संभवत: समस्याओं की एक पूरी श्रेणी को रोकने के लिए। उदाहरण के लिए, यदि कई घटनाएं होती हैं क्योंकि बग्गी कोड उत्पादन के लिए अपना रास्ता बनाता है, तो घटना के पोस्ट-मॉर्टम से एक सबक स्टेजिंग में परीक्षण में सुधार कर सकता है। यदि अलर्ट पर ऑन-कॉल इंजीनियर की प्रतिक्रिया बहुत धीमी थी या रनबुक पुरानी थी, तो यह सुझाव दे सकता है कि टीम को कुछ स्व-उपचार प्रथाओं में निवेश करना चाहिए।
निगरानी सामान्य रूप से अवलोकनीयता और विशेष रूप से सुरक्षा के लिए अवलोकनीयता का एक महत्वपूर्ण हिस्सा है। समस्याओं का पता लगाने के लिए विभिन्न डैशबोर्ड और ग्राफ़ पर "बस कभी-कभी देखना" मनुष्यों के लिए बड़े पैमाने पर अव्यावहारिक है। आपको घटना प्रतिक्रिया प्रथाओं के एक पूरे सेट की आवश्यकता है जिसमें मालिकों की पहचान करना, अलर्ट सेट करना, रनबुक लिखना, रनबुक को स्वचालित करना और ऑन-कॉल प्रक्रियाओं और पोस्ट-मॉर्टम प्रक्रियाओं को सेट करना शामिल है।
आपका दिन वाकई बहुत अच्छा हो!