Kami makan gajah di beberapa bagian. Contoh Aplikasi Strategi Pemantauan Kesehatan

Halo semuanya!

Perusahaan kami bergerak dalam pengembangan perangkat lunak dan dukungan teknis selanjutnya. Sebagai bagian dari dukungan teknis, Anda tidak hanya perlu memperbaiki kesalahan, tetapi memantau kinerja aplikasi kami.

Misalnya, jika salah satu layanan “macet”, maka Anda perlu memperbaiki masalah ini secara otomatis dan mulai menyelesaikannya, dan tidak menunggu panggilan ke dukungan teknis untuk pengguna yang tidak puas.

Kami memiliki perusahaan kecil, tidak ada sumber daya untuk dipelajari dan mengandung solusi yang kompleks untuk memonitor aplikasi, itu perlu untuk menemukan solusi yang sederhana dan efektif.

Strategi pemantauan

Melakukan pemeriksaan kesehatan aplikasi tidaklah mudah, tugas ini tidak sepele, bahkan bisa dikatakan kreatif. Terutama sulit untuk menguji sistem multi-link yang kompleks.

Bagaimana cara memakan gajah? Hanya sebagian! Kami menggunakan pendekatan ini untuk memonitor aplikasi.

Inti dari strategi pemantauan kami:

Hancurkan aplikasi menjadi beberapa komponen.
Untuk setiap komponen, buatlah dengan pemeriksaan kontrol.

Suatu komponen dianggap sehat jika semua pemeriksaan kontrol dilakukan tanpa kesalahan. Suatu aplikasi dianggap sehat jika semua komponennya fungsional.

Dengan demikian, sistem apa pun dapat direpresentasikan sebagai pohon komponen. Komponen kompleks dipecah menjadi komponen yang lebih sederhana. Komponen sederhana harus diperiksa.



Pemeriksaan kontrol tidak boleh melakukan pengujian fungsional, ini bukan tes unit. Pemeriksaan kontrol harus memeriksa perasaan komponen pada saat ini, apakah ada semua sumber daya yang diperlukan untuk fungsinya, apakah ada masalah.

Tidak ada keajaiban, sebagian besar cek perlu dikembangkan secara mandiri. Tapi jangan takut, karena dalam banyak kasus satu cek membutuhkan 5-10 baris kode, tetapi kemudian Anda dapat menerapkan logika apa pun dan akan jelas bagi Anda bagaimana cara kerjanya.

Sistem pemantauan

Misalkan kita membagi aplikasi menjadi komponen, menemukan dan mengimplementasikan cek untuk setiap komponen, tetapi apa yang harus dilakukan dengan hasil pemeriksaan ini? Bagaimana kita tahu bahwa semacam cek gagal?

Kami akan membutuhkan sistem pemantauan. Dia akan melakukan tugas-tugas berikut:

• Terima hasil tes dan tentukan status komponen dari mereka.
  Secara visual, sepertinya menyoroti pohon komponen. Komponen yang bisa diservis berubah menjadi hijau, komponen yang bermasalah menjadi merah.
  
• Lakukan pemeriksaan umum di luar kotak.
  Sistem pemantauan dapat melakukan beberapa pemeriksaan dengan sendirinya. Mengapa menemukan kembali roda, kami akan menggunakannya. Misalnya, Anda dapat memeriksa apakah halaman situs terbuka atau server merespons.
  
• Kirim pemberitahuan masalah ke pihak yang berkepentingan.
• Visualisasi data pemantauan, memberikan laporan, grafik dan statistik.

Deskripsi singkat tentang sistem ASMO

Terbaik dijelaskan dengan contoh. Mari kita lihat bagaimana pemantauan operasi sistem ASMO diatur.

ASMO adalah sistem pendukung cuaca otomatis. Sistem ini membantu spesialis layanan jalan memahami di mana dan kapan perlu merawat jalan dengan bahan anti-icing. Sistem mengumpulkan data dari titik kontrol lalu lintas. Titik kontrol jalan adalah tempat di jalan tempat peralatan dipasang: stasiun cuaca, kamera video, dan banyak lagi. Untuk memprediksi situasi berbahaya, sistem menerima ramalan cuaca dari sumber eksternal.



Jadi, komposisi sistemnya cukup khas: situs web, agen, peralatan. Mari mulai memantau.

Kami memecah sistem menjadi beberapa komponen

Komponen-komponen berikut dapat dibedakan dalam sistem ASMO:

