Download Teknologi App
.png)
Sumber: ChatGPT
Pertanyaan yang Tidak Bisa Dijawab Pemantauan Lama
Pemantauan tradisional menjawab satu pertanyaan dengan baik, yaitu apakah sebuah server menyala atau mati. Selama sistem masih berupa satu aplikasi di satu server, jawaban itu cukup.
Pada sistem yang terdiri dari puluhan layanan, pertanyaan itu kehilangan maknanya. Semua layanan bisa berstatus menyala sementara pengguna tetap mengeluh lambat. Yang perlu dijawab bukan lagi apakah sistem hidup, melainkan di bagian mana waktu terbuang.
Perbedaan inilah yang memisahkan pemantauan dari kemampuan mengamati. Yang pertama memberi tahu bahwa ada masalah. Yang kedua memberi tahu di mana masalahnya.
Tiga Jenis Data yang Saling Melengkapi
Kemampuan mengamati dibangun dari tiga jenis data yang masing-masing menjawab pertanyaan berbeda.
Metrik menjawab pertanyaan berapa. Berapa banyak permintaan per detik, berapa persen yang gagal, berapa besar penggunaan memori. Metrik murah disimpan dalam jangka panjang sehingga cocok untuk melihat kecenderungan dan menetapkan peringatan.
Log menjawab pertanyaan apa yang terjadi. Catatan peristiwa memberi konteks rinci mengenai satu kejadian, tetapi mahal disimpan dalam volume besar sehingga perlu disaring dengan bijak.
Penelusuran menjawab pertanyaan di mana. Dengan memberi penanda unik pada setiap permintaan dan meneruskannya ke seluruh layanan yang dilewati, perjalanan satu permintaan bisa direkonstruksi lengkap dengan waktu yang dihabiskan di setiap tahap.
Ketiganya baru benar-benar berguna ketika saling terhubung, sehingga dari sebuah lonjakan pada metrik bisa langsung ditelusuri ke penelusuran permintaan yang bermasalah, lalu ke log yang menjelaskan penyebabnya.
Empat Indikator yang Paling Layak Dipantau
Kesalahan umum dalam membangun pemantauan adalah mengumpulkan terlalu banyak indikator sehingga tidak ada yang benar-benar diperhatikan.
Waktu respons. Yang perlu dipantau bukan rata-rata, melainkan persentil atas, karena rata-rata menyembunyikan pengalaman sebagian pengguna yang justru paling buruk.
Volume permintaan. Berguna untuk membedakan antara sistem yang melambat karena ada masalah dan sistem yang melambat karena memang sedang ramai.
Tingkat kesalahan. Perlu dibedakan antara kesalahan yang berasal dari permintaan tidak valid dan kesalahan yang berasal dari sistem itu sendiri, karena keduanya menuntut penanganan berbeda.
Tingkat kejenuhan. Seberapa dekat sebuah komponen dengan batas kapasitasnya. Indikator ini paling berguna untuk antisipasi karena naik lebih dulu sebelum yang lain memburuk.
Menghubungkan Indikator Teknis dengan Indikator Bisnis
Dashboard yang hanya menampilkan indikator teknis akan berhenti dibuka oleh siapa pun di luar tim teknis, dan itu mengurangi nilainya.
Dashboard yang berguna menyandingkan keduanya. Waktu respons layanan pembayaran ditampilkan berdampingan dengan jumlah transaksi yang berhasil. Kenaikan tingkat kesalahan ditampilkan berdampingan dengan jumlah pengguna yang terdampak.
Dengan penyandingan seperti ini, pembicaraan mengenai prioritas perbaikan menjadi jauh lebih mudah, karena dampaknya sudah terlihat dalam bahasa yang dipahami semua pihak.
Menjaga Pemantauan Tidak Membebani Sistem
Pengumpulan data pemantauan bukan aktivitas gratis. Bila tidak dirancang dengan hati-hati, beban tambahannya justru memperlambat sistem yang seharusnya diawasi.
Karena itu instrumentasi ditempatkan pada lapisan penghubung agar tidak menyebar ke seluruh kode aplikasi. Pengiriman data dilakukan melalui pengumpul terpisah yang bertindak sebagai penyangga, sehingga aplikasi tidak menunggu proses pengiriman selesai.
Untuk penelusuran, pengambilan sampel diterapkan agar tidak semua permintaan dicatat lengkap. Permintaan yang berujung kesalahan atau berjalan lambat tetap dicatat seluruhnya, karena justru itulah yang paling dibutuhkan saat penelusuran masalah.
Kapan Sistem Anda Membutuhkan Ini
Kebutuhan akan visibilitas biasanya paling terasa saat sedang menangani gangguan, yaitu saat sudah terlambat untuk membangunnya.
Langkah Memulai Bersama Sagara Sagara memulai dari menentukan pertanyaan yang perlu bisa dijawab, bukan dari pemilihan perangkat. Konsultasi discovery untuk memahami gangguan yang paling sering terjadi dan seberapa lama penanganannya. Audit arsitektur untuk menemukan titik buta pada pemantauan yang sudah ada. Implementasi bertahap yang dimulai dari alur paling kritis bagi bisnis. Kesimpulan Mengetahui bahwa sistem menyala tidak sama dengan mengetahui bahwa sistem sehat, dan perbedaannya paling terasa justru saat sedang terjadi gangguan. Sebagai vendor pengembangan dashboard operasional, Sagara membangun visibilitas yang menjawab di mana waktu terbuang, bukan sekadar melaporkan bahwa ada yang salah. Karena kecepatan pemulihan pada akhirnya ditentukan oleh seberapa cepat penyebabnya bisa ditemukan.
Tinggalkan Komentar