हामीले प्रोमेथियस, क्लिकहाउस र ELK मा कसरी निगरानी बनायौं

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

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

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

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

अन्तर्वार्ता प्रक्रियाको बखत, मैले बारम्बार देखेको छु कि प्रशासकहरू सधैं वेब अनुप्रयोगहरू सही रूपमा निगरानी गर्दैनन्: धेरैले अझै पनि अपरेटिङ सिस्टम मेट्रिक्स र कहिलेकाहीं सेवाहरू निगरानीमा ध्यान केन्द्रित गर्छन्।

मेरो मामलामा, ग्राहकको निगरानी प्रणाली पहिले Icinga मा आधारित थियो। यसले कुनै पनि हिसाबले माथिका समस्याहरू समाधान गर्न सकेन। प्रायः क्लाइन्ट आफैले हामीलाई समस्याहरूको बारेमा जानकारी गरायो, र प्रायः होइन, हामीसँग कारणको तल्लो भागमा पुग्न पर्याप्त डेटा थिएन।

थप रूपमा, यसको थप विकासको व्यर्थताको स्पष्ट बुझाइ थियो। मलाई लाग्छ Icinga सँग परिचित व्यक्तिहरूले मलाई बुझ्नेछन्। त्यसोभए, हामीले परियोजनाको लागि वेब अनुप्रयोग अनुगमन प्रणालीलाई पूर्ण रूपमा पुन: डिजाइन गर्ने निर्णय गर्यौं।

Prometheus

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

1. उपलब्ध मेट्रिक्स को एक विशाल संख्या। हाम्रो अवस्थामा ती मध्ये 60 हजार छन्। निस्सन्देह, यो ध्यान दिन लायक छ कि हामी ती मध्ये विशाल बहुमत (सम्भवतः लगभग 95%) प्रयोग गर्दैनौं। अर्कोतर्फ, तिनीहरू सबै अपेक्षाकृत सस्तो छन्। हाम्रो लागि, यो पहिले प्रयोग गरिएको Icinga को तुलनामा अर्को चरम हो। यसमा, मेट्रिकहरू थप्नु एक विशेष पीडा थियो: अवस्थितहरू महँगो थिए (केवल कुनै पनि प्लगइनको स्रोत कोड हेर्नुहोस्)। कुनै पनि प्लगइन Bash वा Python मा एक स्क्रिप्ट थियो, जसको सुरुवात स्रोत खपत को मामला मा महँगो छ।
2. यस प्रणालीले अपेक्षाकृत सानो मात्रामा स्रोतहरू खपत गर्दछ। 600 MB RAM, 15% एक कोर र दुई दर्जन IOPS हाम्रा सबै मेट्रिक्सका लागि पर्याप्त छन्। अवश्य पनि, तपाईंले मेट्रिक्स निर्यातकर्ताहरू चलाउनु पर्छ, तर तिनीहरू सबै Go मा लेखिएका छन् र धेरै शक्ति भोका छैनन्। मलाई लाग्दैन कि आधुनिक वास्तविकतामा यो समस्या हो।
3. Kubernetes मा माइग्रेट गर्ने क्षमता प्रदान गर्दछ। ग्राहकको योजनाहरू विचार गर्दै, छनौट स्पष्ट छ।

एल्क

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

क्लिकहाउस

सुरुमा, छनौट InfluxDB मा गिर्यो। हामीले Nginx लगहरू, pg_stat_statements बाट तथ्याङ्कहरू, र Prometheus ऐतिहासिक डेटा भण्डारण गर्ने आवश्यकता महसुस गर्यौं। हामीलाई Influx मन परेन किनभने यसले आवधिक रूपमा मेमोरीको ठूलो मात्रा उपभोग गर्न थाल्यो र क्र्यास भयो। थप रूपमा, म remote_addr द्वारा समूह प्रश्नहरू गर्न चाहन्थें, तर यस DBMS मा समूहीकरण ट्यागहरूद्वारा मात्र हो। ट्यागहरू महँगो छन् (मेमोरी), तिनीहरूको संख्या सशर्त सीमित छ।

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

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

न्यूरेलीक

NewRelic ऐतिहासिक रूपमा हामीसँग भएको छ किनभने यो ग्राहकको छनौट थियो। हामी यसलाई APM को रूपमा प्रयोग गर्छौं।

Zabbix

हामी विभिन्न API को ब्ल्याक बक्स निगरानी गर्न विशेष रूपमा Zabbix प्रयोग गर्छौं।

अनुगमन दृष्टिकोण परिभाषित गर्दै