1. Akun pribadi
Ini adalah aplikasi web. Minimal, Anda perlu memverifikasi bahwa aplikasi tersebut tersedia di Internet.

2. Basis Data
Data penting untuk pelaporan disimpan dalam database, perlu untuk memverifikasi bahwa cadangan database berhasil dibuat.

3. Server
Yang kami maksud dengan server adalah perangkat keras tempat aplikasi berjalan. Perlu untuk memeriksa status HDD, RAM, CPU.

4. Agen
Ini adalah layanan windows yang melakukan banyak tugas terjadwal yang berbeda. Minimal, Anda perlu memverifikasi bahwa layanan sedang berjalan.

5. Tugas agen
Hanya mengetahui bahwa agen itu berfungsi tidak cukup. Agen dapat bekerja, tetapi tidak memenuhi tugas yang diberikan kepadanya. Kami membagi komponen agen menjadi tugas dan memeriksa apakah masing-masing tugas agen berhasil.

6. Poin kontrol jalan (wadah semua MPC)
Ada banyak titik kontrol jalan, jadi kami akan menggabungkan semua MPC dalam satu komponen. Ini akan membuatnya lebih mudah untuk membaca data pemantauan. Saat melihat status komponen "sistem ASMO" maka akan segera menjadi jelas di mana masalahnya adalah: dalam aplikasi, perangkat keras atau MPC.

7. Titik kontrol jalan (satu MPC)
Kami akan mempertimbangkan komponen ini dapat diservis jika semua perangkat pada MPC ini dapat diservis.

8. Perangkat
Ini adalah kamera video atau stasiun cuaca yang diinstal pada MPC. Anda harus memverifikasi bahwa perangkat berfungsi dengan baik.

Dalam sistem pemantauan, pohon komponen akan terlihat seperti ini:

Pemantauan aplikasi web

Jadi, kami membagi sistem menjadi komponen, sekarang kami perlu membuat cek untuk setiap komponen.

Untuk memantau aplikasi web, kami menggunakan pemeriksaan berikut:

1. Memeriksa pembukaan halaman utama
Pemeriksaan ini dilakukan oleh sistem pemantauan. Untuk pelaksanaannya, kami menunjukkan alamat halaman, fragmen respons yang diharapkan, dan waktu eksekusi kueri maksimum.

2. Verifikasi istilah pembayaran domain
Pemeriksaan sangat penting. Ketika domain dibiarkan tanpa pembayaran, pengguna tidak dapat membuka situs. Mungkin perlu beberapa hari untuk menyelesaikan masalah. Perubahan DNS tidak diterapkan segera.

3. Verifikasi sertifikat SSL
Sekarang hampir semua situs menggunakan protokol https untuk akses. Agar protokol berfungsi dengan benar, Anda memerlukan sertifikat SSL yang valid.

Di bawah ini adalah komponen "Akun Pribadi" dalam sistem pemantauan:



Semua pemeriksaan di atas cocok untuk sebagian besar aplikasi dan tidak memerlukan kode penulisan. Ini bagus karena Anda dapat mulai memonitor aplikasi web apa pun dalam 5 menit. Di bawah ini adalah pemeriksaan tambahan yang dapat dilakukan untuk aplikasi web, tetapi implementasinya lebih kompleks dan spesifik untuk aplikasi yang berbeda, jadi kami tidak akan menganalisisnya dalam artikel ini.

Apa lagi yang bisa saya periksa?

Untuk pemantauan aplikasi web yang lebih lengkap, Anda dapat melakukan pemeriksaan berikut:

• Jumlah kesalahan JavaScript per periode
• Jumlah kesalahan di sisi aplikasi web (back-end) untuk periode tersebut
• Jumlah respons yang gagal dari aplikasi web (kode respons 404, 500, dll.)
• Waktu eksekusi permintaan rata-rata

Memantau layanan windows (agen)

Dalam sistem ASMO, agen bertindak sebagai penjadwal tugas, yang di latar belakang melakukan tugas yang dijadwalkan.

Jika semua tugas agen berhasil, maka agen bekerja dengan baik. Ternyata untuk memantau agen, perlu untuk memantau tugasnya. Karenanya, kami memecah komponen Agen menjadi tugas. Kami akan membuat untuk setiap tugas komponen terpisah dalam sistem pemantauan, di mana komponen "Agen" akan menjadi "induk".

Kami memecah komponen Agen menjadi komponen anak (tugas):



