PagerDuty, किंवा ऑपरेशन विभाग रात्री झोपू शकत नाही का

प्रणाली जितकी अधिक क्लिष्ट असेल तितकी ती सर्व प्रकारच्या सूचनांसह अतिवृद्ध होते. आणि या समान इशाऱ्यांवर प्रतिक्रिया देण्याची, एकत्रित करण्याची आणि त्यांची कल्पना करण्याची गरज आहे. मला वाटते की ही अशी परिस्थिती आहे जी अनेकांना अस्वस्थतेपर्यंत परिचित आहे.

ज्या समाधानावर चर्चा केली जाईल ती सर्वात अनपेक्षित नाही, परंतु शोध या विषयावरील पूर्ण लेख परत देत नाही.

म्हणून, मी FunCorp चा अनुभव सामायिक करण्याचे ठरवले आणि कर्तव्य प्रक्रियेची रचना कशी केली जाते, कोण कॉल करते, का आणि तुम्ही हे सर्व कसे पाहू शकता याबद्दल बोलायचे.

PagerDuty म्हणजे काय?

म्हणून, या सर्व समस्या सोडवण्यासाठी, आम्ही एक सोयीस्कर साधन शोधू लागलो. काही शोध घेतल्यानंतर, आम्ही PagerDuty निवडले. PD आम्हाला मोठ्या संख्येने एकत्रीकरण आणि सेटिंग्जसह एक पूर्ण आणि संक्षिप्त समाधान वाटले. तिला काय आवडते?

थोडक्यात, PagerDuty एक घटना प्रक्रिया प्लॅटफॉर्म आहे जे विविध एकत्रीकरणाद्वारे येणार्‍या घटनांवर प्रक्रिया करू शकते, ड्यूटी ऑर्डर सेट करू शकते आणि त्यानंतर घटनेच्या पातळीनुसार कर्तव्यावर असलेल्या अभियंत्याला सतर्क करू शकते (उच्च स्तरावर - कॉल, निम्न स्तरावर - ऍप्लिकेशन / एसएमएस कडून पुश) .

कर्तव्य अधिकारी कोण आहे?

पीडी सेट करणे सुरू करण्यासाठी हे कदाचित पहिले ठिकाण आहे.

फनकॉर्पमध्ये, इतर कंपन्यांप्रमाणे, कर्तव्य अधिकाऱ्याचे मानद पद आहे. हे दिवसातून एकदा अभियंता ते अभियंता प्रसारित केले जाते. PagerDuty कडील अलर्टला प्रतिसादाची तथाकथित पहिली आणि दुसरी ओळ आहे. समजा उच्च-प्राधान्य इशारा आला, आणि पहिल्या ओळीतून कर्तव्य अधिकाऱ्याला कॉल केल्यानंतर 10 मिनिटांनंतर त्यावर कोणतीही प्रतिक्रिया आली नाही (म्हणजे, ती पोचपावती किंवा निराकरण स्थितीत हस्तांतरित केली जात नाही), तर कॉल दुसऱ्या क्रमांकावर जाईल. कर्तव्य अभियंता. हे एस्केलेशन धोरणांद्वारे स्वतः PagerDuty मध्ये कॉन्फिगर केले आहे.

द्वितीय कर्तव्य अधिकारी प्रतिसाद देत नसल्यास, अधिसूचना परत येईल मुख्य कर्तव्य अधिकाऱ्याला.

अशा प्रकारे, कोणतीही येणारी उच्च प्राधान्य सूचना प्रक्रिया न करता राहू शकत नाही. 

आता घटना कुठून येऊ शकतात ते पाहू.

आम्ही कोणते एकत्रीकरण वापरतो?

पीडीला विविध सेवांमधून अनेक वेगवेगळ्या घटना प्राप्त होतात. आमच्याकडे सध्या अशा सुमारे 25 सेवा आहेत आणि त्यांच्यावर प्रक्रिया करण्यासाठी आम्ही काही रेडीमेड इंटिग्रेशन वापरतो.

• Prometheus

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

• ई-मेल

येथे देखील, मला वाटते, शीर्षकावरून सर्व काही स्पष्ट आहे. क्रॉनद्वारे कार्यान्वित केलेल्या काही स्क्रिप्टमधून सूचना पाठवण्यासाठी हे एकत्रीकरण वापरले जाते. पीडी तुम्हाला एक विशिष्ट पत्ता देतो ज्यावर तुम्ही पत्र पाठवता. अशा समाकलनासह सेवा तयार करताना, आपण प्राधान्यक्रम सेट करू शकता, येणार्‍या घटनांवर कोणत्या क्रमाने प्रक्रिया केली जाईल, एक अलर्ट नेमका कसा तयार करावा (प्रत्येक येणार्या पत्रासाठी, येणार्‍या पत्रासाठी + विशिष्ट नियम इ.).

