आम्ही Prometheus, Clickhouse आणि ELK वर देखरेख कशी तयार केली

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

कोणत्याही देखरेख व्यवस्थेचा आधारस्तंभ म्हणजे व्यवसायातील समस्या सोडवणे. देखरेखीसाठी निगराणी करणे कोणालाच रुचत नाही. व्यवसायाला काय हवे आहे? जेणेकरून सर्व काही त्वरीत आणि त्रुटींशिवाय कार्य करते. व्यवसायांना सक्रिय व्हायचे आहे, जेणेकरून आम्ही स्वतः सेवेतील समस्या ओळखू आणि शक्य तितक्या लवकर त्यांचे निराकरण करू. या, खरं तर, आमच्या ग्राहकांपैकी एकाच्या प्रोजेक्टवर मी गेल्या वर्षी सोडवलेल्या समस्या आहेत.

प्रकल्पाबद्दल

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

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

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

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

Prometheus

आम्ही तीन मुख्य निर्देशकांवर आधारित प्रोमिथियस निवडले:

1. उपलब्ध मेट्रिक्सची मोठी संख्या. आमच्या बाबतीत त्यापैकी 60 हजार आहेत. अर्थात, हे लक्षात घेण्यासारखे आहे की आम्ही त्यापैकी बहुसंख्य (कदाचित सुमारे 95%) वापरत नाही. दुसरीकडे, ते सर्व तुलनेने स्वस्त आहेत. आमच्यासाठी, पूर्वी वापरलेल्या Icinga च्या तुलनेत हे दुसरे टोक आहे. त्यामध्ये, मेट्रिक्स जोडणे ही एक विशिष्ट वेदना होती: विद्यमान महाग होते (फक्त कोणत्याही प्लगइनचा स्त्रोत कोड पहा). कोणतेही प्लगइन हे बॅश किंवा पायथन मधील स्क्रिप्ट होते, ज्याचे लाँच वापरलेल्या संसाधनांच्या दृष्टीने महाग आहे.
2. ही प्रणाली तुलनेने कमी प्रमाणात संसाधने वापरते. 600 MB RAM, 15% एक कोर आणि दोन डझन IOPS आमच्या सर्व मेट्रिक्ससाठी पुरेसे आहेत. अर्थात, तुम्हाला मेट्रिक्स एक्सपोर्टर्स चालवावे लागतील, परंतु ते सर्व गो मध्ये लिहिलेले आहेत आणि ते फारसे पॉवर हँगरी नाहीत. मला वाटत नाही की आधुनिक वास्तवात ही समस्या आहे.
3. कुबर्नेट्समध्ये स्थलांतर करण्याची क्षमता प्रदान करते. ग्राहकांच्या योजना लक्षात घेता, निवड स्पष्ट आहे.

अल्क

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

क्लिकहाऊस

सुरुवातीला, निवड InfluxDB वर पडली. आम्हाला Nginx लॉग, pg_stat_statements वरून आकडेवारी आणि Prometheus ऐतिहासिक डेटा संग्रहित करण्याची आवश्यकता लक्षात आली. आम्हाला इन्फ्लक्स आवडले नाही कारण ते अधूनमधून मोठ्या प्रमाणात मेमरी वापरू लागले आणि क्रॅश झाले. या व्यतिरिक्त, मला रिमोट_एडीडीआर द्वारे प्रश्नांचे गट करायचे होते, परंतु या डीबीएमएसमध्ये गटबद्ध करणे केवळ टॅगद्वारे आहे. टॅग महाग आहेत (मेमरी), त्यांची संख्या सशर्त मर्यादित आहे.

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

क्लिकहाऊस हे सर्व निकष पूर्ण करते आणि आम्हाला आमच्या निवडीबद्दल कधीही पश्चाताप झाला नाही. आम्ही त्यात कोणत्याही विलक्षण प्रमाणात डेटा लिहित नाही (इन्सर्टेशनची संख्या फक्त पाच हजार प्रति मिनिट आहे).

NewRelic

NewRelic ऐतिहासिकदृष्ट्या आमच्यासोबत आहे कारण ती ग्राहकांची निवड होती. आम्ही ते एपीएम म्हणून वापरतो.

झब्बीक्स

आम्ही विविध 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 मध्ये;
• फाइलएफडी - उघडा आणि मर्यादा;
• महत्त्वपूर्ण पृष्ठ अयशस्वी - अशा प्रकारे आपण समजू शकता की कोणती प्रक्रिया बदलली जात आहे.

आम्ही डॉकरमध्ये सर्व मॉनिटरिंग तैनात करतो आणि मेट्रिक्स डेटा गोळा करण्यासाठी आम्ही सल्लागार वापरतो. इतर मशीनवर आम्ही प्रोसेस-एक्सपोर्टर वापरतो.

सिस्टम सेवा, सॉफ्टवेअर स्टॅक

प्रत्येक अनुप्रयोगाची स्वतःची वैशिष्ट्ये आहेत आणि मेट्रिक्सचा एक विशिष्ट संच एकल करणे कठीण आहे.

सार्वत्रिक संच आहे:

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

या स्तरावरील देखरेखीची आमची सर्वात उल्लेखनीय उदाहरणे Nginx आणि PostgreSQL आहेत.

