SRE (साइट विश्वसनीयता ईन्जिनियरिङ्) वेब परियोजनाहरु पहुँचयोग्य बनाउन को लागी एक दृष्टिकोण हो। यसलाई DevOps को लागि एक रूपरेखा मानिन्छ र DevOps अभ्यासहरूको प्रयोगमा कसरी सफल हुने भनेर बताउँछ। यो लेख अनुवाद अध्याय ६ अनुगमन वितरण प्रणालीहरू पुस्तकहरू साइट विश्वसनीयता ईन्जिनियरिङ् Google बाट। मैले यो अनुवाद आफैं तयार गरें र अनुगमन प्रक्रियाहरू बुझ्न मेरो आफ्नै अनुभवमा भर परेको छु। टेलिग्राम च्यानल मा @monitorim_it и मध्यम मा ब्लग मैले सेवा स्तर उद्देश्यहरूमा उही पुस्तकको अध्याय 4 को अनुवादको लिङ्क पनि पोस्ट गरें।

बिल्ली द्वारा अनुवाद। पढेर आनन्द लिनुहोस्!

Google SRE टोलीहरूसँग सफल अनुगमन र सूचना प्रणालीहरू निर्माण गर्न आधारभूत सिद्धान्तहरू र उत्कृष्ट अभ्यासहरू छन्। यो अध्यायले वेब पृष्ठ आगन्तुकले सामना गर्न सक्ने समस्याहरू र वेब पृष्ठहरू प्रदर्शन गर्न गाह्रो बनाउने समस्याहरू कसरी समाधान गर्ने भन्ने बारे सिफारिसहरू प्रदान गर्दछ।

परिभाषाहरू

अनुगमनसँग सम्बन्धित विषयहरू छलफल गर्न कुनै एकल शब्दावली प्रयोग गरिएको छैन। Google मा पनि, तलका सर्तहरू सामान्य प्रयोगमा छैनन्, तर हामी सबैभन्दा सामान्य व्याख्याहरू सूचीबद्ध गर्नेछौं।

निगरानी गर्दै

सङ्कलन, प्रशोधन, एकत्रीकरण र प्रणालीको बारेमा वास्तविक-समय मात्रात्मक डेटाको प्रदर्शन: अनुरोधहरूको संख्या र अनुरोधहरूको प्रकार, त्रुटिहरूको संख्या र त्रुटिहरूको प्रकार, अनुरोध प्रक्रिया समय र सर्भर अपटाइम।

सेतो बक्स निगरानी

आन्तरिक तथ्याङ्कहरू उत्पन्न गर्ने लगहरू, JVM वा HTTP ह्यान्डलर प्रोफाइलिङ मेट्रिकहरू सहित प्रणाली आन्तरिकहरूद्वारा प्रदर्शित मेट्रिक्समा आधारित निगरानी।

ब्ल्याक बक्स निगरानी

प्रयोगकर्ताको दृष्टिकोणबाट अनुप्रयोगको व्यवहार परीक्षण गर्दै।

ड्यासबोर्ड (ड्यासबोर्डहरू)

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

अलर्ट (सूचना)

सूचनाहरू एक व्यक्तिद्वारा इ-मेल वा अन्यथा प्राप्त गर्ने उद्देश्यले, जुन त्रुटिहरूको कारण वा अनुरोध लाइनमा वृद्धिको रूपमा ट्रिगर हुन सक्छ। सूचनाहरूलाई यसरी वर्गीकृत गरिएको छ: टिकटहरू, इमेल अलर्टहरू र मेसेन्जर सन्देशहरू।

मूल कारण (मूल कारण)

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

नोड र मेसिन (नोड र मेसिन)

एक भौतिक सर्भर, भर्चुअल मेसिन, वा कन्टेनरमा चलिरहेको अनुप्रयोगको एकल उदाहरणलाई सन्दर्भ गर्न विनिमेय सर्तहरू। एउटै मेसिनमा धेरै सेवाहरू हुन सक्छन्। सेवाहरू हुन सक्छन्:

• एक अर्कासँग सम्बन्धित: उदाहरणका लागि, क्यास सर्भर र वेब सर्भर;
• एउटै हार्डवेयरमा असंबद्ध सेवाहरू: उदाहरणका लागि, एक कोड भण्डार र कन्फिगरेसन प्रणालीको लागि विजार्ड, जस्तै कठपुतली वा सेफ.

पुस

सफ्टवेयर कन्फिगरेसनमा कुनै पनि परिवर्तन।

किन अनुगमन आवश्यक छ

त्यहाँ धेरै कारणहरू छन् किन अनुप्रयोगहरू अनुगमन गर्नुपर्छ:

दीर्घकालीन प्रवृत्तिहरूको विश्लेषण

डाटाबेस कति ठूलो छ र कति छिटो बढ्दै छ? प्रयोगकर्ताहरूको दैनिक संख्या कसरी परिवर्तन हुन्छ?

प्रदर्शन तुलना

Ajax DB 2.72 भन्दा बाइट्स 3.14 को Acme बकेटमा प्रश्नहरू छिटो छन्? थप नोड देखा परेपछि अनुरोधहरू कति राम्रो हुन्छ? के साइट गत हप्ता भन्दा ढिलो भएको छ?

चेतावनी (सूचनाहरू)

केहि बिग्रिएको छ र कसैले यसलाई ठीक गर्नुपर्छ। वा केहि चाँडै बिग्रन्छ र कसैले यसलाई चाँडै जाँच गर्नुपर्छ।

ड्यासबोर्डहरू सिर्जना गर्दै

ड्यासबोर्डहरूले आधारभूत प्रश्नहरूको जवाफ दिनुपर्छ र त्यसबाट केही समावेश गर्नुपर्छ "4 सुनौलो संकेत" - ढिलाइ (विलम्बता), ट्राफिक (ट्राफिक), त्रुटिहरू (त्रुटिहरू) र लोड मान (संतृप्ति)।

पूर्वव्यापी विश्लेषण सञ्चालन गर्दै (डिबगिङ)

