Panduan Observability: Log, Metrik, dan Alert Server

Monitoring menjawab pertanyaan "apakah sistemnya sehat?", sedangkan observability menjawab "kenapa sistemnya bertingkah begini?". Keduanya dibangun dari tiga jenis data, yaitu metrik, log, dan trace, ditambah alert yang memberi tahu orang yang tepat pada waktu yang tepat.

Panduan ini ditujukan untuk tim kecil yang menjalankan website, API, atau aplikasi internal di satu sampai beberapa server, dan selama ini baru tahu ada masalah setelah pelanggan mengeluh. Kamu akan mendapat gambaran konsepnya, tumpukan alat open-source yang realistis untuk memulai, dan kebiasaan yang membuat alert tetap berguna.

Apa bedanya monitoring dan observability?

Monitoring klasik bekerja dengan daftar pemeriksaan yang sudah ditentukan: apakah website merespons, apakah CPU di bawah batas, apakah disk masih cukup. Kalau salah satu gagal, alert berbunyi. Cara ini efektif untuk masalah yang sudah bisa ditebak sebelumnya.

Observability melangkah lebih jauh. Sistem dikatakan observable bila datanya cukup kaya untuk menjawab pertanyaan yang belum terpikir sebelumnya. Contohnya: kenapa halaman checkout lambat hanya untuk sebagian pengguna, atau kenapa error muncul setiap kali satu jenis laporan dibuat. Monitoring adalah bagian dari observability, bukan lawannya.

Untuk tim kecil, urutannya jelas. Kuasai monitoring dulu, karena itu yang paling cepat memberi manfaat. Tambahkan kemampuan observability seiring aplikasi bertambah rumit.

Tiga pilar data: metrik, log, dan trace

Setiap jenis data menjawab pertanyaan yang berbeda, dan biayanya pun berbeda. Ringkasannya ada di tabel berikut.

Metrik

Metrik adalah angka dengan label dan waktu, misalnya jumlah request per detik untuk endpoint tertentu. Karena berupa angka, metrik murah disimpan dalam jangka panjang dan cocok untuk grafik tren serta alert. Kelemahannya, metrik tidak bercerita tentang detail kejadian. Kamu tahu error naik, tapi belum tahu error apa.

Log

Log memberi detail itu: pesan error, ID pengguna, parameter request. Log jauh lebih boros ruang dibanding metrik, jadi perlu dibatasi masa simpannya. Log yang terstruktur, misalnya dalam format JSON dengan field yang konsisten, jauh lebih mudah dicari dibanding teks bebas.

Trace

Trace mengikuti satu request dari awal sampai akhir melewati beberapa service, misalnya dari API ke database lalu ke layanan pembayaran. Trace sangat membantu bila aplikasimu terdiri dari banyak service. Untuk satu aplikasi monolit di satu server, trace sering belum diperlukan.

Metrik apa yang perlu dipantau pertama kali?

Ada dua kerangka yang banyak dipakai dan mudah diingat. Untuk sumber daya seperti CPU, disk, dan jaringan, pakai pola USE: utilization (seberapa penuh), saturation (seberapa banyak antrean), dan errors. Untuk layanan yang melayani request, pakai pola RED: rate (jumlah request), errors (jumlah yang gagal), dan duration (berapa lama).

Dalam praktik, daftar awal yang masuk akal untuk server bisnis adalah:

• Ketersediaan dari luar: apakah website dan API merespons dengan kode status yang benar.
• Waktu respons: bukan hanya rata-rata, tapi persentil tinggi seperti p95, karena rata-rata menyembunyikan pengguna yang mengalami lambat.
• Tingkat error: persentase response 5xx.
• CPU, RAM, dan load: untuk melihat apakah server kekurangan tenaga.
• Ruang disk: disk penuh sering menyebabkan gangguan, padahal mudah dicegah.
• Masa berlaku sertifikat HTTPS: agar tidak ada sertifikat kedaluwarsa yang terlewat.
• Status backup: apakah backup terakhir berhasil dan kapan.

Tumpukan awal yang realistis untuk tim kecil

Kamu tidak perlu memasang semuanya sekaligus. Bangun bertahap, dan setiap tahap sudah memberi manfaat sendiri.

