Cara Setup Monitoring Server dengan Alert Otomatis untuk SIMRS & ERP

Jam 02:15 WIB, layanan SIMRS di sebuah rumah sakit tipe C berhenti merespons. Tidak ada notifikasi apa pun. Tim IT baru tahu pukul 06:40 ketika petugas pendaftaran mengeluh tidak bisa membuat SEP, dan selama 4,5 jam pasien dilayani dengan pencatatan kertas yang kemudian harus diinput ulang. Kejadian seperti ini hampir selalu bukan soal teknologi yang rumit, melainkan tidak adanya sistem yang memberi tahu lebih dulu. Monitoring server bukan sekadar memasang grafik CPU di dashboard yang tidak pernah dibuka. Yang menentukan adalah kombinasi tiga hal: metrik yang tepat, ambang batas yang masuk akal, dan alert otomatis yang sampai ke orang yang bisa bertindak — cepat, dengan konteks cukup untuk mulai investigasi. Artikel ini membahas langkah konkretnya, dari memilih metrik sampai alert masuk ke Telegram dan WhatsApp tim ops.

Mulai dari Metrik yang Benar, Bukan Semua Metrik

Fondasi monitoring yang sehat tetap merujuk pada empat sinyal emas: latency, traffic, error, dan saturation. Pada sistem layanan kesehatan, sinyal ini perlu diterjemahkan ke alur bisnis nyata — pendaftaran pasien, farmasi, kasir, dan bridging BPJS. Alert yang bagus menjawab pertanyaan "apakah pengguna terdampak?", bukan "apakah angka ini naik?". Metrik yang tidak bisa ditindaklanjuti sebaiknya tidak dijadikan alert sama sekali karena hanya menambah kebisingan.

Untuk lapisan infrastruktur, ambang batas berikut sudah teruji dan tidak memicu alarm palsu berlebihan: CPU di atas 85% selama 5 menit berturut-turut, penggunaan RAM di atas 90% selama 10 menit, dan disk di atas 80% (warning) serta 90% (critical). Ambang disk sebaiknya lebih ketat di server database karena binlog MySQL dan file hasil pemindaian pasien cepat menumpuk. Load average di atas 2x jumlah vCPU selama 10 menit, serta swap terpakai di atas 20%, juga layak dijadikan peringatan dini.

Di lapisan aplikasi, ukur apa yang dirasakan pengguna. Contoh nyata: p95 latency endpoint pendaftaran di atas 1,5 detik selama 5 menit, error rate HTTP 5xx di atas 1% dari total request, connection pool database terpakai di atas 90% selama 3 menit, dan backlog job queue bridging lebih dari 50 job. Untuk integrasi BPJS/SatuSehat, pantau juga waktu respons di atas 3 detik dan lonjakan jumlah kegagalan autentikasi, karena masalah di sisi mitra sering muncul sebagai timeout yang tidak terlihat di metrik server.

Jangan lupakan hal-hal yang "membosankan" tetapi mematikan: masa berlaku sertifikat SSL kurang dari 14 hari, backup harian yang gagal, dan proses cron ETL yang tidak selesai dalam jendela waktunya. Ketiga hal ini jarang masuk dashboard, padahal justru paling sering memicu insiden besar di kemudian hari.

Menyusun Stack Monitoring: Prometheus 2.51, Node Exporter, dan Alertmanager

Stack minimal yang cukup untuk 20–50 target adalah Prometheus 2.51.1 sebagai pengumpul metrik, node_exporter 1.8.2 untuk metrik host, blackbox_exporter 0.25.0 untuk probe HTTP/TCP, mysqld_exporter 0.15.1 untuk database, Alertmanager 0.27.0 untuk routing notifikasi, dan Grafana 11.1 untuk visualisasi. Semua bisa dijalankan lewat Docker Compose pada satu VM 2 vCPU/4 GB. Setel scrape_interval 15 detik, evaluation_interval 15 detik, dan retensi 30 hari — untuk 30 target, kebutuhan disk biasanya berkisar 15–25 GB.

Pasang node_exporter di setiap server dengan systemd unit agar otomatis hidup setelah reboot, lalu tambahkan job blackbox untuk memantau endpoint kritis seperti halaman login SIMRS dan endpoint bridging. Untuk probe, gunakan modul http_2xx dengan timeout 5 detik agar masalah jaringan cepat terdeteksi sebelum pengguna melapor. Setelah itu, tulis aturan alert di berkas rules/simrs.yml seperti contoh berikut.

