देखरेख मृत आहे? दीर्घ थेट निरीक्षण

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

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

मॉनिटरिंग सिस्टीमच्या संघटनेच्या संदर्भात, मी असे म्हणू इच्छितो की ... सक्षम निरीक्षणासह कोणतेही प्रकल्प नाहीत. आणि परिस्थिती इतकी वाईट आहे, जर काहीतरी पडले तर, त्याकडे लक्ष न देण्याचा धोका आहे - शेवटी, प्रत्येकाला खात्री आहे की "प्रत्येक गोष्टीचे निरीक्षण केले जात आहे."
कदाचित सर्वकाही निरीक्षण केले जात आहे. पण कसे?

आपण सर्वांनी खालीलप्रमाणे एक कथा पाहिली आहे: एक विशिष्ट डेव्हप्स काम करत आहे, एक विशिष्ट प्रशासक काम करत आहे, एक विकास कार्यसंघ त्यांच्याकडे येतो आणि म्हणतो - "आम्ही मुक्त झालो आहोत, आता त्याचे निरीक्षण करा." आपण काय निरीक्षण करता? हे कसे कार्य करते?

ठीक आहे. जुन्या पद्धतीचे निरीक्षण करा. परंतु ते आधीच बदलत आहे, आणि असे दिसून आले की तुम्ही सेवेचे परीक्षण केले आहे, जी सेवा B बनली आहे, जी सेवा C शी संवाद साधते. परंतु विकास कार्यसंघ तुम्हाला सांगते: "सॉफ्टवेअर स्थापित करा, त्याने प्रत्येक गोष्टीचे निरीक्षण केले पाहिजे!"

मग काय बदलले आहे? - सर्व काही बदलले आहे!

2008 सर्व काही ठीक आहे

दोन विकासक आहेत, एक सर्व्हर, एक डेटाबेस सर्व्हर. तेथून सर्व काही येते. आमच्याकडे काही माहिती आहे, आम्ही zabbix, Nagios, cacti स्थापित करतो. आणि मग आम्ही CPU साठी, डिस्क ऑपरेशनसाठी, डिस्क स्पेससाठी समजण्यायोग्य अलर्ट सेट करतो. आम्ही काही मॅन्युअल तपासणी देखील करतो की साइट म्हणते की ऑर्डर डेटाबेसवर येत आहेत. आणि तेच आहे - आम्ही कमी-अधिक प्रमाणात संरक्षित आहोत.

जर आपण देखरेख सुनिश्चित करण्यासाठी प्रशासकाने केलेल्या कामाच्या प्रमाणाची तुलना केली तर ते 98% स्वयंचलित होते: ज्या व्यक्तीचे परीक्षण होते त्याला Zabbix कसे स्थापित करावे, ते कसे सेट करावे आणि अलर्ट कसे सेट करावे हे समजले पाहिजे. आणि 2% - बाह्य तपासणीसाठी: की साइट प्रतिसाद देत आहे आणि डेटाबेसला विनंती करत आहे, की नवीन ऑर्डर आल्या आहेत.

2010 भार वाढत आहे

आम्ही वेब स्केल करणे सुरू करतो, शोध इंजिन जोडतो. उत्पादन कॅटलॉगमध्ये सर्व उत्पादने आहेत याची आम्ही खात्री करू इच्छितो. आणि उत्पादन शोध कार्य करते. डेटाबेस कार्यरत आहे, ऑर्डर केले जात आहेत, साइट बाहेरून प्रतिसाद देते आणि दोन सर्व्हरवरून प्रतिसाद देते आणि वापरकर्त्याला साइटवरून बाहेर काढले जात नाही जेव्हा ते दुसर्‍या सर्व्हरवर संतुलित केले जाते, इ. आणखी संस्था आहेत.

शिवाय, पायाभूत सुविधांशी संबंधित सार, पूर्वीप्रमाणेच, व्यवस्थापकाच्या डोक्यात सर्वात मोठा असतो. माझ्या डोक्यात अजूनही कल्पना आहे की मॉनिटरिंगमध्ये गुंतलेली व्यक्ती अशी व्यक्ती आहे जी झब्बिक्स स्थापित करेल आणि ते कॉन्फिगर करण्यास सक्षम असेल.

परंतु त्याच वेळी, बाह्य तपासणी करणे, शोध इंडेक्सर क्वेरी स्क्रिप्टचा संच तयार करणे, इंडेक्सिंग प्रक्रियेदरम्यान शोध बदलतो की नाही हे तपासण्यासाठी स्क्रिप्टचा संच, वस्तू हस्तांतरित केल्या गेल्या आहेत हे तपासण्यासाठी स्क्रिप्टचा संच तयार करणे. वितरण सेवा इ. आणि असेच.