आमच्या सिस्टममध्ये सर्वात जास्त लोड केलेली सेवा डेटाबेस आहे. भूतकाळात, डेटाबेस काय करत आहे हे शोधण्यात आम्हाला अनेकदा समस्या येत होत्या.

आम्ही डिस्कवर उच्च भार पाहिला, परंतु हळू लॉग खरोखर काहीही दर्शवत नाहीत. आम्ही ही समस्या pg_stat_statements वापरून सोडवली, एक दृश्य जे क्वेरी आकडेवारी गोळा करते.

एवढीच अ‍ॅडमिनची गरज आहे.

आम्ही विनंत्या वाचणे आणि लिहिण्याच्या क्रियाकलापांचे आलेख तयार करतो:

सर्व काही सोपे आणि स्पष्ट आहे, प्रत्येक विनंतीचा स्वतःचा रंग आहे.

तितकेच उल्लेखनीय उदाहरण म्हणजे Nginx लॉग. हे आश्चर्यकारक नाही की काही लोक त्यांचे विश्लेषण करतात किंवा आवश्यक असलेल्या यादीमध्ये त्यांचा उल्लेख करतात. मानक स्वरूप फार माहितीपूर्ण नाही आणि विस्तारित करणे आवश्यक आहे.

वैयक्तिकरित्या, मी request_time, upstream_response_time, body_bytes_sent, request_length, request_id जोडले. आम्ही प्रतिसाद वेळ आणि त्रुटींची संख्या प्लॉट करतो:

आम्ही प्रतिसाद वेळ आणि त्रुटींची संख्या यांचा आलेख तयार करतो. आठवतंय? मी व्यवसायाच्या उद्दिष्टांबद्दल बोललो का? त्वरीत आणि त्रुटींशिवाय? आम्ही आधीच दोन तक्त्यांसह या समस्यांचा समावेश केला आहे. आणि तुम्ही त्यांचा वापर करून आधीच प्रशासकांना कर्तव्यावर कॉल करू शकता.

परंतु आणखी एक समस्या उरली आहे - घटनेच्या कारणांचे जलद निर्मूलन सुनिश्चित करण्यासाठी.

घटनेचे निराकरण

समस्या ओळखण्यापासून ते सोडवण्यापर्यंतची संपूर्ण प्रक्रिया अनेक चरणांमध्ये विभागली जाऊ शकते:

• समस्या ओळखणे;
• कर्तव्य प्रशासकास सूचना;
• घटनेला प्रतिसाद;
• कारणे दूर करणे.

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

कल्पना करूया की ड्युटी ऑफिसरचा फोन वाजला. तो काय करणार? प्रश्नांची उत्तरे शोधा - काय तोडले, ते कुठे फुटले, कसे प्रतिक्रिया द्यायची? आम्ही या प्रश्नांची उत्तरे कशी देतो ते येथे आहे:

आम्ही ही सर्व माहिती फक्त अधिसूचनेच्या मजकुरात समाविष्ट करतो, या समस्येला प्रतिसाद कसा द्यायचा, त्याचे निराकरण कसे करावे आणि ते कसे वाढवायचे याचे वर्णन करणाऱ्या विकी पृष्ठाची लिंक देतो.

मी अजुनही ऍप्लिकेशन लेयर आणि बिझनेस लॉजिक बद्दल काहीही बोललो नाही. दुर्दैवाने, आमचे अॅप्लिकेशन अद्याप मेट्रिक्स संकलनाची अंमलबजावणी करत नाहीत. या स्तरावरील कोणत्याही माहितीचा एकमेव स्त्रोत म्हणजे लॉग.

एक दोन गुण.

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

दुसरे म्हणजे, तीव्रता पातळी योग्यरित्या वापरा. प्रत्येक भाषेचा स्वतःचा दर्जा असतो. वैयक्तिकरित्या, मी चार स्तरांमध्ये फरक करतो:

1. कोणतीही त्रुटी नाही;
2. क्लायंट साइड त्रुटी;
3. चूक आमच्या बाजूने आहे, आम्ही पैसे गमावत नाही, आम्ही जोखीम पत्करत नाही;
4. चूक आमच्या बाजूने आहे, आम्ही पैसे गमावतो.

मी सारांश देतो. तुम्हाला व्यवसायाच्या तर्कावर आधारित निरीक्षण तयार करण्याचा प्रयत्न करणे आवश्यक आहे. ऍप्लिकेशनचे स्वतःच निरीक्षण करण्याचा प्रयत्न करा आणि विक्रीची संख्या, नवीन वापरकर्ता नोंदणीची संख्या, सध्या सक्रिय वापरकर्त्यांची संख्या आणि यासारख्या मेट्रिक्ससह कार्य करा.

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

तुमच्याकडे हे नसल्यास, तुम्ही ते ऍप्लिकेशन लॉग्स, Nginx लॉग्स आणि अशाच प्रकारे पकडण्याचा प्रयत्न करू शकता, जसे आम्ही केले. आपण अनुप्रयोगाच्या शक्य तितक्या जवळ असले पाहिजे.

ऑपरेटिंग सिस्टीमचे मेट्रिक्स अर्थातच महत्त्वाचे आहेत, परंतु व्यवसायाला त्यांच्यामध्ये रस नाही, आम्हाला त्यांच्यासाठी पैसे दिले जात नाहीत.

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