क्या निगरानी ख़त्म हो गई है? - लंबे समय तक जीवित रहने वाली निगरानी

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

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

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

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

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

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

2008 और सब ठीक है न

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

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

2010 भार बढ़ रहा है

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

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

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

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

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

लेकिन शायद ही कोई किसी प्रोजेक्ट में 10 साल तक साथ देता है।

मॉनिटरिंगमैन का बायोडाटा

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

सब कुछ स्तरों के अनुसार

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

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

• अनुप्रयोग व्यवसाय तर्क की निगरानी करना;
• सेवाओं के स्वास्थ्य मेट्रिक्स की निगरानी करना;
• एकीकरण निगरानी.

2) बुनियादी ढांचा स्तर:

• ऑर्केस्ट्रेशन स्तर की निगरानी;
• सिस्टम सॉफ़्टवेयर निगरानी;
• लौह स्तर की निगरानी।

3) फिर से अनुप्रयोग स्तर - लेकिन एक इंजीनियरिंग उत्पाद के रूप में:

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

4) चेतावनी:

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

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

एप्लिकेशन परत - बिजनेस लॉजिक मॉनिटरिंग

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

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

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

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

तकनीकी युक्तियाँ:

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

अनुप्रयोग परत - स्वास्थ्य मेट्रिक्स निगरानी

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

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

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

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

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

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

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

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

मैं क्या करने की अनुशंसा करता हूँ:

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

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

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

बुनियादी ढांचा परत

बुनियादी ढांचे की निगरानी एक ऐसी चीज़ है जिसे लंबे समय से स्वयं की निगरानी माना जाता है।

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

एक व्यावसायिक इकाई के रूप में अनुप्रयोग स्तर

प्रमुख बिंदु:

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

सूचना देने वाले

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

प्रौद्योगिकी ढेर

आइए कल्पना करें कि हमारा स्टैक इस प्रकार है:

• डेटा संग्रह - प्रोमेथियस + ग्राफाना;
• लॉग विश्लेषण - ईएलके;
• एपीएम या ट्रेसिंग के लिए - जैगर (ज़िपकिन)।

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

कुछ तकनीकी बिंदु जो मुझे हाल ही में हर जगह दिखाई देते हैं:

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

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

निष्कर्ष

• विकास की निगरानी करना उपयोगिताओं की स्थापना नहीं है, बल्कि एक सॉफ्टवेयर उत्पाद का विकास है। आज की 98% निगरानी कोडिंग है। सेवाओं में कोडिंग, बाहरी जाँचों को कोडिंग, बाहरी सेवाओं की जाँच, और बस इतना ही।
• निगरानी पर अपने डेवलपर्स का समय बर्बाद न करें: इसमें उनके काम का 30% तक लग सकता है, लेकिन यह इसके लायक है।
• देवो, चिंता मत करो कि तुम किसी चीज़ की निगरानी नहीं कर सकते, क्योंकि कुछ चीज़ें सोचने का बिल्कुल अलग तरीका हैं। आप एक प्रोग्रामर नहीं थे, और निगरानी का काम बिल्कुल उनका काम है।
• यदि परियोजना पहले से ही चल रही है और उसकी निगरानी नहीं की गई है (और आप एक प्रबंधक हैं), तो निगरानी के लिए संसाधन आवंटित करें।
• यदि उत्पाद पहले से ही उत्पादन में है, और आप एक देवोप्स हैं जिन्हें "निगरानी स्थापित करने" के लिए कहा गया था - प्रबंधन को यह समझाने का प्रयास करें कि मैंने यह सब किस बारे में लिखा है।

यह सेंट हाईलोड++ सम्मेलन की रिपोर्ट का एक विस्तारित संस्करण है।

यदि आप इस पर और संबंधित विषयों पर मेरे विचारों और विचारों में रुचि रखते हैं, तो आप यहां देख सकते हैं चैनल पढ़ें 🙂

स्रोत: www.habr.com