निगरानी का विशिष्ट कार्यान्वयन। निकोले शिवको

निकोले सिवको की रिपोर्ट "मॉनिटरिंग का विशिष्ट कार्यान्वयन" का डिकोडिंग।

मेरा नाम निकोलाई सिवको है। मैं मॉनिटरिंग भी करता हूं। ओकेमीटर 5 मॉनिटरिंग है जो मैं करता हूं। मैंने फैसला किया कि मैं सभी लोगों को निगरानी के नरक से बचाऊंगा और हम किसी को इस पीड़ा से बचाएंगे। मैं हमेशा अपनी प्रस्तुतियों में ओकेमीटर का विज्ञापन नहीं करने की कोशिश करता हूं। स्वाभाविक रूप से, चित्र वहीं से होंगे। लेकिन जो मैं बताना चाहता हूं वह यह है कि हम हर किसी की तुलना में थोड़ा अलग दृष्टिकोण की निगरानी करते हैं। हम इस बारे में बहुत बात करते हैं। जब हम इसमें प्रत्येक व्यक्ति को समझाने की कोशिश करते हैं, तो अंत में वह आश्वस्त हो जाता है। मैं हमारे दृष्टिकोण के बारे में ठीक से बात करना चाहता हूं ताकि यदि आप स्वयं मॉनिटरिंग करें, ताकि आप हमारे रेक से बचें।

संक्षेप में ओकेमीटर के बारे में। हम आपके जैसे ही करते हैं, लेकिन सभी प्रकार के चिप्स हैं। चिप्स:

• विवरण रहता है;
• बड़ी संख्या में पूर्व-कॉन्फ़िगर ट्रिगर जो हमारे ग्राहकों की समस्याओं पर आधारित हैं;
• ऑटो कॉन्फ़िगरेशन

एक विशिष्ट ग्राहक हमारे पास आता है। उसके दो कार्य हैं:

1) यह समझने के लिए कि सब कुछ निगरानी से टूट गया, जब कुछ भी नहीं है।

2) जल्दी से इसे ठीक करें।

वह उसके जवाबों की निगरानी करने आता है कि उसके साथ क्या हो रहा है।

जिन लोगों के पास कुछ नहीं है, उनमें से पहली चीज़ https://www.pPN.com/ और अन्य सेवाएं सत्यापन के लिए रखी गई हैं। इस घोल का फायदा यह है कि इसे 5 मिनट में किया जा सकता है। अब आप ग्राहक कॉल से समस्या के बारे में नहीं जान पाएंगे। सटीकता के साथ समस्याएं हैं ताकि वे समस्याओं को छोड़ दें। लेकिन सरल साइटों के लिए, यह पर्याप्त है।

दूसरी बात जो हम वकालत करते हैं वह वास्तविक उपयोगकर्ताओं के आंकड़ों के अनुसार लॉग द्वारा गिनना है। यह है कि किसी विशेष उपयोगकर्ता को 5xx त्रुटियाँ कितनी मिलती हैं। उपयोगकर्ताओं द्वारा प्रतिक्रिया समय क्या है। नुकसान हैं, लेकिन सामान्य तौर पर, ऐसा काम करता है।

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

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

हम वहाँ से क्या खींच रहे हैं? व्यवहार में, हम ऐसे आयामों में मैट्रिक्स लेते हैं। ये फ्लैट मेट्रिक्स नहीं हैं। मीट्रिक को index.request.rate - प्रति सेकंड क्वेरी की संख्या कहा जाता है। यह इसके द्वारा विस्तृत है:

• वह होस्ट जिससे आपने लॉग निकाले थे;
• वह लॉग जिससे यह डेटा लिया गया था;
• http विधि द्वारा;
• http स्थिति;
• कैश की स्थिति।

यह सभी तर्कों के साथ प्रत्येक विशिष्ट URL नहीं है। हम लॉग से 100,000 मीट्रिक निकालना नहीं चाहते हैं।

