Monitoring Banyak Server dari Satu Dashboard: Dari Uptime sampai Root Cause

Ketika hanya mengelola satu server, pemeriksaan manual masih terasa masuk akal. Saya bisa masuk lewat SSH, menjalankan top, mengecek kapasitas disk, lalu membaca log service yang bermasalah.

Masalahnya berubah saat jumlah server bertambah. Ada VPS untuk aplikasi publik, mesin lain untuk database, dan home server untuk layanan internal. Memeriksa semuanya satu per satu bukan hanya melelahkan—cara itu juga membuat masalah baru terlihat setelah pengguna lebih dulu mengeluh.

Karena itu, saya mulai menyusun monitoring sebagai sebuah jalur diagnosis, bukan sekadar halaman dengan banyak grafik. Dari satu dashboard, saya ingin bisa menjawab empat pertanyaan:

1. Apakah layanan dapat diakses?
2. Apakah host dan container dalam kondisi sehat?
3. Kapan gejala mulai muncul?
4. Di lapisan mana penyebabnya berada?

Foto oleh Luke Chesser melalui Unsplash.

Monitoring Bukan Satu Tool

Kesalahan yang mudah terjadi adalah mencari satu aplikasi yang dianggap bisa menyelesaikan semuanya. Dalam praktiknya, setiap jenis pemeriksaan menjawab pertanyaan berbeda.

Lapisan	Pertanyaan	Contoh data
Endpoint	Apakah pengguna bisa membuka layanan?	HTTP status, TLS, latency
Service	Apakah proses atau container berjalan?	restart count, health check, port
Host	Apakah mesin kehabisan resource?	CPU, RAM, disk, load, network
Aplikasi	Mengapa request gagal?	error rate, trace, application log
Infrastruktur	Apakah jalur pendukung sehat?	tunnel, DNS, database, private network

Status 200 OK belum tentu berarti aplikasi sehat. Halaman login mungkin tampil, tetapi worker antrean berhenti. Sebaliknya, CPU tinggi belum tentu merupakan insiden jika terjadi saat backup terjadwal dan layanan tetap responsif.

Saya memakai kombinasi beberapa lapisan agar sinyal-sinyal itu saling melengkapi:

• uptime monitor untuk melihat layanan dari sudut pandang pengguna;
• host agent untuk CPU, RAM, disk, network, process, dan container;
• dashboard terpusat untuk membandingkan kondisi lintas server;
• log untuk menjelaskan penyebab setelah gejala ditemukan;
• alert untuk menarik perhatian hanya ketika tindakan memang diperlukan.

Arsitektur yang Saya Pilih

Saya lebih menyukai model hub-and-agent. Satu mesin berperan sebagai pusat visualisasi, sementara agent ringan berjalan di setiap node yang dipantau.

Server aplikasi ── agent ──┐
Server database ── agent ──┼── private network ── monitoring hub
Home server ────── agent ──┘                         │
                                                    ├── dashboard
Internet ───────── HTTP/TCP checks ─────────────────└── alert

Ada dua arah pemeriksaan di sini:

• Dari luar ke layanan, untuk mengetahui pengalaman pengguna.
• Dari dalam host ke hub, untuk mengirim kondisi mesin.

Keduanya penting. Jika pengecekan publik gagal tetapi agent masih online, kemungkinan masalah ada di DNS, reverse proxy, tunnel, sertifikat, atau aplikasi. Jika agent dan endpoint sama-sama hilang, masalahnya mungkin berada di host atau jaringan yang lebih dasar.

Ilustrasi dihasilkan dengan model ag/gemini-3.1-flash-image melalui 9router untuk memvisualisasikan pola hub-and-agent. Elemen dashboard bersifat konseptual, bukan tangkapan layar produk tertentu.

1. Mulai dari Pemeriksaan yang Mewakili Pengguna

Untuk aplikasi web, saya tidak berhenti pada ping. ICMP bisa berhasil ketika aplikasi gagal, dan bisa diblokir ketika aplikasi sebenarnya sehat.

Pengecekan yang lebih berguna biasanya berupa:

GET https://app.example.com/health
Expected status: 200
Timeout: 10s
Interval: 60s

Endpoint health sebaiknya cukup ringan, tetapi tetap memeriksa dependency yang material. Contohnya:

{
  "status": "ok",
  "database": "reachable",
  "queue": "ready"
}

Saya menghindari health check yang menjalankan query berat. Tujuannya adalah memperoleh sinyal cepat, bukan menambah beban baru setiap menit.