अनुरोध प्रशोधन विलम्बता बढ्यो, एकै समयमा अरू के भयो?
निगरानी प्रणालीहरू व्यापार खुफिया प्रणालीहरूको लागि डाटा स्रोतको रूपमा उपयोगी छन् र सुरक्षा घटनाहरूको विश्लेषणलाई सहज बनाउन। यस पुस्तकले ईन्जिनियरिङ् क्षेत्रहरूमा केन्द्रित भएकोले SRE को विशेषज्ञता छ, हामी यहाँ अनुगमन प्रविधिहरू छलफल गर्दैनौं।

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

मानव अलर्टहरू लोड गर्नु कर्मचारीको समयको सट्टा महँगो प्रयोग हो। यदि कर्मचारी काम गरिरहेको छ भने, सतर्कताले कार्यप्रवाहमा बाधा पुर्‍याउँछ। यदि कर्मचारी घरमा छ भने, सतर्कताले व्यक्तिगत समय र सम्भवतः निद्रामा बाधा पुर्‍याउँछ। जब अलर्टहरू धेरै बारम्बार हुन्छन्, कर्मचारीहरू स्किम, ढिलाइ, वा आगमन अलर्टहरूलाई बेवास्ता गर्छन्। समय-समयमा तिनीहरूले वास्तविक सतर्कतालाई बेवास्ता गर्छन्, जुन शोर घटनाहरूद्वारा मास्क गरिएको छ। सेवा अवरोधहरू लामो समयसम्म रहन सक्छन् किनभने आवाज घटनाहरूले द्रुत समस्या निदान र समाधानलाई रोक्छ। प्रभावकारी सार्वजनिक ठेगाना प्रणालीहरूमा राम्रो संकेत-देखि-शोर अनुपात हुन्छ।

अनुगमन प्रणालीबाट उचित अपेक्षाहरू निर्धारण गर्दै

जटिल अनुप्रयोगको लागि अनुगमन सेटअप आफैमा एक जटिल इन्जिनियरिङ कार्य हो। सङ्कलन, प्रदर्शन, र अलर्टिङ उपकरणहरूको महत्त्वपूर्ण पूर्वाधारको साथमा पनि, 10-12 सदस्यहरूको Google SRE टोलीमा सामान्यतया एक वा दुई व्यक्तिहरू समावेश हुन्छन् जसको मुख्य उद्देश्य अनुगमन प्रणालीहरू निर्माण र मर्मत गर्नु हो। हामीले अनुगमन पूर्वाधारलाई सामान्यीकरण र केन्द्रीकृत गर्दा यो संख्या समयको साथ घट्दै गएको छ, तर प्रत्येक SRE टोलीमा सामान्यतया कम्तीमा एकजना अनुगमन-मात्र कर्मचारी सदस्य हुन्छ। यो भन्नु पर्छ कि जब यो निगरानी प्रणाली ड्यासबोर्डहरू हेर्न धेरै रोचक छ, SRE टोलीहरू सावधानीपूर्वक परिस्थितिहरू बेवास्ता गर्छन् जसले समस्याहरू निगरानी गर्न स्क्रिनमा हेर्न आवश्यक छ।

सामान्यमा, गुगलले इष्टतम पछि-द-तथ्य विश्लेषण उपकरणहरूको साथ सरल र छिटो अनुगमन प्रणालीहरूमा सरेको छ। हामी थ्रेसहोल्डहरू भविष्यवाणी गर्ने वा स्वतः मूल कारण पत्ता लगाउने प्रयास गर्ने "जादुई" प्रणालीहरूलाई बेवास्ता गर्छौं। अन्त प्रयोगकर्ता अनुरोधहरूमा अनावश्यक सामग्री पत्ता लगाउने सेन्सरहरू मात्र काउन्टर उदाहरण हुन्; जबसम्म यी सेन्सरहरू सरल रहन्छन्, तिनीहरूले गम्भीर विसंगतिहरूको कारणहरू द्रुत रूपमा पत्ता लगाउन सक्छन्। अनुगमन डाटा प्रयोग गर्नका लागि अन्य ढाँचाहरू, जस्तै क्षमता योजना वा ट्राफिक पूर्वानुमान, बढी चुनौतीपूर्ण छन्। कम नमूना दर (घण्टा वा दिन) मा धेरै लामो समय (महिना वा वर्ष) मा अवलोकनले दीर्घकालीन प्रवृत्ति प्रकट गर्नेछ।

गुगल एसआरई टोलीले जटिल निर्भरता पदानुक्रमको साथ सफलताको विभिन्न डिग्रीहरूसँग काम गरेको छ। हामी विरलै नियमहरू प्रयोग गर्छौं जस्तै "यदि मैले डाटाबेस ढिलो भएको थाहा पाएमा, म डाटाबेस ढिलो चेतावनी पाउँछु, अन्यथा म ढिलो साइट अलर्ट पाउँछु।" निर्भरतामा आधारित नियमहरूले सामान्यतया हाम्रो प्रणालीको अपरिवर्तनीय भागहरूलाई जनाउँछ, जस्तै डेटा केन्द्रमा प्रयोगकर्ता ट्राफिक फिल्टर गर्ने प्रणाली। उदाहरणका लागि, "यदि डेटा केन्द्र ट्राफिक फिल्टरिङ कन्फिगर गरिएको छ भने, प्रयोगकर्ता अनुरोधहरू प्रशोधन गर्न ढिलाइको बारेमा मलाई सचेत नगर्नुहोस्" डेटा केन्द्र अलर्टहरूको लागि एक सामान्य नियम हो। गुगलका केही टोलीहरूले जटिल निर्भरता पदानुक्रमहरूलाई समर्थन गर्छन् किनभने हाम्रो पूर्वाधारमा निरन्तर रिफ्याक्टरिंगको स्थिर दर छ।