हम 1000 मेट्रिक्स लेना चाहते हैं। इसलिए, यदि संभव हो तो हम URL को सामान्य करने का प्रयास कर रहे हैं। शीर्ष URL लें। और सार्थक होने वाले URL के लिए, हम एक अलग बार ग्राफ दिखाते हैं, अलग से 5xx।

यहाँ एक उदाहरण दिया गया है कि कैसे यह साधारण मीट्रिक प्रयोग करने योग्य ग्राफिक्स में बदल जाता है। यह शीर्ष पर हमारा डीएसएल है। मैंने अनुमानित तर्क समझाने के लिए इस DSL की कोशिश की। हमने प्रति सेकंड सभी nginx के अनुरोध को लिया और उन्हें उन सभी मशीनों पर रखा, जो हमारे पास हैं। हमें इस बारे में ज्ञान है कि हम इसे कैसे संतुलित करते हैं, हमारे पास कुल आरपीएस (प्रति सेकंड अनुरोध, प्रति सेकंड अनुरोध) है।

दूसरी ओर, हम इस मीट्रिक को फ़िल्टर कर सकते हैं और केवल 4xx दिखा सकते हैं। 4xx चार्ट पर, उन्हें वास्तविक स्थिति के अनुसार रखा जा सकता है। मैं आपको याद दिलाता हूं कि यह वही मीट्रिक है।

ग्राफ पर, आप URL द्वारा 4xx दिखा सकते हैं। यह वही मेट्रिक है।

हम लॉग से हिस्टोग्राम भी शूट करते हैं। हिस्टोग्राम प्रतिक्रिया_टाइम.इस्ट्रोग्राम मीट्रिक है, जो वास्तव में अतिरिक्त स्तर के पैरामीटर के साथ आरपीएस है। यह केवल समय की कटौती है जिसमें बाल्टी को अनुरोध मिलता है।

हम एक अनुरोध आकर्षित करते हैं: पूरे हिस्टोग्राम को संक्षिप्त करें और इसे स्तरों में क्रमबद्ध करें:

• धीरे-धीरे निवेदन
• त्वरित अनुरोध;
• औसत प्रश्न;

हमारे पास एक तस्वीर है जो पहले से ही सर्वर द्वारा सम्‍मिलित है। मीट्रिक वही है। इसका भौतिक अर्थ समझ में आता है। लेकिन हम इसका पूरी तरह से अलग तरीके से फायदा उठाते हैं।

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

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

यह समझने के कार्य के साथ कि साइट काम कर रही है या नहीं, मेरा मानना ​​है कि हमारे पास कम या ज्यादा हल है। त्रुटियां हैं। अशुद्धि हैं। सामान्य सिद्धांत इस प्रकार हैं।

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

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

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

• यह संसाधन कितना खाता है?
• क्या हम किसी भी सीमा में टकरा रहे हैं?
• रनटाइम के साथ क्या हो रहा है? उदाहरण के लिए, जेवीएम रनटाइम प्लेटफॉर्म, गोलंग रनटाइम और अन्य रनटाइम।
• जब हम पहले से ही यह सब कवर कर चुके हैं, तो यह हमारे लिए दिलचस्प है कि हम पहले से ही अपने कोड के करीब हैं। हम या तो स्वचालित इंट्रामेट्री (स्टैटसड, * -मेट्रिक) का उपयोग कर सकते हैं, जो हमें यह सब दिखाएगा। या टाइमर, काउंटर आदि सेट करके खुद को निर्देश दें।

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

स्मृति के लिए वही जाता है। जब हम इसे इस तरह खींचते हैं। हम Python RSS का चयन करते हैं (RSS ऑपरेटिंग सिस्टम द्वारा प्रक्रिया के लिए आवंटित स्मृति पृष्ठों का आकार है और वर्तमान में RAM में स्थित है)। मेजबान द्वारा योग। हम स्मृति प्रवाह कहीं नहीं देखते हैं। हर जगह स्मृति समान रूप से वितरित की जाती है। सिद्धांत रूप में, हमें अपने सवालों का जवाब मिला।

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

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

