क्या निगरानी मृत है? - लंबे समय तक निगरानी

2008 से, हमारी कंपनी मुख्य रूप से वेब परियोजनाओं के लिए बुनियादी ढांचे के प्रबंधन और चौबीसों घंटे तकनीकी सहायता में लगी हुई है: हमारे पास 400 से अधिक ग्राहक हैं, जो रूस में लगभग 15% ई-कॉमर्स है। तदनुसार, एक बहुत ही विविध वास्तुकला का समर्थन किया जाता है। अगर कुछ गिरता है, तो हमें इसे 15 मिनट के भीतर ठीक करना होगा। लेकिन यह समझने के लिए कि दुर्घटना हुई है, आपको परियोजना की निगरानी करने और घटनाओं पर प्रतिक्रिया देने की आवश्यकता है। यह कैसे करना है?

मेरा मानना ​​है कि सही निगरानी प्रणाली का संगठन मुश्किल में है। यदि कोई परेशानी नहीं थी, तो मेरे भाषण में एक थीसिस शामिल थी: "कृपया प्रोमेथियस + ग्राफाना और प्लगइन्स 1, 2, 3 स्थापित करें।" दुर्भाग्य से, यह अब काम नहीं करता है। और मुख्य समस्या यह है कि हर कोई सॉफ़्टवेयर घटकों के संदर्भ में 2008 में मौजूद कुछ पर विश्वास करना जारी रखता है।

निगरानी प्रणाली के संगठन के बारे में, मैं यह कहते हुए जोखिम उठाता हूं कि ... सक्षम निगरानी वाली परियोजनाएं मौजूद नहीं हैं। और स्थिति इतनी खराब है कि अगर कुछ गिरता है, तो एक जोखिम है कि यह किसी का ध्यान नहीं जाएगा - हर किसी को यकीन है कि "सब कुछ मॉनिटर किया जा रहा है"।
शायद हर चीज पर नजर रखी जा रही है। लेकिन कैसे?

हम सभी निम्नलिखित के समान एक कहानी में आए थे: एक निश्चित डेवूप, एक निश्चित व्यवस्थापक काम कर रहा है, एक विकास टीम उनके पास आती है और कहती है, "हमें यह मिल गया है, अब इसकी निगरानी की जाती है।" क्या निगरानी? यह कैसे काम करता है?

लगभग। हम पुराने ढंग से निगरानी करते हैं। लेकिन यह पहले से ही बदल रहा है, और यह पता चला है कि आपने सेवा ए की निगरानी की, जो सेवा बी बन गया, जो सेवा सी के साथ बातचीत करता है। लेकिन विकास टीम आपसे कहती है: "सॉफ़्टवेयर स्थापित करें, इसे सब कुछ मॉनिटर करना होगा!"

तो क्या बदल गया है? - सब कुछ बदल गया है!

2008 साल। सब कुछ ठीक है

डेवलपर्स के एक जोड़े, एक सर्वर, एक डेटाबेस सर्वर हैं। यहां से सब कुछ चलता है। हमारे पास कुछ infa हैं, हम zabbix, Nagios, cacti डालते हैं। और फिर हम सीपीयू पर डिस्क के स्थान पर, डिस्क के संचालन पर स्पष्ट अलर्ट सेट करते हैं। हम मैन्युअल चेक के एक जोड़े को भी करते हैं जो साइट का उत्तर देता है कि ऑर्डर डेटाबेस पर आते हैं। और यह बात है - हम अधिक या कम संरक्षित हैं।

यदि हम उस काम की मात्रा की तुलना करते हैं जो व्यवस्थापक ने निगरानी सुनिश्चित करने के लिए किया था, तो यह 98% स्वचालित था: निगरानी करने वाले व्यक्ति को यह समझना चाहिए कि ज़ैबिक्स को कैसे स्थापित किया जाए, इसे कैसे कॉन्फ़िगर करें और अलर्ट कॉन्फ़िगर करें। और 2% - बाहरी जांच के लिए: कि साइट प्रतिक्रिया करती है और डेटाबेस से अनुरोध करती है कि नए आदेश आ गए हैं।

2010 का साल। लोड बढ़ रहा है

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

