--- title: "Metrik Server yang Wajib Dipantau dan Batas Wajarnya" description: "CPU, load average, RAM, disk, jaringan, error rate, latensi, sampai masa berlaku SSL. Metrik server yang perlu dipantau dan kapan alert harus berbunyi." url: "https://nivelva.com/insight/metrik-server-wajib-dipantau" category: "Server \u0026 Infrastruktur" tags: ["monitoring server","metrik server","grafana","alerting","observability"] author: "Theresia Candiawan" published: "2026-11-07T02:46:00+07:00" updated: "2026-11-07T02:46:00+07:00" language: "id" publisher: "Nivelva (https://nivelva.com)" --- # Metrik Server yang Wajib Dipantau dan Batas Wajarnya > **Jawaban singkat:** Metrik inti yang perlu dipantau: CPU dan load average, RAM dan swap, ruang serta I/O disk, jaringan, error rate, latensi, dan masa berlaku sertifikat. Batas alert sebaiknya dimulai dari angka konservatif, lalu disesuaikan dengan pola normal servermu sendiri. 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](https://nivelva.com/insight/monitoring-server-uptime-kuma). ## Daftar metrik dan batas awal yang wajar | Metrik | Batas peringatan awal | Batas kritis awal | Catatan | |:--|:--|:--|:--| | CPU | Di atas 85% selama 15 menit | Di atas 95% selama 15 menit | Lonjakan singkat itu normal | | Load average | Di atas jumlah vCPU | Di atas 2 kali jumlah vCPU | Bandingkan dengan jumlah core | | RAM tersedia | Di bawah 15% | Di bawah 5% | Pakai nilai "available", bukan "free" | | Swap | Pemakaian terus naik | Swap hampir penuh | Swap aktif terus tanda RAM kurang | | Ruang disk | Terisi 80% | Terisi 90% | Pantau juga inode | | I/O wait | Di atas 20% berkelanjutan | Di atas 40% berkelanjutan | Tanda disk menjadi leher botol | | Error rate HTTP 5xx | Di atas 1% permintaan | Di atas 5% permintaan | Ukur per 5 menit | | Latensi p95 | 2 kali dari normal | 4 kali dari normal | Bandingkan dengan pola harian | | Sertifikat SSL | Sisa 21 hari | Sisa 7 hari | Perpanjangan otomatis bisa gagal diam-diam | ## 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](https://nivelva.com/insight/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](https://nivelva.com/insight/log-linux-penting). ## 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. > **Supaya alert tidak diabaikan:** > > Alert yang terlalu sering berbunyi akhirnya diabaikan. Mulailah dengan sedikit alert yang benar-benar butuh tindakan, kirim yang kritis ke kanal yang dibaca (misalnya Telegram atau email), dan setiap kali alert ternyata tidak penting, longgarkan batasnya atau hapus. ## 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. ## Pertanyaan yang sering diajukan ### Berapa interval pengambilan metrik yang cukup? Untuk server bisnis umum, interval 15 sampai 60 detik sudah memadai. Interval lebih rapat memberi detail lebih halus tapi memperbesar data yang disimpan. ### Apakah perlu memantau server yang jarang dipakai? Tetap perlu, minimal cek ketersediaan, ruang disk, dan sertifikat. Server yang jarang disentuh justru sering kedapatan disk penuh atau sertifikat kedaluwarsa karena tidak ada yang melihat. ### Lebih baik monitoring dijalankan di server yang sama atau terpisah? Cek ketersediaan sebaiknya dari lokasi lain, karena kalau servernya mati, monitor di server yang sama ikut mati dan tidak bisa mengirim alert. Pengumpul metrik boleh berjalan di server yang dipantau. 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. ## Sumber - - - --- Diterbitkan oleh Nivelva Insight (https://nivelva.com/insight/). Artikel ini: https://nivelva.com/insight/metrik-server-wajib-dipantau Kontak Nivelva: WhatsApp https://wa.me/6285111245007, email hello@nivelva.com