यस अध्यायमा उल्लिखित केही विचारहरू अझै पनि साँचो मानिन्छन्: त्यहाँ जहिले पनि लक्षणबाट मूल कारणमा छिटो सर्ने तरिका हुन्छ, विशेष गरी सधैं परिवर्तन हुने प्रणालीहरूमा। तसर्थ, यस अध्यायले अनुगमन प्रणालीका लागि केही लक्ष्यहरू र ती लक्ष्यहरू कसरी प्राप्त गर्ने भनेर वर्णन गर्दा, यो महत्त्वपूर्ण छ कि अनुगमन प्रणालीहरू सरल र टोलीका सबैका लागि बुझ्ने छन्।

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

लक्षण बनाम कारणहरू

तपाईंको अनुगमन प्रणालीले दुईवटा प्रश्नहरूको जवाफ दिनुपर्छ: "के टुटेको छ" र "किन बिग्रिएको छ"।
"के तोडियो" ले लक्षणलाई बुझाउँछ, र "किन भाँचियो" ले कारणलाई बुझाउँछ। तलको तालिकाले त्यस्ता लिङ्कहरूको उदाहरणहरू देखाउँछ।

लक्षण
कारण

HTTP त्रुटि 500 ​​वा 404 प्राप्त गर्दै
डाटाबेस सर्भरहरूले जडानहरू अस्वीकार गर्दैछन्

ढिलो सर्भर प्रतिक्रियाहरू
उच्च CPU उपयोगिता वा क्षतिग्रस्त इथरनेट केबल

अन्टार्कटिकाका प्रयोगकर्ताहरूले बिरालोको GIF प्राप्त गर्दैनन्
तपाईंको CDN ले वैज्ञानिक र फेलाइनहरूलाई घृणा गर्छ, त्यसैले केही IP हरू कालोसूचीमा परेका छन्

निजी सामग्री जताततै उपलब्ध छ
नयाँ सफ्टवेयर रिलिज रोलिंगले फायरवाललाई सबै ACL बिर्सन र सबैलाई भित्र जान दियो

"के" र "किन" अधिकतम संकेत र न्यूनतम आवाजको साथ राम्रो निगरानी प्रणाली सिर्जना गर्नका लागि सबैभन्दा महत्त्वपूर्ण निर्माण ब्लकहरू मध्ये एक हो।

ब्ल्याक-बक्स बनाम सेतो-बक्स

हामी महत्वपूर्ण मेट्रिक्सका लागि मामूली ब्ल्याक-बक्स निगरानीको साथ व्यापक सेतो-बक्स अनुगमनलाई संयोजन गर्छौं। ब्ल्याक-बक्सलाई सेतो-बक्ससँग तुलना गर्ने सबैभन्दा सजिलो तरिका भनेको ब्ल्याक-बक्स लक्षण-केन्द्रित छ र सक्रिय निगरानीको सट्टा प्रतिक्रियात्मक छ: "प्रणालीले अहिले ठीकसँग काम गरिरहेको छैन।" सेतो-बक्स प्रणालीहरूको आन्तरिक जाँच क्षमताहरूमा निर्भर गर्दछ: घटना लगहरू वा वेब सर्भरहरू। यसरी, व्हाइट-बक्सले तपाईंलाई आगामी समस्याहरू पत्ता लगाउन अनुमति दिन्छ, अनुरोधको पुन: प्रसारण जस्तो देखिने खराबीहरू, आदि।

ध्यान दिनुहोस् कि बहु-तह प्रणालीमा, एक इन्जिनियरको जिम्मेवारीको क्षेत्रमा लक्षण अर्को इन्जिनियरको जिम्मेवारीको क्षेत्रमा एक लक्षण हो। उदाहरणका लागि, डाटाबेस प्रदर्शन घटेको छ। ढिलो डाटाबेस पढ्ने डाटाबेस SRE को एक लक्षण हो जसले तिनीहरूलाई पत्ता लगाउँछ। यद्यपि, फ्रन्ट-एन्ड SRE को लागी एक ढिलो वेबसाइट हेर्दै, एउटै ढिलो डाटाबेस पढ्नको कारण डाटाबेस ढिलो छ। त्यसकारण, सेतो-बक्स निगरानी कहिलेकाहीं लक्षणहरूमा केन्द्रित हुन्छ र कहिलेकाहीं कारणहरूमा, यो कत्तिको व्यापक छ भन्ने आधारमा।

डिबगिङका लागि टेलिमेट्री सङ्कलन गर्दा, सेतो-बक्स निगरानी आवश्यक छ। यदि वेब सर्भरहरू डाटाबेस प्रश्नहरूको जवाफ दिन ढिलो छन् भने, तपाईंलाई वेब सर्भरले डाटाबेससँग कति छिटो सञ्चार गरिरहेको छ र कति छिटो प्रतिक्रिया दिइरहेको छ भनेर जान्न आवश्यक छ। अन्यथा, तपाइँ ढिलो डाटाबेस सर्भर र वेब सर्भर र डाटाबेस बीचको नेटवर्क समस्या बीचको भिन्नता बताउन सक्षम हुनुहुने छैन।

अलर्टहरू पठाउँदा ब्ल्याक-बक्स निगरानीको मुख्य फाइदा हुन्छ: तपाईंले प्रापकलाई सूचना ट्रिगर गर्नुहुन्छ जब समस्याले पहिले नै वास्तविक लक्षणहरू निम्त्याएको छ। अर्कोतर्फ ब्ल्याक बक्सको समस्या अहिलेसम्म नआए पनि आगामी दिनमा अनुगमन बेकार छ ।

चार सुनौलो संकेत

चार सुनौलो निगरानी संकेतहरू विलम्बता, ट्राफिक, त्रुटिहरू, र संतृप्ति हुन्। यदि तपाइँ केवल चार प्रयोगकर्ता प्रणाली मेट्रिक्स मापन गर्न सक्नुहुन्छ, ती चारमा फोकस गर्नुहोस्।

ढिलाइ

