Metrik Server yang Wajib Dipantau dan Batas Wajarnya

Delapan metrik sudah cukup untuk menangkap sebagian besar masalah server sebelum pelanggan merasakannya: CPU, load average, RAM, disk, I/O disk, jaringan, error rate dan latensi aplikasi, serta masa berlaku sertifikat.

Ini penting karena server jarang mati mendadak tanpa tanda. Disk terisi pelan-pelan selama berminggu-minggu, memori bocor sedikit demi sedikit, sertifikat kedaluwarsa pada tanggal yang sebenarnya sudah tercantum sejak sertifikat itu diterbitkan. Pemantauan yang baik mengubah kejutan tengah malam menjadi tugas biasa di jam kerja.

Angka batas di artikel ini adalah titik awal yang umum dipakai, bukan aturan baku. Setiap server punya pola normalnya sendiri, dan pola itulah yang akhirnya menentukan kapan alert perlu berbunyi.

Dua jenis metrik: gejala dan penyebab

Sebelum masuk daftar, bedakan dulu dua kelompok ini.

Metrik gejala menjawab "apakah pengguna terganggu?": website bisa diakses atau tidak, seberapa lambat, seberapa sering error. Ini yang paling layak membangunkan orang di malam hari.

Metrik penyebab menjawab "kenapa?": CPU, RAM, disk. Metrik ini penting untuk diagnosis dan untuk peringatan dini, tapi CPU 90 persen yang tidak membuat website lambat belum tentu masalah.

Pemula sering kebalikannya: banyak alert untuk CPU, tidak ada satu pun untuk "website mati". Alat seperti Uptime Kuma mengisi sisi gejala, sedangkan Grafana dengan pengumpul metrik mengisi sisi penyebab. Keduanya dibahas di memantau server dengan Uptime Kuma dan Grafana.

Daftar metrik dan batas awal yang wajar

CPU dan load average: apa bedanya?

Persentase CPU menunjukkan seberapa sibuk prosesor. Load average menunjukkan berapa banyak proses yang sedang berjalan atau menunggu giliran, termasuk yang menunggu disk di Linux. Itu sebabnya load bisa tinggi padahal CPU santai: prosesnya antre karena disk lambat.

Cara membaca load paling sederhana: bandingkan dengan jumlah vCPU. Load 4 di server 4 vCPU berarti penuh tapi belum antre. Load 4 di server 1 vCPU berarti ada antrean panjang. Perintah nproc memberi tahu jumlah vCPU, uptime menampilkan load 1, 5, dan 15 menit.

Pakai jendela waktu untuk alert CPU. CPU 100 persen selama 30 detik saat cron backup berjalan itu wajar. CPU tinggi selama 15 menit tanpa sebab yang jelas pantas diselidiki.

RAM: kenapa "free" menyesatkan?

Linux sengaja memakai RAM kosong untuk cache file. Akibatnya angka "free" di free -h sering tampak kecil walau server baik-baik saja. Yang perlu dipantau adalah kolom available, yaitu memori yang bisa dipakai aplikasi bila dibutuhkan, termasuk cache yang bisa dilepas.

Saat RAM benar-benar habis, kernel menjalankan OOM killer dan mematikan proses, sering kali proses terbesar seperti database. Jejaknya bisa dicari dengan journalctl -k | grep -i oom. Kalau ini berulang, servermu butuh RAM lebih besar atau aplikasinya perlu dibatasi. Panduan memilih ukuran ada di memilih spesifikasi VPS.

Disk: ruang, inode, dan kecepatan

Disk penuh adalah penyebab gangguan yang paling bisa dicegah. Database berhenti menulis, log tidak tercatat, bahkan login SSH bisa gagal. Pantau tiga hal:

• Ruang terpakai, dengan df -h. Alert di 80 persen memberi waktu bereaksi, terutama bila disk terisi pelan.
• Inode, dengan df -i. Jutaan file kecil (misalnya file sesi atau cache) bisa menghabiskan inode walau ruang masih lega.
• I/O wait dan latensi disk, terlihat di top (kolom wa) atau iostat. Angka tinggi berarti aplikasi menunggu disk.

Alert yang lebih cerdas adalah perkiraan: "disk akan penuh dalam 3 hari dengan laju sekarang". Di Prometheus, fungsi predict_linear menghitung perkiraan seperti ini dan hasilnya bisa dipakai untuk alert di Grafana. Penyebab paling umum disk penuh adalah log, dibahas di lokasi log penting di Linux.

Jaringan dan aplikasi

Untuk jaringan, pantau trafik masuk dan keluar serta paket yang dibuang (dropped). Lonjakan trafik keluar yang tidak wajar bisa menandakan server disalahgunakan, misalnya mengirim spam. Lonjakan trafik masuk disertai latensi naik bisa berarti serangan atau sekadar promosi yang sukses.

Untuk aplikasi, dua angka paling jujur adalah error rate (persentase respons 5xx) dan latensi persentil 95 (p95), yaitu batas waktu respons yang tidak dilampaui oleh 95 persen permintaan. Rata-rata menyembunyikan pengalaman pengunjung yang lambat, p95 tidak.

Sertifikat, backup, dan hal yang mudah terlupa

Beberapa hal tidak muncul di grafik CPU tapi sering jadi sumber gangguan:

• Masa berlaku sertifikat SSL. Perpanjangan otomatis bisa gagal karena DNS berubah atau port 80 tertutup. Alert sisa 21 hari memberi banyak waktu.
• Masa berlaku domain. Sama pentingnya, jarang dipantau.
• Keberhasilan backup. Pantau apakah job backup terakhir sukses dan kapan. Backup yang diam-diam gagal sebulan baru ketahuan saat dibutuhkan.
• Layanan penting berjalan, misalnya status systemd untuk web server dan database.

Bagaimana menyusun alert yang masuk akal?

Urutan praktisnya begini. Pertama, pasang cek dari luar: website dan API bisa diakses, sertifikat belum kedaluwarsa. Kedua, kumpulkan metrik server dan amati satu sampai dua minggu untuk melihat pola normal. Ketiga, baru pasang alert penyebab dengan batas dari tabel di atas, lalu sesuaikan.

Setiap alert sebaiknya punya jendela waktu (misalnya "selama 10 menit") agar lonjakan sesaat tidak memicu notifikasi, dan sebaiknya ada catatan singkat langkah pertama yang harus dilakukan saat alert itu berbunyi.

Mulailah dari yang paling sederhana: cek website dari luar, alert disk 80 persen, dan alert sertifikat 21 hari. Tiga hal itu saja sudah mencegah banyak gangguan yang paling sering terjadi.