Tunas Akara
Kembali ke Blog

Pemantauan Sistem Kecil: Pemeriksaan yang Dibutuhkan

Mulai dari cek akses situs, tugas terjadwal, disk, sertifikat, dan hasil bisnis. Tentukan siapa yang menerima peringatan.

oleh RayhanDiperbarui 8 menit baca

Untuk Bisnis

monitoringalertinguptimereliability
Pemantauan Sistem Kecil: Pemeriksaan yang Dibutuhkan
Daftar isi

Mulai pemantauan sistem kecil dengan empat pemeriksaan: situs bisa diakses, tugas terjadwal selesai, ruang disk cukup, dan sertifikat belum kedaluwarsa. Tambahkan pemeriksaan hasil bisnis, misalnya tagihan benar-benar dibuat. Arahkan peringatan ke petugas yang jelas. Daftar ini memberi titik awal yang terjangkau; kebutuhan tambahan mengikuti risiko dan cara kerja bisnis Anda.

Bisnis kecil dapat ditawari platform pemantauan lengkap seperti Datadog atau New Relic. Untuk sistem pada tiga hingga delapan server, bandingkan kebutuhan dengan biaya serta tenaga pengelolaannya. Selain tagihan berdasarkan server dan volume data, tim perlu menyiapkan tampilan dan petugas penerima peringatan.

Datadog dan New Relic dirancang untuk menjawab "microservice mana dari 400 yang menyebabkan lonjakan P99 latency di checkout" — P99 latency: waktu respons yang menjadi batas bagi 99% permintaan; sekitar 1% lebih lambat. Toko yang menjalankan ERP, website, dan beberapa cron job di empat server punya masalah yang jauh lebih kecil dan membosankan. Apakah server hidup, apakah pencadangan jalan, apakah disk penuh, apakah sertifikat mau kedaluwarsa. Membeli platform yang dirancang untuk fleet seratus simpul demi menjawab empat pertanyaan ya/tidak sama seperti menyewa kontainer kapal untuk memindahkan satu koper.

Sinyal minimum yang benar-benar dibutuhkan

Mulai dengan pemeriksaan akses dari luar jaringan, tanda selesai pekerjaan terjadwal, kapasitas disk, dan masa berlaku sertifikat. Sinyal ini menangkap beberapa kegagalan umum yang sulit diketahui hanya dari laporan pengguna.

Pastikan peringatan dari pemeriksaan tersebut diterima orang yang jelas. Setelah itu, tambahkan pemeriksaan sesuai kegagalan yang masih dapat mengganggu bisnis.

Memeriksa ketersediaan dari luar jaringan

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 tanpa perlu kartu kredit. Periksa jenis monitor, notifikasi, serta pemantauan sertifikat dan domain yang tersedia pada paket saat mendaftar; sebagian fitur memerlukan paket berbayar.

Kalau Anda tidak mau bergantung pada pihak ketiga, atau sudah bayar VPS kecil, Uptime Kuma adalah alternatif self-hosted sumber terbuka berlisensi MIT. Cakupannya: target HTTP(S), TCP, keyword, ping, dan DNS, plus monitor kedaluwarsa sertifikat SSL/TLS khusus. Integrasi notifikasinya sudah mencakup Telegram, Discord, Slack, email, dan lebih dari sembilan puluh layanan lain.

Kedua pilihan membantu menjawab apakah layanan dapat diakses dari luar, sebelum keluhan pelanggan menjadi satu-satunya tanda gangguan.

Mendeteksi pekerjaan terjadwal yang berhenti

Kegagalan yang luput dari pemeriksaan ketersediaan eksternal adalah cron job yang berhenti berjalan. Web server tetap menjawab 200 OK. Skrip pembuat tagihan diam-diam berhenti jalan, dan tidak ada yang sadar sampai seseorang bertanya ke mana perginya angka minggu lalu.

Gunakan tanda selesai: pekerjaan hanya mengirim sinyal sukses setelah berhasil. Healthchecks.io mendokumentasikan pola ini dengan baik: job mengirim ping ke sebuah URL saat selesai, memakai curl atau wget jika tersedia di server. Kalau ping itu tidak datang sesuai jadwal, layanan itu mengirim peringatan.

Pola ini menangkap kegagalan yang tidak terlihat oleh pemeriksaan ketersediaan: 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 gunakan pola yang sama untuk polling job terjadwal di backend IoT — lihat panduan arsitektur backend IoT.