Jadi, kami telah memecah komponen kompleks menjadi beberapa komponen sederhana. Sekarang Anda perlu membuat cek untuk setiap komponen sederhana. Harap dicatat bahwa komponen induk "Agen" tidak akan memiliki pemeriksaan tunggal, karena sistem pemantauan akan menghitung statusnya berdasarkan status komponen anaknya. Dengan kata lain, jika semua tugas diselesaikan dengan sukses, maka agen juga bekerja dengan sukses.

Ada lebih dari seratus tugas dalam sistem ASMO, apakah benar-benar perlu untuk membuat cek unik untuk setiap tugas? Tentu saja, kontrol akan lebih baik jika untuk setiap tugas agen kami datang dan menerapkan pemeriksaan khusus kami sendiri, tetapi dalam kebanyakan kasus cukup untuk menggunakan pemeriksaan universal.

Sistem ASMO hanya menggunakan pemeriksaan universal untuk tugas-tugas dan ini cukup untuk memantau kinerja sistem.

Periksa eksekusi
Pemeriksaan paling sederhana dan paling efektif adalah pemeriksaan kemajuan. Pemeriksaan memverifikasi bahwa tugas sedang dilakukan, dan tanpa kesalahan. Semua tugas memiliki pemeriksaan ini.

Algoritma validasi

Setelah setiap eksekusi tugas, perlu untuk mengirim ke sistem pemantauan hasil dari KESUKSESAN memeriksa apakah tugas itu berhasil, atau KESALAHAN jika eksekusi gagal.

Pemeriksaan ini memungkinkan Anda mendeteksi masalah berikut:

1. Tugas berjalan, tetapi gagal.
2. Tugas telah berhenti dijalankan, misalnya, telah membeku.

Mari kita pertimbangkan bagaimana masalah ini diselesaikan secara lebih rinci.

Masalah 1 - Tugas berjalan, tetapi gagal
Di bawah ini adalah kasus ketika tugas dilakukan, tetapi 14: 00-16: 00 gagal.



Gambar tersebut menunjukkan bahwa ketika tugas gagal, sinyal segera dikirim ke sistem pemantauan dan status pemeriksaan yang sesuai dalam sistem pemantauan menjadi alarm.

Harap dicatat bahwa dalam sistem pemantauan, status komponen tergantung pada status verifikasi. Status alarm cek akan menerjemahkan semua komponen tingkat yang lebih tinggi menjadi alarm, lihat gambar di bawah ini.



Masalah 2 - Tugas berhenti bekerja (digantung)
Bagaimana sistem pemantauan memahami bahwa tugas dibekukan?

Hasil cek memiliki waktu yang relevan, misalnya, 1 jam. Jika satu jam berlalu, dan tidak ada hasil verifikasi baru, maka sistem pemantauan akan mengatur status alarm dalam verifikasi.



Pada gambar di atas jam 14:00 lampu dimatikan. Pada pukul 15:00, sistem pemantauan akan mendeteksi bahwa hasil tes (dari 14:00) busuk, karena waktu relevansi telah kedaluwarsa (satu jam), tetapi tidak ada hasil baru, dan akan mentransfer cek ke status alarm.

Pada pukul 16:00 lampu dinyalakan lagi, program akan menyelesaikan tugas dan mengirimkan hasilnya ke sistem pemantauan, status verifikasi akan menjadi sukses lagi.

Berapa waktu validitas cek?

Waktu relevansi harus lebih lama dari periode pelaksanaan tugas. Saya merekomendasikan pengaturan waktu relevansi 2-3 kali lebih lama dari periode tugas. Ini diperlukan agar tidak menerima pemberitahuan palsu ketika, misalnya, tugasnya lebih lama dari biasanya atau seseorang memuat ulang program.

Pemeriksaan Kemajuan

Sistem ASMO memiliki tugas "Mengunduh prakiraan", yang satu jam sekali mencoba mengunduh prakiraan baru dari sumber eksternal. Waktu yang tepat ketika perkiraan baru muncul di sistem eksternal tidak diketahui, tetapi diketahui bahwa ini terjadi 2 kali sehari. Ternyata jika tidak ada prakiraan baru selama beberapa jam, maka ini normal, tetapi jika tidak ada prakiraan baru selama lebih dari satu hari, maka ada sesuatu yang rusak di suatu tempat. Misalnya, dalam sistem prakiraan eksternal, format data dapat berubah, karena itu ASMO tidak akan melihat rilis perkiraan baru.