हामीले कार्यलाई विघटन गर्न र यसरी अनुगमन गर्ने दृष्टिकोणलाई व्यवस्थित गर्न चाहन्थ्यौं।

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

• हार्डवेयर र VMS;
• अपरेटिङ सिस्टम;
• प्रणाली सेवा, सफ्टवेयर स्ट्याक;
• आवेदन;
• व्यापार तर्क।

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

• हामीलाई थाहा छ कि प्रत्येक स्तरको कामको लागि को जिम्मेवार छ र, यसको आधारमा, हामी अलर्टहरू पठाउन सक्छौं;
• अलर्टहरू दमन गर्दा हामी संरचना प्रयोग गर्न सक्छौं - भर्चुअल मेसिन पूर्ण रूपमा अनुपलब्ध हुँदा डाटाबेस अनुपलब्धताको बारेमा अलर्ट पठाउनु अनौठो हुनेछ।

हाम्रो कार्य प्रणालीको सञ्चालनमा उल्लङ्घनहरू पहिचान गर्ने भएकोले, हामीले प्रत्येक स्तरमा मेट्रिक्सको निश्चित सेटलाई हाइलाइट गर्नुपर्छ जुन सतर्कता नियमहरू लेख्दा ध्यान दिन लायक छ। अर्को, "VMS", "अपरेटिङ सिस्टम" र "सिस्टम सेवाहरू, सफ्टवेयर स्ट्याक" स्तरहरू मार्फत जाऔं।

भर्चुअल मेसिनहरू

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

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

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

IOPS + CPU iowait समय - केहि कारणका लागि, धेरै क्लाउड होस्टिंगहरूले पर्याप्त IOPS प्रदान नगरेर पाप गर्छन्। यसबाहेक, कम IOPS भएको तालिका तिनीहरूको लागि तर्क होइन। त्यसैले, यो CPU iowait सङ्कलन लायक छ। ग्राफहरूको यो जोडीसँग - कम IOPS र उच्च I/O पर्खाइको साथ - तपाइँ पहिले नै होस्टिङसँग कुरा गर्न सक्नुहुन्छ र समस्या समाधान गर्न सक्नुहुन्छ।

अपरेटिङ सिस्टम

अपरेटिङ सिस्टम मेट्रिक्स:

• % मा उपलब्ध मेमोरी को मात्रा;
• स्वैप उपयोग गतिविधि: vmstat swapin, swapout;
• % मा फाइल प्रणालीमा उपलब्ध इनोडहरू र खाली ठाउँहरूको सङ्ख्या
• औसत लोड;
• दुई राज्यमा जडानहरूको संख्या;
• कन्ट्र्याक तालिका पूर्णता;
• नेटवर्कको गुणस्तर ss उपयोगिता, iproute2 प्याकेज प्रयोग गरेर अनुगमन गर्न सकिन्छ - यसको आउटपुटबाट RTT जडानहरूको सूचक प्राप्त गर्नुहोस् र यसलाई गन्तव्य पोर्टद्वारा समूहबद्ध गर्नुहोस्।

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

मेट्रिक्स को सेट निम्नानुसार छ:

• सि.पी. यु;
• मेमोरी मुख्य रूपमा निवासी हो;
• IO - अधिमानतः IOPS मा;
• FileFd - खुला र सीमा;
• महत्त्वपूर्ण पृष्ठ विफलताहरू - यस तरिकाले तपाइँ कुन प्रक्रिया स्वैप भइरहेको छ भनेर बुझ्न सक्नुहुन्छ।

हामी डकरमा सबै निगरानी तैनाथ गर्छौं, र हामी मेट्रिक्स डेटा सङ्कलन गर्न सल्लाहकार प्रयोग गर्छौं। अन्य मेसिनहरूमा हामी प्रक्रिया-निर्यातकर्ता प्रयोग गर्छौं।

प्रणाली सेवाहरू, सफ्टवेयर स्ट्याक

प्रत्येक अनुप्रयोगको आफ्नै विशिष्टताहरू छन्, र मेट्रिक्सको एक निश्चित सेटलाई बाहिर निकाल्न गाह्रो छ।

विश्वव्यापी सेट हो:

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

यस स्तरमा निगरानीको हाम्रो सबैभन्दा उल्लेखनीय उदाहरणहरू Nginx र PostgreSQL हुन्।

हाम्रो प्रणालीमा सबैभन्दा लोड गरिएको सेवा डाटाबेस हो। विगतमा, डाटाबेसले के गरिरहेको छ भनेर पत्ता लगाउन हामीलाई प्राय: समस्या थियो।

