Cara Memilih Alat Pemantau Situs Web yang Sesuai dengan Kebutuhan Anda

Anda dibangunkan oleh nada peringatan dan tidak yakin dengan waktu, tetapi di luar gelap dan saat Anda mulai sadar, Anda melihat notifikasi membanjiri.

Sesuatu telah membuat aplikasi Anda mogok, dan pengguna di Eropa cukup terganggu. Satu jam telah berlalu tanpa cadangan, simpan manajer layanan pelanggan Anda bertanya dengan patuh setiap 15 menit ketika Anda mengharapkan kembali normal. Anda berdua menonton saat anggota tim Anda yang lain bangun, menerima berita, dan mulai menunjuk.

Seluruh situasi ini dapat dihindari, menurut Anda, sebagai puncak jam keempat downtime. Jika saja ada sesuatu yang memperingatkan kita tentang azab yang akan datang.

Selamat datang di dunia pemantauan situs web , di mana waktu aktif aplikasi adalah arahan utama. Mungkin ini bukan bagaimana api jam 3 pagi Anda padam, tetapi jika Anda bertahan selama ini di DevOps, Anda sudah memilikinya – dan kami yakin itu tidak menyenangkan.

Jika tujuan Anda adalah untuk meminimalkan rasa sakit yang unik ini, maka kami di sini untuk membantu Anda mengurangi kesulitan panggilan dengan panduan skim yang mudah yang menjabarkan apa yang Anda butuhkan di penyedia pemantauan web .

Panduan lengkap untuk memilih alat pemantauan situs web

Mari kita mulai dengan dasar-dasar: pemantauan dan pelaporan. Sama seperti telescreens yang serba bisa pada tahun 1984, pemantauan di sini mengacu pada pengawasan "eksternal" atas operasi Anda. Server penyelidikan eksternal biasanya digunakan untuk memantau status aplikasi Anda.

Akuntabilitas dimulai dengan pengawasan, atau lebih tepatnya observabilitas. Apa yang dapat Anda pelajari berdasarkan apa yang dikatakan infrastruktur Anda?

Pelaporan mengukur akuntabilitas Anda, tetapi pelaporan yang baik bersifat subjektif. Beberapa mungkin menyukai data mentah yang dapat mereka kemas ke dalam format apa pun. Lainnya ingin laporan otomatis disampaikan, beberapa berat pada angka yang lain menginginkan pendekatan yang lebih visual. Pelaporan adalah sisi lain dari pemantauan dan mendapatkan kedua elemen ini dengan benar akan memastikan aplikasi Anda tetap dapat diakses, dan perjanjian tingkat layanan Anda terpenuhi.

Semakin baik Anda memahami infrastruktur Anda, semakin banyak nilai yang Anda dapatkan dari pemantauan. Penyedia sering mengurai jenis cek untuk menjaga biaya tetap rendah. Memahami kebutuhan pemantauan web infrastruktur Anda adalah sumber penghematan biaya yang baik.

Pemantauan dan pelaporan web untuk akuntabilitas

Pemantauan bukan hanya tentang menangkap gnome server Anda tertidur di tempat kerja, itu akan memberi tahu Anda lebih banyak daripada jika layanan naik atau turun. Melalui metrik kinerja, Anda dapat mengembangkan gambaran yang jelas tentang bagaimana infrastruktur Anda beroperasi. Terutama dengan pemeriksaan lebih lanjut, seperti pemantauan pengguna nyata (RUM) – tetapi lebih lanjut tentang itu nanti.

Periksa halaman status vendor Anda, dan saring data pemadaman enam hingga 12 bulan sebelumnya. Apakah vendor sering down? Waktu kerja dan manajemen insiden mereka secara keseluruhan harus memberikan petunjuk tentang keandalan mereka.

Jenis pemeriksaan pemantauan situs web mana yang paling berguna?