groups:
- name: simrs-prod
  rules:
  - alert: DiskHampirPenuh
    expr: (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100 < 15
    for: 10m
    labels: { severity: critical, team: ops }
    annotations:
      summary: "Disk {{ $labels.instance }} tersisa {{ printf \"%.1f\" $value }}%"
  - alert: ErrorRate5xxTinggi
    expr: sum(rate(http_requests_total{job="simrs",code=~"5.."}[5m])) / sum(rate(http_requests_total{job="simrs"}[5m])) > 0.01
    for: 5m
    labels: { severity: critical, team: ops }
    annotations:
      summary: "Error 5xx SIMRS di atas 1% selama 5 menit"

Selalu validasi sebelum reload: jalankan promtool check rules /etc/prometheus/rules/simrs.yml, lalu curl -X POST http://localhost:9090/-/reload jika Prometheus dijalankan dengan flag --web.enable-lifecycle. Kebiasaan ini mencegah Prometheus gagal start hanya karena satu salah indentasi YAML — kesalahan yang sering mematikan seluruh monitoring tanpa disadari.

Untuk lingkungan dengan tim kecil, tambahkan exporter ringan berbasis cron bila metrik bisnis tidak tersedia lewat HTTP. Cukup buat skrip yang menulis metrik ke file teks lalu diekspos melalui node_exporter --collector.textfile.directory. Pendekatan ini dipakai untuk mengirim jumlah SEP gagal, jumlah antrean menunggu, atau status backup harian ke Prometheus tanpa membangun aplikasi khusus.

Merutekan Alert ke Kanal yang Dibaca Tim dan Menghindari Alert Fatigue

Alertmanager menentukan apakah peringatan benar-benar sampai. Aturan routing yang praktis: severity critical dikirim ke Telegram grup ops plus WhatsApp gateway (misalnya WhatsApp Business API atau penyedia gateway lokal) dan eskalasi telepon setelah 10 menit tanpa acknowledgment; severity warning cukup ke Telegram. Gunakan group_wait: 30s, group_interval: 5m, dan repeat_interval: 4h untuk critical serta 24 jam untuk warning. Tanpa ini, satu server yang down bisa menghasilkan 40 pesan dalam semenit dan tim berhenti membaca semuanya.

Manfaatkan inhibition rule agar alert turunan tidak dikirim saat penyebab utamanya sudah dilaporkan. Contoh: jika NodeDown aktif, tahan semua alert CPU, RAM, dan disk dari instance yang sama. Lengkapi juga setiap annotation dengan tautan runbook, misalnya runbook_url: https://wiki.internal/runbook/disk-penuh, sehingga petugas jaga tidak perlu menebak langkah pertama pada pukul tiga pagi.

Terakhir, tetapkan jadwal on-call mingguan yang eksplisit dan lakukan review alert bulanan. Hitung berapa alert yang benar-benar butuh tindakan; jika di bawah 70%, ambang batas perlu diperbaiki. Setiap insiden sebaiknya ditutup dengan catatan singkat: apa yang gagal terdeteksi, dan metrik apa yang perlu ditambahkan. Inilah bagian yang membedakan monitoring yang hidup dari dashboard yang sekadar dipajang.

Best Practices

1. Alert harus actionable. Setiap alert wajib punya pemilik, dampak pengguna yang jelas, dan langkah awal di runbook.
2. Gunakan for minimal 5 menit. Mencegah notifikasi dari lonjakan sesaat saat backup atau deploy berjalan.
3. Pantau dari luar, bukan hanya dari dalam. Probe HTTP eksternal mendeteksi masalah DNS, firewall, dan sertifikat yang tidak terlihat oleh metrik host.
4. Uji jalur alert setiap kuartal. Matikan satu service di staging dan pastikan pesan benar-benar masuk ke Telegram/WhatsApp dalam 60 detik.
5. Simpan metrik minimal 30 hari. Dibutuhkan untuk analisis tren kapasitas saat pengambilan keputusan penambahan server atau upgrade database.

FAQ

Apakah Prometheus cocok untuk memantau SIMRS yang berjalan di on-premise?

Sangat cocok. Prometheus bersifat pull-based dan ringan, sehingga aman dijalankan di VM terpisah di jaringan rumah sakit. Untuk arsitektur multi-site seperti Yogyakarta dan Magelang, jalankan Prometheus lokal di tiap site lalu agregasi dengan Prometheus federation atau Thanos agar dashboard tetap terpusat.

Berapa biaya dan waktu implementasi untuk satu rumah sakit?

Untuk 20–30 server, implementasi dasar biasanya selesai 3–5 hari kerja: instalasi stack, penyusunan 15–25 aturan alert, integrasi Telegram/WhatsApp, dan pembuatan 3 dashboard utama. Biaya utamanya adalah VM dan waktu engineer, bukan lisensi, karena seluruh komponen bersifat open source.

Bagaimana menghindari alert palsu saat proses backup malam?

Gunakan for yang lebih panjang pada metrik I/O, atau tambahkan inhibition rule yang menahan alert disk dan CPU ketika job backup sedang berjalan. Alternatif lain adalah menaikkan ambang batas sementara melalui API Alertmanager, tetapi cara ini sebaiknya dipakai secara terbatas.

Apakah monitoring bisa sekaligus memantau aplikasi POS dan ERP?

Bisa. Expose metrik dari aplikasi POS atau ERP melalui endpoint /metrics menggunakan library Prometheus client (Go, PHP, atau Node.js), lalu tambahkan job scrape baru. Metrik bisnis seperti transaksi gagal dan antrean sinkronisasi stok justru lebih bernilai dibanding metrik server semata.

Monitoring yang baik mengubah insiden dari "ditemukan pengguna" menjadi "ditemukan sistem, ditangani sebelum pasien merasakan dampaknya". Mulailah dari lima alert paling kritis minggu ini, ukur akurasinya, lalu perluas secara bertahap. Jika Anda mengelola SIMRS, SIM Klinik, ERP, POS, atau website dan butuh pendampingan membangun monitoring serta alert otomatis yang sesuai alur operasional, tim konsultan IT kami melayani pengembangan aplikasi dan konsultasi IT untuk Yogyakarta, DIY, dan Magelang, Jawa Tengah — termasuk audit infrastruktur, penyusunan runbook, dan pelatihan tim internal agar sistem yang dibangun benar-benar terpakai.

Artikel ini bagian dari edukasi Nugroho Setiawan, konsultan IT Jogja. Solusi terkait: PilarPOS SIMRS Integrator Bridging BPJS & SatuSehat. Butuh konsultasi gratis?