Algoritma validasi

Tugas mengirim hasil pemeriksaan SUKSES ke sistem pemantauan ketika dimungkinkan untuk mendapatkan kemajuan (unduh prakiraan cuaca baru). Jika tidak ada kemajuan atau kesalahan telah terjadi, maka tidak ada yang dikirim ke sistem pemantauan.

Audit harus memiliki interval relevansi sehingga dijamin akan menerima kemajuan baru selama waktu ini.

Harap perhatikan bahwa kami mempelajari masalah dengan penundaan, karena sistem pemantauan menunggu hingga waktu relevansi hasil tes terakhir berakhir. Oleh karena itu, waktu relevansi pemeriksaan tidak perlu dibuat terlalu lama.

Pemantauan basis data

Untuk mengontrol database dalam sistem ASMO, kami melakukan pemeriksaan berikut:

1. Verifikasi cadangan
2. Memeriksa ruang disk kosong

Verifikasi cadangan
Dalam sebagian besar aplikasi, penting untuk memiliki cadangan basis data saat ini, sehingga jika terjadi kegagalan server, Anda dapat menggunakan program ke server baru.

ASMO sekali seminggu membuat salinan cadangan dan mengirimkannya ke repositori. Ketika prosedur ini berhasil diselesaikan, hasil pemeriksaan sukses dikirim ke sistem pemantauan. Hasil cek memiliki validitas waktu 9 hari. Yaitu Untuk mengontrol pembuatan cadangan, mekanisme "memeriksa kemajuan" digunakan, yang kami periksa di atas.

Memeriksa ruang disk kosong
Jika tidak ada cukup ruang kosong pada disk, maka basis data tidak akan dapat bekerja secara normal, oleh karena itu penting untuk mengontrol jumlah ruang kosong.

Lebih mudah menggunakan metrik untuk memeriksa parameter numerik.

Metrik adalah variabel numerik yang nilainya diteruskan ke sistem pemantauan. Sistem pemantauan memeriksa ambang batas dan menghitung status metrik.

Di bawah ini adalah gambaran bagaimana komponen "Database" terlihat dalam sistem pemantauan:

Pemantauan server

Untuk memantau server, kami menggunakan pemeriksaan dan metrik berikut:

1. Ruang disk kosong
Jika ruang disk habis, aplikasi tidak akan dapat bekerja. Kami menggunakan 2 nilai ambang: tingkat pertama adalah PERINGATAN, tingkat kedua adalah ALARM.

2. Nilai rata-rata RAM dalam persen per jam
Kami menggunakan nilai rata-rata per jam, seperti kami tidak tertarik pada ras langka.

3. Nilai rata-rata CPU dalam persen per jam
Kami menggunakan nilai rata-rata per jam, seperti kami tidak tertarik pada ras langka.

4. Ping periksa
Memverifikasi bahwa server sedang online. Sistem pemantauan dapat melakukan pemeriksaan ini, tidak perlu menulis kode.

Di bawah ini adalah gambaran bagaimana komponen "Server" terlihat dalam sistem pemantauan:

Pemantauan peralatan

Saya akan memberi tahu Anda bagaimana data diterima. Untuk setiap titik kontrol jalan (MPC) dalam penjadwal tugas ada tugas, misalnya, "Polling MPC M2 km 200". Tugas sekali dalam 30 menit menerima data dari semua perangkat MPC.

Masalah saluran komunikasi
Sebagian besar peralatan terletak di luar kota, jaringan GSM digunakan untuk transmisi data, yang tidak berfungsi secara stabil (artinya, ia tidak ada).

Karena kegagalan jaringan yang sering, pertama kali memeriksa survei MPC dalam pemantauan tampak seperti ini:



Menjadi jelas bahwa ini bukan opsi yang berfungsi, karena banyak peringatan palsu diterima tentang masalah tersebut. Kemudian diputuskan untuk setiap perangkat menggunakan "pemeriksaan kemajuan", yaitu hanya sinyal keberhasilan yang dikirim ke sistem pemantauan ketika perangkat disurvei tanpa kesalahan. Waktu relevansi ditetapkan 5 jam.



Sekarang pemantauan mengirimkan pemberitahuan masalah hanya ketika perangkat gagal menginterogasi lebih dari 5 jam. Dengan tingkat probabilitas yang tinggi ini bukan alarm yang salah, tetapi masalah nyata.