टीप: मी 3 वेळा "स्क्रिप्ट सेट" लिहिले. म्हणजेच, देखरेखीसाठी जबाबदार व्यक्ती यापुढे फक्त झब्बिक्स स्थापित करणारी व्यक्ती नाही. ही एक व्यक्ती आहे जी कोडिंग सुरू करते. पण संघाच्या मनात काहीही बदल झालेला नाही.

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

पण क्वचितच 10 वर्षे एखाद्या प्रकल्पासोबत कोणीही जात नाही.

मॉनिटरमनचा रेझ्युमे

समजा तुम्ही एका नवीन स्टार्टअपमध्ये आला आहात ज्याने लगेच 20 विकासकांची भरती केली, 15 मायक्रोसर्व्हिसेस लिहिल्या आणि तुम्ही एक प्रशासक आहात ज्याला सांगितले जाते: “सीआय/सीडी तयार करा. कृपया." तुम्ही सीआय/सीडी तयार केली आहे आणि अचानक तुम्हाला ऐकू येते: “अ‍ॅप्लिकेशन कसे कार्य करेल हे समजून घेतल्याशिवाय “क्यूब” मध्ये उत्पादनासह काम करणे आमच्यासाठी कठीण आहे. आम्हाला त्याच "क्यूब" मध्ये सँडबॉक्स बनवा.
तुम्ही या क्यूबमध्ये सँडबॉक्स बनवत आहात. ते लगेच तुम्हाला सांगतात: "आम्हाला उत्पादनातून दररोज अद्ययावत होणारा डेटाबेस तयार करायचा आहे, जेणेकरून आम्हाला समजेल की ते डेटाबेसवर कार्य करते, परंतु त्याच वेळी उत्पादन डेटाबेसमध्ये गोंधळ करू नका."

या सगळ्यात तू राहतोस. रिलीझ होण्यापूर्वी 2 आठवडे बाकी आहेत, ते तुम्हाला म्हणतात: "आता मला या सर्व गोष्टींचे निरीक्षण करायचे आहे ..." म्हणजे. क्लस्टर इन्फ्रास्ट्रक्चरचे निरीक्षण करा, मायक्रोसर्व्हिस आर्किटेक्चरचे निरीक्षण करा, बाह्य सेवांसह कामाचे निरीक्षण करा ...

आणि सहकारी त्यांच्या डोक्यातून अशी परिचित योजना काढतात आणि म्हणतात: “तर येथे सर्व काही स्पष्ट आहे! एक प्रोग्राम स्थापित करा जो या सर्वांचे निरीक्षण करेल. होय, होय: Prometheus + Grafana + प्लगइन.
आणि ते त्याच वेळी जोडतात: "तुमच्याकडे दोन आठवडे आहेत, सर्वकाही विश्वसनीय असल्याची खात्री करा."

आपण पाहत असलेल्या अनेक प्रकल्पांमध्ये, एका व्यक्तीला देखरेखीसाठी वाटप केले जाते. अशी कल्पना करा की आम्ही एका व्यक्तीला कामावर ठेवू इच्छितो जो 2 आठवड्यांसाठी देखरेखीत गुंतलेला असेल आणि आम्ही त्याच्यासाठी एक सारांश संकलित करत आहोत. या व्यक्तीकडे कोणती कौशल्ये असावीत - आम्ही आधी सांगितलेल्या प्रत्येक गोष्टीचा विचार करता?

• त्याला लोखंडाच्या पायाभूत सुविधांच्या ऑपरेशनचे निरीक्षण आणि तपशील समजले पाहिजेत.
• त्याला कुबर्नेट्स मॉनिटरिंगचे तपशील समजले पाहिजेत (आणि प्रत्येकाला "क्यूब" मध्ये रहायचे आहे, कारण आपण सर्व गोष्टींपासून अ‍ॅबस्ट्रॅक्ट करू शकता, लपवू शकता, कारण प्रशासक उर्वरित गोष्टींना सामोरे जाईल) - स्वतःच, त्याची पायाभूत सुविधा आणि निरीक्षण कसे करावे हे समजून घेणे आवश्यक आहे. आत अनुप्रयोग.
• त्याला हे समजले पाहिजे की सेवा एकमेकांशी विशिष्ट मार्गांनी संवाद साधतात आणि सेवांच्या परस्परसंवादाचे तपशील जाणून घेतात. एखादा प्रकल्प पाहणे अगदी वास्तववादी आहे जिथे काही सेवा समकालिकपणे संवाद साधतात, कारण दुसरा कोणताही मार्ग नाही. उदाहरणार्थ, बॅकएंड REST द्वारे, gRPC द्वारे कॅटलॉग सेवेकडे जातो, उत्पादनांची सूची प्राप्त करतो आणि परत येतो. तुम्ही इथे थांबू शकत नाही. आणि इतर सेवांसह, ते असिंक्रोनसपणे कार्य करते. ऑर्डर वितरण सेवेकडे हस्तांतरित करा, पत्र पाठवा इ.
  आपण कदाचित आधीच या सर्व पासून swam? आणि प्रशासक, ज्याला हे निरीक्षण करणे आवश्यक आहे, ते आणखी पोहले.