इसके अलावा, बुनियादी ढांचे से जुड़ी इकाई प्रबंधक के प्रमुख में सबसे बड़ी बनी हुई है। फिर भी यह विचार मेरे दिमाग में बैठा है कि जो व्यक्ति निगरानी कर रहा है वह वह व्यक्ति है जो ज़ैबिक्स स्थापित करेगा और इसे कॉन्फ़िगर करने में सक्षम होगा।

लेकिन साथ ही, खोज इंडेक्सर को क्वेरी करने के लिए स्क्रिप्ट्स का एक सेट बनाने पर, बाहरी जाँच करने पर भी काम होता है, स्क्रिप्ट्स का एक सेट जो यह बताता है कि इंडेक्सिंग प्रक्रिया के दौरान खोज में परिवर्तन होता है, स्क्रिप्ट का एक सेट जो यह सत्यापित करता है कि सामान डिलीवरी सेवा में स्थानांतरित हो गया है, आदि। आदि



नोट: मैंने 3 बार "स्क्रिप्ट सेट" लिखा। यही है, निगरानी के लिए जिम्मेदार व्यक्ति अब वह नहीं है जो सिर्फ zabbix स्थापित करता है। यह वह व्यक्ति है जो कोड करना शुरू करता है। लेकिन टीम के दिमाग में अभी तक कुछ भी नहीं बदला है।

लेकिन दुनिया बदल रही है, अधिक से अधिक जटिल होती जा रही है। एक वर्चुअलाइजेशन परत, कई नए सिस्टम जोड़े जाते हैं। वे आपस में बातचीत करने लगते हैं। किसने कहा "माइक्रोसेरो की स्मैक?" लेकिन प्रत्येक सेवा अभी भी व्यक्तिगत रूप से एक साइट की तरह दिखती है। हम उसकी ओर रुख कर सकते हैं और समझ सकते हैं कि वह आवश्यक जानकारी और अपने द्वारा काम करता है। और यदि आप एक व्यवस्थापक हैं जो लगातार 5-7-10 वर्षों से एक परियोजना में लगे हुए हैं, तो आपके पास यह ज्ञान जमा है: एक नया स्तर प्रकट होता है - आपको इसका एहसास हुआ, एक और स्तर दिखाई देता है - आपको इसका एहसास हुआ ...



लेकिन शायद ही कोई 10 साल के लिए इस परियोजना के साथ है।

मैन मॉनिटरिंग सारांश

मान लीजिए कि आप एक नए स्टार्टअप में आए, जिसने तुरंत 20 डेवलपर्स का स्कोर किया, 15 माइक्रोसर्विसेज लिखे, और आप वह व्यवस्थापक हैं, जिन्हें बताया गया है: "एक CI / CD बनाएँ। प्लीज। ” आपने एक CI / CD का निर्माण किया और अचानक आप सुनते हैं: "हमारे लिए" क्यूब "में उत्पादन के साथ काम करना मुश्किल है, बिना यह समझे कि इसमें आवेदन कैसे काम करेगा। हमें उसी "क्यूब" में एक सैंडबॉक्स बनाएं।
आप इस क्यूब में एक सैंडबॉक्स बनाते हैं। वे तुरंत आपको बताते हैं: "हम एक स्टेज डेटाबेस चाहते हैं, जो उत्पादन से हर दिन अपडेट किया जाता है, ताकि यह समझने के लिए कि यह डेटाबेस पर काम करता है, लेकिन एक ही समय में उत्पादन डेटाबेस को खराब न करें।"

आप सब इसमें रहते हैं। रिलीज़ होने तक 2 सप्ताह बाकी हैं, वे आपसे कहते हैं: "अब यह सब पर नजर रखी जाएगी ..." यही है मॉनिटर क्लस्टर इन्फ्रास्ट्रक्चर, माइक्रोसेवा आर्किटेक्चर की निगरानी, ​​बाहरी सेवाओं के साथ काम की निगरानी ...

और सहकर्मी इस तरह की एक परिचित योजना अपने सिर से निकालते हैं और कहते हैं: “तो यहाँ सब कुछ स्पष्ट है! एक प्रोग्राम स्थापित करें जो इसे मॉनिटर करता है। ” हां: प्रोमेथियस + ग्राफाना + प्लगइन्स।
और वे एक ही समय में जोड़ते हैं: "आपके पास दो सप्ताह हैं, सुनिश्चित करें कि सब कुछ विश्वसनीय है।"