Sebelum memilih penyedia, Anda ingin menilai kebutuhan Anda. Jawab ini, apa yang akan membangunkanmu di tengah malam? Infrastruktur tersebut harus menjadi salah satu komponen pertama yang Anda konfigurasikan saat Anda menguji penyedia.

Buat strategi rencana serangan untuk pemantauan, dan buat daftar layanan yang harus Anda miliki. Penyedia layanan yang menawarkan paket paket dapat membantu atau merugikan di sini. Rencana yang baik memperhitungkan ukuran bisnis yang menggunakannya. Tidak ada salahnya untuk bertanya tentang opsi Anda untuk peningkatan dan add-on untuk menyesuaikan paket Anda.

Mungkin yang mendorong pencarian Anda untuk monitor web adalah kesalahan 404 atau SSL, tetapi beri ruang untuk bereksperimen dan berkembang. Saat Anda menguji, Anda pasti akan menemukan cara tambahan untuk memantau sistem Anda dan menggunakan alokasi cek Anda.

Pemeriksaan dasar dan fungsi pemantauan webnya

Pemeriksaan dasar biasanya hanya melakukan satu hal, seperti memantau satu URL atau memeriksa catatan DNS. Jenis pemeriksaan ini biasanya meminta seseorang untuk mencari pemantauan, biasanya setelah pemadaman listrik terjadi. Mendapatkan hak ini penting.

HTTP(S), SSL, DNS, dan Domain Expiry adalah beberapa pemeriksaan dasar yang baik untuk diingat karena ini adalah jenis pemadaman yang cenderung dirasakan oleh pengguna akhir. Pemeriksaan ini juga merupakan tulang punggung pemantauan sebagian besar pengguna perusahaan. Paket yang hanya menyertakan jenis pemeriksaan ini adalah paket “pemula” yang kuat untuk perusahaan rintisan dan usaha kecil.

Pemeriksaan HTTP(S), terkadang disebut “pemantauan web”, memantau waktu aktif. SSL, DNS, dan Domain Expiry cenderung memastikan infrastruktur penting tidak gagal karena alasan yang dapat dicegah. Jika penyedia Anda juga menyertakan metrik kinerja, itu adalah bonus yang jelas.

Pastikan penyedia Anda mendukung pengiriman peringatan di mana Anda membutuhkannya. Jika Anda memiliki masa berlaku SSL yang akan datang, akan sangat membantu untuk melewati birokrasi dan meletakkan pemberitahuan itu langsung di depan orang yang dapat membayar pembaruan dengan waktu yang cukup bagi mereka untuk memperbarui. Akan lebih baik lagi jika masalah tersebut dapat meningkat secara otomatis ke orang lain jika diperlukan lebih banyak keahlian.

Pemeriksaan lanjutan yang harus dipertimbangkan oleh setiap tim DevOps

Pemeriksaan lanjutan adalah pemeriksaan yang menggunakan data pengguna nyata, atau mendasarkan tindakannya pada tindakan pengguna. Jenis pemeriksaan yang rumit ini biasanya memerlukan beberapa upaya penyiapan. Imbalannya bisa sangat besar bagi organisasi yang menggunakannya.

Jenis pemeriksaan lanjutan mengawasi sasaran penting atau saluran navigasi, seperti masuk atau membeli item. Karena mereka bertindak seperti (atau terkadang mengambil data dari) pengguna nyata, pemeriksaan ini memberikan gambaran yang jelas tentang kinerja situs Anda dalam berbagai kondisi.

Mengapa menginvestasikan upaya untuk menyiapkan jenis pemeriksaan ini?

• Pengujian: visibilitas ke dalam kinerja fitur dan peningkatan baru sambil menghasilkan banyak data historis
• Tanggapan pertama: halaman checkout yang turun dapat berarti lebih dari satu pemeriksaan HTTP(S) gagal. Apa yang gagal dan kapan merupakan indikator yang baik untuk memulai diagnosis.

Mari kita bertemu James dan melihat bagaimana beberapa jenis cek terbukti berguna:

