Lebih kompleks sistem, lebih banyak ia menjadi ditumbuhi dengan semua jenis amaran. Dan terdapat keperluan untuk bertindak balas terhadap makluman yang sama ini, mengagregatnya dan memvisualisasikannya. Saya rasa ini adalah situasi yang biasa bagi ramai hingga gementar.
Penyelesaian yang akan dibincangkan bukanlah yang paling tidak dijangka, tetapi carian tidak mengembalikan artikel lengkap mengenai topik ini.
Oleh itu, saya memutuskan untuk berkongsi pengalaman FunCorp dan bercakap tentang cara proses kewajipan distrukturkan, siapa yang menelefon, mengapa dan bagaimana anda boleh melihat semuanya.
Apakah PagerDuty?
Jadi, untuk menyelesaikan semua masalah ini, kami mula mencari alat yang mudah. Selepas beberapa carian, kami memilih PagerDuty. PD nampaknya merupakan penyelesaian yang cukup lengkap dan ringkas dengan sejumlah besar penyepaduan dan tetapan. Apa yang dia suka?
Ringkasnya, PagerDuty ialah platform pemprosesan insiden yang boleh memproses insiden masuk melalui pelbagai integrasi, menyediakan pesanan tugas dan kemudian memberi amaran kepada jurutera yang bertugas bergantung pada tahap kejadian (pada tahap tinggi - panggilan, pada tahap rendah - tolakan daripada aplikasi / SMS) .
Siapa pegawai bertugas?
Ini mungkin tempat pertama untuk mula menyediakan PD.
Di FunCorp, seperti syarikat lain, terdapat jawatan kehormat pegawai bertugas. Ia dihantar dari jurutera ke jurutera sekali sehari. Terdapat apa yang dipanggil baris respons pertama dan kedua kepada amaran daripada PagerDuty. Katakan amaran keutamaan tinggi tiba, dan jika 10 minit selepas panggilan kepada pegawai bertugas dari barisan pertama tiada reaksi terhadapnya (iaitu, ia tidak dipindahkan ke status yang diakui atau diselesaikan), panggilan itu pergi ke yang kedua jurutera bertugas. Ini dikonfigurasikan dalam PagerDuty sendiri melalui Dasar Peningkatan.
Jika pegawai bertugas kedua tidak bertindak balas, pemberitahuan kembali kepada utama kepada pegawai bertugas.
Oleh itu, sebarang amaran keutamaan tinggi yang masuk tidak boleh kekal tidak diproses.
Sekarang mari kita lihat dari mana insiden boleh datang.
Apakah integrasi yang kita gunakan?
PD menerima banyak insiden berbeza daripada pelbagai perkhidmatan. Pada masa ini kami mempunyai kira-kira 25 perkhidmatan sedemikian, dan untuk memprosesnya kami menggunakan beberapa penyepaduan siap sedia.
- Prometheus
Sistem pengumpulan metrik utama ialah Prometheus. Banyak yang telah ditulis mengenainya di HabrΓ©, saya hanya akan mengatakan bahawa kami mempunyai beberapa daripadanya untuk persekitaran yang berbeza: satu mengumpul metrik daripada mesin maya dan dockers, satu lagi daripada perkhidmatan Amazon, yang ketiga daripada mesin perkakasan. Telegraf digunakan terutamanya sebagai pengeksport metrik.
- E-mel
Di sini juga, saya rasa, semuanya jelas dari tajuk. Penyepaduan ini digunakan untuk menghantar pemberitahuan daripada beberapa skrip yang dilaksanakan oleh cron. PD memberi anda alamat tertentu yang anda hantar surat. Apabila mencipta perkhidmatan dengan penyepaduan sedemikian, anda boleh menetapkan keutamaan, dalam urutan apakah insiden masuk akan diproses, cara tepat untuk membuat amaran (untuk setiap surat masuk, untuk surat masuk + peraturan tertentu, dsb.).
- Slack
Pada pendapat saya, integrasi yang sangat menarik. Ada kalanya sesuatu berlaku tetapi tidak dilindungi oleh insiden. Oleh itu, kami menambah integrasi daripada Slack untuk mencipta insiden. Iaitu, anda boleh menulis kepada Slack korporat /callofduty semuanya lambat dan akan rosak tidak lama lagi dan PD akan memprosesnya dan menghantar kejadian itu kepada jurutera bertugas.
Kami buat:
Kita lihat:
- API
Penyepaduan HTTP. Sebenarnya, tiada apa-apa yang menarik di sini, hanya permintaan POST dengan badan dalam format JSON. Sebagai contoh, sesuatu yang menarik: kami menggunakannya untuk pemantauan luaran menggunakan . Perkhidmatan ini menyemak kebolehcapaian tapak kami dari pelbagai bahagian dunia. Dalam kes apabila kami menerima kod respons yang tidak boleh diterima (contohnya, 502), insiden dibuat dan kemudian semuanya mengikut rantaian yang diterangkan di atas. StatusCake sendiri mempunyai keupayaan untuk memantau URL dalaman, sijil SSL atau tamat tempoh domain.
- LibreNMS
Ini adalah satu lagi sistem pemantauan, anda boleh membaca lebih lanjut mengenainya di laman web mereka . Dengan bantuannya, kami memantau antara muka rangkaian dan iDRAC daripada pelayan.
Terdapat juga penyepaduan seperti Datadog, CloudWatch. Anda boleh melihat lebih lanjut tentang apa yang berlaku kepada mereka .
Visualisasi
Sistem pelaporan insiden utama ialah Slack. Semua insiden yang datang ke PD ditulis ke sembang khas, dan jika statusnya berubah, ini juga dipaparkan dalam sembang.
Apabila peluang muncul untuk memaparkan data berguna pada skrin monitor yang tergantung di siling, kami tiba-tiba menyedari bahawa kami (di jabatan devops) tidak mempunyai apa-apa untuk dipaparkan pada mereka. Terdapat Grafana yang menarik, tetapi ia tidak meliputi segala-galanya, dan pekerja bertindak balas terhadap makluman, bukan carta.
Selepas carian yang teliti tetapi tidak berjaya di GitHub untuk "papan" ringkas dan bermaklumat untuk PD, kami memutuskan untuk menulis sendiri - hanya dengan apa yang kami perlukan. Walaupun pada mulanya ada idea untuk memaparkan antara muka PD itu sendiri, ia kelihatan lebih menyusahkan.
Untuk menulisnya, anda hanya perlu mendapatkan kunci daripada PD dengan hak baca sahaja.
Dan inilah yang kami dapat:
Skrin memaparkan insiden terbuka semasa, nama jurutera semasa yang bertugas daripada jadual yang dipilih dan masa tanpa insiden keutamaan tinggi (panel dengan insiden keutamaan tinggi akan diserlahkan dengan warna merah).
.
Hasilnya, kami menerima papan pemuka yang mudah untuk melihat semua insiden kami. Saya akan gembira jika sesetengah daripada anda mendapati pengalaman kami berguna.
Sumber: www.habr.com