PagerDuty ឬហេតុអ្វីបានជានាយកដ្ឋានប្រតិបត្តិការមិនអាចគេងនៅពេលយប់

ប្រព័ន្ធកាន់តែស្មុគ្រស្មាញ វានឹងកាន់តែធំឡើងជាមួយនឹងការជូនដំណឹងគ្រប់ប្រភេទ។ ហើយចាំបាច់ត្រូវមានប្រតិកម្មចំពោះការដាស់តឿនដូចគ្នាទាំងនេះ ប្រមូលផ្តុំពួកវា និងមើលឃើញពួកវា។ ខ្ញុំ​គិត​ថា​នេះ​ជា​ស្ថានភាព​ដែល​មនុស្ស​ជា​ច្រើន​ធ្លាប់​ស្គាល់​រហូត​ដល់​មាន​ការ​ភ័យ​ខ្លាច។

ដំណោះស្រាយដែលនឹងត្រូវបានពិភាក្សាមិនមែនជាអ្វីដែលមិននឹកស្មានដល់បំផុតនោះទេ ប៉ុន្តែការស្វែងរកមិនត្រឡប់អត្ថបទពេញលេញលើប្រធានបទនេះទេ។

ដូច្នេះហើយ ខ្ញុំបានសម្រេចចិត្តចែករំលែកបទពិសោធន៍របស់ FunCorp ហើយនិយាយអំពីរបៀបដែលដំណើរការកាតព្វកិច្ចត្រូវបានរៀបចំឡើង អ្នកណាហៅទូរសព្ទ ហេតុអ្វី និងរបៀបដែលអ្នកអាចមើលវាបានទាំងអស់។

តើ PagerDuty ជាអ្វី?

ដូច្នេះ ដើម្បីដោះស្រាយបញ្ហាទាំងអស់នេះ យើងបានចាប់ផ្តើមស្វែងរកឧបករណ៍ងាយស្រួល។ បន្ទាប់ពីការស្វែងរកមួយចំនួន យើងបានជ្រើសរើស PagerDuty។ PD ហាក់បីដូចជាពួកយើងជាដំណោះស្រាយពេញលេញ និងសង្ខេបដោយមានការរួមបញ្ចូល និងការកំណត់មួយចំនួនធំ។ តើនាងដូចអ្វី?

សរុបមក PagerDuty គឺជាវេទិកាដំណើរការឧប្បត្តិហេតុដែលអាចដំណើរការឧប្បត្តិហេតុចូលមកតាមរយៈការរួមបញ្ចូលផ្សេងៗ រៀបចំការបញ្ជាទិញកាតព្វកិច្ច ហើយបន្ទាប់មកជូនដំណឹងដល់វិស្វករដែលបំពេញកាតព្វកិច្ចអាស្រ័យលើកម្រិតនៃឧប្បត្តិហេតុ (នៅកម្រិតខ្ពស់ - ការហៅទូរស័ព្ទនៅកម្រិតទាប - ការជំរុញពីកម្មវិធី / SMS) ។

តើអ្នកណាជាមន្ត្រីកាតព្វកិច្ច?

នេះប្រហែលជាកន្លែងដំបូងដើម្បីចាប់ផ្តើមដំឡើង PD ។

នៅ FunCorp ដូចក្រុមហ៊ុនផ្សេងទៀតដែរ មានតំណែងជាមន្ត្រីកិត្តិយស។ វាត្រូវបានបញ្ជូនពីវិស្វករទៅវិស្វករម្តងក្នុងមួយថ្ងៃ។ មាន​អ្វី​ដែល​ហៅ​ថា​ជា​ជួរ​ទី​មួយ​និង​ទីពីរ​នៃ​ការ​ឆ្លើយ​តប​ទៅ​នឹង​ការ​ជូន​ដំណឹង​ពី PagerDuty ។ ឧបមាថាការជូនដំណឹងជាអាទិភាពខ្ពស់មកដល់ ហើយប្រសិនបើ 10 នាទីបន្ទាប់ពីការហៅទៅកាន់មន្ត្រីកាតព្វកិច្ចពីជួរទីមួយនោះ មិនមានប្រតិកម្មចំពោះវាទេ (ឧ. វាមិនត្រូវបានផ្ទេរទៅស្ថានភាពទទួលស្គាល់ឬត្រូវបានដោះស្រាយទេ) ការហៅទូរស័ព្ទទៅទីពីរ វិស្វករកាតព្វកិច្ច។ នេះត្រូវបានកំណត់រចនាសម្ព័ន្ធនៅក្នុង PagerDuty ខ្លួនវាផ្ទាល់តាមរយៈគោលនយោបាយកើនឡើង។