James meluncurkan produk baru untuk perusahaannya, Edgeco. Layanan baru ini akan memerlukan sertifikat keamanannya sendiri, di samping infrastruktur baru. James akan menerapkan layanan ini dengan pemantauan pengguna nyata sehingga dia belajar lebih banyak tentang pengalaman pengguna awal. Pemantauan SSL akan memastikan bahwa ketika James pindah ke proyek lain, sertifikatnya akan memiliki perlindungan untuk memastikan pembaruan tidak dilupakan.

Dengan pemeriksaan HTTP(S) yang memantau URL ini, James dan timnya memiliki kemampuan respons pertama saat waktu henti terdeteksi. Dengan menggunakan pemeriksaan transaksi, James dapat menguji aliran pengguna yang penting, seperti masuk ke layanan baru dan menggunakan komponen intinya.

Karena James menggunakan Real User Monitoring, layanannya telah mengumpulkan statistik penggunaan di setiap perubahan yang dia dan timnya lakukan selama masa pakai layanan. Dalam enam bulan, James akan memiliki cukup data untuk mengidentifikasi masalah kinerja yang dilokalkan ke wilayah tertentu dan mengarahkan timnya untuk meningkatkannya. Lapisan pemeriksaan membantu menjaga dan menyederhanakan pengelolaan infrastruktur yang kompleks.

Perangkat lunak pemantauan web yang bagus untuk dimiliki

Setelah Anda menetapkan jenis pemeriksaan yang Anda butuhkan, inilah saatnya untuk mulai membandingkan fitur-fitur yang bagus untuk membuat hidup Anda sedikit lebih mudah. Ada banyak perbedaan di sini, karena beberapa penyedia menyajikan halaman status atau integrasi sebagai penawaran "premium".

Pelaporan publik dan pribadi

Visibilitas penting. Siapa yang bisa melihatnya? Akankah para eksekutif memahaminya? Apakah publik memiliki akses? Selama pemadaman, DevOps kemungkinan mendapatkan tekanan secara internal dan melalui pengguna, jadi ada nilai untuk pelaporan yang terlihat.

Dukungan tidak bekerja secara gratis. Setiap tiket dukungan, bahkan dengan respons makro/cepat, membutuhkan waktu. Seseorang harus mengirimkan tiket, berhenti mengerjakan tugas lain, dan menanggapinya. Tingkatkan basis pengguna Anda hingga ratusan ribu, atau jutaan pengguna, dan dukungan dapat kehilangan seluruh hari produktivitas mengirimkan respons boilerplate yang sama untuk pertanyaan tentang apakah itu naik atau turun. Pelaporan yang terlihat menciptakan platform untuk menjawab pertanyaan dan mengurangi ketegangan pada respons dukungan.

Manfaat kedua adalah pengiriman pesan, karena berita yang salah dapat merusak reputasi Anda. Ketika Anda berada di depan bencana, dengan fokus pada transparansi, Anda menjadi sumber berita. Itu jauh lebih baik daripada berada di bawah belas kasihan industri yang didorong oleh kontroversi klik-tayang.

Kemudahan penggunaan dan nilai

Segala sesuatu mulai dari pemantauan dan pelaporan tampak hebat. Bagaimana dengan biaya setup ? Seperti tim dukungan Anda, teknisi Anda juga tidak bekerja secara gratis. Ada biaya penyiapan bahkan untuk menguji penyedia, jadi luangkan waktu untuk mengevaluasi semua kebutuhan Anda.

Kemudahan penggunaan mengacu pada apa pun mulai dari pengaturan akun hingga orientasi pengguna baru. Selama uji coba, Anda mungkin berfokus pada dasar-dasar dan mulai serta menjalankan secepatnya; memproyeksikan jangka panjang dan mempertimbangkan bagaimana pengguna akan berinteraksi dengan sistem.