Ruang disk dan masa berlaku sertifikat

Ruang disk yang habis dan sertifikat TLS yang kedaluwarsa dapat menghentikan layanan. Keduanya dapat dipantau sebelum terjadi. Periksa juga siapa yang bertanggung jawab atas perpanjangan sertifikat otomatis.

UptimeRobot dan Uptime Kuma dapat membantu memantau masa berlaku sertifikat. Periksa dukungan sertifikat dan domain pada paket serta versi yang dipilih karena keduanya fitur berbeda. Atur peringatan 14 atau 30 hari sebelum kedaluwarsa, lalu uji peringatan dan proses perpanjangannya.

Pemeriksaan terjadwal sederhana dapat membaca pemakaian disk melalui df dan mengirim peringatan ketika melewati ambang. Uji penanganan kegagalannya serta pantau apakah pemeriksaan itu sendiri berjalan.

Satu kanal peringatan yang benar-benar dibaca orang

Peringatan hanya berguna jika diterima dan ditindaklanjuti. Beberapa dasbor dengan kotak masuk penuh notifikasi belum menunjukkan bahwa ada orang yang memeriksa gangguan.

Pilih satu kanal yang benar-benar dicek seseorang: WhatsApp, Telegram, atau nomor telepon. Arahkan semua peringatan 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 kanal yang sama.

Memuat diagram…

Mencegah kelelahan akibat terlalu banyak peringatan

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.

Dahulukan peringatan yang memiliki arti serta tindakan jelas. Terlalu banyak notifikasi rutin dapat membuat petugas membisukan kanal dan melewatkan gangguan penting.

Pemantauan server bukan pemantauan bisnis

Celah terakhir ini yang paling mahal ongkosnya. Server yang menjawab 200 OK memberi tahu Anda prosesnya jalan, bukan bahwa pekerjaannya selesai. Dokumentasi Checkly menggambarkan batas ini dengan jelas: pemantauan ketersediaan hanya memastikan "that a server is up and returning 200 OK status messages." Sementara pemantauan alur aplikasi memverifikasi "that the application is operational and responding as expected" dengan mengecek hasil akhir dari sebuah alur kerja nyata.

Untuk skala usaha kecil dan menengah, pemeriksaan hasil bisnis dapat dimulai dengan skrip sederhana. Misalnya, periksa apakah tagihan yang dijadwalkan hari ini sudah dibuat atau laporan sudah tersimpan di lokasi yang benar.

Sambungkan ke pola heartbeat yang sama dengan cron job. Pemeriksaan ini menjawab pertanyaan yang sebenarnya penting: bukan "apakah server-nya hidup," tetapi "apakah bisnisnya jalan hari ini." Seperti yang pernah saya tulis soal single point of failure di sistem bisnis: pemeriksaan yang layak dipasang adalah yang terkait dengan sesuatu nyata. Sesuatu yang benar-benar akan hilang kalau sistem itu diam.

Yang perlu benar-benar disiapkan

  1. Pemeriksaan ketersediaan eksternal — paket gratis UptimeRobot, atau Uptime Kuma self-hosted.
  2. Heartbeat ping di setiap cron job yang penting — Healthchecks.io atau yang setara.
  3. Alarm ruang disk dan kedaluwarsa sertifikat — sebagian besar sudah ada di alat di atas.
  4. Satu kanal peringatan, dipilih dengan sengaja, yang benar-benar dipantau seseorang.
  5. Satu pemeriksaan hasil bisnis, bukan hanya kesehatan server — apakah tagihan hari ini sudah dibuat.

Mulai dari pemeriksaan yang dapat dirawat tim dan saluran peringatan yang benar-benar dipantau. Tinjau daftar secara berkala agar setiap notifikasi tetap berkaitan dengan tindakan yang dibutuhkan.

Artikel Terkait

Perlu bantuan menerapkan solusi ini?

Konsultasi Perencanaan Sistem

Petakan kebutuhan, integrasi, dan risiko sebelum membangun atau memperluas sistem. Dapatkan rancangan serta prioritas yang bisa dibahas bersama tim.

Lihat layanan terkait

Ceritakan kendala operasional Anda agar kita dapat membahas langkah yang sesuai.

Bagikan artikel
Diskusi Awal Gratis