हामीले डिस्कहरूमा उच्च भार देख्यौं, तर ढिलो लगहरूले वास्तवमा केहि देखाउँदैन। हामीले यो समस्या pg_stat_statements प्रयोग गरेर हल गर्यौं, क्वेरी तथ्याङ्क सङ्कलन गर्ने दृश्य।

यो सबै प्रशासक को आवश्यकता छ।

हामीले पढ्ने र लेख्ने अनुरोधहरूको गतिविधिको ग्राफहरू निर्माण गर्छौं:

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

समान रूपमा उल्लेखनीय उदाहरण Nginx लगहरू हो। यो अचम्मको कुरा होइन कि थोरै मानिसहरूले तिनीहरूलाई पार्स गर्छन् वा आवश्यक-अवश्यकताहरूको सूचीमा उल्लेख गर्छन्। मानक ढाँचा धेरै जानकारीपूर्ण छैन र विस्तार गर्न आवश्यक छ।

व्यक्तिगत रूपमा, मैले request_time, upstream_response_time, body_bytes_sent, request_length, request_id थपे। हामी प्रतिक्रिया समय र त्रुटिहरूको संख्या प्लट गर्छौं:

हामी प्रतिक्रिया समय र त्रुटिहरूको संख्याको ग्राफहरू निर्माण गर्छौं। सम्झनु? के मैले व्यापारिक कार्यहरूको बारेमा कुरा गरें? छिटो र त्रुटि बिना? हामीले यी मुद्दाहरूलाई दुईवटा चार्टहरूसँग समेटेका छौं। र तपाइँ पहिले नै तिनीहरूलाई प्रयोग गरेर ड्यूटीमा प्रशासकहरूलाई कल गर्न सक्नुहुन्छ।

तर एउटा थप समस्या बाँकी छ - घटना को कारण को छिटो उन्मूलन सुनिश्चित गर्न।

घटना समाधान

समस्याको पहिचान देखि समाधान सम्मको सम्पूर्ण प्रक्रियालाई धेरै चरणहरूमा विभाजन गर्न सकिन्छ:

• समस्या पहिचान;
• कर्तव्य प्रशासकलाई सूचना;
• घटना को प्रतिक्रिया;
• कारणहरूको उन्मूलन।

यो महत्त्वपूर्ण छ कि हामीले यसलाई सकेसम्म चाँडो गर्नुपर्छ। र यदि समस्या पहिचान गर्ने र अधिसूचना पठाउने चरणहरूमा हामीले धेरै समय प्राप्त गर्न सक्दैनौं - कुनै पनि अवस्थामा दुई मिनेट तिनीहरूमा खर्च गरिनेछ, त्यसपछि पछिका व्यक्तिहरू मात्र सुधारको लागि अनप्लोड फिल्ड हुन्।

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

हामीले सूचनाको पाठमा यी सबै जानकारीहरू मात्र समावेश गर्छौं, यसलाई विकि पृष्ठमा लिङ्क दिनुहोस् जसले यस समस्यालाई कसरी प्रतिक्रिया दिने, यसलाई कसरी समाधान गर्ने र यसलाई बढाउने वर्णन गर्दछ।

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

केही अंक।

पहिले, संरचित लगहरू लेख्नुहोस्। सन्देशको पाठमा सन्दर्भ समावेश गर्न आवश्यक छैन। यसले तिनीहरूलाई समूह र विश्लेषण गर्न गाह्रो बनाउँछ। Logstash ले यी सबैलाई सामान्य बनाउन लामो समय लिन्छ।

दोस्रो, गम्भीरता स्तरहरू सही रूपमा प्रयोग गर्नुहोस्। प्रत्येक भाषाको आफ्नै मापदण्ड हुन्छ। व्यक्तिगत रूपमा, म चार स्तरहरू छुट्याउँछु:

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

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

यदि तपाइँको सम्पूर्ण व्यवसाय ब्राउजरमा एक बटन हो भने, तपाइँले यसलाई क्लिक गर्दछ र ठीकसँग काम गर्दछ कि भनेर निगरानी गर्न आवश्यक छ। बाँकी सबैले फरक पर्दैन।

यदि तपाइँसँग यो छैन भने, तपाइँ यसलाई अनुप्रयोग लगहरू, Nginx लगहरू, र यस्तै अन्यमा समात्न प्रयास गर्न सक्नुहुन्छ, हामीले गरेझैं। तपाईं सकेसम्म अनुप्रयोगको नजिक हुनुपर्छ।

अपरेटिङ सिस्टम मेट्रिक्स पक्कै पनि महत्त्वपूर्ण छन्, तर व्यापार तिनीहरूमा रुचि छैन, हामीलाई तिनीहरूको लागि भुक्तान गरिएको छैन।

स्रोत: www.habr.com