❕ 🚺 👩🏾‍🤝‍👩🏻 हमने प्रोमेथियस, क्लिकहाउस और ईएलके पर निगरानी कैसे बनाई 👦🏿 💜 🕧

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

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

परियोजना के बारे में

यह परियोजना देश के सबसे बड़े वफादारी कार्यक्रमों में से एक है। हम खुदरा विक्रेताओं को बोनस कार्ड जैसे विभिन्न मार्केटिंग टूल के माध्यम से अपनी बिक्री आवृत्ति बढ़ाने में मदद करते हैं। कुल में, परियोजना में दस सर्वरों पर चलने वाले 14 अनुप्रयोग शामिल हैं।

साक्षात्कार आयोजित करने की प्रक्रिया में, मैंने बार-बार ध्यान दिया है कि प्रवेश हमेशा वेब अनुप्रयोगों की निगरानी ठीक से दूर है: अब तक, कई ऑपरेटिंग सिस्टम मेट्रिक्स और कभी-कभी सेवाओं की निगरानी पर रोक दिए हैं।

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

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

प्रोमेथियस

हमने तीन प्रमुख संकेतकों के आधार पर प्रोमेथियस को चुना:

उपलब्ध मेट्रिक्स की एक बड़ी संख्या। हमारे मामले में, उनमें से 60 हजार हैं। बेशक, यह ध्यान देने योग्य है कि उनमें से अधिकांश हम उपयोग नहीं करते हैं (शायद लगभग 95%)। दूसरी ओर, वे सभी अपेक्षाकृत सस्ते हैं। हमारे लिए, यह पहले से इस्तेमाल किए गए Icinga की तुलना में एक और चरम है। इसमें, मैट्रिक्स को जोड़ना एक विशेष दर्द था: उपलब्ध वाले महंगे थे (बस किसी भी प्लगइन के स्रोत कोड को देखें)। कोई भी प्लग-इन एक बैश या पायथन लिपि थी, जिसका लॉन्च उपभोग संसाधनों के लिहाज से सस्ता नहीं है।
यह प्रणाली अपेक्षाकृत कम मात्रा में संसाधनों का उपभोग करती है। हमारे सभी मेट्रिक्स में 600 एमबी रैम, 15% एक कोर और एक दर्जन आईओपीएस हैं। बेशक, आपको मेट्रिक्स के निर्यातकों को चलाना होगा, लेकिन वे सभी गो में लिखे गए हैं और लोलुपता में भी भिन्न नहीं हैं। मुझे नहीं लगता कि आधुनिक वास्तविकताओं में यह कोई समस्या है।
यह कुबेरनेट्स पर स्विच करना संभव बनाता है। ग्राहक की योजनाओं को देखते हुए, चुनाव स्पष्ट है।

ELK

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

Slickhouse

प्रारंभ में, विकल्प InfluxDB पर गिर गया। हमने Nginx लॉग, pg_stat_statements के आंकड़े, और Prometheus ऐतिहासिक डेटा संग्रहीत करने की आवश्यकता को पहचान लिया। हमें इन्फ्लूक्स पसंद नहीं आया, क्योंकि यह समय-समय पर बड़ी मात्रा में मेमोरी का उपभोग करने लगा और दुर्घटनाग्रस्त हो गया। इसके अलावा, मैं Remote_addr द्वारा अनुरोधों को समूहित करना चाहता था, और केवल टैग द्वारा इस DBMS में समूहीकरण करना चाहता था। सड़क (मेमोरी) का टैग, उनकी संख्या सशर्त रूप से सीमित है।

हमने फिर से खोज शुरू की। हमें न्यूनतम संसाधन खपत के साथ एक विश्लेषणात्मक आधार की आवश्यकता थी, अधिमानतः डिस्क पर डेटा संपीड़न के साथ।

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

NewRelic

NewRelic ऐतिहासिक रूप से हमारे साथ रहा है क्योंकि यह ग्राहक की पसंद था। हम इसे एपीएम के रूप में उपयोग करते हैं।

Zabbix

हम विभिन्न APIs के ब्लैक बॉक्स की निगरानी के लिए विशेष रूप से Zabbix का उपयोग करते हैं।

एक निगरानी दृष्टिकोण को परिभाषित करना