Untuk layanan non-HTTP, pemeriksaannya bisa berupa TCP connect, DNS resolution, atau validasi sertifikat TLS. Yang penting, metode pemeriksaan sesuai dengan kegagalan yang benar-benar ingin diketahui.

2. Pantau Resource, tetapi Fokus pada Saturation

Grafik CPU dan RAM terlihat menarik, tetapi tidak semua lonjakan adalah masalah. Saya lebih memperhatikan kondisi yang menunjukkan resource mulai tidak mampu mengikuti beban.

Beberapa sinyal yang berguna:

• load average yang tinggi secara konsisten dibanding jumlah CPU;
• memory pressure dan penggunaan swap yang terus naik;
• disk hampir penuh atau pertumbuhan filesystem yang tidak wajar;
• I/O wait tinggi;
• packet loss atau latency antarnode meningkat;
• container berulang kali restart;
• proses penting hilang walaupun host masih online.

Disk layak mendapat perhatian khusus. Banyak layanan gagal bukan karena CPU habis, tetapi karena volume log, backup, cache, atau database memenuhi filesystem.

Pemeriksaan cepat dari host tetap berguna untuk memvalidasi dashboard:

uptime
free -h
df -h
ss -lntp
systemctl --failed

Dashboard mempercepat deteksi pola, sedangkan pemeriksaan langsung membantu memastikan bahwa interpretasinya benar.

3. Bedakan Availability dan Performance

Sebuah endpoint dapat tetap up tetapi membutuhkan beberapa detik untuk merespons. Karena itu, saya menyimpan latency sebagai sinyal terpisah dari availability.

Contoh aturan yang lebih informatif:

Critical: 3 kali check gagal berturut-turut
Warning: p95 latency > 1.5 detik selama 10 menit
Recovery: 3 kali check berhasil berturut-turut

Kondisi berturut-turut membantu mengurangi alert akibat gangguan singkat. Namun, ambangnya tidak boleh dibuat terlalu longgar sampai insiden nyata terlambat diketahui.

Saya juga lebih memilih percentile seperti p95 daripada hanya rata-rata. Average dapat terlihat normal walaupun sebagian pengguna menerima respons yang sangat lambat.

4. Gunakan Private Network untuk Jalur Operasional

Dashboard monitoring dan endpoint agent membawa informasi yang tidak perlu dibuka ke internet. Karena itu, jalur operasional saya tempatkan di private network, misalnya melalui Tailscale.

Prinsipnya sederhana:

• agent mengirim data melalui alamat privat;
• dashboard hanya bind ke loopback atau interface privat;
• SSH dan administrasi host tidak menggunakan port publik;
• halaman monitoring publik, jika memang diperlukan, diterbitkan melalui reverse proxy atau tunnel yang sengaja dikonfigurasi.

Contoh binding yang lebih aman:

services:
  dashboard:
    image: example/monitoring-hub:latest
    ports:
      - "127.0.0.1:3000:3000"
    restart: unless-stopped

Binding ke 127.0.0.1 mencegah dashboard otomatis mendengarkan di seluruh interface host. Akses publik kemudian menjadi keputusan eksplisit, bukan efek samping konfigurasi Docker.

Pendekatan private network juga membuat agent tetap dapat berkomunikasi meskipun alamat IP publik berubah. Identitas node lebih stabil dan jalur monitoring tidak bergantung pada membuka port baru di setiap server.

5. Rancang Alert untuk Manusia

Monitoring yang mengirim terlalu banyak notifikasi akhirnya diabaikan. Saya ingin setiap alert menjelaskan apa yang rusak, di mana, sejak kapan, dan pemeriksaan pertama yang perlu dilakukan.

Alert yang baik setidaknya membawa:

Service: api-production
Node: app-01
State: DOWN
Started: 02:14 UTC
Check: HTTPS /health timed out after 10s
Dashboard: https://monitor.example.com/...

Beberapa aturan yang saya gunakan untuk mengurangi noise:

1. beri jeda pendek sebelum mengirim alert untuk gejala sesaat;
2. kelompokkan alert dari dependency yang sama;
3. kirim recovery notification agar status akhirnya jelas;
4. bedakan warning dan critical;
5. jangan menjadikan setiap kenaikan CPU sebagai insiden;
6. uji kanal notifikasi secara berkala.

Alert juga harus memiliki pemilik. Notifikasi yang masuk ke kanal tanpa ada orang yang merasa bertanggung jawab sama saja dengan tidak memiliki alert.

6. Troubleshooting dari Gejala ke Penyebab