Jika Anda berpindah penyedia, ada gunanya juga memiliki fungsi impor/ekspor tempat Anda dapat dengan mudah mentransfer ratusan cek.

Perangkat lunak sistem masuk tunggal (SSO) adalah contoh yang baik, menawarkan tingkat keamanan untuk perusahaan Anda dan memudahkan pengguna Anda untuk mengadopsi. Dokumentasi dukungan dan penggunaan umum dapat membantu Anda mengetahui aksesibilitas perangkat lunak. Anda dapat mempertimbangkan untuk mengundang pengguna lain untuk mencoba dan menyiapkan beberapa pemeriksaan, atau mengambil laporan, untuk menguji cara kerja sistem dari setiap perspektif.

Kustomisasi dan observabilitas

Mari kita pertimbangkan kasus penggunaan perusahaan rata-rata, di mana 100+ monitor tidak mungkin. Seperti apa pelaporan untuk jenis penyiapan ini? Besar, adalah satu kata. Berbelit-belit, mungkin yang lain. Lebih dari seratus hal akan sulit dilacak, jadi membangun observabilitas dari pemantauan web juga harus mempertimbangkan apa yang perlu Anda lihat untuk melakukan pekerjaan Anda. Bagaimana penyedia Anda menangani visibilitas memberi tahu Anda banyak tentang bisnis utama mereka.

Beberapa fitur berguna yang harus diperhatikan termasuk tag, di mana Anda dapat mewarnai kode atau menggunakan konvensi penamaan tim atau internal untuk mengatur pemeriksaan. Anda mungkin juga memiliki preferensi untuk bekerja di baris perintah, dalam hal ini API adalah fitur penting yang harus dicari. Pastikan untuk bertanya tentang batasan potensial yang perlu Anda ketahui saat mempertimbangkan pilihan Anda.

Dasbor memberikan visibilitas internal

Salah satu cara untuk mendekati masalah volume ini adalah dengan menyediakan ruang terpusat untuk manajemen cek. Jika Anda adalah tipe orang yang menyukai ikhtisar dan akses instan ke metrik utama, dasbor memberikan visibilitas yang Anda idamkan. Bonus di sini termasuk kemampuan berbagi. Dapatkah Anda atau tim Anda mendesain dasbor yang dapat Anda alihkan dengan cepat? Bisakah Anda mengontrol akses, atau menetapkan dasbor khusus pengguna tertentu?

Halaman status bermerek memberikan kepercayaan

Sebagian besar perusahaan menghargai transparansi, jadi halaman status adalah hal lain yang bagus untuk dimiliki. Kepercayaan tidak memanifestasikan dirinya. Menggabungkan halaman pemantauan dan status Anda menawarkan kesederhanaan. Jika Anda menggunakan vendor untuk masing-masing layanan ini, Anda perlu memiliki beberapa lapisan di antaranya yang membantu mendorong komunikasi di antara keduanya. Biasanya itu berarti seseorang harus dengan cermat membuat komponen atau menulis skrip. Meski begitu, Anda mungkin menarik data ke layanan yang dihosting sendiri yang dapat menjalankan risiko pemadaman yang sama seperti situs web Anda.

Pengalaman mulus antara halaman status Anda dan situs web Anda terlihat profesional. Namun, Anda perlu memasukkan manajemen insiden ke dalam rutinitas respons Anda, termasuk pembaruan rutin ke halaman status Anda selama periode pemadaman atau pemeliharaan.

Ada juga halaman status internal yang dirancang untuk menyimpan informasi berdasarkan kebutuhan untuk diketahui. Orang-orang di luar tim TI Anda dapat memiliki visibilitas saat waktu henti kritis. Saat pemadaman terjadi, halaman status internal menjadi hub yang memperbarui seluruh perusahaan.

Peringatan dan observabilitas

Perjanjian tingkat layanan cenderung memiliki ambang batas built-in sinyal itu ketika saatnya untuk bereaksi terhadap masalah. "Anggaran kesalahan" ini, memungkinkan tim Anda untuk tidur di malam hari. Lansiran, dan isinya, membuat perbedaan antara waktu lima dan 60 menit untuk merespons.