हम कार्य को समाप्त करना चाहते थे और इस तरह निगरानी के दृष्टिकोण को व्यवस्थित करते थे।

ऐसा करने के लिए, हमने हमारी प्रणाली को निम्न स्तरों में विभाजित किया है:

हार्डवेयर और वीएमएस;
ऑपरेटिंग सिस्टम
सिस्टम सेवाएं, सॉफ्टवेयर स्टैक;
आवेदन;
व्यापार तर्क।

क्या इस दृष्टिकोण को सुविधाजनक बनाता है:

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

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

वर्चुअल मशीनें

होस्टिंग हमें एक प्रोसेसर, डिस्क, मेमोरी और नेटवर्क देता है। और पहले दो के साथ हमें समस्याएं थीं। तो मीट्रिक:

सीपीयू चोरी का समय - जब आप अमेज़ॅन पर एक आभासी मशीन खरीदते हैं (उदाहरण के लिए t2.micro), तो आपको यह समझना चाहिए कि आपको एक पूरे प्रोसेसर कोर आवंटित नहीं किया गया है, लेकिन इसके समय का केवल एक कोटा। और जब आप इसे समाप्त करते हैं, तो प्रोसेसर आपसे लिया जाएगा।

यह मीट्रिक आपको ऐसे क्षणों को ट्रैक करने और निर्णय लेने की अनुमति देता है। उदाहरण के लिए, क्या यह आवश्यक है कि टैरिफ टेटर ले या एपीआई और विभिन्न सर्वरों में पृष्ठभूमि कार्यों के प्रसंस्करण को वितरित किया जाए।

IOPS + CPU iowait समय - किसी कारण से, कई क्लाउड होस्टिंग कंपनियां IOPS वितरित नहीं करके पाप करती हैं। इसके अलावा, कम आईओपीएस के साथ एक अनुसूची उनके लिए एक तर्क नहीं है। इसलिए, यह आयोवाइट सीपीयू इकट्ठा करने के लायक है। ग्राफ की इस जोड़ी के साथ - कम IOPS और उच्च I / O उम्मीदों के साथ - आप पहले से ही होस्टिंग से बात कर सकते हैं और समस्या को हल कर सकते हैं।

ऑपरेटिंग सिस्टम

ऑपरेटिंग सिस्टम मेट्रिक्स:

% में उपलब्ध स्मृति की मात्रा;
स्वैप का उपयोग कर गतिविधि: स्वमस्ट स्वेपिन, स्वैपआउट;
% में फ़ाइल सिस्टम पर उपलब्ध इनोड और मुक्त स्थान की संख्या
औसत भार;
बीस राज्य में कनेक्शन की संख्या;
संयोजक तालिका परिपूर्णता;
नेटवर्क की गुणवत्ता की निगरानी ss यूटिलिटी का उपयोग करके की जा सकती है, iproute2 पैकेज - इसके आउटपुट से प्राप्त होता है, जो कि आरटीटी कनेक्शनों का एक संकेतक है और डेस्ट-पोर्ट द्वारा समूह है।

ऑपरेटिंग सिस्टम के स्तर पर भी, प्रक्रियाओं के रूप में हमारे पास एक ऐसी इकाई है। सिस्टम में एक ऐसी प्रक्रिया को उजागर करना महत्वपूर्ण है जो इसके काम में महत्वपूर्ण भूमिका निभाती है। यदि, उदाहरण के लिए, आपके पास कई pgpool हैं, तो आपको उनमें से प्रत्येक के लिए जानकारी एकत्र करने की आवश्यकता है।

मैट्रिक्स का सेट इस प्रकार है:

सीपीयू;
स्मृति मुख्य रूप से निवासी है;
IO - अधिमानतः IOPS में;
FileFd - खुली और सीमा;
महत्वपूर्ण पृष्ठ विफलताओं - तो आप समझ सकते हैं कि क्या प्रक्रिया स्वैपिंग है।

सभी मॉनिटरिंग डॉकटर में तैनात है, हम मीट्रिक डेटा एकत्र करने के लिए advisor का उपयोग करते हैं। अन्य मशीनों पर, हम प्रक्रिया-निर्यातक का उपयोग करते हैं।

सिस्टम सर्विसेज, सॉफ्टवेयर स्टैक