ប្រសិនបើមន្ត្រីកាតព្វកិច្ចទីពីរមិនឆ្លើយតប ការជូនដំណឹងនឹងត្រឡប់ទៅវិញ។ មេ ទៅមន្រ្តីកាតព្វកិច្ច។

ដូច្នេះ ការជូនដំណឹងដែលមានអាទិភាពខ្ពស់ណាមួយដែលចូលមកមិនអាចនៅមិនទាន់ដំណើរការបានទេ។ 

ឥឡូវ​យើង​មើល​ថា​តើ​ឧបទ្ទវហេតុ​អាច​មក​ពី​ណា?

តើការរួមបញ្ចូលអ្វីខ្លះដែលយើងប្រើ?

PD ទទួលបានឧប្បត្តិហេតុផ្សេងៗគ្នាជាច្រើនពីសេវាកម្មផ្សេងៗ។ បច្ចុប្បន្នយើងមានសេវាកម្មបែបនេះប្រហែល 25 ហើយដើម្បីដំណើរការពួកវា យើងប្រើការរួមបញ្ចូលដែលត្រៀមរួចជាស្រេចមួយចំនួន។

• Prometheus

ប្រព័ន្ធប្រមូលម៉ែត្រសំខាន់ៗគឺ Prometheus ។ ជាច្រើនត្រូវបានសរសេររួចហើយអំពីវានៅលើ Habre ខ្ញុំគ្រាន់តែនិយាយថាយើងមានពួកវាជាច្រើនសម្រាប់បរិស្ថានផ្សេងៗគ្នា៖ មួយប្រមូលម៉ែត្រពីម៉ាស៊ីននិម្មិត និង dockers មួយទៀតមកពីសេវាកម្ម Amazon ទីបីពីម៉ាស៊ីនផ្នែករឹង។ Telegraf ត្រូវបានប្រើជាចម្បងជាអ្នកនាំចេញម៉ែត្រ។

• អ៊ីមែល

នៅទីនេះផងដែរខ្ញុំគិតថាអ្វីគ្រប់យ៉ាងគឺច្បាស់ពីចំណងជើង។ ការរួមបញ្ចូលនេះត្រូវបានប្រើដើម្បីផ្ញើការជូនដំណឹងពីស្គ្រីបមួយចំនួនដែលប្រតិបត្តិដោយ cron ។ PD ផ្តល់ឱ្យអ្នកនូវអាសយដ្ឋានជាក់លាក់មួយដែលអ្នកផ្ញើសំបុត្រ។ នៅពេលបង្កើតសេវាកម្មជាមួយនឹងការរួមបញ្ចូលបែបនេះ អ្នកអាចកំណត់អាទិភាព ថាតើឧប្បត្តិហេតុចូលមកក្នុងលំដាប់ណានឹងត្រូវបានដំណើរការ របៀបបង្កើតការជូនដំណឹង (សម្រាប់សំបុត្រចូលនីមួយៗ សម្រាប់សំបុត្រចូល + ច្បាប់ជាក់លាក់។ល។)។

• slack

នៅក្នុងគំនិតរបស់ខ្ញុំ, ការរួមបញ្ចូលគួរឱ្យចាប់អារម្មណ៍ខ្លាំងណាស់។ មាន​ពេល​ខ្លះ​កើត​ឡើង ប៉ុន្តែ​មិន​ត្រូវ​បាន​គ្រប​ដណ្តប់​ដោយ​ឧប្បត្តិហេតុ​ទេ។ ដូច្នេះហើយ យើងបានបន្ថែមការរួមបញ្ចូលពី Slack ដើម្បីបង្កើតឧប្បត្តិហេតុមួយ។ នោះគឺអ្នកអាចសរសេរទៅក្រុមហ៊ុន Slack / callofduty អ្វីគ្រប់យ៉ាងគឺយឺត ហើយនឹងខូចក្នុងពេលឆាប់ៗនេះ ហើយ PD នឹងដំណើរការវា ហើយបញ្ជូនឧប្បត្តិហេតុទៅវិស្វករកាតព្វកិច្ច។

យើង​ធ្វើ:

យើង​ឃើញ:

• ការ API

ការរួមបញ្ចូល HTTP ។ តាមពិតគ្មានអ្វីគួរឱ្យចាប់អារម្មណ៍នៅទីនេះទេ គ្រាន់តែជាសំណើ POST ដែលមានតួក្នុងទម្រង់ JSON ប៉ុណ្ណោះ។ ឧទាហរណ៍ អ្វីមួយដែលគួរឱ្យចាប់អារម្មណ៍៖ យើងប្រើវាសម្រាប់ការត្រួតពិនិត្យខាងក្រៅដោយប្រើ https://www.statuscake.com/. សេវាកម្មនេះពិនិត្យលទ្ធភាពប្រើប្រាស់គេហទំព័ររបស់យើងពីផ្នែកផ្សេងៗនៃពិភពលោក។ ក្នុងករណីនៅពេលដែលយើងទទួលបានលេខកូដឆ្លើយតបដែលមិនអាចទទួលយកបាន (ឧទាហរណ៍ 502) ឧប្បត្តិហេតុមួយត្រូវបានបង្កើតឡើង ហើយបន្ទាប់មកអ្វីៗទាំងអស់ធ្វើតាមខ្សែសង្វាក់ដែលបានពិពណ៌នាខាងលើ។ StatusCake ខ្លួនវាមានសមត្ថភាពត្រួតពិនិត្យ URL ខាងក្នុង វិញ្ញាបនបត្រ SSL ឬការផុតកំណត់ដែន។

