# Monitoring dan Alerting untuk DevOps Solo: Stack Praktis yang Berhasil > Cara menyiapkan monitoring dan alerting sebagai engineer DevOps solo — Prometheus, Grafana, Uptime Kuma, dan alert Telegram tanpa kompleksitas enterprise. URL: https://www.matthewswong.com/id/blog/monitoring-alerting-solo/ - Author: Matthews Wong (https://www.matthewswong.com/id/about/) - Published: 2025-06-10 - Updated: 2026-10-17 - Category: DevOps Seorang engineer DevOps solo atau tim yang sangat kecil biasanya tidak mampu membayar tim SRE khusus atau alat APM enterprise. Yang terjangkau adalah stack monitoring self-hosted yang biaya operasinya kecil dan memberi tahu Anda tentang masalah sebelum klien menyadarinya. Kombinasi yang berjalan baik adalah Prometheus + Grafana untuk metrik infrastruktur, Uptime Kuma untuk pemantauan ketersediaan eksternal, dan Telegram untuk alert. ## Pemisahan Monitoring Inside vs Outside Monitoring efektif memerlukan dua perspektif. Monitoring inside (Prometheus + Grafana) memberi tahu Anda apa yang terjadi di server Anda: lonjakan CPU, tekanan memori, saturasi disk, latensi query, dan metrik tingkat aplikasi. Monitoring outside (Uptime Kuma) memberi tahu Anda apa yang dialami pengguna: apakah situs memuat, apakah API merespons, apakah sertifikat TLS valid. ### Prometheus + Grafana untuk Metrik Infrastruktur Jalankan Prometheus, Node Exporter, dan Grafana sebagai container Docker di VPS ringan khusus. Prometheus mengikis Node Exporter setiap 15 detik untuk 1000+ metrik host. Impor dashboard Grafana ID 1860 (Node Exporter Full) segera setelah menghubungkan Prometheus — ini memberi Anda 30+ panel yang mencakup CPU, memori, disk, dan jaringan. ### Uptime Kuma untuk Pemeriksaan Eksternal Uptime Kuma adalah alat monitoring self-hosted dengan UI yang bersih dan notifikasi Telegram/Slack/Discord bawaan. Deploy melalui Docker dan siapkan monitor untuk setiap endpoint publik: pemeriksaan HTTP(S) untuk aplikasi web dan API, pemeriksaan DNS untuk domain Anda, pemeriksaan kedaluwarsa sertifikat untuk sertifikat TLS (alert pada 14 hari tersisa). > Saat menjalankan DevOps sendirian, siapkan bot dan channel Telegram khusus untuk alert produksi — terpisah dari obrolan kerja utama. Alert produksi di obrolan utama diabaikan; channel alert khusus dengan suara notifikasi yang berbeda melatih otak Anda untuk merespons segera. ## Kelelahan Alert: Musuh Sebenarnya Kelelahan alert membunuh monitoring. Jika alert Anda terus berbunyi untuk kondisi yang tidak mendesak, Anda mulai mengabaikannya — termasuk yang penting. Rancang alert Anda dengan tiga prinsip: dapat ditindaklanjuti (setiap alert harus memiliki tindakan respons yang jelas), pemisahan urgensi (alert P1 membangunkan Anda pukul 3 pagi, alert P3 diperiksa di pagi hari), dan penindasan (hindari alert duplikat untuk penyebab root yang sama). ### Metrik Tingkat Aplikasi dengan Prometheus Client Node Exporter mencakup metrik host. Untuk observabilitas tingkat aplikasi, tambahkan paket npm prom-client ke aplikasi NestJS Anda dan ekspos endpoint /metrics. Lacak: durasi permintaan HTTP (histogram), jumlah permintaan berdasarkan rute dan kode status, durasi query database, rasio hit/miss cache. > **Jangan Memantau Hal yang Tidak Bisa Anda Tindak Lanjuti** > Di awal perjalanan monitoring, sangat menggoda untuk menambahkan puluhan panel Grafana dan banyak aturan alert agar terasa komprehensif. Hasilnya adalah kelumpuhan dashboard dan kelelahan alert. Aturan yang lebih baik: jika Anda tidak dapat mendeskripsikan tindakan tepat yang akan Anda ambil saat alert berbunyi, jangan membuat alert tersebut. ## Agregasi Log dengan Anggaran Terbatas Agregasi log penuh (stack ELK, Loki) menambahkan overhead sumber daya yang signifikan. Untuk operator solo, pendekatan pragmatis: gunakan journalctl -u '<'service> -f untuk tailing log real-time, kirim kesalahan aplikasi kritis ke instance Sentry gratis, dan gunakan Loki hanya jika Anda perlu mencari log historis di beberapa server. ## Stack Monitoring Produksi Saya Stack yang ramping terlihat seperti ini: Prometheus yang mengikis Node Exporter di setiap server, Grafana dengan dua dashboard, Uptime Kuma yang memeriksa endpoint HTTP dan sertifikat TLS, Sentry untuk pelacakan kesalahan aplikasi, dan Telegram untuk semua pengiriman alert. Satu Droplet monitoring kecil yang khusus menjaga biaya tetap rendah. ## Memulai dalam 30 Menit Jalur tercepat menuju monitoring yang berguna: deploy Uptime Kuma terlebih dahulu (10 menit), tambahkan monitor HTTP untuk semua endpoint produksi Anda, konfigurasikan notifikasi Telegram. Kemudian deploy Prometheus + Node Exporter melalui Docker Compose di server terbesar Anda (15 menit), hubungkan ke Grafana Cloud tingkat gratis, impor dashboard 1860, dan atur satu alert untuk penggunaan disk >85%. ## Sumber & Bacaan Lanjutan - Uptime Kuma — Situs Resmi dan Deployment Docker - DCHost — Monitoring VPS Tanpa Kesulitan dengan Prometheus Grafana dan Uptime Kuma - AWS Builder — Membangun Stack Monitoring Self-Hosted dengan Uptime Kuma Grafana dan Prometheus ## Source links - https://uptimekuma.org/ - https://www.dchost.com/blog/en/vps-monitoring-and-alerts-without-tears-getting-started-with-prometheus-grafana-and-uptime-kuma/ - https://builder.aws.com/content/37UYQpI9EINmQYcV0EYWgHYC0W0/building-a-self-hosted-monitoring-stack-with-uptime-kuma-grafana-and-prometheus ## FAQ ### Mengapa perlu menggunakan Prometheus + Grafana dan Uptime Kuma sekaligus, bukan hanya satu alat? Keduanya memantau dari perspektif yang berlawanan. Prometheus + Grafana memantau apa yang terjadi di dalam server — CPU, memori, disk, dan metrik tingkat aplikasi. Uptime Kuma memantau apa yang dialami pengguna dari luar — apakah situs memuat, API merespons, dan sertifikat TLS masih valid. Metrik inside bisa terlihat normal padahal situs sudah down karena pemblokiran firewall atau masalah DNS, sehingga keduanya dibutuhkan. ### Bagaimana cara mencegah kelelahan alert saat bekerja sebagai DevOps solo? Rancang alert berdasarkan tiga prinsip: dapat ditindaklanjuti (setiap alert harus memiliki tindakan respons yang jelas), pemisahan urgensi (alert P1 untuk situs down atau disk >95% memicu notifikasi Telegram langsung, tren informasional P3 cukup tampil di Grafana), dan penindasan duplikat (hindari alert berulang untuk penyebab yang sama). Penulis juga memegang aturan ketat: jika tidak bisa mendeskripsikan tindakan tepat yang akan diambil saat alert berbunyi, jangan buat alert tersebut. Mulai dengan 5-6 alert kritis dan pelajari selama sebulan sebelum menambah lebih banyak. ### Bagaimana setup Telegram yang direkomendasikan untuk alert produksi? Buat bot dan channel Telegram khusus untuk alert produksi, terpisah dari obrolan kerja utama. Alert produksi yang bercampur di obrolan utama cenderung diabaikan. Channel alert khusus dengan suara notifikasi yang berbeda melatih otak untuk merespons segera. Arahkan alert kritis (disk >90%, situs down) ke channel alert, dan alert informasional ke channel terpisah yang bisa dibisukan di malam hari. ### Berapa lama waktu yang dibutuhkan untuk memulai monitoring yang berguna dari nol? Jalur tercepat membutuhkan sekitar 30 menit. Deploy Uptime Kuma terlebih dahulu (10 menit), tambahkan monitor HTTP untuk semua endpoint produksi, dan konfigurasikan notifikasi Telegram. Kemudian deploy Prometheus + Node Exporter melalui Docker Compose di server terbesar (15 menit), hubungkan ke Grafana Cloud tingkat gratis, impor dashboard ID 1860 (Node Exporter Full), dan atur satu alert untuk penggunaan disk >85%. Ini menghasilkan monitoring ketersediaan eksternal dan metrik host dasar tanpa biaya tambahan jika menggunakan Grafana Cloud gratis. ### Bagaimana cara menambahkan metrik tingkat aplikasi di luar metrik host dasar? Node Exporter hanya mencakup metrik tingkat host seperti CPU, memori, dan disk. Untuk observabilitas aplikasi, tambahkan paket npm prom-client ke aplikasi NestJS dan ekspos endpoint /metrics. Metrik penting yang perlu dilacak meliputi durasi permintaan HTTP (sebagai histogram), jumlah permintaan berdasarkan rute dan kode status, durasi query database, serta rasio hit/miss cache. Metrik aplikasi ini menangkap masalah yang luput dari metrik host, seperti kebocoran memori di heap NestJS, query database yang lambat, atau integrasi yang rusak. --- - HTML version: https://www.matthewswong.com/id/blog/monitoring-alerting-solo/ - English: https://www.matthewswong.com/en/blog/monitoring-alerting-solo/ - Site index for agents: https://www.matthewswong.com/llms.txt - Sitemap: https://www.matthewswong.com/sitemap.xml - API description (OpenAPI): https://www.matthewswong.com/openapi.json