Desain Pemantauan

Topik ini membahas desain pemantauan yang menopang keandalan, yaitu empat golden signal sebagai kumpulan metrik minimum sebuah layanan, cara persentil latensi dihitung dari sampel pengukuran, dan filosofi alerting yang berorientasi pada tindakan. Pemantauan menutup rangkaian materi keandalan karena setiap target ketersediaan dan anggaran error hanya dapat ditegakkan bila perilakunya diukur secara berkelanjutan. Setelah membacanya, metrik mana yang harus dikumpulkan dan kapan sebuah alert boleh dibuat dapat diputuskan dengan aturan yang jelas.

Pertanyaan yang dijawab pemantauan#

Pemantauan (monitoring) mengumpulkan, menyimpan, dan menampilkan ukuran perilaku sistem untuk menjawab dua pertanyaan, yaitu apakah layanan memenuhi sasarannya saat ini dan mengapa tidak bila sasaran terlanggar. Pertanyaan pertama dijawab oleh metrik yang angkanya langsung terkait dengan SLO, sedangkan pertanyaan kedua dijawab oleh deret waktu per komponen yang menunjukkan perubahan pada titik mana keadaan mulai memburuk. Tanpa kedua lapisan tersebut, insiden hanya dapat ditebak dari keluhan pengguna yang datang belakangan, dan penyebabnya justru baru ditemukan setelah kerugiannya selesai.

Hasil pemantauan disajikan pada dua kanal yang berbeda tugasnya. Dashboard, yaitu papan metrik yang dikunjungi manusia saat menyelidiki, menyimpan deret waktu, perbandingan antarkomponen, dan konteks yang luas tanpa memerlukan pembacaan cepat. Alert, yaitu pemberitahuan otomatis yang dikirim pada kanal yang mengganggu, hanya dibuat untuk keadaan yang menuntut reaksi segera. Pemisahan ini penting karena penyelidikan butuh banyak informasi, sedangkan pemberitahuan butuh sedikit dan tepat.

Empat golden signal#

Golden signal adalah empat jenis metrik yang paling sering menunjukkan masalah nyata pada layanan berjaringan, yaitu latensi, trafik, error, dan saturasi (saturation). Keempatnya dipilih karena setiap insiden nyata hampir selalu terlihat pada salah satunya, sedangkan metrik lain seperti penggunaan CPU berfungsi sebagai petunjuk penyebab dan bukan gejala utamanya. Urutan keempatnya juga menjadi urutan pemeriksaan yang lazim saat kejadian, yaitu mulai dari apakah layanan lambat, seberapa besar permintaannya, seberapa sering gagal, lalu seberapa penuh sumber dayanya.

Latensi diukur pada persentil, bukan rata-rata, dan permintaan yang gagal cepat dihitung sebagai error serta tidak boleh menurunkan rata-rata latensi. Trafik menyatakan tingkat permintaan yang diterima, sehingga lonjakannya membedakan masalah kapasitas dari masalah perangkat lunak. Saturasi mengukur seberapa penuh sumber daya yang paling membatasi layanan, dan nilainya mendahului kegagalan, karena antrean yang memanjang dan memori yang menipis terjadi sebelum layanan benar-benar menyerah. Kombinasi keempatnya memberi gambaran yang cukup untuk memutuskan apakah keadaan memburuk tanpa harus membaca setiap metrik yang tersedia.

Persentil latensi dari sampel#

Persentil dan latensi ekor (tail latency) sudah diperkenalkan pada topik Kebutuhan Nonfungsional, sedangkan bagian ini menunjukkan cara menghitungnya dari sampel pengukuran. Prinsipnya sederhana, yaitu sampel diurutkan terlebih dahulu, lalu nilai pada posisi p% diambil dengan interpolasi linier antara dua sampel yang mengapitnya. Skrip berikut menghitung rata-rata dan tiga persentil dari seribu sampel latensi hasil pembangkitan acak dengan distribusi normal.

import random

random.seed(1)
latensi = sorted(random.gauss(120, 30) for _ in range(1000))

def persentil(data, p):
    """Interpolasi linier sederhana pada daftar terurut."""
    k = (len(data) - 1) * p / 100
    bawah = int(k)
    atas = min(bawah + 1, len(data) - 1)
    bobot = k - bawah
    return data[bawah] + (data[atas] - data[bawah]) * bobot