जब हम इंस्ट्रूमेंटेशन के बारे में बात करते हैं, तो सभी प्रकार के टूल जैसे http://pinba.org/ for php आते हैं। Pinba, Badoo से php के लिए एक एक्सटेंशन है, जिसे आप php पर इंस्टॉल और कनेक्ट करते हैं। यह आपको तुरंत UDP पर प्रोटॉब को हटाने और भेजने की अनुमति देता है। उनके पास एक पिनबा सर्वर है। लेकिन हमने एजेंट में एक एम्बेडेड पिनबा सर्वर बनाया। PHP स्वयं को भेजता है कि उसने ऐसी स्क्रिप्ट के लिए CPU और मेमोरी को कितना खर्च किया, इस तरह की स्क्रिप्ट द्वारा कितना ट्रैफ़िक दिया जाता है, और इसी तरह। यहाँ पिनाबा के साथ एक उदाहरण दिया गया है। हम सीपीयू खपत पर शीर्ष 5 स्क्रिप्ट दिखाते हैं। हम एक वायलेट बाहरी रूप से देखते हैं जो PHP का एक स्मियरड पॉइंट है। हम PHP के स्मियर किए गए बिंदु को सुधारने या यह समझने के लिए जा रहे हैं कि यह सीपीयू को क्यों खाता है। हमने समस्या के दायरे को पहले ही कम कर दिया है ताकि हम निम्नलिखित चरणों को समझ सकें। हम कोड को देखने और उसकी मरम्मत करने जाते हैं।

वही ट्रैफिक के लिए जाता है। हम शीर्ष 5 ट्रैफ़िक स्क्रिप्ट देखते हैं। अगर यह हमारे लिए महत्वपूर्ण है, तो हम जाकर समझें।

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

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

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

संसाधनों के बारे में। उसी तरह, हम देखते हैं कि हमारी डिस्क पर MySQL प्रक्रिया कितनी उत्पन्न होती है। हम देखते हैं कि औसतन बहुत कुछ है, लेकिन कुछ चोटियां होती हैं। उदाहरण के लिए, बहुत सारी प्रविष्टियाँ आती हैं और यह 15.15, 16.15, 17.15 पर डिस्क पर लिखना शुरू करती है।

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

मांग पर संसाधन। यह इतना आसान नहीं है। आधार पर निर्भर करता है। आधार को अपने बारे में बताने में सक्षम होना चाहिए: यह किन संसाधनों को खर्च करता है, आदि। इसमें नेता PostgreSQL है। उसके पास pg_stat_statements हैं। आप समझ सकते हैं कि आपके पास सीपीयू का उपयोग करने के लिए किस तरह का अनुरोध है, डिस्क और ट्रैफ़िक पढ़ें और लिखें।

MySQL में, ईमानदार होने के लिए, सब कुछ बहुत खराब है। इसमें performance_schema है। यह किसी तरह से 5.7 संस्करण से काम करता है। PostgreSQL के एक दृश्य के विपरीत, प्रदर्शन_कासा MySQL में एक 27 या 23 सिस्टम व्यू टेबल है। कभी-कभी, यदि आप गलत तालिकाओं (गलत दृष्टिकोण पर) पर प्रश्न बनाते हैं, तो आप MySQL को रोक सकते हैं।

रेडिस के पास टीम के आंकड़े हैं। आप देखते हैं कि एक निश्चित कमांड CPU का बहुत उपयोग करता है, आदि।

कैसंड्रा में विशिष्ट तालिकाओं को क्वेरी करने के लिए समय है। लेकिन चूंकि कैसेंड्रा को डिज़ाइन किया गया है ताकि एक प्रकार की क्वेरी तालिका में बनाई जाए, यह निगरानी के लिए पर्याप्त है।

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