Di bawah ini adalah gambaran seperti apa peralatan itu dalam sistem pemantauan:



Penting!
Ketika jaringan GSM berhenti bekerja, maka semua perangkat MPC tidak diinterogasi. Untuk mengurangi jumlah huruf dari sistem pemantauan, teknisi kami berlangganan pemberitahuan masalah komponen dengan jenis "MPC", dan bukan "Perangkat". Ini memungkinkan Anda untuk menerima satu notifikasi untuk setiap MAC, daripada menerima notifikasi terpisah untuk setiap perangkat.

Skema pemantauan akhir ASMO

Mari kita kumpulkan semuanya dan lihat skema pemantauan seperti apa yang kita miliki.

Kesimpulan

Mari kita simpulkan.
Apa yang memantau kinerja ASMO memberi kita?

1. Mengurangi waktu pemecahan masalah
Kami dulu belajar tentang cacat dari pengguna, tetapi tidak semua pengguna melaporkan cacat. Kebetulan kami menemukan tentang kerusakan komponen sistem seminggu setelah kemunculannya. Sekarang sistem pemantauan memberi tahu kami tentang masalah segera setelah masalah terdeteksi.

2. Meningkatkan stabilitas sistem
Karena cacat mulai diperbaiki sebelumnya, sistem secara keseluruhan mulai bekerja jauh lebih stabil.

3. Mengurangi jumlah panggilan dukungan teknis
Banyak masalah sekarang diperbaiki sebelum pengguna mengetahuinya. Pengguna memiliki lebih sedikit kontak dukungan teknis. Semua ini berdampak baik pada reputasi kita.

4. Meningkatkan loyalitas pelanggan dan pengguna
Pelanggan memperhatikan perubahan positif dalam stabilitas sistem. Pengguna cenderung mengalami masalah dengan sistem.

5. Mengurangi biaya dukungan teknis
Kami berhenti melakukan pemeriksaan secara manual. Sekarang semua cek otomatis. Kami dulu belajar tentang masalah dari pengguna, seringkali sulit untuk memahami masalah apa yang dibicarakan pengguna. Sekarang sebagian besar masalah dilaporkan oleh sistem pemantauan, notifikasi berisi data teknis, yang selalu jelas apa dan di mana ia rusak.

Penting!
Anda tidak dapat menginstal sistem pemantauan di server yang sama tempat aplikasi Anda berjalan. Jika server macet, aplikasi akan berhenti bekerja, dan tidak akan ada yang mengirim pemberitahuan tentang hal itu.

Sistem pemantauan harus bekerja pada server terpisah di pusat data lain.

Jika Anda tidak ingin menggunakan server khusus di pusat data baru, Anda dapat menggunakan sistem pemantauan cloud. Perusahaan kami menggunakan sistem pemantauan cloud Zidium, tetapi Anda dapat menggunakan sistem pemantauan lainnya. Biaya sistem pemantauan cloud lebih rendah daripada menyewa server baru.

Rekomendasi:

1. Hancurkan aplikasi dan sistem dalam bentuk pohon komponen sedetail mungkin, sehingga akan lebih mudah untuk memahami di mana dan apa yang telah rusak, dan kontrol akan lebih lengkap.
2. Untuk memeriksa kesehatan komponen, gunakan pemeriksaan. Lebih baik menggunakan banyak cek sederhana daripada yang kompleks.
3. Nilai metrik ambang batas dikonfigurasikan di samping sistem pemantauan, dan jangan menulis dalam kode. Ini akan menyelamatkan Anda dari kompilasi ulang, konfigurasi ulang, atau memulai ulang aplikasi.
4. Untuk pemeriksaan khusus, gunakan waktu yang relevan dengan margin agar tidak menerima pemberitahuan palsu karena fakta bahwa beberapa jenis pemeriksaan butuh waktu sedikit lebih lama dari biasanya.
5. Cobalah untuk memastikan bahwa komponen-komponen dalam sistem pemantauan menjadi merah hanya ketika ada masalah. Jika mereka berubah menjadi merah sia-sia, maka Anda akan berhenti memperhatikan pemberitahuan dari sistem pemantauan, artinya akan hilang.

Jika Anda belum menggunakan sistem pemantauan, mulailah! Tidak sesulit kelihatannya. Dapatkan tinggi dengan melihat pohon komponen hijau yang telah Anda kembangkan sendiri.

Semoga beruntung