• तो योग्यरित्या योजना आणि योजना करण्यास सक्षम असणे आवश्यक आहे - कारण अधिक आणि अधिक काम आहे.
• म्हणूनच, विशेषत: त्याचे निरीक्षण कसे करावे हे समजून घेण्यासाठी त्याने तयार केलेल्या सेवेमधून एक धोरण तयार केले पाहिजे. त्याला प्रोजेक्ट आर्किटेक्चर आणि त्याचा विकास + विकासात वापरल्या जाणार्‍या तंत्रज्ञानाची समज असणे आवश्यक आहे.

चला एक अगदी सामान्य केस लक्षात ठेवूया: काही सेवा php मध्ये, काही सेवा Go मध्ये, काही सेवा JS मधील. ते कसे तरी एकमेकांसोबत काम करतात. येथूनच "मायक्रोसर्व्हिस" हा शब्द आला आहे: अशा अनेक स्वतंत्र प्रणाली आहेत की विकासक संपूर्ण प्रकल्प समजू शकत नाहीत. संघाचा एक भाग JS मधील सेवा लिहितो ज्या स्वत: कार्य करतात आणि उर्वरित प्रणाली कशी कार्य करते हे माहित नसते. दुसरा भाग पायथनमध्ये सेवा लिहितो आणि इतर सेवा कशा कार्य करतात हे समजत नाही, त्या त्यांच्या क्षेत्रात वेगळ्या आहेत. तिसरा php किंवा इतर काहीतरी सेवा लिहितो.
हे सर्व 20 लोक 15 सेवांमध्ये विभागले गेले आहेत आणि एकच अॅडमिन आहे ज्याला हे सर्व समजून घ्यायचे आहे. थांबा! आम्ही फक्त 15 मायक्रो सर्व्हिसेसमध्ये सिस्टम विभाजित करतो, कारण 20 लोक संपूर्ण सिस्टम समजू शकत नाहीत.

पण ते कसे तरी दुरुस्त करणे आवश्यक आहे ...

परिणाम काय? परिणामी, एक व्यक्ती आहे जो संपूर्ण विकास कार्यसंघाला समजू शकत नाही अशा सर्व गोष्टी त्याच्या डोक्यात प्रवेश करतो आणि त्याच वेळी त्याला अजूनही माहित असणे आवश्यक आहे आणि आम्ही वर सूचित केले आहे ते करण्यास सक्षम असणे आवश्यक आहे - लोह पायाभूत सुविधा, कुबर्नेट्स पायाभूत सुविधा, इ.

मी काय सांगू... ह्यूस्टन, आम्हाला एक समस्या आहे.

आधुनिक सॉफ्टवेअर प्रकल्पाचे निरीक्षण करणे हा एक सॉफ्टवेअर प्रकल्प आहे

मॉनिटरिंग हे सॉफ्टवेअर आहे या खोट्या आत्मविश्वासातून, आमचा चमत्कारांवर विश्वास आहे. पण चमत्कार, अरेरे, घडत नाहीत. आपण zabbix स्थापित करू शकत नाही आणि सर्वकाही कार्य करण्यासाठी प्रतीक्षा करू शकत नाही. Grafana स्थापित करण्यात काही अर्थ नाही आणि सर्व काही ठीक होईल अशी आशा आहे. बहुतेक वेळ सेवांच्या ऑपरेशनवर चेक आयोजित करण्यात आणि एकमेकांशी त्यांचा परस्परसंवाद, बाह्य प्रणाली कशा कार्य करतात हे तपासण्यासाठी खर्च केला जाईल. खरं तर, 90% वेळ स्क्रिप्टिंगवर नाही तर सॉफ्टवेअर डेव्हलपमेंटवर खर्च केला जाईल. आणि ते प्रकल्पाचे काम समजून घेणार्‍या टीमने केले पाहिजे.
अशा परिस्थितीत एका व्यक्तीला देखरेखीसाठी पाठवले तर त्रास होईल. जे सर्वत्र घडते.

उदाहरणार्थ, काफ्का मार्गे एकमेकांशी संवाद साधणाऱ्या अनेक सेवा आहेत. ऑर्डर आली, आम्ही काफ्काला ऑर्डरबद्दल संदेश पाठवला. एक सेवा आहे जी ऑर्डरबद्दल माहिती ऐकते आणि माल पाठवते. अशी सेवा आहे जी ऑर्डरबद्दल माहिती ऐकते आणि वापरकर्त्याला पत्र पाठवते. आणि मग इतर सेवांचा समूह आहे आणि आम्ही गोंधळात पडू लागतो.