कैसेंड्रा। हम कुल प्रतिक्रिया समय के अनुसार पढ़ने के अनुरोध के लिए शीर्ष 5 तालिकाओं को देखते हैं। हम इस उछाल को देखते हैं। ये तालिका के लिए प्रश्न हैं, और हम मोटे तौर पर समझते हैं कि इस तालिका के लिए एक क्वेरी कोड का एक टुकड़ा बनाती है। कैसंड्रा एक SQL डेटाबेस नहीं है जिसमें हम तालिकाओं पर विभिन्न प्रश्न बना सकते हैं। कैसंड्रा तेजी से विकराल होता जा रहा है।

वर्कफ़्लो के बारे में कुछ शब्द घटनाओं के साथ काम करते हैं। जैसा कि मैं इसे देखता हूं।

अलर्ट के बारे में। घटना के वर्कफ़्लो के बारे में हमारा दृष्टिकोण आमतौर पर स्वीकार किए जाने वाले से अलग है।

सीवियर क्रिटिकल। हम आपको एसएमएस और सभी वास्तविक समय संचार चैनलों के माध्यम से सूचित करते हैं।

सीवरी इंफो एक लाइट बल्ब है जो घटनाओं के साथ काम करने पर आपकी कुछ मदद कर सकता है। जानकारी कहीं भी अधिसूचित नहीं की गई है। जानकारी बस हैंग करती है और आपको बताती है कि कुछ हो रहा है।

सीवरी वार्निंग एक ऐसी चीज है जिसे अधिसूचित किया जा सकता है, शायद नहीं।

गंभीर उदाहरण।

साइट बिल्कुल काम नहीं करती है। उदाहरण के लिए, 5xx 100% या प्रतिक्रिया समय बढ़ गया है और उपयोगकर्ताओं को छोड़ना शुरू हो गया है।

व्यापार तर्क त्रुटियों। क्रिटिकल क्या है। प्रति सेकंड पैसे को मापना आवश्यक है। क्रिटिकल के लिए धन प्रति सेकंड डेटा का एक अच्छा स्रोत है। उदाहरण के लिए, आदेशों की संख्या, विज्ञापनों का प्रचार और अन्य।

क्रिटिकल के साथ वर्कफ़्लो ऐसे कि इस घटना को स्थगित नहीं किया जा सकता है। आप ठीक क्लिक नहीं कर सकते और घर जा सकते हैं। यदि क्रिटिकल आपके पास आया और आप मेट्रो ले रहे हैं, तो आपको मेट्रो से बाहर निकलना होगा, बाहर जाना होगा, बेंच लेना होगा और मरम्मत शुरू करनी होगी। अन्यथा, यह महत्वपूर्ण नहीं है। इन विचारों से, हम अवशिष्ट विशेषता के लिए शेष गंभीरता का निर्माण करते हैं।

चेतावनी। चेतावनी के उदाहरण।

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

अन्य सभी सेवरी आपको क्रिटिकल से निपटने में मदद करने के लिए डिज़ाइन किए गए हैं।

चेतावनी। हम चेतावनी के साथ काम करने के लिए इस दृष्टिकोण की वकालत करते हैं। अधिमानतः दिन के दौरान चेतावनी बंद करें। हमारे अधिकांश ग्राहकों ने चेतावनी अधिसूचना अक्षम कर दी है। इस प्रकार, उनके पास तथाकथित निगरानी अंधापन नहीं है। इसका अर्थ है एक अलग निर्देशिका को पढ़े बिना मेल में अक्षरों को मोड़ना। ग्राहकों ने चेतावनी चेतावनी को अक्षम कर दिया है।

(जैसा कि मैं इसे समझता हूं, शुद्ध निगरानी अनावश्यक अलर्ट है और ट्रिगर अपवादों में जोड़े गए हैं - पोस्ट के लेखक द्वारा ध्यान दें)

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

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