परियोजनाओं के ढेर में जो हम देखते हैं, एक व्यक्ति को निगरानी के लिए आवंटित किया जाता है। कल्पना करें कि हम किसी व्यक्ति को मॉनिटर करने के लिए 2 सप्ताह के लिए किराए पर लेना चाहते हैं, और हम उसे फिर से शुरू करेंगे। इस व्यक्ति के पास क्या कौशल होना चाहिए - जो कुछ भी हमने पहले कहा है उसे दिया है?

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

आइए हम एक बिल्कुल सामान्य मामला याद करते हैं: php में सेवाओं का हिस्सा, Go में सेवाओं का हिस्सा, JS में सेवाओं का हिस्सा। वे किसी तरह आपस में काम करते हैं। यह वह जगह है जहां शब्द "माइक्रोसिस्ट सर्विस" से आता है: इतने सारे अलग-अलग सिस्टम हैं कि डेवलपर्स परियोजना को पूरी तरह से समझ नहीं सकते हैं। टीम का एक हिस्सा JS में ऐसी सेवाएँ लिखता है जो अपने आप काम करती हैं और यह नहीं जानती हैं कि बाकी सिस्टम कैसे काम करता है। दूसरा भाग पायथन में सेवाएं लिखता है और अन्य सेवाओं के काम करने के तरीके में नहीं जाता है, वे अपने क्षेत्र में अलग-थलग हैं। तीसरा - php या कुछ और में सेवाएं लिखते हैं।
इन सभी 20 लोगों को 15 सेवाओं में विभाजित किया गया है, और केवल एक व्यवस्थापक है जिसे यह सब समझना चाहिए। इसे रोको! हम सिस्टम को केवल 15 माइक्रोसर्विसेस में विभाजित करते हैं, क्योंकि 20 लोग पूरे सिस्टम को नहीं समझ सकते हैं।

लेकिन इसकी निगरानी किसी तरह करने की जरूरत है ...

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

मैं क्या कह सकता हूं ... ह्यूस्टन, हमें समस्याएं हैं।

आधुनिक सॉफ्टवेयर प्रोजेक्ट की निगरानी अपने आप में एक सॉफ्टवेयर प्रोजेक्ट है

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

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

और यदि आप अभी भी इसे एक मंच पर प्रशासक और डेवलपर्स को देते हैं, जब रिलीज से पहले कम समय बचा है, तो एक व्यक्ति को इस पूरे प्रोटोकॉल को समझने की आवश्यकता होगी। यानी इस पैमाने की एक परियोजना में काफी समय लगता है, और इसे सिस्टम के विकास में शामिल किया जाना चाहिए।
लेकिन बहुत बार, विशेष रूप से जलने में, स्टार्टअप्स में, हम देखते हैं कि निगरानी को बाद में कैसे बंद किया जाता है। “अब हम प्रूफ ऑफ कॉन्सेप्ट बनाएंगे, हम इसके साथ शुरुआत करेंगे, इसे गिरने देंगे - हम बलिदान के लिए तैयार हैं। और फिर हम इसकी पूरी निगरानी करेंगे। ” जब (या यदि) परियोजना पैसा बनाने के लिए शुरू होती है, तो व्यवसाय और भी अधिक सुविधाओं में कटौती करना चाहता है - क्योंकि यह काम करना शुरू कर देता है, इसलिए आपको आगे जाने की आवश्यकता है! और आप उस बिंदु पर हैं जहां शुरुआत में आपको पिछले सब कुछ की निगरानी करने की आवश्यकता होती है, जिसमें 1% समय नहीं लगता है, लेकिन बहुत अधिक। और वैसे, डेवलपर्स को निगरानी की आवश्यकता होगी, और उन्हें नई सुविधाओं में रखना आसान है। नतीजतन, नई विशेषताएं लिखी जाती हैं, सब कुछ लपेटा जाता है, और आप अंतहीन गतिरोध में हैं।

तो आप शुरू से ही एक परियोजना की निगरानी कैसे करते हैं, और क्या होगा अगर आपको एक परियोजना मिली जिसे आपको निगरानी करने की आवश्यकता है, लेकिन आप नहीं जानते कि कहां से शुरू करें?

सबसे पहले, आपको योजना बनाने की आवश्यकता है।

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

