Observability dengan Anggaran Terbatas: Log Terstruktur, Metrik, dan Jejak Seperlunya

Kata observability sering disamakan dengan tumpukan perangkat lunak yang mahal dan rumit. Bagi tim kecil, sebagian besar manfaatnya sebenarnya dapat diperoleh dari tiga kebiasaan yang tidak menuntut infrastruktur tambahan apa pun.

Log terstruktur, bukan kalimat

Log berbentuk kalimat bebas mudah dibaca satu per satu dan hampir mustahil dianalisis secara agregat. Pertanyaan seperti "berapa banyak permintaan dari pengguna ini yang gagal dalam satu jam terakhir" membutuhkan pencarian teks yang rapuh.

Menuliskan log sebagai JSON dengan medan yang konsisten mengubah keadaan sepenuhnya. Satu baris berisi stempel waktu, tingkat keparahan, pengenal permintaan, pengenal pengguna, dan durasi dapat langsung ditanyai dengan alat baris perintah sederhana, bahkan tanpa layanan pengindeksan.

Satu aturan yang wajib: jangan pernah menuliskan kata sandi, token, atau nomor kartu ke dalam log. Sanitasi harus dilakukan di lapisan pencatat, bukan diserahkan pada kedisiplinan setiap pemanggil.

Pengenal permintaan yang mengikat semuanya

Kebiasaan kedua adalah menghasilkan pengenal acak pada setiap permintaan masuk dan menyertakannya pada setiap baris log yang dihasilkan selama permintaan itu diproses.

Manfaatnya terasa pada saat penelusuran galat. Satu keluhan pengguna disertai pengenal permintaan mengubah pencarian yang menghabiskan waktu berjam-jam menjadi satu perintah penyaringan. Menyertakan pengenal yang sama pada halaman galat yang dilihat pengguna membuat mereka dapat melaporkannya tanpa diminta.

Empat metrik yang hampir selalu cukup

Godaan untuk mencatat segalanya menghasilkan papan pemantau yang tidak pernah dibuka. Empat angka berikut menangkap sebagian besar gangguan: laju permintaan, tingkat galat, distribusi latensi, dan tingkat kejenuhan sumber daya seperti memori atau koneksi basis data.

Untuk latensi, gunakan persentil, bukan rata-rata. Rata-rata menyembunyikan persoalan dengan sangat efektif — layanan dengan rata-rata 80 milidetik dapat memiliki persentil ke-99 sebesar empat detik, dan pengguna yang mengalami empat detik itulah yang menulis keluhan.

Jejak seperlunya

Penelusuran terdistribusi penuh memang berlebihan bagi aplikasi yang berjalan pada satu server. Versi sederhananya tetap bernilai: catat durasi setiap tahap penting dalam satu permintaan — waktu query basis data, panggilan API eksternal, penyajian tampilan — dan sertakan dalam log ringkasan di akhir permintaan.

Satu baris yang menyatakan permintaan memakan 1.200 milidetik dengan 1.100 di antaranya dihabiskan pada satu query langsung menunjuk penyebabnya, tanpa perlu satu pun layanan tambahan.

Peringatan yang layak dibangunkan

Peringatan yang terlalu sering berbunyi akan diabaikan, dan peringatan yang diabaikan sama saja dengan tidak ada. Batasi peringatan pada kondisi yang benar-benar menuntut tindakan seseorang saat itu juga.

Aturan yang berguna: jika penerima peringatan tidak tahu harus berbuat apa setelah membacanya, peringatan tersebut sebaiknya menjadi entri di papan pemantau, bukan pesan yang membangunkan orang di tengah malam.