चेतावनी (शायद मुझे जानकारी दिखती है - पोस्ट के लेखक द्वारा एक नोट) ये वे लाइट हैं जो क्रिटिकल को सुधारने के लिए आती हैं। आप दो चेतावनी के संकेत को साथ-साथ देखते हैं (हो सकता है कि कोई जानकारी लिंक हो - पोस्ट के लेखक द्वारा नोट करें)। वे क्रिटिकल के साथ घटना को सुलझाने में आपकी मदद कर सकते हैं। एसएमएस या पत्र में उच्च सीपीयू उपयोग के बारे में स्पष्ट क्यों नहीं है।

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

अलर्ट डिजाइन के लिए सामान्य सिद्धांत। अलर्ट का कारण बताना चाहिए। यह एकदम सही है। लेकिन इसे हासिल करना मुश्किल है। यहां हम कार्य पर पूर्ण समय काम कर रहे हैं और यह सफलता के कुछ हिस्से के साथ निकलता है।

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

(यहां वीडियो छोड़ दिया - पोस्ट के लेखक द्वारा नोट)

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

• आदमी बनाया
• छात्रावास की स्थापना की
• बॉट आ गए

यदि आप उन्हें वर्गीकृत करते हैं, तो हर कोई खुश होगा।

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

• इस तरह के तर्क को बैकएंड में लिखने के लिए दो लोगों को एक चौथाई समय लगता है।
• अधिक प्रतिकृतियां डालने की जरूरत है।

यह सुनिश्चित करना आवश्यक है कि ठीक वही घटना न घटे। जब आप एन पुनरावृत्तियों के माध्यम से इस तरह के वर्कफ़्लो में काम करते हैं, तो खुशी आपको इंतजार करती है, अच्छा अपटाइम।

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

हमने गणना की कि हम कितने समय के लिए लेटे हैं, उदाहरण के लिए हॉस्टल के कारण 90%। हम चार्ज करते हैं कि हम इस होस्ट को बदल दें। अगर लोग हमारे साथ खिलवाड़ करते हैं, तो हम उन्हें पाठ्यक्रमों में भेजते हैं। , - — . . , . , .

. :

• .
• .

, , . , , .

: , . : , , . False Positive ( ), , . ?

: . 10- frontend , . 9 frontend nginx, 10- , warning alert . . , . . .

: . , , load avarage 4 , - load avarage 20 .

: load avarage. 100 . CPU usage Hadoop . . . . , , . PostgreSQL autovacuum, worker autovacuum . 99 . Warning . Critical . Critical 10 5 , Critical.

प्रश्न: किस सीमा पर और कैसे निर्धारित किया जाता है? यह कौन कर रहा है?

उत्तर: आप हमारे पास आते हैं और कहते हैं: हम अपने प्रोजेक्ट के कुछ क्रिटिकल पूछना चाहते हैं। यदि आप प्रति सेकंड 10 5xx डालते हैं, तो आपको एक सप्ताह पहले कितनी सूचनाएं प्राप्त होंगी।

प्रश्न: इस सभी अच्छी निगरानी का बोझ क्या है?

उत्तर: औसतन, यह आमतौर पर अदृश्य होता है। लेकिन अगर आप 50,000 आरपीएस को पार्स करते हैं तो यह एक सीपीयू के 1% से 10% तक होगा। चूंकि हम केवल निगरानी कर रहे हैं, हमने अपने एजेंट को अनुकूलित किया। हम एजेंट के प्रदर्शन को मापते हैं। यदि आपके पास सर्वर पर निगरानी रखने के लिए संसाधन नहीं हैं, तो आप कुछ गलत कर रहे हैं। निगरानी के लिए हमेशा संसाधन होने चाहिए। यदि आप नहीं करते हैं, तो आप अपनी परियोजना को संचालित करने के लिए स्पर्श के रूप में अंधे होंगे।