Menstandarkan sistem Alert dan mengelolanya dengan IaC
(engineering.ab180.co)Pengantar
Seiring layanan berkembang, sinyal yang perlu dipantau selama operasional juga ikut bertambah. Dalam artikel ini, kami memperkenalkan proses mengelola Alert sebagai kode dan menstandarkan alur respons yang terhubung ke Slack dan PagerDuty.
Tujuan awalnya sederhana. Membuat Alert lebih mudah dibuat, dikirim dengan tampilan yang lebih baik, dan memperjelas siapa yang harus melihatnya. Setelah itu, sambil terus menjalankan operasional, kami juga menyempurnakan grouped Alert, definisi berulang, otomatisasi respons, hingga stabilitas sistem monitoring.
Motivasi
Ada banyak cara untuk meningkatkan ketersediaan layanan dan mengurangi dampak ke pengguna.
Di antara semuanya, pekerjaan kali ini berfokus pada peningkatan sistem Alert.
Alert lebih dekat dengan antarmuka operasional yang menghubungkan pencegahan insiden dan penanganan insiden. Jika sinyal risiko dapat ditemukan lebih cepat, tindakan bisa diambil sebelum berkembang menjadi insiden nyata, dan bahkan setelah insiden terjadi, pihak yang bertanggung jawab bisa lebih cepat menyadari masalah dan mulai merespons.
Arah perbaikan yang ingin dicapai saat itu juga jelas. Kami ingin menangkap sinyal risiko dengan lebih baik, membuat pihak yang bertanggung jawab lebih cepat menyadarinya, langsung menghubungkannya ke investigasi dan respons, serta mengurangi alur respons yang berulang.
Kami memang tidak memulai dengan mengukur semuanya secara kuantitatif sejak awal, tetapi kesadaran masalah bahwa Alert tidak boleh sekadar menjadi notifikasi, melainkan harus menjadi sistem operasional yang mencegah insiden dan menghubungkannya ke respons, sudah sangat jelas.
Peran Alert
Untuk layanan yang stabil, mencegah insiden memang penting, tetapi sama pentingnya untuk mendeteksi tanda-tanda anomali pada layanan yang sedang berjalan secepat mungkin.
Pada titik ini, Alert memiliki dua peran. Sebelum insiden terjadi, Alert membantu mengenali sinyal risiko dengan cepat dan mengambil tindakan terlebih dahulu sebelum berubah menjadi insiden nyata. Setelah insiden terjadi, Alert memberi tahu pihak yang bertanggung jawab tentang masalah tersebut dan menghubungkannya ke tindakan berikutnya yang dibutuhkan untuk memahami situasi, seperti konteks, Runbook, Dashboard, Log, dan Silence.
Dengan kata lain, Alert bukan sekadar notifikasi yang memberi tahu "terjadi masalah", melainkan lebih dekat dengan antarmuka operasional yang menghubungkan pencegahan dan penanganan insiden.
Hal-hal yang dirasa kurang dari Alert yang ada
Ada tiga kekurangan besar pada Alert yang ada sebelumnya. Sulit dibuat, meskipun diterima sulit langsung dipahami, dan tidak jelas siapa yang harus merespons serta mengelolanya.
Sulit membuat Alert
Saat itu, pembuatan dan pengiriman Alert melibatkan banyak sistem seperti Grafana, Slack, PagerDuty, CloudWatch, EventBridge, dan Lambda, sementara sumber datanya juga beragam seperti NewRelic, VictoriaMetrics, Steampipe, OpenSearch, Druid, dan MySQL.
Cara kerja tiap Alert juga berbeda-beda. Ada Alert yang langsung dikirim dari Grafana ke Slack, ada yang menambahkan Lambda di belakang CloudWatch Alarm, ada yang menilai kondisi dengan mengecek status resource AWS melalui Steampipe, dan jika perlu integrasi dengan PagerDuty maka harus mempertimbangkan konfigurasi tambahan.
Masalahnya adalah kurangnya konvensi di tingkat organisasi. Belum tertata dengan baik Alert mana yang harus dikelola di mana, apakah cukup dikirim ke Slack atau perlu dihubungkan sampai ke PagerDuty, penjelasan dan tautan apa yang harus dimasukkan ke pesan, serta di mana tim penanggung jawab dan jalur pengirimannya harus dikelola.
Akibatnya, Alert memang dibuat saat dibutuhkan, tetapi seiring waktu cara pembuatannya dan cara pengelolaannya makin terfragmentasi.
Sulit membaca Alert
Hanya karena Alert sudah dibuat bukan berarti pesan Slack yang dikirim selalu tampil dalam bentuk yang mudah dibaca. Bergantung pada pembuat dan sistemnya, format serta kualitas informasinya berbeda-beda. Ada Alert yang judulnya panjang dan rumit, dan ada juga yang menampilkan nilai internal seperti Value atau Labels apa adanya.
Walaupun ada tautan, terkadang tidak jelas apa yang harus dilihat lebih dulu. Bahkan jika ada tombol Dashboard atau Log, terkadang integrasinya sebenarnya tidak berjalan. Selain itu, sering kali konteks Alert juga kurang, sehingga penanggung jawab harus mencari lagi layanan, cluster, resource, dan rentang waktunya.
Dalam situasi insiden, selisih beberapa menit pun terasa besar. Karena itu, saat menerima Alert, harus bisa langsung memahami masalah apa ini, seberapa pentingnya, masalah ini terkait layanan dan resource yang mana, bagian mana yang harus diperiksa lebih dulu, dan apa tindakan berikutnya.
Sulit mengelola tanggung jawab respons Alert
Saat Alert berbunyi, terkadang juga tidak jelas siapa yang harus memeriksa dan meresponsnya. Jika tim atau penanggung jawabnya tidak terlihat, orang yang melihat Alert itu harus lebih dulu menilai "apakah ini yang harus saya tangani?" dan "saya harus bertanya ke siapa?", dan dalam situasi insiden, keputusan singkat seperti ini pun bisa menyebabkan keterlambatan respons.
Selain tanggung jawab setelah Alert berbunyi, siapa yang memiliki dan mengelola Alert itu sendiri juga penting. Perlu terlihat bersama-sama Alert itu terkait dengan layanan tim mana, siapa yang boleh mengubah kondisinya, bagaimana pesan atau threshold-nya harus ditinjau, dan siapa yang akan membereskan Alert yang sudah usang.
Singkatnya, kondisi yang ingin diperbaiki adalah sebagai berikut:
- Cara membuat dan mengelola Alert terfragmentasi
- Meskipun menerima Alert, sulit memahami artinya dalam sekali lihat
- Saat Alert berbunyi, tidak jelas siapa yang harus memeriksa dan meresponsnya
- Juga tidak jelas tim mana yang harus memiliki dan mengelola Alert itu sendiri
Apa yang diperbaiki dan bagaimana caranya
Ada tiga arah perbaikan. Menstandarkan cara membuat Alert, menyediakan informasi yang dibutuhkan dalam struktur yang konsisten di pesan Slack, dan menata struktur agar penanggung jawab serta jalur pengiriman terlihat pada setiap Alert.
Menstandarkan cara pembuatan dan pengelolaan Alert
Pertama, kami menyatukan cara pembuatan dan pengelolaan Alert. Evaluasi dan eksekusi alert rule distandardisasi menggunakan Grafana, integrasi antara Grafana, Slack, dan PagerDuty diabstraksikan dengan Terraform Module, dan semua definisi Alert dikelola sebagai IaC di bawah direktori alerts/ dalam repo internal alerts. Penghubung kanal Slack, integrasi PagerDuty, format pesan, dan pembuatan tombol umum juga ditata agar ditangani oleh modul bersama.
Dengan begitu, penulis Alert tidak lagi harus memahami seluruh pipeline Alert, melainkan bisa lebih fokus pada kondisi apa yang ingin dideteksi, seberapa penting Alert tersebut, siapa yang harus memeriksanya, dan informasi apa yang dibutuhkan untuk respons.
Di dalam repo, cara penulisan, struktur direktori, field yang diperlukan, dan konvensi yang direkomendasikan juga dikelola bersama. Dengan mengelola Alert sebagai kode, review dan riwayat perubahan pun tercatat pada level PR dan commit.
Struktur direktori Alert
Semua Alert ditata agar mengikuti struktur {main-category}/{sub-category}/{severity}/{alert-name}.yml.
Contohnya seperti berikut:
infra/kubernetes/critical/pod-unhealthy.ymldata/airflow/warning/task-failed.ymlfinops/aws/warning/cost-increase.yml
Melalui struktur ini, hanya dengan melihat lokasi file saja sudah bisa dipahami Alert ini termasuk area apa dan ditangani dengan tingkat keparahan seperti apa. Struktur ini juga bisa dimanfaatkan sebagai dasar untuk mengumpulkan Alert di area tertentu, memeriksa Alert yang duplikat dan sudah usang, atau menghubungkan Slack channel, PagerDuty Service, dan CODEOWNERS.
Cara mendefinisikan Alert
Setiap file Alert memuat informasi seperti datasource, query, threshold, condition, dan message.
Kami tidak membuat DSL baru secara terpisah. Formatnya lebih dekat ke mengekspresikan isi Grafana Alert yang diserialisasikan ke JSON dalam bentuk YAML, sehingga Alert apa pun yang bisa didefinisikan di Grafana pada umumnya dapat dijadikan IaC dengan struktur yang sama.
Belakangan ini kami juga memanfaatkan LLM. Jika seseorang menjelaskan dengan bahasa alami bahwa mereka "ingin menerima Alert dengan pesan tertentu pada kondisi tertentu", LLM akan membuat draf awal definisi Alert dalam bentuk YAML dengan merujuk pada contoh dan konvensi yang sudah ada. Berkat ini, penulis Alert dapat lebih fokus pada apa yang ingin dideteksi dan mengapa itu diperlukan daripada pada format serialisasi yang rumit.
Membuat pesan Alert bisa langsung dipahami dan ditindaklanjuti
Kami juga melihat pesan Alert sebagai sebuah antarmuka. Dalam situasi insiden, sering kali tidak ada banyak waktu untuk menafsirkan pesan secara perlahan, jadi apa pun Alert yang datang, informasi dengan jenis yang sama harus bisa ditemukan di tempat yang sama.
Karena itu, struktur pesan Slack ditata secara konsisten. Judul memuat nama Alert, status, dan tingkat keparahan, sedangkan isi memuat penjelasan yang bisa langsung dipahami manusia beserta penanggung jawab, tim, layanan, region, nama resource, dan label utama. Tombol juga dibagi menjadi tombol umum dan tombol opsional, sehingga secara default menyediakan IaC, PagerDuty, Silence dan hanya menampilkan Runbook, Dashboard, Log saat diperlukan
Tombol umum dibuat agar terhubung secara otomatis oleh sistem, dan semua perubahan status Alert juga dicatat di thread Slack. Dengan begitu, semuanya bisa dilihat dalam satu alur: siapa yang melakukan Acknowledge, apakah ditangani di Slack atau di PagerDuty, kapan di-Resolve, hingga catatan apa yang ditinggalkan selama penanganan
Hasilnya, siapa pun yang membuat Alert, bentuk yang terlihat di Slack menjadi serupa, dan anggota tim bisa lebih cepat menentukan bagian mana yang perlu dilihat
Memperjelas struktur tanggung jawab Alert
Sama pentingnya dengan bisa langsung memahami Alert saat melihatnya adalah membuat jelas siapa yang bertanggung jawab untuk memeriksa dan menanganinya
Karena itu, informasi tag dan label dari resource dimanfaatkan dalam alur penanganan. Alih-alih menetapkan tim atau PIC secara langsung pada setiap Alert, metadata seperti layanan, tim, resource, dan environment digunakan agar tim dan PIC yang tepat bisa di-mention otomatis di pesan Slack
Jalur eskalasi juga ditata dengan aturan yang sama. Berdasarkan klasifikasi dan severity Alert, Slack channel, PagerDuty Service, dan Escalation Policy dihubungkan secara otomatis. Alert level Warning hanya dikirim ke Slack channel, sedangkan Alert Critical yang berpotensi berdampak besar ke pengguna atau menimbulkan insiden juga membuat PagerDuty Incident
CODEOWNERS juga dimanfaatkan. File Alert dibagi ke dalam direktori berdasarkan kategori dan area layanan, lalu tim penanggung jawab untuk tiap path ditetapkan di CODEOWNERS agar terlihat jelas di dalam repo tim mana yang memiliki area Alert tertentu
Hasilnya, tanggung jawab Alert dikelola di dua titik. Saat Alert benar-benar berbunyi, tim dan PIC akan di-mention berdasarkan tag dan label, dan saat definisi Alert diubah, area tim yang bertanggung jawab bisa dipastikan berdasarkan struktur direktori dan CODEOWNERS
Peran Alert proxy
Agar struktur ini benar-benar berjalan, dibutuhkan lapisan perantara yang menafsirkan dan meneruskan Alert. Karena itu, ditempatkan proxy berbasis AWS Lambda di antara Grafana, Slack, dan PagerDuty
Grafana mengevaluasi Alert rule dan mengirim webhook. Proxy menerima webhook ini lalu menafsirkan Alert context seperti category, severity, label, annotation, dan fingerprint, kemudian menentukan ke Slack channel mana Alert dikirim, PagerDuty Incident seperti apa yang dibuat, siapa yang di-mention, tombol apa yang dilampirkan, bagaimana thread Slack yang sudah ada diperbarui, dan bagaimana lifecycle Ack/Resolve dikelola
Artinya, jika Terraform module dan struktur direktori menstandarkan "bagaimana Alert harus didefinisikan", maka proxy berperan menghubungkan agar definisi tersebut terlihat dan berjalan dengan cara yang sama dalam alur operasional nyata
Berkat proxy, format pesan Slack, mention penanggung jawab, integrasi PagerDuty, pembaruan thread Slack, dan interaksi Ack/Resolve bisa dikelola secara konsisten di satu tempat. Ini juga memudahkan perluasan perbaikan berikutnya seperti grouped Alert, custom action button, integrasi agen AI, dan model Alert bersama
Apa lagi yang masih kurang
Setelah perbaikan pertama, definisi Alert sudah dikelola sebagai IaC, dan pesan Slack serta jalur penyampaiannya juga berjalan di bawah aturan yang konsisten. Namun, sistem Alert bukanlah alat yang sekali dibuat lalu selesai. Setelah dijalankan hampir satu tahun, makin banyak Alert berarti mulai muncul masalah baru: bagaimana menampilkan banyak instance yang muncul dalam Alert yang sama, bagaimana mengelola definisi Alert yang berulang, bagaimana membuat orang bisa benar-benar melakukan sesuatu setelah melihat Alert, dan bagaimana memastikan serta memverifikasi stabilitas sistem Alert itu sendiri
Sulit dilihat saat Alert yang sama berbunyi untuk banyak target sekaligus
Karena pembuatan Alert menjadi lebih mudah, jumlah Alert juga secara alami bertambah. Yang особенно terasa tidak nyaman saat itu adalah ketika satu Alert rule berbunyi untuk banyak target sekaligus
Di Grafana, meskipun rule-nya sama, jika nilai label seperti region, name, node, pod, app berbeda, masing-masing dianggap sebagai Alert instance terpisah. Misalnya, jika ada Alert Pod unhealthy dan beberapa pod sekaligus menjadi unhealthy, maka Alert instance akan dibuat untuk setiap pod
Grafana sebenarnya sudah memiliki fitur Alert Grouping, tetapi hanya mengelompokkannya saja tidak cukup. Yang penting adalah menampilkan status Alert yang tergabung itu dengan cara yang mudah dipahami operator: target mana saja yang ada di dalam group, mana yang masih firing, mana yang baru saja resolve, apakah ada target baru yang ditambahkan, dan apakah perubahan status dalam group yang sama tersambung sebagai satu alur
Definisi Alert yang berulang makin bertambah
Semakin banyak definisi Alert, pendekatan menyalin YAML lalu mengubah sedikit demi sedikit juga mulai menunjukkan batasnya. Alert seperti SQS lag, CloudWatch error log, Pod OOM, ALB 5xx, dan Lambda error/throttle dibuat berulang kali, dan pada awalnya cukup menyalin file yang ada lalu mengubah nama, query, threshold, dan label
Namun, ketika file bertambah banyak, makin sulit memperbaiki perilaku bersama, dan muncul masalah bahwa meskipun maksud Alert-nya sama, link dashboard, susunan labels, dan cara mengekspresikan threshold jadi sedikit berbeda-beda. Karena itu, dibutuhkan struktur yang bisa menggunakan ulang pola yang berulang
Setelah melihat Alert pun masih ada jarak menuju tindakan berikutnya
Menambahkan tombol Runbook, Dashboard, IaC, dan PagerDuty ke pesan Slack memang membantu, tetapi dalam penanganan insiden nyata, sering kali link saja tidak cukup. Khususnya Runbook terbukti efektif, tetapi tidak mudah memasang Runbook yang baik ke semua Alert dan terus menjaganya tetap mutakhir
Selain itu, dalam penanganan nyata, pekerjaan investigasi yang mirip terus berulang, seperti memeriksa log Kubernetes, memeriksa status pod, memeriksa rollout history, memeriksa metrik SQS·Lambda, dan memeriksa error log. Sebagian besar pekerjaan ini dilakukan di luar pesan Slack, dan penanggung jawab harus membaca label dan value dari Alert, berpindah ke alat lain, memindahkan nilainya, lalu membagikan hasilnya kembali ke thread Slack
Pada akhirnya, perbaikan pertama memang membuat Alert lebih mudah dibaca, tetapi investigasi dan penanganan masih banyak terjadi di luar pesan Alert
SPOF di sistem monitoring bertambah
Saat sistem Alert ditata ulang, titik-titik yang bisa menjadi SPOF juga bertambah. Definisi dan deployment Alert rule terpusat di repo alerts dan Terraform, evaluasi Alert rule ditangani Grafana, sementara pesan Slack, PagerDuty Incident, dan lifecycle Ack/Resolve dikelola oleh proxy
Peran yang menjadi lebih jelas adalah perubahan yang baik, tetapi pada saat yang sama kemungkinan seluruh alur Alert terdampak ketika titik tersebut gagal juga membesar. Yang lebih sulit, kegagalan seperti ini mungkin tidak terlihat dari luar. Jika jalur yang seharusnya memberi tahu adanya anomali di sistem lain diam-diam berhenti, maka bahkan ketika insiden nyata terjadi, tidak ada yang akan mengetahuinya
Pada akhirnya, ini berujung pada pertanyaan "siapa yang akan memonitor sistem monitoring"
Perbaikan kedua
Perbaikan pertama sudah membentuk kerangka dasar sistem Alert, tetapi ketika membuat dan mengirim Alert menjadi lebih mudah, masalah yang perlu diperhatikan dalam operasional pun ikut berubah
Dalam perbaikan kedua, fokus diarahkan ke empat hal: menggabungkan perubahan status ketika banyak target berbunyi bersamaan dalam Alert rule yang sama agar bisa dilihat sekilas dalam satu tampilan, membuat definisi Alert yang berulang bisa digunakan ulang sebagai pola bersama, melengkapi Runbook sambil menghubungkan investigasi berulang dan tindakan mitigasi terbatas ke tombol Slack, dan mengukur serta memverifikasi stabilitas definisi, evaluasi, dan jalur pengiriman Alert yang berpotensi menjadi SPOF
Menangani Grouped Alert dengan benar
Pertama, kami memperbaiki cara representasi grouped Alert. Ketika beberapa instance memicu secara bersamaan pada Alert rule yang sama, jika masing-masing dikirim sebagai pesan terpisah maka channel Slack menjadi berantakan, sedangkan jika digabungkan hanya menjadi satu group, mudah untuk melewatkan resource mana yang sebenarnya bermasalah.
Intinya adalah mengelompokkan, tetapi tidak kehilangan status di dalam kelompok tersebut. Di Slack, grouped Alert ditampilkan sebagai satu pesan representatif, sambil tetap menampilkan target-target yang saat ini terdampak bersama-sama. Jika target baru ditambahkan atau target lama sudah terselesaikan, perubahan itu dicatat di thread yang sama. Saat banyak perubahan status terjadi sekaligus, beberapa perubahan tersebut ditampilkan secara batch, dan sisi PagerDuty juga disesuaikan agar merujuk ke masalah yang sama dengan grouped Alert yang terlihat di Slack.
Hasilnya, beberapa Alert yang berasal dari penyebab yang sama kini bisa dilihat di Slack sebagai satu alur.
Mengurangi definisi Alert yang berulang
Cara copy-paste lalu sedikit mengubah isinya akan meningkatkan biaya pemeliharaan dan kemungkinan kesalahan seiring bertambahnya jumlah Alert. Untuk menguranginya, kami menambahkan global/templates dan matrix.
global/templates adalah fitur untuk mendefinisikan struktur Alert yang berulang sebagai template bersama, dan matrix adalah fitur untuk mengekspansi Alert yang sama menjadi beberapa Alert berdasarkan kombinasi region, queue, datasource, dan service.
Pola berulang seperti SQS queue lag, CloudWatch error log, Pod OOM di berbagai cluster, ALB 5xx, Lambda error/throttle, dan ECS memory/CPU/max-capacity dijadikan template, lalu hanya nilai yang berubah seperti nama queue, region, cluster, threshold, dan variabel dashboard yang diisikan ke matrix.
Dengan begitu, struktur pesan bersama, tombol, penanganan link Runbook/dashboard, dan cara menangani datasource bisa diperbaiki dari satu tempat, sekaligus mengurangi inkonsistensi dan biaya pemeliharaan yang muncul saat jumlah Alert bertambah.
Mulai merespons langsung dari pesan Slack
Berikutnya, kami menambah hal-hal yang bisa dilakukan langsung dari dalam pesan Slack. Link Runbook dan dashboard tetap penting, tetapi kami ingin mengurangi kebutuhan untuk berulang kali melakukan pengecekan serupa atau tindakan mitigasi terbatas di luar pesan Slack.
Karena itu, selain tombol yang sudah ada, kami menambahkan custom action button. Jika perintah didefinisikan di message.actions pada Alert YAML, perintah itu akan ditampilkan sebagai tombol di pesan Slack. Saat tombol ditekan, proxy akan menjalankan perintah melalui Lambda invocation terpisah, lalu meninggalkan komentar di thread Slack yang sama tentang siapa yang menekan tombol apa dan hasil eksekusinya.
Dengan tombol ini, kami bisa menyediakan pekerjaan seperti melihat log, memeriksa status Kubernetes rollout, melakukan rollout restart pada situasi terbatas, menjalankan satu perintah, atau mengeksekusi beberapa perintah secara berurutan.
Bagian yang paling kami perhatikan adalah keamanan. Jika nama tombol diakhiri dengan !, Slack confirm dialog akan ditampilkan. Nilai label seperti ${labels.namespace} dan ${labels.pod} akan disubstitusikan ke dalam perintah dengan shell quoting diterapkan untuk mencegah command injection. Untuk pekerjaan yang memerlukan izin tambahan, IAM role di-assume melalui actionRole. Penggunaan role yang tidak diizinkan diproses secara fail-closed, dan webhook serta interaksi Slack juga diverifikasi masing-masing dengan Bearer token, tanda tangan HMAC-SHA256, dan replay protection.
Integrasi dengan agen AI
Kami juga ingin mengurangi proses mengumpulkan informasi yang diperlukan setelah menerima Alert. Karena itu, kami menghubungkan agen AI internal abot ke alur Alert.
Saat tombol abot di pesan Slack ditekan, proxy akan mengumpulkan nama Alert, deskripsi, labels, values, link IaC, serta context tambahan yang dimasukkan pengguna lewat modal, lalu mengirim permintaan analisis. abot dibuat berjalan dengan identity berbasis OAuth milik orang yang menekan tombol, sehingga meskipun perlu mengambil informasi dari Grafana, AWS, Kubernetes, dan lainnya, data yang diambil tetap dibatasi pada cakupan yang memang bisa dilihat pengguna tersebut.
Hasil analisis ditinggalkan sebagai komentar di thread Slack yang sama. Di situ juga dicatat metrik dan log apa yang diperiksa, kemungkinan mana yang lebih dahulu patut dicurigai, dan petunjuk apa yang layak dirangkum ke dalam RCA, sehingga waktu untuk membuka banyak sistem dan mengumpulkan ulang informasi bisa dikurangi.
Memonitor sistem monitoring itu sendiri
Pada perbaikan kedua, proses mendefinisikan, mengevaluasi, dan mengirimkan Alert itu sendiri juga kami masukkan sebagai target observasi.
Pertama, kami mengumpulkan metrik operasional proxy. Kami mengumpulkan metrik seperti waktu hingga Ack, waktu hingga Resolve, jumlah Alert yang sedang aktif, berapa lama Alert tetap aktif, dan berapa kali Alert yang sama berbunyi lagi. Kami juga menambahkan watchdog untuk mendeteksi saat Lambda mendekati timeout. Jika proxy gagal di tengah pemrosesan, full stack trace dan event payload asli juga akan dicatat.
Namun, ada keterbatasan jika proxy memberi tahu masalahnya sendiri. Jika proxy mati bahkan sebelum sempat mengirim notifikasi itu, Alert yang seharusnya terkirim bisa langsung hilang.
Karena itu, kami menempatkan mekanisme deteksi di luar proxy yang bergantung pada sistem berbeda. Salah satunya adalah Grafana, yang dibuat mengevaluasi metric yang dikirim proxy sebagai Alert di domain monitoring untuk menampilkan anomali. Namun karena Grafana dan VictoriaMetrics berada di atas EKS yang sama, jika EKS atau Grafana mati total, hal itu tidak bisa terdeteksi.
Yang lainnya adalah deadman switch. Dalam keadaan normal, Grafana mengirimkan /api/health sebagai heartbeat, dan heartbeat itu diterima oleh CloudWatch yang independen dari EKS. CloudWatch alarm akan menganggapnya sebagai gangguan jika heartbeat terputus atau missing, dan dalam kasus ini notifikasi dikirim langsung ke PagerDuty dan Slack tanpa melewati Grafana atau proxy.
Dengan kata lain, sisi yang mendeteksi dan sisi yang dideteksi ditempatkan di infrastruktur yang berbeda, sehingga selama EKS dan CloudWatch tidak mati bersamaan, matinya sistem monitoring tetap bisa diketahui.
Tugas perbaikan berikutnya
Perbaikan kedua sudah selesai, tetapi masih ada bagian yang perlu ditingkatkan lebih lanjut.
Memanfaatkan metrik operasional yang dikumpulkan dengan benar
Karena proxy mengumpulkan metrik operasional Alert, kini kami bisa menjawab dengan data pertanyaan seperti Alert apa yang seberapa sering berbunyi di channel tertentu, apakah Alert terlalu banyak terkonsentrasi ke penanggung jawab atau tim tertentu, dan apakah ada Alert yang hanya berulang antara firing dan auto resolve tanpa interaksi apa pun.
Namun, bisa melihat data dan benar-benar menyempurnakan Alert berdasarkan data tersebut adalah dua hal yang berbeda. Sampai sekarang, kami masih belum secara serius melakukan perbaikan seperti menyesuaikan threshold, mengelompokkan Alert yang mirip, menghapus Alert yang tidak perlu, mengurangi noisy alert, dan mengarahkan perbaikan pada benar-benar menurunkan waktu deteksi maupun waktu penyelesaian.
Peningkatan Alert IaC
Saat ini definisi Alert dideploy dari repo alerts melalui CI/CD, tetapi masih bergantung pada resource grafana_rule_group dari Grafana Terraform provider. Masalahnya, bahkan jika hanya satu rule yang diubah, di PR perubahan itu terlihat seolah seluruh rule group berubah sehingga diff sulit dibaca. Selain itu, karena interval_seconds berada pada level rule group, untuk memberi siklus evaluasi yang berbeda per Alert, group harus dipecah menjadi bagian-bagian kecil.
Belakangan ini Grafana menghadirkan alerting API baru yang memperlakukan Alert rule seperti resource Kubernetes, dan di Terraform provider juga ditambahkan resource grafana_apps_rules_alertrule_v0alpha1. Karena masih alpha, penerapannya belum dilakukan sekarang, tetapi jika nanti sudah stable, kami akan mempertimbangkan untuk berpindah dari grafana_rule_group yang ada saat ini.
Harapan kami jelas. Memisahkan definisi rule group dan rule, mendapatkan diff yang rapi sehingga saat hanya satu rule diubah, hanya perubahan itu yang terlihat jelas, menyesuaikan siklus evaluasi secara detail untuk tiap rule, dan menggunakan resource monitoring dengan lebih efisien.
Penutup
Tujuan awalnya sederhana. Membuat Alert lebih mudah dibuat, lebih mudah dipahami sekilas saat diterima, dan lebih jelas siapa yang bertanggung jawab.
Pada perbaikan pertama, kami mengumpulkan definisi Alert ke dalam IaC, menstandarkan pesan Slack dan jalur pengiriman, menghubungkan mention penanggung jawab dengan CODEOWNERS, dan merapikan pengelolaan lifecycle Slack/PagerDuty melalui proxy.
Masalah yang terungkap selama operasional berlanjut kemudian dibenahi pada perbaikan tahap kedua. Alert yang membanjir dari rule yang sama ditampilkan dengan digabung menjadi satu, definisi yang berulang dikurangi dengan template dan matrix, investigasi serta mitigasi bisa dimulai langsung dari dalam pesan Slack, dan juga disiapkan mekanisme untuk menyadari ketika sistem monitoring itu sendiri berhenti.
Berkat itu, pekerjaan membuat Alert, mengirimkannya, dan menanganinya menjadi lebih mudah daripada sebelumnya.
Namun, membuat data menjadi dapat dilihat dan benar-benar memperbaiki operasional berdasarkan data tersebut adalah dua hal yang berbeda. Jika sampai sekarang yang dilakukan adalah menstandarkan sistem Alert dan membuatnya bisa diukur, maka mulai sekarang yang tersisa adalah benar-benar menguranginya dan merapikannya sambil melihat angka-angka tersebut.
Ada isi yang tidak bisa dimuat dalam tulisan ini karena keterbatasan panjang. Jika Anda ingin mengetahui detail lebih lanjut, kami merekomendasikan untuk turut membaca artikel aslinya.
Belum ada komentar.