• मंदीचा काळ

माझ्या मते, एक अतिशय मनोरंजक एकत्रीकरण. असे काही वेळा असतात जेव्हा एखादी गोष्ट घडते परंतु घटनांनी कव्हर केले जात नाही. म्हणून, घटना तयार करण्यासाठी आम्ही स्लॅकमधून एकत्रीकरण जोडले. म्हणजेच, तुम्ही कॉर्पोरेट स्लॅकला लिहू शकता /callofduty सर्वकाही मंद आहे आणि लवकरच खंडित होईल आणि PD त्यावर प्रक्रिया करेल आणि घटना कर्तव्य अभियंत्याकडे पाठवेल.

आम्ही करू:

आम्ही ते पाहू:

• API

HTTP एकत्रीकरण. खरं तर, येथे विशेष मनोरंजक काहीही नाही, फक्त JSON स्वरूपात मुख्य भाग असलेली पोस्ट विनंती. उदाहरणार्थ, काहीतरी मनोरंजक: आम्ही ते वापरून बाह्य निरीक्षणासाठी वापरतो https://www.statuscake.com/. ही सेवा जगाच्या विविध भागांतून आमच्या साइट्सची प्रवेशयोग्यता तपासते. जेव्हा आम्हाला एक अस्वीकार्य प्रतिसाद कोड प्राप्त होतो (उदाहरणार्थ, 502), एक घटना तयार केली जाते आणि नंतर सर्व काही वर वर्णन केलेल्या साखळीचे अनुसरण करते. स्टेटसकेकमध्ये स्वतः अंतर्गत URL, SSL प्रमाणपत्र किंवा डोमेन कालबाह्यतेचे निरीक्षण करण्याची क्षमता आहे.

• LibreNMS

ही दुसरी मॉनिटरिंग सिस्टम आहे, तुम्ही त्यांच्या वेबसाइटवर त्याबद्दल अधिक वाचू शकता https://www.librenms.org/. त्याच्या मदतीने, आम्ही सर्व्हरवरून नेटवर्क इंटरफेस आणि iDRAC चे निरीक्षण करतो.

डेटाडॉग, क्लाउडवॉच सारखे एकत्रीकरण देखील होते. त्यांचे काय झाले याबद्दल तुम्ही अधिक पाहू शकता येथे.

व्हिज्युअलायझेशन

मुख्य घटना अहवाल प्रणाली स्लॅक आहे. PD वर येणार्‍या सर्व घटना एका खास चॅटवर लिहिल्या जातात आणि जर त्यांची स्थिती बदलली तर हे देखील चॅटमध्ये प्रदर्शित केले जाते.

जेव्हा छतावरून लटकलेल्या मॉनिटर्सच्या स्क्रीनवर उपयुक्त डेटा प्रदर्शित करण्याची संधी आली तेव्हा आम्हाला अचानक लक्षात आले की आमच्याकडे (डेव्हॉप्स विभागात) प्रदर्शित करण्यासाठी काहीही नव्हते. एक अद्भुत ग्राफना आहे, परंतु ते सर्व काही कव्हर करत नाही आणि कर्मचारी अलर्टवर प्रतिक्रिया देतात, चार्टवर नाही.

PD साठी संक्षिप्त आणि माहितीपूर्ण “बोर्ड” साठी GitHub वर सखोल परंतु अयशस्वी शोध घेतल्यानंतर, आम्ही आमचे स्वतःचे लिहिण्याचे ठरवले - फक्त आम्हाला आवश्यक असलेल्या गोष्टींसह. जरी सुरुवातीला PD इंटरफेस स्वतः प्रदर्शित करण्याची कल्पना होती, तरीही ते अधिक गैरसोयीचे वाटले.

ते लिहिण्यासाठी, तुम्हाला फक्त वाचनीय अधिकार असलेल्या PD कडून एक की मिळवायची आहे.
आणि आम्हाला हे मिळाले:

स्क्रीन वर्तमान खुल्या घटना, निवडलेल्या शेड्यूलमधून कर्तव्यावर असलेल्या वर्तमान अभियंत्याचे नाव आणि उच्च प्राधान्य घटना नसलेली वेळ (उच्च प्राधान्य घटना असलेले पॅनेल लाल रंगात हायलाइट केले जाईल) प्रदर्शित करते.

या अंमलबजावणीचे स्रोत येथे पहा.

परिणामी, आम्हाला आमच्या सर्व घटना पाहण्यासाठी एक सोयीस्कर डॅशबोर्ड मिळाला. तुमच्यापैकी काहींना आमचा अनुभव उपयुक्त वाटला तर मला आनंद होईल.

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