Peringatan yang baik bersifat instruktif. Lansiran mungkin berisi kode status, perbaikan yang disarankan, atau mengarahkan Anda ke sumber daya yang berguna seperti analisis lansiran. Peringatan terbaik menandakan masalah nyata sedang terjadi, dan memberi tahu Anda apa masalah itu. "Ini turun" versus "Ini melaporkan kesalahan 500" menunjukkan masalah yang sangat berbeda.

Peringatan dan detail

Terlalu samar dan devops cenderung kehilangan rambut untuk mencari masalah, tetapi jarang ada masalah dengan menjadi terlalu spesifik. Uji sistem peringatan secara menyeluruh. Jika Anda berencana untuk mengubah penyedia, jalankan latihan hari permainan menggunakan sistem peringatan. Informasi apa yang diberikan kepada tim Anda? Apakah peringatan membantu diagnosis Anda?

Jika Anda merencanakan beberapa pemadaman, baik sebagai latihan gameday atau tes yang diperpanjang, Anda dapat belajar banyak tentang cara kerja sistem pemantauan Anda. Apakah peringatan meningkat? Bagaimana dengan jendela pemeliharaan alih-alih pemadaman? Dapatkah sistem Anda membedakan?

Pengiriman peringatan

Mari kita kembali ke kasus penggunaan Edgecom kita. James memantau layanannya ketika dia mendapatkan ping di saluran Slack-nya. Gangguan HTTP(S) menandakan blognya sedang down. James dapat menandai orang yang bertanggung jawab atas blog tersebut, yang dengan cepat menyelidiki insiden tersebut. Ternyata jumlah pemuatan halaman yang tidak biasa adalah penyebabnya.

Tim bertanya-tanya apakah unggahan baru-baru ini menjadi viral. James merasakan serangan yang akan datang dan meningkatkan server untuk meningkatkan kapasitas. Benar saja, tindakannya adalah bagian dari rangkaian peristiwa yang membantu menangkis serangan DDoS yang ditujukan untuk menghancurkan situs utamanya.

Moral di sini adalah bahwa peringatan yang dikirimkan ke tim Anda dapat mengarah pada diagnosis dan kebetulan yang tidak terduga. Tidak ada peringatan berarti rasa sakit. Sakit yang mengerikan.

Pemantauan web benar-benar tentang analisis

Jangan mengabaikan nilai riwayat peringatan. Pengguna devops yang berpengalaman kemungkinan memiliki kepekaan supernatural terhadap bencana. Bagaimana mereka mengasah rasa itu? Dengan mengamati penyebab bencana dan mendokumentasikannya dengan cermat.

Eskalasi dan fleksibilitas

Katakanlah James bukan lagi DevOps Spider-Man, dan indra supranaturalnya tidak cukup baik. Serangan DDoS memang menurunkan beberapa layanan. Apa yang dapat dilakukan oleh penyedia pemantauan untuk membantu?

Eskalasi dan pemeliharaan adalah awal yang baik. Jika penyedia Anda mengizinkannya, jendela pemeliharaan dapat memberikan fleksibilitas untuk merespons pemadaman sambil memperingatkan pengguna. Apakah pemeliharaan termasuk atau tidak menjadi faktor dalam SLA Anda, akan sangat membantu bila Anda dapat menjadwalkan jendela pemeliharaan rutin dan mendorong pembaruan ke power user Anda.

Anda juga membuang lebih sedikit waktu untuk menyeret tanggung jawab dan meningkatkan secara internal jika Anda memetakan batas Anda sebelumnya. Berapa lama terlalu lama untuk pemadaman? Meningkat setelah tanda lima atau sepuluh menit adalah tempat yang baik untuk memulai, karena pemadaman yang lebih lama menandakan ada sesuatu yang benar-benar salah. Sistem peringatan yang mengotomatiskan eskalasi menghilangkan dugaan itu, memungkinkan tim Anda bekerja tanpa khawatir tentang kapan harus memberi tahu tingkat yang lebih tinggi.

