Uptime Kuma merupakan tool ringan untuk monitoring uptime website, API, dan layanan lainnya dari luar sistem yang dipantau. Instalasinya relatif cepat, tetapi penempatan instance perlu diperhatikan. Jika Uptime Kuma dijalankan di server yang sama dengan aplikasi yang dipantau, kegagalan server atau jaringan dapat membuat aplikasi dan sistem monitoring tidak tersedia secara bersamaan. Karena itu, instance monitoring sebaiknya ditempatkan di lingkungan yang terpisah.
Fungsi Uptime Kuma dan Batasannya
Uptime Kuma digunakan untuk memeriksa ketersediaan layanan dari sisi luar. Tool ini dapat memeriksa endpoint secara terjadwal, mencatat response time dan uptime, mengirim notifikasi ketika pemeriksaan gagal, serta menyediakan status page. Karena bersifat self-hosted dan ringan, Uptime Kuma cukup praktis untuk tim development atau operations yang ingin mengelola monitoring sendiri.
Uptime Kuma bukan pengganti infrastructure monitoring. Tool ini tidak memberikan visibilitas server seperti CPU, memory, disk, atau metrik kapasitas jangka panjang. Pembagian peran yang praktis adalah menggunakan platform seperti Zabbix untuk monitoring resource dan kapasitas, sedangkan Uptime Kuma digunakan untuk memeriksa ketersediaan layanan dari luar, termasuk notifikasi dan komunikasi status.
Jalankan Uptime Kuma di Luar Sistem yang Dipantau
Penempatan instance monitoring sangat penting. Jika Uptime Kuma berbagi server, hypervisor, jalur jaringan, atau region cloud dengan aplikasi, keduanya dapat terkena gangguan yang sama. Ketika lingkungan aplikasi tidak tersedia, dashboard dan jalur notifikasi juga bisa ikut tidak tersedia.
Untuk layanan publik, gunakan instance kecil pada provider berbeda atau setidaknya region berbeda. Layanan internal yang tidak dapat diakses dari internet publik mungkin membutuhkan instance kedua di dalam jaringan. Untuk layanan yang digunakan pelanggan, usahakan tetap memiliki monitoring dari luar lingkungan internal.
Sistem monitoring sebaiknya tetap tersedia ketika aplikasi yang dipantau mengalami gangguan.
Pilih Jenis Monitor Uptime Kuma Sesuai Layanannya
Uptime Kuma menyediakan beberapa jenis monitor. Jenis yang digunakan sebaiknya mengikuti cara sebuah layanan dapat mengalami kegagalan. HTTP check sederhana, misalnya, belum tentu mendeteksi aplikasi yang menampilkan halaman error tetapi tetap mengembalikan status code 200.
| Jenis monitor | Digunakan untuk | Catatan |
|---|---|---|
| HTTP(s) | Endpoint publik yang status code-nya memang bermakna | Pastikan aplikasi benar-benar mengembalikan status error saat gagal sebelum mengandalkan jenis ini saja |
| HTTP(s) Keyword | Halaman dan API yang bisa gagal tetapi tetap mengembalikan 200 | Cocokkan teks yang hanya muncul ketika halaman benar-benar tampil, bukan kata dari elemen layout |
| HTTP(s) Json Query | Health endpoint yang mengembalikan field status dalam format JSON | Berguna ketika endpoint melaporkan dependency yang terdegradasi, bukan sekadar hidup atau mati |
| TCP Port | Layanan non-HTTP seperti mail, database, atau message broker | Membuktikan port menerima koneksi, yang buktinya lebih lemah dibanding pemeriksaan pada level protokol |
| Ping | Keterjangkauan jaringan dasar | ICMP sering difilter atau diprioritaskan rendah, jadi perlakukan sebagai bukti pendukung saja |
| DNS | Resolusi dan kebenaran record | Menangkap masalah registrar, propagasi, dan penyedia yang oleh endpoint check hanya dilaporkan sebagai kegagalan umum |
| Push | Cron job, backup, dan proses terjadwal | Job memanggil sebuah URL ketika berhasil, dan alert muncul saat heartbeat yang ditunggu tidak kunjung datang |
Push monitor berguna untuk job terjadwal yang tidak memiliki endpoint untuk diperiksa. Backup, misalnya, dapat mengirim heartbeat setelah proses berhasil. Jika heartbeat yang diharapkan tidak diterima, Uptime Kuma dapat memicu alert. HTTP monitor juga dapat memeriksa masa berlaku sertifikat TLS dan memberikan notifikasi lebih awal.
Atur Retry dan Notifikasi agar Alert Tetap Relevan
Satu kali pemeriksaan gagal belum tentu berarti layanan sedang down. Gangguan jaringan sesaat dapat menghasilkan failed check, sehingga notifikasi pada kegagalan pertama dapat menambah alert yang tidak perlu. Gunakan retry dan interval retry yang sesuai agar Uptime Kuma memastikan kegagalan berulang sebelum menganggapnya sebagai insiden.
- Tentukan interval pemeriksaan sesuai seberapa cepat sebuah kegagalan perlu diketahui. Enam puluh detik merupakan pilihan awal yang wajar, dan interval yang lebih pendek umumnya hanya menambah beban tanpa mempercepat penanganan.
- Gunakan retry dengan interval retry yang lebih singkat agar gangguan nyata tetap terkonfirmasi dalam satu sampai dua menit, sementara request yang gagal sesekali tidak ikut memicu alert.
- Aktifkan opsi resend agar insiden yang belum selesai mengirim notifikasi ulang secara berkala, sehingga satu pesan yang terlewat tidak berubah menjadi gangguan yang tidak disadari.
- Pasang minimal dua kanal notifikasi pada monitor yang kritis, karena integrasi yang rusak atau token bot yang terkena rate limit dapat membuat keadaan menjadi sunyi sepenuhnya.
- Jadwalkan maintenance window sebelum pekerjaan terencana agar downtime yang memang diketahui tidak menghubungi siapa pun dan tidak muncul sebagai insiden di status page.
- Pisahkan tujuan notifikasi berdasarkan tingkat kepentingan, bukan mengirim semua monitor ke kanal yang sama, supaya notifikasi yang butuh tindakan segera tidak tenggelam di antara yang bersifat informatif.
Gunakan Status Page untuk Komunikasi Layanan
Uptime Kuma dapat menyediakan status page yang menampilkan kondisi layanan kepada pengguna. Saat terjadi gangguan, halaman ini dapat mengurangi pertanyaan berulang dengan memberikan informasi mengenai layanan yang terdampak dan status penanganannya.
Status page sebaiknya ditempatkan di luar infrastruktur yang dilaporkannya. Nama layanan juga perlu menggunakan istilah yang mudah dipahami pengguna, bukan hostname internal. Contohnya, pengguna lebih mudah memahami 'Payment Service' dibandingkan nama internal seperti 'api-gateway-02'.
Detail Operasional dan Maintenance Uptime Kuma
- Aplikasi menyimpan konfigurasi dan riwayatnya di sebuah direktori data, sehingga direktori tersebut harus berupa volume persisten dan masuk dalam cakupan backup. Membuat ulang container tanpa data itu berarti menyusun kembali seluruh monitor secara manual.
- Tempatkan antarmukanya di belakang reverse proxy dengan TLS, batasi akses administratif, lalu aktifkan autentikasi dua faktor. Instance ini menyimpan token notifikasi dan mengetahui peta lingkungan Anda.
- Jaga versinya tetap mutakhir. Pembaruan relatif sederhana untuk deployment satu container, dan software monitoring yang setahun tidak diperbarui merupakan risiko yang tidak perlu pada host yang terbuka ke internet.
- Perhatikan kombinasi jumlah monitor dan frekuensi pemeriksaan, bukan salah satunya saja. Ratusan monitor dengan interval pendek pada instance minimal akan menghasilkan pemeriksaan yang tertunda dan terlihat seperti alarm palsu.
- Tinjau daftar monitor setiap kuartal. Layanan yang sudah dinonaktifkan tetapi monitornya masih ada akan memunculkan alert berulang, sedangkan layanan yang baru ditambahkan biasanya justru yang belum dipantau siapa pun.
Urutan Implementasi Uptime Kuma
- 1Susun daftar layanan yang berdampak pada pengguna beserta penanggung jawab masing-masing sebelum membuat monitor apa pun. Pemeriksaan tanpa pemilik menghasilkan notifikasi yang tidak menjadi tanggung jawab siapa pun untuk diselesaikan.
- 2Pasang instance di luar lingkungan yang akan dipantau, lengkap dengan penyimpanan persisten, TLS, dan pembatasan akses administratif sejak awal, bukan sebagai langkah pengamanan menyusul.
- 3Buat monitor untuk alur yang paling penting bagi pengguna terlebih dahulu, dengan pemeriksaan keyword atau JSON pada kasus yang tidak cukup dideteksi lewat status code.
- 4Tambahkan monitor push untuk backup dan job terjadwal, karena kegagalan diam-diam pada area ini biasanya baru diketahui pada saat yang paling tidak tepat.
- 5Atur retry, perilaku resend, dan minimal dua kanal notifikasi, lalu uji jalur alerting dengan sengaja menggagalkan satu monitor percobaan, bukan sekadar mengasumsikan semuanya berjalan.
- 6Terbitkan status page dengan nama layanan yang dipahami audiens, dan sepakati siapa yang memperbarui pesan insiden saat gangguan berlangsung.
Seperti Apa Setup Uptime Kuma yang Baik
Pada setup yang baik, setiap notifikasi memiliki alasan yang jelas dan membutuhkan tindakan. Instance monitoring tetap terpisah dari sistem yang dipantau, maintenance terencana tidak menghasilkan alert yang tidak perlu, dan status page menjadi sumber informasi bagi pengguna. Data uptime juga dapat digunakan dalam evaluasi layanan karena dikumpulkan dari luar sistem.
Uptime Kuma berfokus pada availability, bukan root-cause analysis. Fungsinya adalah memberi indikasi yang andal ketika layanan tidak lagi merespons sesuai pemeriksaan yang dikonfigurasi, kemudian meneruskan informasi tersebut melalui kanal notifikasi yang digunakan tim.
Poin penting
- Pasang monitor di luar infrastruktur yang dipantau. Instance monitoring yang ikut mati bersama aplikasi tidak melaporkan apa pun.
- Sesuaikan jenis monitor dengan bentuk kegagalannya. Pemeriksaan keyword dan JSON menangkap aplikasi yang gagal tetapi tetap mengembalikan status 200.
- Gunakan monitor push sebagai heartbeat untuk backup dan job terjadwal, karena di area itu kegagalan diam-diam adalah pola yang paling umum.
- Atur retry, perilaku resend, dan kanal notifikasi cadangan, lalu uji jalur alert secara sengaja alih-alih mengasumsikannya berfungsi.