Langkah pertama dan ketiga dibahas lebih rinci di memantau server dengan Uptime Kuma dan Grafana. Semua komponen di atas tersedia sebagai image container resmi, sehingga mudah dijalankan dengan Docker Compose seperti di panduan container.

Membuat alert yang tidak diabaikan

Masalah yang sering muncul pada alert bukan kekurangan, tapi kebanyakan. Ketika notifikasi masuk puluhan kali sehari dan sebagian besar tidak butuh tindakan, tim mulai mengabaikannya. Lalu alert yang benar-benar penting ikut terlewat.

Beberapa prinsip menjaga alert tetap berharga:

• Alert hanya untuk hal yang butuh tindakan manusia. Sisanya cukup tampil di dashboard.
• Utamakan gejala yang dirasakan pengguna, seperti website tidak bisa diakses atau error naik, dibanding penyebab seperti CPU tinggi sesaat.
• Beri jeda waktu. Kondisi yang harus bertahan beberapa menit sebelum alert dikirim menghindari notifikasi dari lonjakan singkat.
• Bedakan tingkat urgensi. Disk 80 persen cukup diberi tahu lewat pesan biasa, website mati perlu notifikasi yang membangunkan orang.
• Setiap alert punya catatan langkah awal, misalnya cek apa dulu dan siapa yang dihubungi.

Tinjau alert secara berkala. Alert yang sering berbunyi tanpa tindakan sebaiknya diubah batasnya atau dihapus.

Dashboard yang benar-benar dipakai

Dashboard yang baik menjawab satu pertanyaan dengan cepat. Hindari satu layar berisi puluhan panel yang tidak pernah dibaca. Pola yang membantu adalah membuat tingkatan: satu dashboard ringkasan untuk kesehatan layanan secara umum, lalu dashboard rinci per server atau per aplikasi untuk investigasi.

Letakkan panel paling penting di atas: ketersediaan, tingkat error, dan waktu respons. Grafik sumber daya server di bawahnya. Tautkan panel metrik ke log pada rentang waktu yang sama, sehingga saat melihat lonjakan error kamu bisa langsung membuka log yang relevan.

Berapa lama data perlu disimpan?

Masa simpan menentukan kebutuhan disk dan biaya. Tidak ada angka yang berlaku untuk semua, tapi pertimbangannya bisa dipetakan.

Cara praktis menekan biaya tanpa kehilangan informasi penting adalah memisahkan tingkat detail. Simpan metrik beresolusi tinggi untuk beberapa minggu, lalu ringkasan yang lebih kasar untuk jangka panjang bila alatmu mendukung. Untuk log, buang baris yang tidak pernah dibaca, seperti log debug di produksi atau pemeriksaan kesehatan yang berulang setiap beberapa detik. Volume log bisa turun cukup banyak hanya dengan menyaring dua jenis baris itu.

Satu jebakan teknis yang perlu dikenal adalah cardinality. Kalau kamu memberi label metrik dengan nilai yang sangat bervariasi, seperti ID pengguna atau URL lengkap, jumlah deret waktu meledak dan Prometheus jadi berat. Simpan detail seperti itu di log, bukan di label metrik.

Kebiasaan tim yang membuat observability bermanfaat

Alat hanya separuh cerita. Separuh lainnya adalah kebiasaan. Setelah setiap insiden, tulis catatan singkat: apa yang terjadi, bagaimana terdeteksi, apa yang memperbaikinya, dan alert atau dashboard apa yang perlu ditambah. Catatan seperti ini membuat sistem pemantauan makin baik dari waktu ke waktu.

Pastikan juga lebih dari satu orang tahu cara membaca dashboard dan merespons alert. Simpan konfigurasi Prometheus, aturan alert, dan dashboard dalam repository Git agar bisa dipulihkan bila server pemantauan rusak. Dan ingat bahwa sistem pemantauan juga butuh pengamanan: dashboard dan log sering berisi informasi sensitif, jadi jangan dibiarkan terbuka ke internet tanpa login. Langkah dasarnya ada di cara mengamankan VPS baru.

Saat aplikasi mulai dijalankan di beberapa server di balik load balancer, observability jadi semakin penting, karena masalah bisa terjadi di satu server saja sementara yang lain tampak sehat.