Pemantauan web pengguna sintetis dan nyata untuk menangkap pengalaman pengguna

Berhenti mengandalkan laporan pengguna dari penguji beta berbayar (pelanggan Anda), dan tangkap pengalaman pengguna secara langsung. Pemantauan pengguna nyata biasanya memerlukan beberapa kode, seperti piksel pelacakan, tetapi hasilnya adalah data pengguna aktual dari sesi nyata. Jika Anda pernah bertanya-tanya apa yang dilihat pengguna Anda, pemantauan RUM adalah tambahan yang berguna untuk toolkit Anda.

Pemantauan sintetis

Pemantauan sintetis hadir dalam dua rasa, biasanya: API dan Transaksi. Pemeriksaan transaksi persis seperti apa suaranya. Mereka menguji corong sasaran dan memberikan kemampuan respons pertama untuk transaksi penting. Jadilah yang pertama tahu tentang masalah dengan keranjang belanja Anda, formulir pendaftaran, login, dan banyak lagi.

Pemeriksaan API berguna untuk memeriksa titik akhir yang mendorong sisi otomatisasi layanan Anda. Anda dapat GET, PUSH, PULL, PATCH, atau DELETE dengan sebagian besar penyedia, memungkinkan berbagai kemungkinan untuk pemantauan titik akhir. Poin bonus jika Anda dapat mengatur dan mengambil variabel.

Dukungan adalah faktor yang tidak terlihat dalam pemantauan web

Ini jam 2 pagi dan pemantauan web Anda mengeluarkan peringatan dari kiri dan kanan. Anda butuh bantuan! Anda perlu analisis dan penjelasan. Dukungan responsif dari penyedia Anda membuktikan nilainya ketika Anda menemukan kesalahan yang tidak dapat Anda lihat atau tidak dapat ditiru.

Ketika Anda membutuhkan bantuan, penting ada tim yang bersedia bekerja dengan Anda. Interaksi dukungan awal merupakan indikasi yang baik untuk kualitas layanan. Berapa lama waktu yang dibutuhkan agen untuk merespon tiket? Bagaimana kualitas tanggapan mereka dan dokumentasi apa yang dapat mereka berikan? Jenis dukungan apa yang tersedia, seperti dukungan telepon atau obrolan? Saat penyedia menyembunyikan tombol kontak, itu bisa menjadi tanda bahaya.

Dokumentasi

Dokumentasi harus menyeluruh, menyertakan contoh, dan memberikan petunjuk langkah demi langkah. Jika penyedia Anda menggunakan kode dalam dokumentasi mereka, itu pertanda baik bahwa mereka tahu apa yang mereka bicarakan dan menganggapnya serius. Poin bonus untuk penyedia yang mengembangkan perangkat luar, ekstensi browser, dan lainnya untuk membantu membuat sistem pemantauan Anda.

Berkomitmen ke penyedia pemantauan web

Pemantauan dan Pelaporan adalah komponen terpenting dalam menentukan penyedia Anda, tetapi daftar fitur yang bagus dapat menyederhanakan pekerjaan Anda dan meningkatkan pengawasan. Ingat, titik peringatan adalah respons pertama. Jika peringatan Anda hilang di eter dan tidak ada yang bisa mengklaimnya, apakah kebakaran itu benar-benar terjadi?

Perangkat lunak pemantauan web adalah bagian dari komitmen penting yang Anda buat untuk basis pelanggan Anda. Dikatakan Anda peduli untuk menyediakan layanan, dan pengguna Anda dapat mempercayai Anda untuk berada di sana untuk mereka. Mengambil komitmen itu dengan serius berarti merenungkan persyaratan mana yang paling relevan dengan organisasi Anda.