आणि रिलीझ होण्याआधी थोडा वेळ शिल्लक असताना तुम्ही अॅडमिन आणि डेव्हलपरना ते दिले तर, त्या व्यक्तीला हा संपूर्ण प्रोटोकॉल समजून घेणे आवश्यक आहे. त्या. या विशालतेच्या प्रकल्पासाठी बराच वेळ लागतो आणि हे सिस्टमच्या विकासामध्ये तयार केले जावे.
परंतु बर्‍याचदा, विशेषत: बर्निंगमध्ये, स्टार्टअपमध्ये, आम्ही पाहतो की देखरेख नंतरपर्यंत कशी पुढे ढकलली जाते. “आता आम्ही संकल्पनेचा पुरावा बनवू, आम्ही त्यासह लॉन्च करू, ते पडू द्या - आम्ही त्याग करण्यास तयार आहोत. आणि मग आम्ही हे सर्व निरीक्षण करू." जेव्हा (किंवा जर) प्रकल्पाने पैसे आणणे सुरू केले, तेव्हा व्यवसायाला आणखी वैशिष्ट्ये कमी करायची आहेत - कारण ते कार्य करू लागले आहे, त्यामुळे तुम्हाला ते आणखी वाढवण्याची गरज आहे! आणि तुम्ही अशा ठिकाणी आहात जिथे तुम्हाला आधीच्या सर्व गोष्टींचे निरीक्षण करणे आवश्यक आहे, ज्यासाठी 1% वेळ नाही, परंतु बरेच काही लागते. आणि तसे, देखरेखीसाठी विकासकांची आवश्यकता असेल आणि त्यांना नवीन वैशिष्ट्यांवर कार्य करू देणे सोपे आहे. परिणामी, नवीन वैशिष्ट्ये लिहिली गेली आहेत, सर्व काही बंद झाले आहे आणि तुम्ही अंतहीन गतिरोधात आहात.

तर तुम्ही सुरुवातीपासूनच एखाद्या प्रकल्पाचे निरीक्षण कसे कराल आणि जर तुम्हाला एखादा प्रकल्प मिळाला ज्याचे परीक्षण करणे आवश्यक आहे आणि तुम्हाला कुठे सुरू करायचे हे माहित नसेल तर?

प्रथम, आपण योजना करणे आवश्यक आहे.

गीतात्मक विषयांतर: बरेचदा ते पायाभूत सुविधांच्या देखरेखीपासून सुरू होतात. उदाहरणार्थ, आमच्याकडे कुबर्नेट्स आहेत. चला Grafana सह Prometheus स्थापित करून, "क्यूब" च्या देखरेखीखाली प्लगइन ठेवून प्रारंभ करूया. केवळ विकासकच नाही तर प्रशासकांना देखील एक दुर्दैवी सराव आहे: "आम्ही हे प्लगइन स्थापित करू आणि प्लगइनला ते कसे करायचे हे कदाचित माहित असेल." लोकांना महत्त्वाच्या कृतींऐवजी साध्या आणि स्पष्टपणे सुरुवात करायला आवडते. आणि पायाभूत सुविधांचे निरीक्षण करणे सोपे आहे.

प्रथम, आपण काय आणि कसे निरीक्षण करू इच्छिता ते ठरवा आणि नंतर एक साधन निवडा, कारण इतर लोक आपल्यासाठी विचार करू शकत नाहीत. आणि त्यांनी करावे? इतर लोकांनी स्वतःचा विचार केला, सार्वत्रिक प्रणालीबद्दल - किंवा हे प्लगइन लिहिले तेव्हा अजिबात विचार केला नाही. आणि या प्लगइनचे 5 हजार वापरकर्ते आहेत याचा अर्थ असा नाही की त्याचा काही उपयोग आहे. कदाचित तुम्ही 5001 वा व्हाल कारण तिथे आधीपासून 5000 लोक होते.

जर तुम्ही पायाभूत सुविधांचे निरीक्षण करण्यास सुरुवात केली आणि तुमच्या अॅपचा बॅकएंड प्रतिसाद देणे थांबवल्यास, सर्व वापरकर्ते त्यांचे मोबाइल अॅपशी कनेक्शन गमावतील. एक त्रुटी पॉप अप होईल. ते तुमच्याकडे येतील आणि म्हणतील "अॅप्लिकेशन काम करत नाही, तुम्ही इथे काय करत आहात?" "आम्ही देखरेख करत आहोत." - “अ‍ॅप्लिकेशन काम करत नसल्याचे तुम्हाला दिसत नसेल तर तुम्ही कसे निरीक्षण कराल?!”