अनुरोध प्रशोधन गर्न आवश्यक समय। सफल र असफल अनुरोधहरूको विलम्बताको बीचमा छुट्याउन महत्त्वपूर्ण छ। उदाहरणका लागि, डाटाबेस वा अर्को ब्याकइन्डमा हराएको जडानको कारणले गर्दा HTTP 500 त्रुटि धेरै चाँडै निदान गर्न सकिन्छ, यद्यपि, HTTP 500 त्रुटिले असफल अनुरोधलाई संकेत गर्न सक्छ। समग्र विलम्बतामा 500 त्रुटिको प्रभाव पत्ता लगाउनाले गलत निष्कर्ष निम्त्याउन सक्छ। अर्कोतर्फ, ढिलो त्रुटि पनि छिटो त्रुटि हो! त्यसकारण, त्रुटिहरू फिल्टर गर्नुको सट्टा त्रुटि विलम्बता ट्र्याक गर्न महत्त्वपूर्ण छ।

यातायात

उच्च-स्तर प्रणाली मेट्रिक्समा मापन गरिएको तपाईंको प्रणालीमा अनुरोधहरूको संख्या। वेब सेवाको लागि, यो मापनले सामान्यतया प्रति सेकेन्ड HTTP अनुरोधहरूको संख्यालाई अनुरोधहरूको प्रकृति (उदाहरणका लागि, स्थिर वा गतिशील सामग्री) द्वारा विभाजित गर्दछ। अडियो स्ट्रिमिङ प्रणालीको लागि, यो मापन नेटवर्क I/O दर वा समवर्ती सत्रहरूको संख्यामा केन्द्रित हुन सक्छ। मुख्य-मान भण्डारण प्रणालीको लागि, यो मापन लेनदेन वा लुकअप प्रति सेकेन्ड हुन सक्छ।

गल्तीहरू

यो असफल अनुरोधहरूको दर हो, या त स्पष्ट रूपमा (उदाहरणका लागि, HTTP 500), स्पष्ट रूपमा (उदाहरणका लागि, HTTP 200 तर खराब सामग्रीसँग जोडिएको), वा नीतिद्वारा (उदाहरणका लागि, "यदि तपाईंले एक सेकेन्डमा प्रतिक्रिया क्याप्चर गर्नुभयो भने, कुनै पनि। एक सेकेन्ड त्रुटि हो")। यदि सबै विफलता अवस्थाहरू व्यक्त गर्न पर्याप्त HTTP प्रतिक्रिया कोडहरू छैनन् भने, आंशिक विफलता पत्ता लगाउन माध्यमिक (आन्तरिक) प्रोटोकलहरू आवश्यक हुन सक्छ। त्यस्ता सबै त्रुटिपूर्ण अनुरोधहरूको अनुगमन सूचनाविहीन हुन सक्छ, जबकि अन्त्य-देखि-अन्त प्रणाली परीक्षणहरूले तपाईंलाई गलत सामग्री प्रशोधन गर्दै हुनुहुन्छ भनेर पत्ता लगाउन मद्दत गर्न सक्छ।

संतृप्ति

मेट्रिकले तपाईंको सेवा कत्तिको प्रयोग भइरहेको छ भनेर देखाउँछ। यो एक प्रणाली निगरानी उपाय हो जसले धेरै सीमित स्रोतहरू पहिचान गर्दछ (उदाहरणका लागि, सीमित मेमोरी भएको प्रणालीमा, मेमोरी देखाउँदछ, सीमित I / O भएको प्रणालीमा, I / O को संख्या देखाउँदछ)। ध्यान दिनुहोस् कि धेरै प्रणालीहरू 100% उपयोगमा पुग्नु अघि नै कमजोर हुन्छन्, त्यसैले उपयोग लक्ष्य हुनु आवश्यक छ।

जटिल प्रणालीहरूमा, संतृप्ति उच्च-स्तर लोड मापन द्वारा पूरक हुन सक्छ: के तपाईंको सेवाले राम्रोसँग दोहोरो ट्राफिक ह्यान्डल गर्न सक्छ, केवल 10% बढी ट्राफिक ह्यान्डल गर्न सक्छ, वा हालको भन्दा कम ट्राफिक ह्यान्डल गर्न सक्छ? अनुरोधको जटिलता परिवर्तन गर्ने प्यारामिटरहरू नभएका साधारण सेवाहरूका लागि (जस्तै "मलाई केही नदिनुहोस्" वा "मलाई एउटा अद्वितीय एक मोनोटोनिक पूर्णांक चाहिन्छ") जसले विरलै कन्फिगरेसन परिवर्तन गर्छ, स्थिर लोड परीक्षण मान पर्याप्त हुन सक्छ। अघिल्लो अनुच्छेदमा छलफल गरिए अनुसार, धेरैजसो सेवाहरूले अप्रत्यक्ष संकेतहरू जस्तै CPU उपयोग वा नेटवर्क ब्यान्डविथ प्रयोग गर्नुपर्छ जसमा ज्ञात अपर बाउन्ड छ। बढ्दो विलम्बता प्रायः संतृप्तिको मुख्य सूचक हो। एउटा सानो सञ्झ्यालमा (जस्तै एक मिनेट) 99 औं प्रतिशत प्रतिक्रिया समय मापन गर्दा धेरै प्रारम्भिक संतृप्ति संकेत दिन सक्छ।

अन्तमा, संतृप्ति आसन्न संतृप्तिको भविष्यवाणीहरूसँग पनि सम्बन्धित छ, जस्तै: "तपाईंको डाटाबेसले तपाईंको हार्ड ड्राइभलाई 4 घण्टामा भर्नेछ जस्तो देखिन्छ।"

यदि तपाइँ सबै चार सुनौलो संकेतहरू मापन गर्नुहुन्छ र जब मेट्रिक्स मध्ये एकमा समस्या छ (वा, संतृप्तिको अवस्थामा, लगभग एक समस्या), तपाइँ व्यक्तिलाई सूचित गर्नुहुन्छ, तपाइँको सेवा कम वा कम निगरानी द्वारा कवर गरिनेछ।

पुच्छरको बारेमा चिन्ता (वा उपकरण र प्रदर्शन)

