Pemantauan Waktu Respons

Mengapa waktu respons pantas mendapatkan peringatannya sendiri

Peringatan uptime standar didasarkan pada sinyal biner: up atau down. Zona abu-abu di antara keduanya – up, tapi lambat – adalah tempat sebenarnya mayoritas kegagalan modern terjadi. Query database yang salah konfigurasi mulai memakan waktu 4 detik alih-alih 50ms. Kebocoran memori menyebabkan lonjakan garbage collection. API eksternal yang dipanggil backend mulai tidak stabil. Tidak satu pun dari masalah ini benar-benar merusak situs sepenuhnya, tetapi membuatnya tidak dapat digunakan – dan ini adalah sinyal awal kegagalan besar yang akan terjadi dalam satu atau dua jam ke depan.

Pemantauan waktu respons menangkap perlambatan sebelum berubah menjadi kegagalan. Anda mengonfigurasi ambang batas per monitor, dan jika waktu respons melebihi angka tersebut dalam beberapa pemeriksaan berturut-turut, Anda akan menerima peringatan. Sebelum peringatan dikirim, Anda masih punya waktu untuk menyelidiki masalah, menambah sumber daya, membatasi pemanggilan yang bermasalah, atau membatalkan deploy yang menyebabkannya.

Bagaimana ambang batas bekerja di DiagnoSEO Uptime Monitoring

Setiap monitor dapat dikonfigurasi dengan dua parameter: rt_threshold_ms dan rt_threshold_breaches. Yang pertama adalah waktu respons dalam milidetik yang Anda anggap masih dapat diterima. Yang kedua adalah berapa kali berturut-turut pemeriksaan harus melewati ambang ini agar peringatan dikirim. Secara default, ambang batas ini dinonaktifkan dan jumlah pelanggaran adalah tiga.

Desain dua parameter ini melindungi dari false positive. Jitter jaringan kadang terjadi. Pause garbage collection juga kadang terjadi. Lonjakan satu kali ke 1 detik saat biasanya hanya 200ms tidak perlu membangunkan Anda jam 3 pagi. Tapi tiga kali berturut-turut respons 1 detik – itu menunjukkan perlambatan yang nyata, bukan hanya sekilas. Pilih ambang berdasarkan perilaku normal yang Anda amati ditambah margin yang aman: jika p95 biasanya 400ms, atur ambang 1000ms. Jika p95 adalah 50ms (API internal), ambang 200ms.

Cocok dipadukan dengan apa

Peringatan waktu respons bekerja paling baik jika dikombinasikan dengan sinyal pemantauan lain. Gambarannya lengkap: ambang waktu respons mengindikasikan sistem mulai mengalami degradasi; kode HTTP memberitahu kapan benar-benar gagal; peringatan SSL/domain – tentang gangguan berbasis waktu; peringatan perubahan DNS – tentang perubahan konfigurasi. Keempat sinyal ini pada monitor yang sama mengubah pertanyaan biner "apakah berjalan" menjadi observabilitas penuh.

Dashboard juga membantu di sini. Setiap monitor menampilkan sparkline waktu respons terbaru – indikator visual cepat pola degradasi. Tampilan detail menunjukkan rata-rata 24 jam, 7 hari, dan 30 hari. Jika Anda melihat rata-rata naik perlahan minggu demi minggu – ini sinyal dini yang layak diselidiki, sebelum ambang peringatan terlewati.

Ambang batas praktis berdasarkan tipe situs

• Landing page marketing: 1500ms cukup masuk akal. Biasanya berat karena gambar dan skrip tracking; kecepatan mutlak kurang penting daripada stabilitas.
• Halaman produk/kategori ecommerce: 800–1200ms. Ecommerce yang lambat membunuh konversi; ambang lebih ketat bisa menangkap masalah lebih cepat.
• Dashboard aplikasi: 500–800ms. Pengguna mengharapkan responsif. Dashboard yang lambat membuat produk terasa bermasalah.
• API publik: 200–400ms untuk endpoint sederhana, lebih tinggi untuk proses berat. Segmentasikan sesuai berat proses.
• Cek kesehatan mikroservis internal: 50–100ms. Harus hampir seketika; perlambatan hampir selalu berarti masalah nyata.

Apa pun yang Anda pilih, jangan hanya sekali atur lalu lupakan. Evaluasi ulang tiap kuartal berdasarkan tren yang Anda lihat. Jika Anda terus menerima peringatan pelanggaran yang tidak mewakili masalah nyata – ambangnya terlalu ketat. Jika Anda mengalami kegagalan tanpa peringatan ambang sebelumnya – ambangnya terlalu longgar.

Routing peringatan

Peringatan pelanggaran ambang dikirim lewat kanal yang sama dengan peringatan down/recovery: Email, Telegram, Slack, Discord, SMS. Tunduk pada pengaturan tidak diganggu malam. Dicatat di tabel peringatan yang sama. Satu-satunya perbedaan pada jenis kejadian ("threshold" bukan "down") dan isi pesan – menampilkan waktu respons aktual dan ambang yang dikonfigurasi, sehingga Anda langsung tahu besarnya pelanggaran.

Konfigurasi

Edit monitor apa saja. Pada form, atur "Ambang waktu respons (ms)" ke angka pilihan Anda. Opsional sesuaikan "pelanggaran berturut-turut" jika nilai default 3 tidak sesuai toleransi Anda. Simpan. Mulai siklus berikutnya, tiap pemeriksaan membandingkan waktu respons dengan ambang tersebut, dan setelah jumlah pelanggaran berturut-turut yang dikonfigurasi, Anda akan menerima notifikasi.

Pertanyaan yang sering diajukan

• Metode pengukuran waktu respons apa yang dicatat?

  Time To First Byte (TTFB) — milidetik antara permintaan dikirim dan byte pertama respon diterima. Plus waktu total pengunduhan seluruh respons. TTFB adalah metrik tunggal paling berguna untuk kesehatan server.

• Berapa waktu respons yang dianggap "baik"?

  Tergantung lokasi dan konten. Untuk situs statis dengan CDN: di bawah 100ms sangat bagus, di bawah 300ms masih OK. Untuk aplikasi dinamis: di bawah 500ms masih OK, di bawah 1000ms bisa diterima, di atas 2000ms terasa lambat. Bandingkan dengan data historis Anda sendiri, bukan angka mutlak.

• Bisakah saya dapat peringatan jika waktu respons melewati ambang batas?

  Bisa. Setiap monitor memiliki ambang waktu respons opsional. Jika 3 pemeriksaan berturut-turut melewati ambang, Anda akan menerima peringatan "slow response". Syarat 3 pemeriksaan mencegah peringatan palsu akibat gangguan jaringan sesaat.

• Dari mana waktu respons diukur?

  Dari 13 titik pengecekan geografis kami (Eropa, Amerika Utara, Asia, Amerika Selatan, Oseania). Untuk monitor single-region, waktu diambil dari region terdekat. Untuk multi-region, setiap region diukur secara independen — berguna untuk mendeteksi masalah CDN regional.

• Apakah dashboard menampilkan tren waktu respons?

  Ya — rata-rata bergerak 30 hari, max/min harian, dan persentil (p50, p95). Berguna untuk perencanaan kapasitas: jika p95 naik dari 800ms ke 1500ms dalam sebulan, server Anda kelebihan beban meskipun uptime % tetap 100%.