• LibreNMS

នេះគឺជាប្រព័ន្ធត្រួតពិនិត្យមួយផ្សេងទៀត អ្នកអាចអានបន្ថែមអំពីវានៅលើគេហទំព័ររបស់ពួកគេ។ https://www.librenms.org/. ដោយមានជំនួយរបស់វា យើងត្រួតពិនិត្យចំណុចប្រទាក់បណ្តាញ និង iDRAC ពីម៉ាស៊ីនមេ។

វាក៏មានការរួមបញ្ចូលផងដែរដូចជា Datadog, CloudWatch ។ អ្នកអាចមើលបន្ថែមទៀតអំពីអ្វីដែលបានកើតឡើងចំពោះពួកគេ។ នៅទីនេះ.

ការមើលឃើញ

ប្រព័ន្ធរាយការណ៍ឧប្បត្តិហេតុសំខាន់គឺ Slack ។ ឧប្បត្តិហេតុទាំងអស់ដែលមកដល់ PD ត្រូវបានសរសេរទៅកាន់ការជជែកពិសេស ហើយប្រសិនបើស្ថានភាពរបស់ពួកគេផ្លាស់ប្តូរ នេះក៏ត្រូវបានបង្ហាញនៅក្នុងការជជែកផងដែរ។

នៅពេលដែលមានឱកាសបង្ហាញទិន្នន័យដែលមានប្រយោជន៍នៅលើអេក្រង់ម៉ូនីទ័រដែលព្យួរពីលើពិដាននោះ យើងស្រាប់តែដឹងថាយើង (នៅក្នុងនាយកដ្ឋាន devops) មិនមានអ្វីបង្ហាញនៅលើពួកវានោះទេ។ មាន Grafana ដ៏អស្ចារ្យ ប៉ុន្តែវាមិនគ្របដណ្តប់អ្វីគ្រប់យ៉ាងទេ ហើយបុគ្គលិកមានប្រតិកម្មចំពោះការជូនដំណឹង មិនមែនតារាងទេ។

បន្ទាប់ពីការស្វែងរកហ្មត់ចត់ប៉ុន្តែមិនទទួលបានជោគជ័យនៅលើ GitHub សម្រាប់ "ក្រុមប្រឹក្សា" សង្ខេបនិងផ្តល់ព័ត៌មានសម្រាប់ PD យើងបានសម្រេចចិត្តសរសេររបស់យើង - តែជាមួយអ្វីដែលយើងត្រូវការ។ ទោះបីជាដំបូងមានគំនិតដើម្បីបង្ហាញចំណុចប្រទាក់ PD ខ្លួនវាក៏ដោយវាមើលទៅកាន់តែមិនស្រួល។

ដើម្បីសរសេរវា អ្វីដែលអ្នកត្រូវធ្វើគឺទទួលបានកូនសោពី PD ដែលមានសិទ្ធិបានតែអានប៉ុណ្ណោះ។
ហើយនេះគឺជាអ្វីដែលយើងទទួលបាន៖

អេក្រង់បង្ហាញឧប្បត្តិហេតុបើកបច្ចុប្បន្ន ឈ្មោះវិស្វករបច្ចុប្បន្នកំពុងបំពេញកាតព្វកិច្ចពីកាលវិភាគដែលបានជ្រើសរើស និងពេលវេលាដែលគ្មានឧប្បត្តិហេតុអាទិភាពខ្ពស់ (បន្ទះដែលមានឧប្បត្តិហេតុអាទិភាពខ្ពស់នឹងត្រូវបានបន្លិចជាពណ៌ក្រហម)។

សូមមើលប្រភពនៃការអនុវត្តនេះនៅទីនេះ.

ជាលទ្ធផល យើងទទួលបានផ្ទាំងគ្រប់គ្រងងាយស្រួលសម្រាប់មើលឧប្បត្តិហេតុទាំងអស់របស់យើង។ ខ្ញុំនឹងរីករាយប្រសិនបើអ្នកខ្លះយល់ថាបទពិសោធន៍របស់យើងមានប្រយោជន៍។

ប្រភព: www.habr.com