1. माझा विश्वास आहे की वापरकर्त्याच्या प्रवेश बिंदूपासून देखरेख सुरू करणे आवश्यक आहे. जर वापरकर्त्याला हे दिसत नसेल की अनुप्रयोग कार्य करत आहे, तर ते अयशस्वी आहे. आणि मॉनिटरिंग सिस्टमने प्रथम स्थानावर याबद्दल चेतावणी दिली पाहिजे.
2. आणि त्यानंतरच आपण पायाभूत सुविधांवर लक्ष ठेवू शकतो. किंवा समांतर करा. पायाभूत सुविधा सोपे आहे - येथे आपण शेवटी फक्त zabbix स्थापित करू शकतो.
3. आणि आता काहीतरी कुठे कार्य करत नाही हे समजून घेण्यासाठी आपल्याला अनुप्रयोगाच्या मुळांवर जाण्याची आवश्यकता आहे.

माझी मुख्य कल्पना अशी आहे की विकास प्रक्रियेच्या समांतरपणे निरीक्षण केले पाहिजे. तुम्ही इतर कामांसाठी (CI/CD तयार करणे, सँडबॉक्सिंग करणे, पायाभूत सुविधांची पुनर्रचना करणे) साठी मॉनिटरिंग टीम काढून टाकल्यास, मॉनिटरिंग मागे पडू लागेल आणि तुम्हाला विकास कधीच मिळू शकणार नाही (किंवा लवकर किंवा नंतर तुम्हाला ते थांबवावे लागेल).

सर्व स्तरांनुसार

अशा प्रकारे मी मॉनिटरिंग सिस्टमची संस्था पाहतो.

1) अर्ज पातळी:

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

2) पायाभूत सुविधा पातळी:

• ऑर्केस्ट्रेशन पातळी निरीक्षण;
• सिस्टम सॉफ्टवेअर निरीक्षण;
• लोह पातळी निरीक्षण.

3) पुन्हा अनुप्रयोग स्तर - परंतु आधीच अभियांत्रिकी उत्पादन म्हणून:

• अर्ज नोंदी गोळा आणि निरीक्षण;
• एपीएम;
• ट्रेसिंग

4) चेतावणी:

• चेतावणी प्रणालीची संस्था;
• कर्तव्य प्रणालीची संघटना;
• घटनांवर प्रक्रिया करण्यासाठी "नॉलेज बेस" आणि वर्कफ्लोची संघटना.

महत्वाचे: आम्ही नंतर नाही, पण लगेच अलर्ट करू! निरीक्षण सुरू करण्याची आणि "काही तरी नंतर" कोणाला सूचना प्राप्त होतील हे शोधण्याची आवश्यकता नाही. शेवटी, देखरेख करण्याचे कार्य काय आहे: सिस्टममध्ये काहीतरी चुकीचे कार्य करते हे समजून घेणे आणि योग्य लोकांना त्याबद्दल कळवा. जर हे शेवटपर्यंत सोडले तर, "आमच्यासाठी काहीही काम करत नाही" असे कॉल करून, काहीतरी चूक होत आहे हे योग्य लोकांना कळेल.

ऍप्लिकेशन लेयर - बिझनेस लॉजिक मॉनिटरिंग

येथे आम्ही वापरकर्त्यासाठी अनुप्रयोग कार्य करतो हे सत्य तपासण्याबद्दल बोलत आहोत.

हा स्तर विकासाच्या टप्प्यात केला पाहिजे. उदाहरणार्थ, आमच्याकडे एक सशर्त प्रोमिथियस आहे: तो चेकमध्ये गुंतलेल्या सर्व्हरवर चढतो, एंडपॉइंट खेचतो आणि एंडपॉइंट जाऊन API तपासतो.

साइट कार्य करते याची खात्री करण्यासाठी मुख्य पृष्ठाचे निरीक्षण करण्यास सांगितले जाते तेव्हा, प्रोग्रामर प्रत्येक वेळी API कार्य करते याची खात्री करण्यासाठी त्यांना खेचण्यासाठी हँडल देतात. आणि या क्षणी प्रोग्रामर अजूनही / एपीआय / चाचणी / हॅलोवर्ल्ड घेतात आणि लिहितात
सर्वकाही कार्य करते याची खात्री करण्याचा एकमेव मार्ग? - नाही!

• असे चेक तयार करणे हे खरे तर विकासकांचे काम आहे. कोड लिहिणाऱ्या प्रोग्रामरद्वारे युनिट चाचण्या लिहिल्या पाहिजेत. कारण जर तुम्ही ते प्रशासकावर थुंकले तर "मित्रा, सर्व २५ फंक्शन्ससाठी एपीआय प्रोटोकॉलची यादी येथे आहे, कृपया प्रत्येक गोष्टीचे निरीक्षण करा!" - काहीही चालणार नाही.
• तुम्ही "हॅलो वर्ल्ड" मुद्रित केल्यास, एपीआयने कार्य केले पाहिजे आणि ते कार्य करते हे कोणालाही कळणार नाही. API मधील प्रत्येक बदलामुळे चेकमध्ये बदल होणे आवश्यक आहे.
• तुम्हाला आधीच अशी समस्या असल्यास, वैशिष्ट्ये थांबवा आणि विकासक निवडा जे हे धनादेश लिहतील किंवा नुकसान सहन करतील, काहीही तपासले गेले नाही आणि पडणार नाही.