rata_rata = sum(latensi) / len(latensi)
print(f"Rata-rata: {rata_rata:.1f} ms")
for p in [50, 95, 99]:
    print(f"p{p}: {persentil(latensi, p):.1f} ms")

Rata-rata: 119.6 ms
p50: 119.7 ms
p95: 167.7 ms
p99: 185.9 ms

Keluaran mengulang pelajaran penting tentang rata-rata. Distribusi sampelnya hampir simetris, sehingga rata-rata 119,6 ms dan p50 119,7 ms hampir sama, tetapi p99 mencapai 185,9 ms, hampir 1,6 kali rata-rata. Pada seribu permintaan, p99 185,9 ms berarti sepuluh permintaan paling lambat melewati nilai itu, dan pengguna yang terkena sepuluh permintaan tersebut tidak nyaman walaupun rata-rata layanan terlihat sehat. Perhitungan persentil juga memiliki aturan kerja, yaitu dihitung dari sampel yang terurut dan tidak boleh digabungkan dari persentil-persentil yang lebih kecil, sehingga sistem pemantauan menyimpan sampel atau histogram, bukan rata-rata jadi.

Alerting yang berorientasi pada tindakan#

Alerting adalah kebijakan yang menentukan kapan sistem pemantauan mengirimkan alert kepada manusia. Aturan dasarnya hanya satu, yaitu setiap alert harus menuntut tindakan manusia saat itu juga. Keadaan yang cukup ditinjau besok ditempatkan pada dashboard atau laporan harian, sedangkan alert yang dikirim berulang tanpa tindakan apa pun melatih penerimanya untuk mengabaikan pemberitahuan, dan keadaan itulah yang disebut alert fatigue.

Sasaran alert yang paling bernilai adalah gejala yang dirasakan pengguna, bukan setiap penyebab yang mungkin muncul. SLO yang terlanggar dan anggaran error yang terbakar terlalu cepat merupakan gejala berangka yang selalu berarti, sedangkan penuhnya satu disk atau naiknya satu metrik internal sering kali pulih sendiri tanpa penanganan. Alert pada setiap penyebab menghasilkan banjir pemberitahuan yang menenggelamkan yang penting, dan jaraknya dengan alert berbasis gejala terlihat pada jumlahnya. Setiap alert yang dipertahankan disertai tautan ke runbook, yaitu dokumen berisi langkah penanganannya, sehingga penerima tidak memulai dari nol pada saat genting.

Kesalahan umum#

1. Membuat alert pada setiap penyebab alih-alih pada gejala. Metrik internal naik dan turun sepanjang hari, sedangkan pelanggaran SLO selalu berarti masalah nyata. Perbaikannya, buat alert pada gejala berbasis SLO dan anggaran error, lalu letakkan penyebab yang mungkin pada dashboard untuk penyelidikan.
2. Melaporkan rata-rata latensi sebagai satu-satunya ukuran. Rata-rata menyembunyikan permintaan terlambat yang justru paling terasa bagi pengguna, seperti terlihat pada selisih p50 dan p99 di bagian sebelumnya. Perbaikannya, laporkan latensi sebagai persentil dan pasangkan dengan rasio error.
3. Membiarkan alert tanpa langkah penanganan yang terdokumentasi. Penerima yang tidak tahu apa yang harus dilakukan akan menolak pemberitahuannya, dan alert yang benar-benar penting ikut terabaikan. Perbaikannya, setiap alert disertai tautan runbook dan dibuang bila tidak ada tindakan yang sesuai untuknya.

Ringkasan#

• Empat golden signal, yaitu latensi, trafik, error, dan saturasi, membentuk kumpulan metrik minimum yang dipantau pada layanan berjaringan.
• Persentil dihitung dari sampel yang terurut, dan p99 dari seribu sampel menandai sepuluh permintaan terlambat yang tidak terlihat oleh rata-rata.
• Alert yang baik adalah gejala berbasis SLO yang menuntut tindakan saat itu juga, sedangkan penyebab dan pertanyaan penyelidikan ditempatkan pada dashboard.

Referensi#

• Monitoring Distributed Systems — Google SRE Book — Bab yang memuat empat golden signal dan perbandingan alert pada gejala dengan alert pada penyebab.
• Practical Alerting — Google SRE Book — Bab tentang penyusunan alert dari metrik dan penjagaan kualitasnya.
• Alerting on SLOs — Google SRE Workbook — Panduan merancang alert dari anggaran error agar setiap pemberitahuan dapat ditindaklanjuti.