स्क्र्याचबाट निगरानी प्रणाली निर्माण गर्दा, औसतमा आधारित प्रणाली विकास गर्न लोभ्याउँछ: औसत विलम्बता, औसत नोड CPU उपयोग, वा औसत डाटाबेस कब्जा। अन्तिम दुई उदाहरणहरूको खतरा स्पष्ट छ: प्रोसेसरहरू र डाटाबेसहरू धेरै अप्रत्याशित तरिकामा निलम्बन गरिन्छ। उस्तै ढिलाइमा लागू हुन्छ। यदि तपाइँ प्रति सेकेन्ड 100 अनुरोधहरूमा 1000ms को औसत विलम्बताको साथ वेब सेवा चलाउँदै हुनुहुन्छ भने, 1% अनुरोधहरूले 5 सेकेन्ड लिन सक्छ। यदि प्रयोगकर्ताहरू धेरै त्यस्ता वेब सेवाहरूमा निर्भर छन् भने, एकल ब्याकइन्डको 99 औं प्रतिशत सजिलै इन्टरफेसको मध्य प्रतिक्रिया समय बन्न सक्छ।

एक ढिलो औसत र अनुरोधहरूको धेरै ढिलो पुच्छर बीच भेद गर्ने सरल तरिका भनेको तथ्याङ्कहरूमा व्यक्त गरिएका अनुरोधहरूको मापन सङ्कलन गर्नु हो (हिस्टोग्रामहरू प्रदर्शन गर्नको लागि उपयुक्त उपकरण हो), वास्तविक ढिलाइको सट्टा: कतिवटा अनुरोधहरू सेवाद्वारा सेवा गरियो। 0 ms र 10ms को बीचमा, 10ms र 30ms को बीचमा, 30ms र 100ms को बिचमा, 100ms र 300ms को बिचमा, आदि। हिस्टोग्राम बाउन्डलाई लगभग एक्सपोनेन्शिअल विस्तार गर्नु (लगभग 3 को कारक द्वारा) प्रायः क्वेरीहरूको वितरण कल्पना गर्ने सजिलो तरिका हो।

मापनको लागि सही ग्रेन्युलेरिटी छनौट गर्दै

प्रणालीका विभिन्न तत्वहरूलाई विभिन्न स्तरको विवरणको साथ मापन गर्नुपर्छ। उदाहरणका लागि:

• समयको अवधिमा CPU उपयोग प्रयोग हेर्दा लामो स्पाइक्सहरू देखाउँदैन जसले उच्च विलम्बताको परिणाम दिन्छ।
• अर्कोतर्फ, प्रति वर्ष 9 घण्टा भन्दा बढी डाउनटाइम (99,9% वार्षिक अपटाइम) लक्षित वेब सेवाको लागि, HTTP 200 प्रतिक्रियाको लागि प्रति मिनेट एक वा दुई पटक भन्दा बढी जाँच गर्दा अनावश्यक रूपमा बारम्बार हुनेछ।
• त्यसै गरी, हार्ड ड्राइभमा 99,9% उपलब्धताको लागि प्रत्येक 1-2 मिनेटमा एक पटक भन्दा बढी खाली ठाउँको लागि जाँच गर्न सम्भव छैन।

तपाईंले आयामहरूको ग्रेन्युलारिटी कसरी संरचना गर्नुहुन्छ भन्ने कुरामा ध्यान दिनुहोस्। 1 प्रति सेकेन्डको CPU उपयोग दरले रोचक डेटा प्रदान गर्न सक्छ, तर यस्ता बारम्बार मापनहरू सङ्कलन, भण्डारण र विश्लेषण गर्न धेरै महँगो हुन सक्छ। यदि तपाईंको अनुगमन लक्ष्यलाई उच्च ग्रेन्युलेरिटी चाहिन्छ र उच्च प्रतिक्रियाको आवश्यकता पर्दैन भने, तपाईंले सर्भरमा मेट्रिक्स सङ्कलन सेटअप गरेर र त्यसपछि ती मेट्रिकहरू सङ्कलन र जम्मा गर्न बाह्य प्रणाली कन्फिगर गरेर यी लागतहरू घटाउन सक्नुहुन्छ। के तपाईं:

1. प्रत्येक सेकेन्ड CPU उपयोग मापन गर्नुहोस्।
2. विवरणलाई ५% मा घटाउनुहोस्।
3. प्रत्येक मिनेटमा मेट्रिकहरू जम्मा गर्नुहोस्।

यो रणनीतिले तपाईंलाई विश्लेषण र भण्डारणको लागि उच्च ओभरहेडहरू अनुभव नगरी उच्च दानेदार डेटा सङ्कलन गर्न अनुमति दिनेछ।

सकेसम्म सरल, तर सजिलो छैन

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

• अनुरोध विलम्बताका लागि विभिन्न थ्रेसहोल्डहरू अनुसार अलर्टहरू, विभिन्न प्रतिशतहरूमा, सबै प्रकारका विभिन्न मेट्रिकहरूमा।
• सम्भावित कारणहरू पत्ता लगाउन र पहिचान गर्न थप कोड लेख्दै।
• सम्भावित समस्याहरूको प्रत्येक कारणको लागि सम्बन्धित ड्यासबोर्डहरू सिर्जना गर्नुहोस्।

सम्भावित जटिलताको स्रोत कहिल्यै समाप्त हुँदैन। सबै सफ्टवेयर प्रणालीहरू जस्तै, निगरानी यति जटिल हुन सक्छ कि यो कमजोर, परिवर्तन गर्न र मर्मत गर्न गाह्रो हुन्छ।

त्यसकारण, तपाइँको निगरानी प्रणालीलाई सकेसम्म सरल बनाउन डिजाइन गर्नुहोस्। के ट्र्याक गर्ने छनौट गर्दा, निम्नलाई ध्यानमा राख्नुहोस्:

• प्रायः वास्तविक घटनाहरू समात्ने नियमहरू सम्भव भएसम्म सरल, भविष्यवाणी गर्न सकिने र भरपर्दो हुनुपर्छ।
• डेटा सङ्कलन, सङ्कलन, र अलर्टिङका ​​लागि कन्फिगरेसन जुन बारम्बार प्रदर्शन गरिन्छ (उदाहरणका लागि, केही SRE टोलीहरूका लागि त्रैमासिकभन्दा कम) हटाइनुपर्छ।
• सङ्कलन गरिएका तर कुनै पनि पूर्वावलोकन प्यानलमा नदेखाइएका वा कुनै अलर्टद्वारा प्रयोग गरिएका मेट्रिकहरू मेटाउनका लागि उम्मेदवार हुन्।

Google मा, मेट्रिक्सको आधारभूत सङ्कलन र सङ्कलन, अलर्टहरू र ड्यासबोर्डहरूसँग मिलेर, अपेक्षाकृत आत्म-निहित प्रणालीको रूपमा राम्रोसँग काम गर्दछ (Google को निगरानी प्रणाली वास्तवमा धेरै उपप्रणालीहरूमा विभाजित छ, तर सामान्यतया मानिसहरू यी उपप्रणालीका सबै पक्षहरू बारे सचेत हुन्छन्)। यो जटिल प्रणालीहरू परीक्षण गर्ने अन्य विधिहरूसँग निगरानी संयोजन गर्न प्रलोभन हुन सक्छ: विस्तृत प्रणाली प्रोफाइलिङ, प्रक्रिया डिबगिङ, ट्र्याकिङ अपवाद वा विफलता विवरणहरू, लोड परीक्षण, लग सङ्कलन र विश्लेषण, वा ट्राफिक निरीक्षण। यी धेरैजसो कुराहरूले आधारभूत अनुगमनसँग समानताहरू साझा गर्दा, तिनीहरूलाई मिलाएर धेरै नतिजाहरू ल्याउनेछ र जटिल र भंगुर प्रणाली सिर्जना गर्नेछ। सफ्टवेयर विकासका अन्य धेरै पक्षहरू जस्तै, स्पष्ट, सरल, ढिलो जोडिएको एकीकरण बिन्दुहरू सहित विभिन्न प्रणालीहरूलाई समर्थन गर्नु उत्तम रणनीति हो (उदाहरणका लागि, लामो समयसम्म स्थिर रहन सक्ने ढाँचामा सारांश डेटा पुन: प्राप्त गर्नको लागि वेब API प्रयोग गर्नुहोस्। )।

सिद्धान्तहरू एकसाथ जोड्ने

यस अध्यायमा छलफल गरिएका सिद्धान्तहरूलाई अनुगमन र सचेत गर्ने दर्शनमा जोड्न सकिन्छ जुन Google SRE टोलीहरूद्वारा अनुमोदित र पछ्याइएको छ। यस अनुगमन दर्शनको पालना गर्न वांछनीय छ, यो सचेत पद्धति सिर्जना वा परिमार्जन गर्नको लागि राम्रो सुरुवात बिन्दु हो, र तपाइँको संगठनको आकार वा सेवा वा प्रणालीको जटिलतालाई ध्यान नदिई तपाइँलाई सञ्चालनमा सही प्रश्नहरू सोध्न मद्दत गर्न सक्छ।

अनुगमन र चेतावनी नियमहरू सिर्जना गर्दा, निम्न प्रश्नहरू सोध्दा तपाईंलाई गलत सकारात्मक र अनावश्यक अलर्टहरूबाट बच्न मद्दत गर्न सक्छ:

• के यो नियमले अत्यावश्यक, कल टु एक्शन, र अनिवार्य रूपमा प्रयोगकर्तालाई प्रभाव पार्ने अन्यथा पत्ता लगाउन नसकिने प्रणाली अवस्था पत्ता लगाउँछ?
• के म यो चेतावनी बेवास्ता गर्न सक्छु कि यो सौम्य छ भनेर थाहा छ? कहिले र किन म यो चेतावनीलाई बेवास्ता गर्न सक्छु र म कसरी यस परिदृश्यबाट बच्न सक्छु?
• के यो अलर्टको मतलब प्रयोगकर्ताहरू प्रतिकूल रूपमा प्रभावित भइरहेका छन्? के त्यहाँ परिस्थितिहरू छन् जहाँ प्रयोगकर्ताहरू नकारात्मक रूपमा प्रभावित हुँदैनन्, उदाहरणका लागि, ट्राफिक फिल्टरिङको कारणले वा परीक्षण प्रणालीहरू प्रयोग गर्दा, सतर्कताहरू जसमा फिल्टर गर्नुपर्छ?
• के म यो चेतावनीको प्रतिक्रियामा कारबाही गर्न सक्छु? के यी उपायहरू अत्यावश्यक छन् वा तिनीहरू बिहानसम्म पर्खन सक्छन्? के यो कार्य स्वचालित गर्न सुरक्षित छ? यो कार्य दीर्घकालीन समाधान हो कि अल्पकालीन समाधान?
• केही व्यक्तिहरूले यस मुद्दाको लागि धेरै अलर्टहरू प्राप्त गर्छन्, त्यसैले यो संख्या घटाउन सम्भव छ?

यी प्रश्नहरूले अलर्ट र अलर्ट प्रणालीहरूमा आधारभूत दर्शनलाई प्रतिबिम्बित गर्दछ:

• हरेक पटक अलर्ट आउँछ, मैले तुरुन्तै प्रतिक्रिया दिनु पर्छ। म थकित हुनु अघि दिनमा धेरै पटक हतार गर्न सक्छु।
• प्रत्येक अलर्ट अप टु डेट हुनुपर्छ।
• चेतावनीको प्रत्येक प्रतिक्रियालाई मानव हस्तक्षेप आवश्यक पर्दछ। यदि सूचना स्वचालित रूपमा प्रशोधन गर्न सकिन्छ भने, यो आउनु हुँदैन।
• अलर्टहरू कुनै नयाँ मुद्दा वा पहिले नभएको घटनाको बारेमा हुनुपर्छ।

