Monitoring untuk Sistem Kecil: Sinyal yang Cukup Tanpa Budget Enterprise

Monitoring untuk Sistem Kecil: Sinyal yang Cukup Tanpa Budget Enterprise
Ada tiga check gratis atau murah: uptime eksternal, heartbeat cron — job terjadwal yang lapor "saya masih hidup" tiap interval — dan alarm disk plus sertifikat. Ketiganya sudah menangkap hampir semua kegagalan yang biasa menjatuhkan sistem kecil. Tambahkan satu channel alert yang benar-benar dibaca orang, dan setup itu selesai dalam sehari. Tidak perlu dashboard enterprise.
Hampir setiap bisnis kecil yang saya tangani akhirnya ditelepon sales Datadog atau New Relic: dashboard full-stack, distributed tracing, anomaly detection di setiap host. Untuk perusahaan yang jalan di tiga sampai delapan server, semua itu tidak sebanding biayanya. Tagihannya naik mengikuti jumlah host dan volume data, dan tetap harus ada orang yang membangun dashboard-nya lalu jaga on-call untuk membacanya.
Datadog dan New Relic dirancang untuk menjawab "microservice mana dari 400 yang menyebabkan lonjakan P99 latency di checkout" — P99 latency: waktu respons terlambat yang masih dialami 1% request. Toko yang menjalankan ERP, website, dan beberapa cron job di empat server punya masalah yang jauh lebih kecil dan membosankan. Apakah server hidup, apakah backup jalan, apakah disk penuh, apakah sertifikat mau kedaluwarsa. Membeli platform yang dirancang untuk fleet seratus node demi menjawab empat pertanyaan ya/tidak sama seperti menyewa kontainer kapal untuk memindahkan satu koper.
Sinyal minimum yang benar-benar dibutuhkan
Tiga check ini menangkap hampir semua yang biasanya rusak di skala ini. Uptime check eksternal mengecek apakah situs bisa diakses dari luar jaringan sendiri. Heartbeat aplikasi dan cron mengecek apakah job terjadwal benar-benar jalan. Alarm disk space plus expiry sertifikat menangkap dua pembunuh diam-diam.
Kalau tiga ini sudah benar, ditambah satu channel alert yang benar-benar dibaca orang, hampir semua kegagalan yang bisa menjatuhkan sistem kecil sudah tertangani.
Uptime check eksternal, murah meriah
Sinyal termurah dan paling bisa diandalkan justru yang paling sederhana: ping dari luar jaringan sendiri, terjadwal. Ping ini memberi tahu situs down sebelum pelanggan yang menelepon duluan. Paket gratis UptimeRobot mencakup 50 monitor dengan interval lima menit, plus monitoring HTTP, port, keyword, DNS, dan SSL/domain expiration — tanpa perlu kartu kredit. Itu lebih banyak dari yang dibutuhkan kebanyakan setup skala SME.
Kalau Anda tidak mau bergantung pada pihak ketiga, atau sudah bayar VPS kecil, Uptime Kuma adalah alternatif self-hosted open-source berlisensi MIT. Cakupannya: target HTTP(S), TCP, keyword, ping, dan DNS, plus monitor expiry sertifikat SSL/TLS khusus. Integrasi notifikasinya sudah mencakup Telegram, Discord, Slack, email, dan lebih dari sembilan puluh layanan lain.
Kedua opsi ini menjawab pertanyaan yang sama, yang seharusnya tidak perlu dijawab oleh keluhan pelanggan: apakah pintu depannya masih terbuka.
Heartbeat: menangkap job yang diam-diam berhenti
Kegagalan yang luput dari uptime check eksternal adalah cron job yang berhenti berjalan. Web server tetap menjawab 200 OK. Skrip pembuat invoice diam-diam berhenti jalan, dan tidak ada yang sadar sampai seseorang bertanya ke mana perginya angka minggu lalu.
Solusinya dead man's switch. Healthchecks.io mendokumentasikan pola ini dengan baik: job mengirim ping ke sebuah URL saat selesai, memakai curl atau wget yang hampir pasti sudah terpasang di server. Kalau ping itu tidak datang sesuai jadwal, layanan itu mengirim alert.
Pola ini menangkap kegagalan yang tidak terlihat oleh uptime check: mesinnya mati total, cron daemon-nya sendiri tidak jalan, job keluar dengan exit code bukan nol. Atau job yang masih berjalan jauh melewati waktu seharusnya selesai. Saya pakai pola yang sama untuk polling job terjadwal di backend IoT — lihat panduan arsitektur backend IoT.
Disk dan expiry sertifikat: si pembunuh membosankan
Dua kegagalan ini menyebabkan lebih banyak downtime bisnis kecil dibanding bug eksotis mana pun. Disk yang diam-diam penuh selama berbulan-bulan, dan sertifikat TLS yang kedaluwarsa karena orang yang setup auto-renewal tiga tahun lalu sudah keluar dari perusahaan. Keduanya bisa diprediksi. Keduanya murah untuk dialarmkan lebih awal.
UptimeRobot dan Uptime Kuma sama-sama menyediakan monitoring expiry sertifikat dan domain sebagai fitur standar. Arahkan salah satunya ke domain Anda, set warning window ke 14 atau 30 hari, dan masalah sertifikat berhenti jadi masalah.
Untuk disk space cukup satu cron job yang mengecek df dan mengirim
ping ke channel alert Anda begitu melewati threshold. Lima baris kode,
bukan platform.
Satu channel alert yang benar-benar dibaca orang
Semua di atas tidak ada gunanya kalau alert-nya mendarat di tempat yang tidak pernah dicek siapa pun. Saya pernah melihat toko yang punya lima dashboard monitoring terpisah dengan inbox penuh email notifikasi yang tidak pernah dibuka. Itu visibilitas di atas kertas, bukan di praktik.
Pilih satu channel yang benar-benar dicek seseorang: WhatsApp, Telegram, atau nomor telepon. Arahkan semua alert ke sana. Integrasi notifikasi Uptime Kuma mencakup Telegram dan lebih dari sembilan puluh layanan lain langsung dari aplikasinya. Healthchecks.io dan UptimeRobot sama-sama mendukung webhook dan email yang bisa diarahkan ke channel yang sama.
Alert fatigue adalah kegagalan sesungguhnya
Begitu sistem alerting ada, insting yang muncul adalah menambah terus, satu aturan untuk setiap metrik yang bisa diukur. Lawan insting itu. SRE book milik Google sendiri tegas soal standar yang harus dipenuhi sebuah page: "every page should be actionable." Page itu juga harus "about a novel problem or an event that hasn't been seen before." Kalau sebuah masalah cukup ditangani skrip robotik, itu tidak layak jadi page.
SRE book yang sama memperingatkan apa yang terjadi begitu disiplin ini kendur. Kalau page datang terlalu sering, "employees second-guess, skim, or even ignore incoming alerts, sometimes even ignoring a 'real' page that's masked by the noise."
SRE Workbook menambahkan angka acuan yang layak dipakai di skala mana pun. Maksimal dua paging incident per shift on-call, supaya masih ada waktu untuk benar-benar menindaklanjuti. Filosofi alerting Rob Ewaschuk menyampaikan trade-off-nya dengan jelas: tim sebaiknya "err on the side of removing noisy alerts," karena over-monitoring lebih sulit diperbaiki dibanding under-monitoring.
Tiga atau empat jenis alert yang masing-masing berarti sesuatu yang spesifik terjadi, jauh lebih baik dari dua puluh dashboard yang akhirnya di-mute dalam sebulan.
Monitoring server bukan monitoring bisnis
Celah terakhir ini yang paling mahal ongkosnya. Server yang menjawab 200 OK memberi tahu Anda proses-nya jalan, bukan bahwa pekerjaannya selesai. Dokumentasi Checkly menggambarkan batas ini dengan jelas: uptime monitoring hanya memastikan "that a server is up and returning 200 OK status messages." Sementara synthetic monitoring memverifikasi "that the application is operational and responding as expected" dengan mengecek hasil akhir dari sebuah alur kerja nyata.
Anda tidak perlu platform synthetic-monitoring lengkap untuk menerapkan ide ini di skala SME. Skrip harian bisa mengecek apakah jumlah invoice hari ini di atas nol, atau apakah laporan hari ini sudah mendarat di folder yang seharusnya. Itu prinsip yang sama, cuma dalam lima baris kode.
Sambungkan ke pola heartbeat yang sama dengan cron job. Check ini menjawab pertanyaan yang sebenarnya penting: bukan "apakah server-nya hidup," tapi "apakah bisnisnya jalan hari ini." Seperti yang pernah saya tulis soal single point of failure di sistem bisnis: check yang layak dipasang adalah yang terkait dengan sesuatu nyata. Sesuatu yang benar-benar akan hilang kalau sistem itu diam.
Yang perlu benar-benar disiapkan
- Uptime check eksternal — paket gratis UptimeRobot, atau Uptime Kuma self-hosted.
- Heartbeat ping di setiap cron job yang penting — Healthchecks.io atau yang setara.
- Alarm disk space dan expiry sertifikat — sebagian besar sudah ada di tools di atas.
- Satu channel alert, dipilih dengan sengaja, yang benar-benar dipantau seseorang.
- Satu check untuk outcome bisnis, bukan cuma kesehatan server — apakah invoice hari ini sudah dibuat.
Semua ini tidak butuh kontrak platform atau rotasi on-call khusus. Cukup sehari untuk setup, dan disiplin untuk menjaga daftar alert tetap pendek supaya orang-orang tetap mempercayainya.
Artikel Terkait
Mau bangun hal serupa?
Jasa Pengembangan Backend IoT & Integrasi Multi-Protokol
Backend yang menyerap telemetri perangkat lintas MQTT, WebSocket, Modbus, dan BLE, lalu menyatukannya jadi dashboard real-time yang andal.
Lihat cara saya bisa bantu