Semakin kompleks sistemnya, semakin ditumbuhi segala macam peringatan. Dan ada kebutuhan untuk bereaksi terhadap peringatan yang sama, menggabungkannya, dan memvisualisasikannya. Saya pikir ini adalah situasi yang akrab bagi banyak orang hingga membuat mereka merasa gugup.
Solusi yang akan dibahas bukanlah yang paling tidak terduga, tetapi pencarian tidak menghasilkan artikel lengkap tentang topik ini.
Oleh karena itu, saya memutuskan untuk berbagi pengalaman FunCorp dan berbicara tentang bagaimana proses tugas disusun, siapa yang menelepon, mengapa dan bagaimana Anda dapat melihat semuanya.
Apa itu PagerDuty?
Jadi, untuk mengatasi semua masalah ini, kami mulai mencari alat yang mudah digunakan. Setelah beberapa pencarian, kami memilih PagerDuty. Bagi kami, PD merupakan solusi yang cukup lengkap dan ringkas dengan banyak integrasi dan pengaturan. Apa yang dia suka?
Singkatnya, PagerDuty adalah platform pemrosesan insiden yang dapat memproses insiden masuk melalui berbagai integrasi, mengatur perintah tugas, dan kemudian memperingatkan teknisi yang bertugas tergantung pada tingkat insiden (pada tingkat tinggi - panggilan, pada tingkat rendah - push dari aplikasi / SMS) .
Siapa petugas jaganya?
Ini mungkin tempat pertama untuk mulai menyiapkan PD.
Di FunCorp, seperti perusahaan lainnya, terdapat jabatan kehormatan sebagai petugas jaga. Itu ditransmisikan dari insinyur ke insinyur sekali sehari. Ada yang disebut respons baris pertama dan kedua terhadap peringatan dari PagerDuty. Misalkan peringatan prioritas tinggi tiba, dan jika 10 menit setelah panggilan ke petugas jaga dari saluran pertama tidak ada reaksi terhadapnya (yaitu, tidak dialihkan ke status diakui atau diselesaikan), panggilan tersebut diteruskan ke yang kedua. insinyur bertugas. Hal ini dikonfigurasi di PagerDuty sendiri melalui Kebijakan Eskalasi.
Jika petugas jaga kedua tidak merespon, pemberitahuan kembali ke utama kepada petugas jaga.
Oleh karena itu, setiap peringatan berprioritas tinggi yang masuk tidak dapat dibiarkan tidak diproses.
Sekarang mari kita lihat dari mana datangnya insiden.
Integrasi apa yang kami gunakan?
PD menerima banyak kejadian berbeda dari berbagai dinas. Saat ini kami memiliki sekitar 25 layanan seperti itu, dan untuk memprosesnya kami menggunakan beberapa integrasi yang sudah jadi.
- Prometheus
Sistem pengumpulan metrik utama adalah Prometheus. Banyak yang telah ditulis tentang hal ini di Habré, saya hanya akan mengatakan bahwa kami memiliki beberapa di antaranya untuk lingkungan yang berbeda: yang satu mengumpulkan metrik dari mesin virtual dan buruh pelabuhan, yang lain dari layanan Amazon, yang ketiga dari mesin perangkat keras. Telegraf terutama digunakan sebagai pengekspor metrik.
Di sini juga menurut saya semuanya sudah jelas dari judulnya. Integrasi ini digunakan untuk mengirimkan notifikasi dari beberapa skrip yang dijalankan oleh cron. PD memberi Anda alamat tertentu yang Anda kirimi surat. Saat membuat layanan dengan integrasi seperti itu, Anda dapat menetapkan prioritas, dalam urutan apa insiden masuk akan diproses, bagaimana tepatnya membuat peringatan (untuk setiap surat masuk, untuk surat masuk + aturan tertentu, dll.).
- Kendur
Menurut saya, integrasi yang sangat menarik. Ada kalanya sesuatu terjadi namun tidak tercakup dalam kejadian. Oleh karena itu, kami menambahkan integrasi dari Slack untuk menciptakan sebuah insiden. Artinya, Anda dapat menulis ke perusahaan Slack /callofduty semuanya lambat dan akan segera rusak dan PD akan memprosesnya dan mengirimkan kejadian tersebut ke teknisi jaga.
Kami melakukan:
Kami melihat:
- API
Integrasi HTTP. Sebenarnya, tidak ada yang menarik di sini, hanya permintaan POST dengan isi dalam format JSON. Misalnya, sesuatu yang menarik: kami menggunakannya untuk pemantauan eksternal . Layanan ini memeriksa aksesibilitas situs kami dari berbagai belahan dunia. Jika kami menerima kode respons yang tidak dapat diterima (misalnya, 502), sebuah insiden terjadi dan kemudian semuanya mengikuti rantai yang dijelaskan di atas. StatusCake sendiri memiliki kemampuan untuk memantau URL internal, sertifikat SSL, atau masa berlaku domain.
- LibreNMS
Ini adalah sistem pemantauan lain, Anda dapat membaca lebih lanjut di situs web mereka . Dengan bantuannya, kami memantau antarmuka jaringan dan iDRAC dari server.
Ada juga integrasi seperti Datadog, CloudWatch. Anda dapat melihat lebih banyak tentang apa yang terjadi pada mereka .
Visualisasi
Sistem pelaporan insiden utama adalah Slack. Semua kejadian yang masuk ke PD ditulis ke chat khusus, dan jika statusnya berubah, ini juga ditampilkan di chat.
Ketika ada kesempatan untuk menampilkan data yang berguna di layar monitor yang tergantung di langit-langit, kami tiba-tiba menyadari bahwa kami (di departemen devops) tidak memiliki apa pun untuk ditampilkan pada layar tersebut. Ada Grafana yang luar biasa, tetapi tidak mencakup semuanya, dan karyawan bereaksi terhadap peringatan, bukan grafik.
Setelah pencarian menyeluruh tetapi tidak berhasil di GitHub untuk “papan” ringkas dan informatif untuk PD, kami memutuskan untuk menulis sendiri - hanya dengan apa yang kami butuhkan. Meskipun pada awalnya ada ide untuk menampilkan antarmuka PD itu sendiri, namun terlihat lebih merepotkan.
Untuk menulisnya, yang perlu Anda lakukan hanyalah mendapatkan kunci dari PD dengan hak read-only.
Dan inilah yang kami dapatkan:
Layar menampilkan insiden terbuka saat ini, nama teknisi yang bertugas saat ini dari jadwal yang dipilih, dan waktu tanpa insiden prioritas tinggi (panel dengan insiden prioritas tinggi akan disorot dengan warna merah).
.
Hasilnya, kami menerima dasbor yang nyaman untuk melihat semua insiden kami. Saya akan senang jika beberapa dari Anda menganggap pengalaman kami bermanfaat.
Sumber: www.habr.com