Saat menerima notifikasi, saya berusaha tidak langsung me-restart container. Restart memang bisa memulihkan layanan, tetapi juga dapat menghapus petunjuk penting.

Urutan diagnosis yang saya pakai:

A. Pastikan dampaknya

curl -I --max-time 10 https://app.example.com/health

Apakah layanan benar-benar gagal dari lokasi lain, atau hanya monitor yang kehilangan koneksi?

B. Periksa jalur publik

• DNS mengarah ke target yang benar;
• sertifikat belum kedaluwarsa;
• tunnel atau reverse proxy aktif;
• response code sesuai, bukan redirect loop atau halaman error proxy.

C. Periksa origin

curl -I http://127.0.0.1:3000/health
ss -lntp

Jika origin sehat tetapi hostname publik gagal, fokus dapat dipersempit ke lapisan jaringan dan proxy.

D. Periksa host dan container

docker ps --format 'table {{.Names}}\t{{.Status}}'
docker stats --no-stream
journalctl --since "15 minutes ago" -p warning

E. Korelasikan waktu

Saya melihat grafik CPU, memory, disk, latency, restart count, dan log pada rentang waktu yang sama. Korelasi temporal sering memberikan petunjuk lebih cepat daripada membaca log tanpa batas waktu.

Misalnya:

02:11 disk mencapai 98%
02:12 database mulai menolak write
02:13 API latency meningkat
02:14 health check gagal

Rangkaian itu jauh lebih berguna daripada satu alert “website down”.

7. Hal yang Sering Terlupakan

Monitor juga bisa mati

Jika monitoring hub mati, dashboard tidak akan bisa memberi tahu dirinya sendiri. Minimal, saya menambahkan pengecekan eksternal untuk endpoint hub atau heartbeat yang diawasi dari lokasi berbeda.

Retensi harus direncanakan

Metrik beresolusi tinggi dan log tumbuh cepat. Retensi perlu disesuaikan dengan kapasitas disk dan kebutuhan investigasi. Data satu menit untuk beberapa minggu sering lebih berguna daripada data sangat detail yang memenuhi storage dalam dua hari.

Clock harus sinkron

Korelasi antarnode sulit dilakukan jika jam server berbeda. Sinkronisasi waktu melalui NTP adalah dependency kecil yang sangat penting untuk observability.

Backup konfigurasi monitoring

Dashboard, alert rule, daftar endpoint, dan konfigurasi agent adalah bagian dari infrastruktur. Saya menyimpan konfigurasi yang dapat diekspor dan memasukkannya ke strategi backup, bukan hanya membackup data aplikasi.

Lakukan simulasi kegagalan

Monitoring belum benar-benar diuji sampai ada kegagalan. Saya melakukan percobaan terkontrol seperti menghentikan service nonkritis, mengubah health check sementara, atau menguji kanal notifikasi. Tujuannya memastikan deteksi, alert, dan recovery bekerja dari ujung ke ujung.

Checklist Implementasi

Berikut checklist ringkas yang saya gunakan saat menambahkan node baru:

• identitas dan hostname node konsisten;
• private network terhubung;
• agent berjalan otomatis setelah reboot;
• CPU, memory, disk, network, dan process terlihat di hub;
• endpoint pengguna memiliki health check;
• expiry TLS dipantau;
• critical service memiliki process atau container check;
• alert failure dan recovery sudah diuji;
• dashboard tidak terekspos langsung ke internet;
• konfigurasi masuk ke backup;
• runbook mencantumkan langkah diagnosis pertama.

Penutup

Bagi saya, nilai monitoring bukan pada jumlah grafik, melainkan pada waktu yang berhasil dihemat saat sesuatu gagal.

Dashboard yang baik membuat saya bergerak dari sinyal umum menuju penyebab yang lebih spesifik: dari “website tidak dapat diakses”, ke “origin sehat tetapi tunnel putus”, atau dari “API lambat”, ke “disk database penuh setelah log tumbuh tanpa rotasi”.

Itulah alasan saya membangun monitoring secara berlapis. Uptime check memberi tahu dampaknya, metrik host menunjukkan tekanan resource, log menjelaskan kejadian, dan private network menjaga jalur operasional tetap tidak perlu dibuka ke internet.

Monitoring tidak menghilangkan insiden. Namun, dengan sinyal yang tepat dan jalur diagnosis yang jelas, insiden tidak lagi dimulai dari tebakan.

Jika tertarik dengan cara menerbitkan layanan self-hosted tanpa membuka port origin, baca juga Membuka Akses Home Server Tanpa Membuka Port dengan Cloudflare Tunnel.