यो दृष्टिकोणले केही भिन्नताहरूलाई धमिलो पार्छ: यदि चेतावनीले अघिल्लो चार सर्तहरू पूरा गर्छ भने, यो अलर्ट व्हाइट-बक्स निगरानी प्रणाली वा ब्ल्याक-बक्सबाट पठाइएको हो भने फरक पर्दैन। यस दृष्टिकोणले केही भिन्नताहरूलाई पनि सुदृढ बनाउँछ: कारणहरू भन्दा लक्षणहरू पहिचान गर्न धेरै प्रयासहरू खर्च गर्नु राम्रो हुन्छ। जब यो कारणहरु को लागी आउँछ, तपाईले केवल अपरिहार्य कारणहरु को बारे मा चिन्ता गर्न आवश्यक छ।

दीर्घकालीन निगरानी

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

यो महत्त्वपूर्ण छ कि दीर्घकालीन लक्ष्यहरूलाई ध्यानमा राखेर अनुगमन निर्णयहरू गरिन्छ। आज चल्ने हरेक सतर्कताले व्यक्तिलाई भोलि प्रणालीमा सुधार गर्नबाट टाढा लैजान्छ, त्यसैले दीर्घकालीन रूपमा अनुगमन प्रणाली सुधार गर्न लाग्ने समयको लागि उत्पादक प्रणालीको उपलब्धता वा कार्यसम्पादनमा अक्सर कमी आउँछ। यस घटनालाई चित्रण गर्ने दुईवटा उदाहरणहरू हेरौं।

Bigtable SRE: ओभर-अलर्टको बारेमा कथा

Google को आन्तरिक पूर्वाधार सामान्यतया प्रदान गरिन्छ र सेवा स्तर (SLO) को सर्तमा मापन गरिन्छ। वर्षौं पहिले, Bigtable सेवाको SLO चलिरहेको ग्राहकको अनुकरण गर्ने सिंथेटिक लेनदेनको औसत प्रदर्शनमा आधारित थियो। Bigtable मा समस्याहरू र भण्डारण स्ट्याकको तल्लो तहको कारणले गर्दा, औसत प्रदर्शन "ठूलो" पुच्छरद्वारा संचालित थियो: सबैभन्दा खराब 5% क्वेरीहरू प्रायः बाँकी भन्दा धेरै ढिलो थिए।

इमेल सूचनाहरू पठाइयो जब SLO थ्रेसहोल्ड नजिक थियो, र मेसेन्जर अलर्टहरू पठाइयो जब SLO नाघ्यो। इन्जिनियरिङ समयको अस्वीकार्य मात्रा उपभोग गर्दै, दुबै प्रकारका अलर्टहरू प्रायः प्रायः पठाइयो: टोलीले वास्तवमा सान्दर्भिक भएका केही फेला पार्न अलर्टहरू पार्स गर्न महत्त्वपूर्ण समय खर्च गर्यो। हामीले प्रायः प्रयोगकर्ताहरूलाई असर गर्ने एउटा मुद्दा छुटेका छौं किनभने केही अलर्टहरू मात्र त्यो विशेष मुद्दाका लागि थिए। धेरै अलर्टहरू बुझ्न सकिने पूर्वाधार समस्याहरूको कारणले अत्यावश्यक थिएनन् र मानक तरिकामा ह्यान्डल गरिएका थिए, वा पटक्कै ह्यान्डल गरिएको थिएन।

स्थितिको समाधान गर्न, टोलीले तीन-पक्षीय दृष्टिकोण प्रयोग गर्‍यो: Bigtable को प्रदर्शन सुधार गर्न कडा मेहनत गर्दा, हामीले हाम्रो SLO लक्ष्यको रूपमा प्रश्न प्रतिक्रिया ढिलाइको लागि अस्थायी रूपमा 75 औं प्रतिशत सेट गर्यौं। हामीले इमेल अलर्टहरू पनि बन्द गर्यौं, किनकि तिनीहरूमध्ये धेरै थिए कि तिनीहरूलाई निदान गर्न समय बर्बाद गर्न असम्भव थियो।

यो रणनीतिले हामीलाई बिगटेबल र भण्डारण स्ट्याकको तल्लो तहहरूमा रणनीतिक मुद्दाहरू निरन्तर फिक्स गर्नुको सट्टा दीर्घकालीन समस्याहरू फिक्स गर्न सुरु गर्न एक सास फेर्न अनुमति दियो। ईन्जिनियरहरूले वास्तवमा काम गर्न सक्थे जब तिनीहरू सबै समय अलर्टहरू बमबारी गर्दैनन्। अन्ततः, अलर्टहरू प्रशोधन गर्नमा अस्थायी ढिलाइले हामीलाई सेवाको गुणस्तर सुधार गर्न अनुमति दियो।

जीमेल: अनुमानित, एल्गोरिदमिक मानव प्रतिक्रियाहरू

प्रारम्भमा, जीमेल एक परिमार्जित कार्यक्यु प्रक्रिया नियन्त्रण प्रणालीमा बनाइएको थियो जुन ब्याच प्रक्रिया खोज अनुक्रमणिका टुक्राहरूको लागि सिर्जना गरिएको थियो। Workqueue लाई लामो समयसम्म चल्ने प्रक्रियाहरूमा अनुकूलित गरियो र पछि Gmail मा लागू गरियो, तर अपारदर्शी शेड्यूलर कोडमा केही बगहरू समाधान गर्न धेरै गाह्रो साबित भयो।

त्यस समयमा, Gmail अनुगमनलाई कार्यक्यु प्रयोग गरेर व्यक्तिगत कार्यहरू रद्द गर्दा अलर्टहरू सक्रिय हुने गरी संरचना गरिएको थियो। यो दृष्टिकोण आदर्श थिएन, किनकि त्यो समयमा पनि Gmail ले हजारौं कार्यहरू गरेको थियो, जसमध्ये प्रत्येक हाम्रा प्रयोगकर्ताहरूको एक प्रतिशतको अंशलाई दिइएको थियो। हामीले Gmail प्रयोगकर्ताहरूसँग राम्रो प्रयोगकर्ता अनुभव छ भनी सुनिश्चित गर्न ठूलो ख्याल राख्यौं, तर धेरै अलर्टहरू ह्यान्डल गर्ने प्रश्न बाहिर थियो।

