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

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

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

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

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

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

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

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

प्रोमिथेउस

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

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

ELK

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

क्लिकहाउस

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

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

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

NewRelic

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

Zabbix

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

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

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

ऐसा करने के लिए, मैंने अपने सिस्टम को निम्नलिखित स्तरों में विभाजित किया:

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

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

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

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

आभाषी दुनिया

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

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

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

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

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

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

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

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

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

• CPU;
• स्मृति मुख्य रूप से निवासी है;
• आईओ - अधिमानतः आईओपीएस में;
• FileFd - खुला और सीमित;
• महत्वपूर्ण पृष्ठ विफलताएँ - इस तरह से आप समझ सकते हैं कि किस प्रक्रिया की अदला-बदली की जा रही है।

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

सिस्टम सेवाएँ, सॉफ़्टवेयर स्टैक

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

सार्वभौमिक सेट है:

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

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

हमारे सिस्टम में सबसे अधिक भरी हुई सेवा डेटाबेस है। पहले, हमें अक्सर यह पता लगाने में परेशानी होती थी कि डेटाबेस क्या कर रहा है।

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

व्यवस्थापक को बस इतना ही चाहिए.

हम पढ़ने और लिखने के अनुरोधों की गतिविधि के ग्राफ़ बनाते हैं:

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

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

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

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

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

घटना समाधान

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

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

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

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

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

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

कुछ बिंदु.

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

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

1. कोई ग़लती नहीं;
2. ग्राहक पक्ष त्रुटि;
3. गलती हमारी तरफ से है, हम पैसा नहीं खोते, हम जोखिम नहीं उठाते;
4. गलती हमारी तरफ से होती है, हम पैसे खो देते हैं।

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

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

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

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

स्रोत: www.habr.com