Monitoring Homelab: Prometheus dan Grafana Tanpa Alert Berisik

Dashboard dengan empat puluh panel terlihat mengesankan sampai satu layanan mati enam jam dan tidak ada satu pun notifikasi yang masuk. Grafik yang indah tidak menolong siapa pun kalau tidak ada yang melihatnya.

Foto: NASA/JPL-Caltech, public domain, via Wikimedia Commons

Uptime Kuma sudah memberi tahu Anda bahwa sesuatu mati. Yang tidak diberikannya adalah jawaban atas pertanyaan yang sebenarnya: kenapa. Untuk itu Anda butuh data historis — dan itulah bedanya monitoring dengan sekadar pengecekan status.

Tiga lapisan yang perlu dipantau

Sebagian besar homelab hanya memantau lapisan pertama, lalu bingung ketika masalah muncul dari lapisan lain.

• Infrastruktur — CPU, RAM, disk, suhu, daya. Ini yang memberi tahu Anda kapasitas sedang habis, bukan sekadar layanan mati.
• Layanan — apakah aplikasi benar-benar melayani permintaan, bukan hanya berjalan. Container hidup dengan respons 500 tetap dihitung mati.
• Pengalaman pengguna — waktu respons dan tingkat error dari sudut pandang luar. Ini satu-satunya lapisan yang benar-benar dirasakan orang.

Stack minimal yang cukup

Empat komponen, tidak lebih: node_exporter untuk metrik host, cadvisor untuk metrik per container, Prometheus untuk menyimpan, Grafana untuk melihat. Alertmanager ditambahkan hanya ketika Anda sudah punya sesuatu yang layak diberitakan.

services:
  prometheus:
    image: prom/prometheus:v2.54.1
    restart: unless-stopped
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - prom_data:/prometheus
    command:
      - --config.file=/etc/prometheus/prometheus.yml
      - --storage.tsdb.retention.time=15d
      - --storage.tsdb.retention.size=8GB
    ports:
      - "127.0.0.1:9090:9090"

volumes:
  prom_data:

Dua hal yang saya sengaja tulis eksplisit. Pertama, 127.0.0.1 di depan port — Prometheus tidak perlu terbuka ke internet. Kedua, batas retensi dan ukuran. Hanya memakai batas waktu berarti server dengan banyak metrik bisa menghabiskan disk jauh sebelum 15 hari tercapai.

Kardinalitas: cara paling cepat membunuh Prometheus

Prometheus menyimpan satu deret waktu untuk setiap kombinasi label. Menambahkan label berisi ID pengguna, URL lengkap, atau alamat IP akan melipatgandakan jumlah deret secara eksplosial. Saya pernah melihat satu exporter menghasilkan dua juta deret dari satu endpoint sederhana, dan Prometheus kehabisan RAM dalam hitungan jam.

Aturannya: label hanya untuk dimensi yang jumlahnya terbatas dan memang ingin Anda agregasi — instance, job, status_code. Kalau nilainya bisa berubah tanpa batas, jangan dijadikan label.

Alert yang baik adalah alert tentang gejala

Kesalahan umum: memberi alert untuk setiap metrik yang bisa naik. CPU 80 persen bukan masalah kalau layanan tetap responsif. Yang perlu Anda ketahui adalah ketika pengguna mulai merasakan sesuatu.

Empat alert yang menurut saya cukup untuk homelab:

• Disk hampir penuh — prediksi berdasarkan laju pertumbuhan, bukan angka statis. Disk 90 persen yang tumbuh 1 persen per hari berbeda dengan yang stabil.
• Layanan tidak merespons — probe HTTP dari luar, bukan dari host yang sama.
• Tingkat error naik — 5xx di atas ambang selama beberapa menit.
• Server berhenti melapor — ini yang paling penting dan paling sering dilupakan.

Tambahkan for: 5m pada setiap aturan. Tanpa itu, satu lonjakan sesaat akan mengirim notifikasi, dan setelah beberapa kali orang berhenti mempercayai notifikasi itu. Alert fatigue bukan masalah teknis, tapi masalah kepercayaan — dan jauh lebih sulit diperbaiki.

Dead man's switch

Alertmanager berjalan di server yang sama dengan yang dipantaunya. Kalau servernya mati total, tidak ada yang mengirim notifikasi. Ini lubang yang tidak bisa ditutup dari dalam.

Solusinya sederhana: layanan eksternal yang mengharapkan ping berkala. Kalau ping berhenti, layanan itu yang memberi tahu Anda. Prometheus bisa mengirim ping lewat curl terjadwal, atau Anda cukup memakai layanan seperti healthchecks.io dengan satu systemd timer. Yang penting: pengawasnya berada di luar mesin yang diawasi.

Yang tidak perlu Anda pantau

Setiap panel di dashboard adalah janji bahwa Anda akan melihatnya. Kalau tidak, panel itu hanya dekorasi yang menambah beban mental. Saya membuang metrik seperti suhu CPU per core, jumlah proses, dan grafik jaringan per detik — semuanya jarang menjawab pertanyaan nyata.

Yang saya pertahankan hanya yang bisa menjawab satu dari tiga pertanyaan: apakah ini akan segera penuh, apakah ini sedang rusak, dan sejak kapan. Sisanya boleh dilihat saat dibutuhkan, tidak perlu dipajang.

Monitoring yang baik terasa sepi. Tidak ada notifikasi, tidak ada panel merah, dan ketika sesuatu terjadi Anda tahu persis ke mana harus melihat.

Baca juga:

• How to Self-Host Uptime Kuma for Server Monitoring
• Kenapa Homelab Mati dalam 6 Bulan: Bedah Kegagalan Self-Hosting
• Cara Install Proxmox VE di PC Bekas untuk Homelab
• Cara Memakai Cloudflare Tunnel: Akses Server Tanpa Buka Port