सबसे पहले, तय करें कि आप क्या और कैसे निगरानी करना चाहते हैं, और फिर साधन उठाएं, क्योंकि अन्य लोग आपके लिए नहीं सोच सकते हैं। हाँ, और उन्हें करना चाहिए? सार्वभौमिक प्रणाली के बारे में अन्य लोगों ने खुद को सोचा - या जब इस प्लगइन को लिखा गया था, तो बिल्कुल भी नहीं सोचा था। और तथ्य यह है कि इस प्लगइन के 5 हजार उपयोगकर्ता हैं इसका मतलब यह नहीं है कि यह कोई लाभ लाता है। शायद आप 5001 वें बस बन जाएंगे क्योंकि वहां पहले से ही 5,000 लोग थे।

यदि आपने बुनियादी ढांचे की निगरानी शुरू कर दी और आपके आवेदन के बैकएंड ने प्रतिक्रिया देना बंद कर दिया, तो सभी उपयोगकर्ता मोबाइल एप्लिकेशन से संपर्क खो देंगे। एक गलती उड़ जाएगी। वे आपके पास आएंगे और कहेंगे, "एप्लिकेशन काम नहीं करता है, आप यहां क्या कर रहे हैं?" "हम निगरानी कर रहे हैं।" - "यदि आप यह नहीं देखते हैं कि आवेदन कैसे काम नहीं कर रहा है तो आप कैसे निगरानी करेंगे?"

1. मेरा मानना ​​है कि उपयोगकर्ता के प्रवेश बिंदु से निगरानी शुरू करना आवश्यक है। यदि उपयोगकर्ता यह नहीं देखता है कि एप्लिकेशन काम कर रहा है - यह सब है, तो यह विफलता है। और निगरानी प्रणाली को इस बारे में पहले ही चेतावनी देनी चाहिए।
2. और उसके बाद ही हम बुनियादी ढांचे की निगरानी कर सकते हैं। या समानांतर में करते हैं। बुनियादी ढांचा सरल है - यहाँ हम अंततः सिर्फ zabbix स्थापित कर सकते हैं।
3. और अब आपको यह समझने के लिए एप्लिकेशन की जड़ों पर जाने की आवश्यकता है कि यह कहां काम नहीं करता है।

मेरा मुख्य विचार यह है कि निगरानी को विकास प्रक्रिया के समानांतर जाना चाहिए। यदि आप अन्य कार्यों के लिए निगरानी टीम को फाड़ देते हैं (एक CI / CD, सैंडबॉक्स बनाने, बुनियादी ढांचे को पुनर्गठित करते हैं), तो निगरानी पिछड़ने लगेगी और आप कभी भी विकास (या इसके बाद या बाद में इसे रोकना नहीं होगा) पकड़ सकते हैं।

सभी स्तरों द्वारा

यह है कि मैं निगरानी प्रणाली के संगठन को कैसे देखता हूं।

1) आवेदन स्तर:

• आवेदन के व्यापार तर्क की निगरानी;
• सेवाओं के स्वास्थ्य मैट्रिक्स की निगरानी करना;
• एकीकरण निगरानी।

2) इन्फ्रास्ट्रक्चर स्तर:

• ऑर्केस्ट्रेशन के स्तर की निगरानी करना;
• निगरानी प्रणाली सॉफ्टवेयर;
• "लोहे" के स्तर की निगरानी करना।

3) एक बार फिर, आवेदन स्तर - लेकिन एक इंजीनियरिंग उत्पाद के रूप में:

• आवेदन लॉग एकत्र करना और निगरानी करना;
• एपीएम;
• अनुरेखण।

4) चेतावनी:

• एक चेतावनी प्रणाली का संगठन;
• एक घड़ी प्रणाली का संगठन;
• एक "ज्ञान आधार" और वर्कफ़्लो घटना प्रसंस्करण का संगठन।

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

आवेदन परत - निगरानी व्यापार तर्क

यहां हम इस तथ्य की जांच करने के बारे में बात कर रहे हैं कि एप्लिकेशन उपयोगकर्ता के लिए काम करता है।

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

जब अक्सर यह सुनिश्चित करने के लिए कहा जाता है कि साइट काम कर रही है, तो मुख्य पृष्ठ की निगरानी करें, प्रोग्रामर एक पेन देते हैं जिसे हर बार खींचा जा सकता है ताकि आपको यह सुनिश्चित करने की आवश्यकता हो कि एपीआई काम करता है। और इस समय के प्रोग्रामर अभी भी / api / test / helloworld लिखते हैं
यह सुनिश्चित करने का एकमात्र तरीका है कि सब कुछ काम करता है? - नहीं!

