के अनुगमन मरेको छ? - लामो प्रत्यक्ष निगरानी

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

उचित अनुगमन प्रणाली व्यवस्थित गर्नमा समस्या छ भन्ने मेरो विश्वास छ । यदि त्यहाँ कुनै समस्या नभएको भए, तब मेरो भाषणमा एउटा थीसिस हुनेछ: "कृपया प्रोमेथियस + ग्राफाना र प्लगइनहरू 1, 2, 3 स्थापना गर्नुहोस्।" दुर्भाग्यवश, यो अब त्यस तरिकाले काम गर्दैन। र मुख्य समस्या यो हो कि सबैले सफ्टवेयर कम्पोनेन्टहरूको सन्दर्भमा 2008 मा अस्तित्वमा रहेको कुरामा विश्वास गर्न जारी राख्छन्।

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

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

ठिक छ। हामी पुरानो तरिकाले निगरानी गर्छौं। र यो पहिले नै परिवर्तन हुँदैछ, र यो पत्ता लगाउँछ कि तपाईंले सेवा A को निगरानी गर्नुभयो, जुन सेवा B भयो, जसले सेवा C सँग अन्तरक्रिया गर्दछ। तर विकास टोलीले तपाईंलाई भन्छ: "सफ्टवेयर स्थापना गर्नुहोस्, यसले सबै कुराको निगरानी गर्नुपर्छ!"

त्यसोभए के परिवर्तन भएको छ? - सबै कुरा बदलिएको छ!

2008 सबै ठीक छ

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

यदि हामीले अनुगमन प्रदान गर्न प्रशासकले गरेको कामको मात्रा तुलना गर्छौं भने, त्यसको 98% स्वचालित थियो: अनुगमन गर्ने व्यक्तिले Zabbix कसरी स्थापना गर्ने, यसलाई कसरी कन्फिगर गर्ने र अलर्टहरू कन्फिगर गर्ने भनेर बुझ्नुपर्छ। र 2% - बाह्य जाँचहरूको लागि: कि साइटले प्रतिक्रिया दिन्छ र डेटाबेसमा अनुरोध गर्दछ, कि नयाँ अर्डरहरू आइपुगेका छन्।

2010 भार बढिरहेको छ

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

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

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

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

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

तर विरलै कोही 10 वर्षको लागि परियोजनाको साथ आउँछन्।

अनुगमनकर्ताको पुन: सुरुवात

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

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

र मेरा सहकर्मीहरूले आफ्नो टाउकोबाट सामान्य योजना निकाल्छन् र भन्छन्: "ठीक छ, यहाँ सबै कुरा स्पष्ट छ! यो सबै निगरानी गर्ने कार्यक्रम स्थापना गर्नुहोस्।" हो, हो: Prometheus + Grafana + प्लगइनहरू।
र तिनीहरू थप्छन्: "तपाईंसँग दुई हप्ता छ, सुनिश्चित गर्नुहोस् कि सबै कुरा सुरक्षित छ।"

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

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

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

तर यसलाई कुनै न कुनै रूपमा अनुगमन गर्न आवश्यक छ ...

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

म के भन्न सक्छु... ह्युस्टन, हामीसँग समस्या छ।

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

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

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

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

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

पहिलो, तपाईंले योजना बनाउन आवश्यक छ।

लिरिकल डिग्रेसन: प्रायः तिनीहरू पूर्वाधार अनुगमनको साथ सुरु हुन्छन्। उदाहरण को लागी, हामी Kubernetes छ। Grafana सँग प्रोमिथियस स्थापना गरेर, "क्यूब" को निगरानीको लागि प्लगइनहरू स्थापना गरेर सुरु गरौं। विकासकर्ताहरू मात्र होइन, तर प्रशासकहरूको पनि दुर्भाग्यपूर्ण अभ्यास छ: "हामी यो प्लगइन स्थापना गर्नेछौं, तर प्लगइनलाई यो कसरी गर्ने भनेर थाहा छ।" मानिसहरू महत्त्वपूर्ण कार्यहरू भन्दा सट्टा सरल र सीधाबाट सुरु गर्न मन पराउँछन्। र पूर्वाधार अनुगमन सजिलो छ।

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

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

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

मेरो मूल विचार भनेको अनुगमन विकास प्रक्रियासँग समानान्तर हुनुपर्छ। यदि तपाइँ अन्य कार्यहरू (CI/CD सिर्जना गर्ने, स्यान्डबक्सिङ, पूर्वाधार पुनर्गठन) को लागी अनुगमन टोलीलाई विचलित गर्नुहुन्छ भने, अनुगमन ढिलो हुन थाल्छ र तपाइँ विकासको साथ कहिले पनि समात्न सक्नुहुन्न (वा ढिलो वा पछि तपाइँ यसलाई रोक्नु पर्छ)।

स्तर अनुसार सबै कुरा

अनुगमन प्रणालीको संगठन यसरी देख्छु।

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

• अनुगमन आवेदन व्यापार तर्क;
• सेवाहरूको स्वास्थ्य मेट्रिक्स निगरानी;
• एकीकरण निगरानी।