तांत्रिक टिपा:

• चेक आयोजित करण्यासाठी बाह्य सर्व्हर आयोजित केल्याची खात्री करा - तुमचा प्रकल्प बाहेरील जगासाठी उपलब्ध असल्याची तुम्हाला खात्री असणे आवश्यक आहे.
• संपूर्ण API प्रोटोकॉलसाठी चेक आयोजित करा, आणि केवळ वैयक्तिक एंडपॉइंटसाठी नाही.
• चेकच्या परिणामांसह प्रोमिथियस-एंडपॉइंट तयार करा.

अनुप्रयोग स्तर - आरोग्य मेट्रिक्सचे निरीक्षण करणे

आता आम्ही सेवांच्या बाह्य आरोग्य-मेट्रिक्सबद्दल बोलत आहोत.

आम्‍ही ठरवले की आम्‍ही बाह्य मॉनिटरींग सिस्‍टममधून कॉल करणार्‍या बाह्य तपासणीचा वापर करून अॅप्लिकेशनच्‍या सर्व "हँडल" चे परीक्षण करू. परंतु ही तंतोतंत "हँडल" आहेत जी वापरकर्ता "पाहतो". आम्हाला खात्री करायची आहे की सेवा स्वतः आमच्यासाठी कार्य करतात. ही एक चांगली गोष्ट आहे: K8 ची आरोग्य तपासणी केली जाते जेणेकरून किमान "क्यूब" स्वतः सेवा कार्य करत असल्याची खात्री करेल. पण मी पाहिलेल्या निम्मे चेक "हॅलो वर्ल्ड" सारखेच प्रिंट आहेत. त्या. येथे तो तैनात केल्यानंतर एकदा खेचतो, त्याने उत्तर दिले की सर्व काही ठीक आहे - आणि तेच. आणि सेवा, जर ती त्याचे API विश्रांती म्हणून देते, तर त्याच API चे मोठ्या संख्येने एंट्री पॉईंट्स आहेत, ज्याचे परीक्षण देखील करणे आवश्यक आहे, कारण आम्हाला हे जाणून घ्यायचे आहे की ते कार्य करते. आणि आम्ही आधीपासूनच त्याचे निरीक्षण करतो.

तांत्रिकदृष्ट्या ते योग्यरित्या कसे अंमलात आणायचे: प्रत्येक सेवा त्याच्या वर्तमान कार्यक्षमतेबद्दल एक अंतिम बिंदू उघड करते आणि ग्राफना (किंवा इतर कोणत्याही अनुप्रयोग) च्या आलेखांमध्ये आम्ही सर्व सेवांची स्थिती पाहतो.

• API मधील प्रत्येक बदलामुळे चेकमध्ये बदल होणे आवश्यक आहे.
• आरोग्य मेट्रिक्ससह लगेच नवीन सेवा तयार करा.
• प्रशासक विकासकांकडे येऊ शकतो आणि "माझ्यासाठी काही वैशिष्ट्ये जोडा जेणेकरून मला सर्वकाही समजेल आणि माझ्या मॉनिटरिंग सिस्टममध्ये त्याबद्दलची माहिती जोडेल." परंतु विकासक सहसा उत्तर देतात "आम्ही प्रकाशनाच्या दोन आठवड्यांपूर्वी काहीही जोडणार नाही."
  असे नुकसान होणार आहे हे विकास व्यवस्थापकांना कळू द्या, विकास व्यवस्थापकांच्या वरिष्ठांनाही कळू द्या. कारण जेव्हा सर्व काही कमी होते, तरीही कोणीतरी कॉल करेल आणि "सतत कमी होत असलेल्या सेवेवर" लक्ष ठेवण्याची मागणी करेल (c)
• तसे, Grafana साठी प्लगइन लिहिण्यासाठी विकासकांना नियुक्त करा - हे प्रशासकांसाठी चांगली मदत होईल.

ऍप्लिकेशन लेयर - इंटिग्रेशन मॉनिटरिंग

इंटिग्रेशन मॉनिटरिंग व्यवसाय-महत्त्वपूर्ण प्रणालींमधील संप्रेषणाचे निरीक्षण करण्यावर लक्ष केंद्रित करते.

उदाहरणार्थ, 15 सेवा आहेत ज्या एकमेकांशी संवाद साधतात. त्या यापुढे वेगळ्या साइट नाहीत. त्या. आम्ही स्वतः सेवा खेचू शकत नाही, /helloworld मिळवू आणि सेवा चालू आहे हे समजू शकत नाही. चेकआउट वेब सेवेने बसला ऑर्डरबद्दल माहिती पाठवणे आवश्यक असल्याने, वेअरहाऊस सेवेला बसमधून हा संदेश प्राप्त होणे आवश्यक आहे आणि त्यासह पुढे कार्य करणे आवश्यक आहे. आणि ई-मेल वितरण सेवेला पुढे कसे तरी त्यावर प्रक्रिया करावी लागते, आणि असेच.

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