• इस तरह के चेक बनाना अनिवार्य रूप से डेवलपर्स का काम है। यूनिट परीक्षण कोड लिखने वाले प्रोग्रामर द्वारा लिखे जाने चाहिए। क्योंकि यदि आप इसे व्यवस्थापक में मिलाते हैं "यार, यहाँ सभी 25 कार्यों के लिए एपीआई प्रोटोकॉल की एक सूची है, तो कृपया सब कुछ मॉनिटर करें!" - कुछ नहीं चलेगा।
• यदि आप "हैलो वर्ल्ड" प्रिंट करते हैं, तो कोई भी कभी भी यह नहीं जान पाएगा कि एपीआई और वास्तव में काम करना चाहिए। एपीआई में प्रत्येक परिवर्तन से चेक में बदलाव होना चाहिए।
• यदि आपके पास पहले से ही इस तरह की आपदा है, तो सुविधाओं को रोकें और उन डेवलपर्स का चयन करें जो इन चेकों को लिखेंगे, या नुकसान के साथ सामंजस्य स्थापित करेंगे, यह समेट लेंगे कि कुछ भी जाँच नहीं है और गिर जाएगा।

तकनीकी सुझाव:

• निरीक्षणों के आयोजन के लिए एक बाहरी सर्वर को व्यवस्थित करना सुनिश्चित करें - आपको यह सुनिश्चित करना होगा कि आपकी परियोजना बाहरी दुनिया के लिए सुलभ है।
• पूरे एपीआई प्रोटोकॉल में सत्यापन को व्यवस्थित करें, न कि केवल व्यक्तिगत समापन बिंदु।
• परीक्षा परिणामों के साथ एक प्रोमेथियस-समापन बिंदु बनाएं।

आवेदन स्तर - स्वास्थ्य मेट्रिक्स निगरानी

अब हम सेवाओं के बाहरी स्वास्थ्य-मैट्रिक्स के बारे में बात कर रहे हैं।

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

इसे तकनीकी रूप से सही ढंग से कैसे लागू किया जाए: प्रत्येक सेवा अपने वर्तमान प्रदर्शन के बारे में एक अंतिम बिंदु निर्धारित करती है, और ग्राफाना (या किसी अन्य अनुप्रयोग) के रेखांकन में हम सभी सेवाओं की स्थिति देखते हैं।

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

अनुप्रयोग परत - एकीकरण निगरानी

एकीकरण निगरानी व्यावसायिक महत्वपूर्ण प्रणालियों के बीच निगरानी संचार पर केंद्रित है।

उदाहरण के लिए, 15 सेवाएं हैं जो एक दूसरे के साथ संवाद करती हैं। ये अब अलग-अलग साइट नहीं हैं। यानी हम सेवा को अपने दम पर नहीं खींच सकते, पा सकते हैं / helloworld और समझ सकते हैं कि सेवा काम कर रही है। क्योंकि ऑर्डर देने के लिए वेब सेवा को ऑर्डर के बारे में बस को जानकारी भेजनी चाहिए - वेयरहाउस सेवा को बस से यह संदेश प्राप्त करना चाहिए और इसके लिए आगे काम करना चाहिए। और ई-मेल वितरण सेवा को इसे किसी तरह आगे संभालना चाहिए, आदि।

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

जैसा कि मैं करने की सलाह देता हूं:

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

जैसा कि आमतौर पर होता है: हमारे पास एक सेवा है जो बस पर डेटा फेंकता है। हम इस सेवा में आते हैं और आपको इसके एकीकरण स्वास्थ्य के बारे में बात करने के लिए कहते हैं। और अगर सेवा को आगे (WebApp) कुछ संदेश बेचने की आवश्यकता है, तो वह इस परीक्षण संदेश का उत्पादन करेगा। और अगर हम ऑर्डरप्रोसेसिंग साइड पर सेवा को खींचते हैं, तो यह पहले कुछ ऐसा पोस्ट करता है कि यह स्वतंत्र पोस्ट कर सकता है, और यदि कोई आश्रित चीजें हैं, तो यह बस से परीक्षण संदेशों का एक सेट पढ़ता है, समझता है कि यह उन्हें संसाधित कर सकता है, इसकी रिपोर्ट कर सकता है। यदि आवश्यक हो, तो उन्हें आगे पोस्ट करें, और इस बारे में वह कहते हैं - सब कुछ ठीक है, मैं जीवित हूं।