प्रत्येक एप्लिकेशन की अपनी विशिष्टताएं होती हैं, और कुछ सेट मेट्रिक्स को भेद करना मुश्किल होता है।

यूनिवर्सल सेट हैं:

अनुरोध दर;
त्रुटियों की संख्या;
विलंबता;
संतृप्ति।

इस स्तर पर निगरानी के सबसे हड़ताली उदाहरण Nginx और PostgreSQL हैं।

हमारे सिस्टम में सबसे भरी हुई सेवा डेटाबेस है। डेटाबेस क्या करता है, यह जानने के लिए हमें अक्सर समस्याएँ आती थीं।

हमने डिस्क पर एक उच्च भार देखा, लेकिन नारे वास्तव में कुछ भी नहीं दिखाते थे। हमने इस समस्या को pg_stat_statements, एक दृष्टिकोण से हल किया है जो अनुरोधों पर आंकड़े एकत्र करता है।

यह सभी व्यवस्थापक की आवश्यकता है।

हम अनुरोध पढ़ने और लिखने की गतिविधि की साजिश रचते हैं:

सब कुछ सरल और स्पष्ट है, प्रत्येक अनुरोध का अपना रंग है।

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

व्यक्तिगत रूप से, मैंने request_time, upstream_response_time, body_bytes_sent, request_length, request_id को जोड़ा। हम प्रतिक्रिया समय और त्रुटियों की संख्या की साजिश करते हैं:

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

लेकिन एक और समस्या बनी हुई है - घटना के कारणों का त्वरित उन्मूलन सुनिश्चित करने के लिए।

हादसा प्रबंधन

किसी समस्या को हल करने की पहचान करने से लेकर पूरी प्रक्रिया को कई चरणों में विभाजित किया जा सकता है:

समस्या की पहचान;
ड्यूटी पर प्रशासक की अधिसूचना;
घटना की प्रतिक्रिया;
कारणों का उन्मूलन।

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

चलो बस कल्पना करें कि फोन ड्यूटी पर बजता है। वह क्या करेगा? प्रश्नों के उत्तर देखें - क्या टूटा है, कहां टूटा है, कैसे प्रतिक्रिया करें? यहां हम इन सवालों के जवाब देते हैं:

हम केवल सूचना पाठ में इस सभी जानकारी को शामिल करते हैं, इसे एक विकी पृष्ठ का लिंक देते हैं जो बताता है कि इस समस्या का जवाब कैसे दिया जाए, इसे कैसे हल किया जाए और आगे बढ़ाया जाए।

मैंने अभी भी एप्लिकेशन लेयर और बिजनेस लॉजिक के बारे में कुछ नहीं कहा है। दुर्भाग्य से, मैट्रिक्स संग्रह अभी तक हमारे अनुप्रयोगों में लागू नहीं किया गया है। इन स्तरों से कम से कम कुछ जानकारी का एकमात्र स्रोत लॉग्स हैं।

कुछ बिंदु।

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

दूसरे, गंभीरता स्तर का सही ढंग से उपयोग करें। प्रत्येक भाषा का अपना मानक होता है। व्यक्तिगत रूप से, मैं चार स्तरों में अंतर करता हूं:

कोई त्रुटि नहीं;
ग्राहक पक्ष की त्रुटि;
एक गलती हमारी तरफ है, हम पैसा नहीं खोते हैं, हम जोखिम नहीं उठाते हैं;
गलती हमारी तरफ है, हम पैसे खो रहे हैं।

मैं संक्षेप में बताता हूं। व्यवसाय तर्क से निगरानी की निर्माण करने की कोशिश करना आवश्यक है। एप्लिकेशन को स्वयं मॉनिटर करने की कोशिश करें और बिक्री की संख्या, नए उपयोगकर्ता पंजीकरण की संख्या, वर्तमान में सक्रिय उपयोगकर्ताओं की संख्या, और इसी तरह ऐसे मैट्रिक्स के साथ काम करें।

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

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

ऑपरेटिंग सिस्टम मैट्रिक्स निश्चित रूप से महत्वपूर्ण हैं, लेकिन वे व्यवसाय के लिए दिलचस्प नहीं हैं, हम उनके लिए भुगतान नहीं करते हैं।

हमने प्रोमेथियस, क्लिकहाउस और ईएलके पर निगरानी कैसे बनाई