यस समस्याको समाधान गर्न, Gmail SRE ले प्रयोगकर्ताहरूमा पर्न सक्ने प्रभावलाई सकेसम्म राम्रोसँग डिबग गर्न मद्दतको लागि एउटा उपकरण सिर्जना गर्‍यो। टोलीले समस्याको खोजीदेखि दिर्घकालिन समाधान नआएसम्म सम्पूर्ण चक्रलाई मात्रै स्वचालित गर्ने कि नगर्ने भन्ने विषयमा धेरै छलफल भएको थियो, तर कतिपयले यस्तो समाधानले समस्याको वास्तविक समाधानमा ढिलाइ हुने चिन्ता व्यक्त गरेका थिए।

यस्तो तनाव टोली भित्र सामान्य थियो र प्रायः आत्म-अनुशासनको अविश्वासलाई प्रतिबिम्बित गर्दछ: जबकि केही टोली सदस्यहरू उचित समाधानको लागि समय दिन चाहन्छन्, अरूहरू चिन्ता गर्छन् कि अन्तिम फिक्स बिर्सिनेछ र अस्थायी फिक्स सदाको लागि लिनेछ। यो समस्या ध्यानको योग्य छ, किनकि स्थायी समाधान गर्नुको सट्टा अस्थायी रूपमा समस्याहरू समाधान गर्न धेरै सजिलो छ। प्रबन्धकहरू र प्राविधिक कर्मचारीहरूले प्रारम्भिक दुखाइ कम हुँदा पनि सम्भावित रूपमा दीर्घकालीन दीर्घकालीन फिक्सहरूलाई समर्थन र प्राथमिकता दिएर दीर्घकालीन समाधानहरूको कार्यान्वयनमा महत्त्वपूर्ण भूमिका खेल्छन्।

नियमित आवर्ती अलर्टहरू र एल्गोरिदमिक प्रतिक्रियाहरू रातो झण्डा हुनुपर्छ। यी अलर्टहरू स्वचालित गर्न तपाईंको टोलीको अनिच्छुकताको मतलब टोलीले एल्गोरिदमहरूमा विश्वास गर्न सक्छ भन्ने विश्वासको कमी छ। यो एक गम्भीर समस्या हो जसलाई सम्बोधन गर्न आवश्यक छ।

लामो अवधि

एउटा साझा विषयवस्तुले Bigtable र Gmail उदाहरणहरूलाई लिङ्क गर्दछ: छोटो अवधि र दीर्घकालीन उपलब्धता बीचको प्रतिस्पर्धा। प्रायः एक बलियो प्रयासले कमजोर प्रणालीलाई उच्च उपलब्धता हासिल गर्न मद्दत गर्न सक्छ, तर यो मार्ग सामान्यतया छोटो समयको हुन्छ, टोली बर्नआउट र यही वीर टोलीका सदस्यहरूको सानो संख्यामा निर्भरताले भरिएको हुन्छ।

उपलब्धतामा नियन्त्रित, छोटो अवधिको गिरावट अक्सर पीडादायी हुन्छ, तर प्रणालीको दीर्घकालीन स्थिरताका लागि रणनीतिक रूपमा महत्त्वपूर्ण हुन्छ। प्रत्येक अलर्टलाई अलगावमा विचार नगर्नु महत्त्वपूर्ण छ, तर अलर्टहरूको समग्र दरले एक सक्षम टोली र अनुकूल पूर्वानुमानको साथ एक स्वस्थ, उचित रूपमा पहुँचयोग्य प्रणालीमा लैजान्छ कि भनेर विचार गर्न महत्त्वपूर्ण छ। हामी व्यवस्थापनसँग त्रैमासिक रिपोर्टहरूमा सतर्कता दर तथ्याङ्कहरू (सामान्यतया प्रति शिफ्ट घटनाहरूको रूपमा व्यक्त गरिन्छ, जहाँ घटनामा धेरै सम्बन्धित घटनाहरू समावेश हुन सक्छन्) विश्लेषण गर्छौं, जसले निर्णयकर्ताहरूलाई सतर्क प्रणाली लोड र समग्र टोली स्वास्थ्यलाई निरन्तर प्रस्तुत गर्न अनुमति दिन्छ।

निष्कर्षमा

स्वस्थ अनुगमन र अलर्ट को मार्ग सरल र सीधा छ। यसले समस्याका लक्षणहरूमा फोकस गर्छ जसको लागि अलर्टहरू उत्पन्न हुन्छन्, र कारणको निगरानीले समस्याहरू डिबग गर्न मद्दतको रूपमा कार्य गर्दछ। तपाईले नियन्त्रण गर्ने स्ट्याकमा जति माथि हुनुहुन्छ लक्षण अनुगमन सजिलो हुन्छ, यद्यपि डाटाबेस लोड र कार्यसम्पादन अनुगमन डाटाबेसमा नै सिधै गरिनुपर्छ। इमेल अधिसूचनाहरू धेरै सीमित प्रयोगका हुन्छन् र सजिलै आवाजमा बढ्छ; यसको सट्टा, तपाईंले ड्यासबोर्ड प्रयोग गर्नुपर्छ जसले सबै हालका समस्याहरूलाई इमेलद्वारा सचेत गराउँछ। ऐतिहासिक सहसम्बन्धहरू विश्लेषण गर्न ड्यासबोर्डलाई घटना लगसँग जोड्न सकिन्छ।

दीर्घकालीन रूपमा, लक्षण सतर्कताहरू र आसन्न वास्तविक समस्याहरू बीचको सफल परिवर्तन हासिल गर्न आवश्यक छ, र अनुगमनले द्रुत निदानलाई समर्थन गर्दछ भनी सुनिश्चित गर्न लक्ष्यहरू अनुकूलित गर्नुपर्छ।

अनुवाद अन्त्यमा पढ्नुभएकोमा धन्यवाद। अनुगमनको बारेमा मेरो टेलिग्राम च्यानलको सदस्यता लिनुहोस् @monitorim_it и मध्यम मा ब्लग.

स्रोत: www.habr.com