२) पूर्वाधार स्तर:

• आर्केस्ट्रा स्तर निगरानी;
• प्रणाली सफ्टवेयर निगरानी;
• फलाम स्तर निगरानी।

3) फेरि आवेदन स्तर - तर एक ईन्जिनियरिङ् उत्पादन रूपमा:

• आवेदन लगहरू सङ्कलन र निगरानी;
• एपीएम;
• ट्रेसिङ।

4) चेतावनी:

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

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

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

यहाँ हामी एप्लिकेसनले प्रयोगकर्ताका लागि काम गर्छ भन्ने तथ्यलाई जाँच्ने बारे कुरा गर्दैछौं।

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

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

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

प्राविधिक सुझाव:

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

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

अब हामी सेवाहरूको बाह्य स्वास्थ्य मेट्रिक्सको बारेमा कुरा गर्दैछौं।

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

यसलाई कसरी प्राविधिक रूपमा सही रूपमा कार्यान्वयन गर्ने: प्रत्येक सेवाले यसको हालको कार्यसम्पादनको बारेमा अन्तिम बिन्दु उजागर गर्दछ, र Grafana (वा कुनै अन्य अनुप्रयोग) को ग्राफमा हामी सबै सेवाहरूको स्थिति देख्छौं।

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

आवेदन तह - एकीकरण निगरानी

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

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

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

म के गर्न सिफारिस गर्छु:

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

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

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

पूर्वाधार स्तर

पूर्वाधार अनुगमन भनेको लामो समयदेखि अनुगमन गर्ने कुरा हो।

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

एक व्यापार एकाइ रूपमा आवेदन स्तर

मुख्य बुँदाहरू:

• ELK। यो उद्योग मापदण्ड हो। यदि कुनै कारणले तपाइँ लगहरू जम्मा गर्नुहुन्न भने, तुरुन्तै त्यसो गर्न सुरु गर्नुहोस्।
• APM। बाह्य एपीएमहरू द्रुत रूपमा अनुप्रयोग अनुगमन बन्द गर्ने तरिकाको रूपमा (NewRelic, BlackFire, Datadog)। तपाईले यो चीज अस्थायी रूपमा स्थापना गर्न सक्नुहुन्छ कम्तिमा पनि तपाईसँग के भइरहेको छ भनेर बुझ्नको लागि।
• ट्रेसिङ। दर्जनौं माइक्रोसर्भिसेसहरूमा, तपाईंले सबै कुरा ट्रेस गर्नुपर्छ, किनभने अनुरोध अब आफ्नै रूपमा रहँदैन। यो पछि थप्न धेरै गाह्रो छ, त्यसैले यो तुरुन्तै विकासमा ट्रेसिङ तालिका बनाउन राम्रो छ - यो विकासकर्ताहरूको काम र उपयोगिता हो। यदि तपाईंले यसलाई अहिलेसम्म लागू गर्नुभएको छैन भने, यसलाई लागू गर्नुहोस्! Jaeger/Zipkin हेर्नुहोस्

अलर्ट गर्दै

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

टेक्नोलोजी स्ट्याक

कल्पना गरौं कि हाम्रो स्ट्याक निम्नानुसार छ:

• डाटा संग्रह - प्रोमेथियस + ग्राफाना;
• लग विश्लेषण - ELK;
• APM वा ट्रेसिङका लागि - Jaeger (Zipkin)।

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

केहि प्राविधिक बिन्दुहरू जुन मैले भर्खरै जताततै देखेको छु:

प्रोमेथियसलाई कुबर्नेट्स भित्र धकेलिएको छ - कसले यो संग आयो?! यदि तपाईंको क्लस्टर क्र्यास भयो भने, तपाईं के गर्नुहुन्छ? यदि तपाईको भित्र जटिल क्लस्टर छ भने, त्यहाँ क्लस्टर भित्र कुनै प्रकारको निगरानी प्रणाली हुनुपर्छ, र केहि बाहिर, जसले क्लस्टर भित्रबाट डाटा सङ्कलन गर्नेछ।

क्लस्टर भित्र हामी लगहरू र अरू सबै सङ्कलन गर्छौं। तर अनुगमन प्रणाली बाहिर हुनुपर्छ। प्रायः, क्लस्टरमा जहाँ प्रोमथियस आन्तरिक रूपमा स्थापित छ, त्यहाँ साइटको सञ्चालनको बाह्य जाँच गर्ने प्रणालीहरू पनि छन्। यदि बाहिरी संसारमा तपाईंको जडानहरू घटेको छ र अनुप्रयोगले काम गर्दैन भने के हुन्छ? यो बाहिर जान्छ कि भित्र सबै ठीक छ, तर यसले प्रयोगकर्ताहरूको लागि चीजहरू सजिलो बनाउँदैन।

निष्कर्ष

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

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

यदि तपाइँ यसमा र सम्बन्धित विषयहरूमा मेरो विचार र विचारहरूमा रुचि राख्नुहुन्छ भने, तपाइँ यहाँ सक्नुहुन्छ च्यानल पढ्नुहोस् ????

स्रोत: www.habr.com