बहुत बार हम यह सवाल सुनते हैं कि "हम इसका मुकाबला डेटा पर कैसे कर सकते हैं?" उदाहरण के लिए, हम उसी ऑर्डर सेवा के बारे में बात कर रहे हैं। ऑर्डर उस माल को संदेश भेजता है जहां माल लिखा हुआ है: हम इसका मुकाबला डेटा पर नहीं कर सकते, क्योंकि "मेरा माल बंद हो जाएगा!" बाहर निकलें: प्रारंभिक चरण में, इस पूरे परीक्षण की योजना बनाएं। आपके पास इकाई परीक्षण हैं जो नकली करते हैं। इसलिए, इसे एक गहरे स्तर पर करें, जहां आपके पास एक संचार चैनल होगा जो व्यवसाय को नुकसान नहीं पहुंचाएगा।

अवसंरचना स्तर

इंफ्रास्ट्रक्चर मॉनिटरिंग वह है जिसे लंबे समय से खुद मॉनिटरिंग माना जाता है।

• इन्फ्रास्ट्रक्चर मॉनिटरिंग को एक अलग प्रक्रिया के रूप में लॉन्च किया जा सकता है और किया जाना चाहिए।
• यदि आप वास्तव में करना चाहते हैं, तो आपको किसी कार्यशील परियोजना पर बुनियादी ढांचे की निगरानी से शुरू नहीं करना चाहिए। यह सभी देवरों के लिए दुख की बात है। "पहले मैं क्लस्टर की निगरानी करता हूं, मैं बुनियादी ढांचे की निगरानी करता हूं" - यानी सबसे पहले, यह मॉनिटर करेगा कि नीचे क्या है, लेकिन यह एप्लिकेशन में नहीं चढ़ेगा। क्योंकि एप्लिकेशन देवोपा के लिए एक समझ से बाहर की चीज है। उन्होंने उसे लीक कर दिया, और उसे समझ नहीं आया कि यह कैसे काम करता है। और वह बुनियादी ढांचे को समझता है और इसके साथ शुरू होता है। लेकिन नहीं - आपको हमेशा पहले आवेदन पर नजर रखने की जरूरत है।
• . , , - . on-call, , « ». .

-

:

• ELK. . - , .
• APM. APM (NewRelic, BlackFire, Datadog). , - , .
• Tracing. , . , tracing — . – ! . Jaeger/Zipkin

• : . Grafana. PagerDuty. (, …). ,
• : ( , ). Oncall : , , , — ( — , : , ). , — (« — »), .
• « » workflow : , , . , — ; .

, :

• — Prometheus + Grafana;
• — ELK;
• APM Tracing — Jaeger (Zipkin).

. , , , . , . , , , — .

, :

Prometheus Kubernetes — ?! , ? , , — , .

. . , Promtheus, , , . ? , , .

निष्कर्ष

• — , . 98% — . , , , --.
• : 30% , .
• , , - , — . , — .
• ( ) — .
• , , « » — , .

Saint Highload++.

UPD ( ):

1. , , , «, , , ». , : DevOps , — , , , .
2. मैं संकेत देने की कोशिश नहीं कर रहा हूं, वे कहते हैं, "हर जगह सब कुछ खराब है, लेकिन हम आपकी निगरानी कर सकते हैं - इत्सुम्मा के पास आओ।" नहीं, यदि परियोजना शुरू की गई है, तो निगरानी किसी तीसरे पक्ष की कंपनी द्वारा नहीं की जा सकती है। बेशक, हमारे पास व्यावसायिक लक्ष्य भी हैं, और हम वास्तव में क्या कर रहे हैं, इसके विकास की प्रक्रिया में परियोजना का समर्थन करने के लिए परामर्श पेश करने के बारे में सोच रहे हैं ताकि यह सुनिश्चित किया जा सके कि विकास के निगरानी भाग का सही तरीके से संचालन कैसे किया जाए।

यदि आप मेरे विचारों और उस पर और इसी तरह के विचारों में रुचि रखते हैं, तो आप चैनल को पढ़ सकते हैं :-)