मी कसे करण्याची शिफारस करतो:

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

जसे हे सहसा घडते: आमच्याकडे एक सेवा आहे जी बसमध्ये डेटा टाकते. आम्ही या सेवेत येतो आणि त्याच्या एकात्मिक आरोग्याबद्दल सांगण्यास सांगतो. आणि जर सेवेला पुढे कुठेतरी काही संदेश (WebApp) तयार करायचा असेल तर तो हा चाचणी संदेश तयार करेल. आणि जर आम्ही ऑर्डरप्रोसेसिंगच्या बाजूने सेवा खेचली, तर ती प्रथम पोस्ट करते की ती स्वतंत्र पोस्ट करू शकते, आणि जर काही अवलंबून गोष्टी असतील, तर ते बसमधील चाचणी संदेशांचा संच वाचते, समजते की ती त्यावर प्रक्रिया करू शकते, अहवाल देते. त्याबद्दल आणि, आवश्यक असल्यास, त्यांना पुढे पोस्ट करा, आणि तो याबद्दल म्हणतो - सर्वकाही ठीक आहे, मी जिवंत आहे.

"आम्ही लढाऊ डेटावर याची चाचणी कशी करू शकतो?" असा प्रश्न अनेकदा आपण ऐकतो. उदाहरणार्थ, आम्ही त्याच ऑर्डर सेवेबद्दल बोलत आहोत. ऑर्डर ज्या गोदामात माल लिहून ठेवला आहे तेथे संदेश पाठवते: आम्ही हे लढाऊ डेटावर तपासू शकत नाही, कारण "माझा माल लिहून दिला जाईल!" मार्ग: सुरुवातीच्या टप्प्यावर, या संपूर्ण चाचणीचे नियोजन करा. तुमच्याकडे युनिट चाचण्या देखील आहेत ज्या मस्क बनवतात. आता, ते सखोल स्तरावर करा जिथे तुमच्याकडे संवादाचे चॅनेल आहे ज्यामुळे व्यवसायाला इजा होणार नाही.

पायाभूत सुविधा स्तर

इन्फ्रास्ट्रक्चर मॉनिटरिंग ही अशी गोष्ट आहे जी बर्याच काळापासून स्वतःचे निरीक्षण मानले जाते.

• इन्फ्रास्ट्रक्चर मॉनिटरिंग ही एक वेगळी प्रक्रिया म्हणून चालवली जाऊ शकते आणि केली पाहिजे.
• तुमची खरोखर इच्छा असली तरीही तुम्ही चालू असलेल्या प्रकल्पावर पायाभूत सुविधांच्या देखरेखीपासून सुरुवात करू नये. हे सर्व डेव्हपसाठी एक घसा आहे. “प्रथम मी क्लस्टरचे निरीक्षण करीन, मी पायाभूत सुविधांचे निरीक्षण करीन” - म्हणजे प्रथम, ते खाली काय आहे ते निरीक्षण करेल, परंतु ते अनुप्रयोगात येणार नाही. कारण अॅप्लिकेशन ही डेव्हॉप्ससाठी न समजणारी गोष्ट आहे. हे त्याच्याकडे लीक झाले होते आणि ते कसे कार्य करते हे त्याला समजत नाही. आणि तो पायाभूत सुविधा समजून घेतो आणि त्याच्यापासून सुरुवात करतो. परंतु नाही - आपण नेहमी प्रथम अनुप्रयोगाचे निरीक्षण करणे आवश्यक आहे.
• नोटिफिकेशन्सच्या संख्येवर जास्त जाऊ नका. आधुनिक सिस्टीमची जटिलता लक्षात घेता, अॅलर्ट नेहमीच उडतात आणि तुम्हाला या अलर्टच्या समूहासह कसे तरी जगावे लागेल. आणि ऑन-कॉल व्यक्ती, शंभर नियमित सूचना पाहिल्यानंतर, "मला याबद्दल विचार करायचा नाही" असे ठरवते. अॅलर्टने केवळ गंभीर गोष्टींबद्दल सूचित केले पाहिजे.

व्यवसाय एकक म्हणून अनुप्रयोग स्तर

मुख्य मुद्दे:

• ELK. हे उद्योग मानक आहे. जर काही कारणास्तव तुम्ही नोंदी एकत्रित करत नसाल, तर ते लगेच करायला सुरुवात करा.
• एपीएम ऍप्लिकेशन मॉनिटरिंग (NewRelic, BlackFire, Datadog) द्रुतपणे बंद करण्याचा एक मार्ग म्हणून बाह्य APM. तुमच्यासोबत काय चालले आहे हे समजण्यासाठी तुम्ही ही गोष्ट तात्पुरती ठेवू शकता.
• ट्रेसिंग डझनभर मायक्रोसर्व्हिसेसमध्ये, तुम्हाला सर्वकाही ट्रेस करावे लागेल, कारण विनंती यापुढे स्वतःच राहणार नाही. नंतर जोडणे खूप कठीण आहे, म्हणून विकासामध्ये ट्रेसिंगचे शेड्यूल त्वरित करणे चांगले आहे - हे विकासकांचे कार्य आणि उपयुक्तता आहे. तुम्ही अजून अंमलात आणला नसेल तर अंमलात आणा! Jaeger/Zipkin पहा

चेतावणी

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

तंत्रज्ञान स्टॅक

चला कल्पना करूया की आमच्याकडे खालील स्टॅक आहे:

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

पर्यायांची निवड गंभीर नाही. कारण, जर सुरुवातीला तुम्हाला सिस्टमचे निरीक्षण कसे करावे हे समजले असेल आणि एक योजना तयार केली असेल, तर तुम्ही आधीच तुमच्या गरजेनुसार साधने निवडण्यास सुरुवात केली आहे. प्रश्न हा आहे की आपण सुरुवातीला निरीक्षण करण्यासाठी काय निवडले. कारण, कदाचित, तुम्ही सुरुवातीला निवडलेले साधन - ते तुमच्या गरजांमध्ये अजिबात बसत नाही.

मी अलीकडे सर्वत्र पाहत असलेल्या काही तांत्रिक गोष्टी:

प्रोमिथियसला कुबर्नेट्सच्या आत ढकलले गेले आहे - हे कोण घेऊन आले?! जर तुमचा क्लस्टर अयशस्वी झाला तर तुम्ही काय कराल? जर तुमच्या आत एक जटिल क्लस्टर असेल, तर क्लस्टरच्या आत काही मॉनिटरिंग सिस्टम काम करेल आणि काही बाहेरील, जी क्लस्टरच्या आतून डेटा गोळा करेल.

क्लस्टरच्या आत, आम्ही लॉग आणि इतर सर्व काही गोळा करतो. पण देखरेख यंत्रणा बाहेर असायला हवी. बर्‍याचदा, क्लस्टरमध्ये जेथे प्रॉमथियस आहे, जे आत स्थापित केले गेले होते, तेथे अशा सिस्टम देखील असतात ज्या साइटची बाह्य तपासणी करतात. आणि जर तुमचे बाह्य जगाशी संपर्क कमी झाले आणि अनुप्रयोग कार्य करत नसेल तर? असे दिसून आले की आपल्या आत सर्व काही ठीक आहे, परंतु यामुळे वापरकर्त्यांसाठी ते सोपे होत नाही.

निष्कर्ष

• मॉनिटरिंग डेव्हलपमेंट म्हणजे युटिलिटीजची स्थापना नव्हे तर सॉफ्टवेअर उत्पादनाचा विकास. आजचे 98% मॉनिटरिंग कोडिंग आहे. सेवांमध्ये कोडिंग करणे, बाह्य तपासण्यांचे कोडिंग करणे, बाह्य सेवा तपासणे आणि सर्वकाही.
• विकासकांना देखरेखीसाठी वेळ देऊ नका: हे त्यांच्या कामाच्या 30% पर्यंत लागू शकते, परंतु ते फायदेशीर आहे.
• देवोप्स, एखाद्या गोष्टीचे निरीक्षण करण्यास सक्षम नसल्याबद्दल काळजी करू नका, कारण काही गोष्टी पूर्णपणे भिन्न मानसिकता आहेत. तुम्ही प्रोग्रॅमर नव्हतो, आणि देखरेख करण्याचे काम त्यांचे काम आहे.
• जर प्रकल्प आधीच चालू असेल आणि त्याचे परीक्षण केले जात नसेल (आणि तुम्ही व्यवस्थापक असाल), तर देखरेखीसाठी संसाधने वाटप करा.
• जर उत्पादन आधीपासूनच उत्पादनात असेल आणि तुम्ही डेव्हॉप्स असाल ज्यांना "निरीक्षण सेट अप" करण्यास सांगितले गेले असेल - मी हे सर्व काय लिहिले आहे ते व्यवस्थापनाला समजावून सांगण्याचा प्रयत्न करा.

सेंट हायलोड++ कॉन्फरन्समधील अहवालाची ही विस्तारित आवृत्ती आहे.

जर तुम्हाला माझ्या कल्पना आणि त्यावरील विचार आणि तत्सम विषयांमध्ये स्वारस्य असेल, तर तुम्ही हे करू शकता चॅनेल वाचा 🙂

स्त्रोत: www.habr.com