Hello!
Perusahaan kami bergerak dalam pengembangan perangkat lunak dan dukungan teknis selanjutnya. Dukungan teknis tidak hanya memerlukan perbaikan kesalahan, namun pemantauan kinerja aplikasi kami.
Misalnya, jika salah satu layanan mogok, maka Anda perlu mencatat masalah ini secara otomatis dan mulai menyelesaikannya, dan tidak menunggu pengguna yang tidak puas menghubungi dukungan teknis.
Kami memiliki perusahaan kecil, kami tidak memiliki sumber daya untuk mempelajari dan memelihara solusi rumit apa pun untuk memantau aplikasi, kami perlu menemukan solusi yang sederhana dan efektif.
Strategi pemantauan
Tidak mudah untuk memeriksa fungsionalitas suatu aplikasi, tugas ini tidak sepele, bahkan bisa dikatakan kreatif. Sangat sulit untuk memverifikasi sistem multi-link yang kompleks.
Bagaimana Anda bisa memakan gajah? Hanya sebagian! Kami menggunakan pendekatan ini untuk memantau aplikasi.
Inti dari strategi pemantauan kami:
Bagi aplikasi Anda menjadi beberapa komponen.
Buat pemeriksaan kontrol untuk setiap komponen.
Suatu komponen dianggap operasional jika semua pemeriksaan kontrolnya dilakukan tanpa kesalahan. Suatu aplikasi dianggap sehat jika semua komponennya berfungsi.
Dengan demikian, sistem apa pun dapat direpresentasikan sebagai pohon komponen. Komponen yang kompleks dipecah menjadi komponen yang lebih sederhana. Komponen sederhana memiliki pemeriksaan.
Tolok ukur tidak dimaksudkan untuk melakukan pengujian fungsional, melainkan bukan pengujian unit. Pemeriksaan kontrol harus memeriksa bagaimana perasaan komponen pada saat ini, apakah ada semua sumber daya yang diperlukan untuk berfungsinya, dan apakah ada masalah.
Tidak ada keajaiban; sebagian besar pemeriksaan perlu dikembangkan secara mandiri. Namun jangan takut, karena dalam kebanyakan kasus, satu pemeriksaan memerlukan 5-10 baris kode, tetapi Anda dapat menerapkan logika apa pun dan Anda akan memahami dengan jelas cara kerja pemeriksaan tersebut.
Sistem pemantauan
Katakanlah kita membagi aplikasi menjadi beberapa komponen, membuat dan menerapkan pemeriksaan untuk setiap komponen, tetapi apa yang harus dilakukan dengan hasil pemeriksaan tersebut? Bagaimana kita tahu jika suatu pemeriksaan gagal?
Kita memerlukan sistem pemantauan. Dia akan melakukan tugas-tugas berikut:
- Menerima hasil pengujian dan menggunakannya untuk menentukan status komponen.
Secara visual, ini terlihat seperti menyorot pohon komponen. Komponen fungsional berubah menjadi hijau, komponen bermasalah menjadi merah. - Lakukan pemeriksaan umum di luar kotak.
Sistem pemantauan dapat melakukan beberapa pemeriksaan sendiri. Mengapa menemukan kembali roda, mari kita gunakan. Misalnya, Anda dapat memeriksa apakah halaman situs web sedang dibuka atau server sedang melakukan ping. - Kirim pemberitahuan masalah kepada pihak yang berkepentingan.
- Visualisasi data pemantauan, penyediaan laporan, grafik dan statistik.
Deskripsi singkat tentang sistem ASMO
Yang terbaik adalah menjelaskannya dengan sebuah contoh. Mari kita lihat bagaimana pemantauan kinerja sistem ASMO diatur.
ASMO adalah sistem pendukung meteorologi otomatis. Sistem ini membantu spesialis layanan jalan raya memahami di mana dan kapan perlunya merawat jalan dengan bahan penghilang lapisan es. Sistem mengumpulkan data dari titik kontrol jalan. Titik kendali jalan adalah tempat di jalan tempat peralatan dipasang: stasiun cuaca, kamera video, dll. Untuk memprediksi situasi berbahaya, sistem menerima prakiraan cuaca dari sumber eksternal.
Jadi, komposisi sistemnya cukup khas: website, agen, peralatan. Mari kita mulai memantau.
Memecah sistem menjadi beberapa komponen
Komponen-komponen berikut dapat dibedakan dalam sistem ASMO:
1. Akun pribadi
Ini adalah aplikasi web. Minimal, Anda perlu memeriksa apakah aplikasi tersebut tersedia di Internet.
2. Basis Data
Basis data menyimpan data yang penting untuk pelaporan, dan Anda harus memastikan bahwa cadangan basis data berhasil dibuat.
3. Pelayan
Yang kami maksud dengan server adalah perangkat keras tempat aplikasi dijalankan. Penting untuk memeriksa status HDD, RAM, CPU.
4. Agen
Ini adalah layanan Windows yang melakukan banyak tugas berbeda sesuai jadwal. Minimal, Anda perlu memeriksa apakah layanan sedang berjalan.
5. Tugas agen
Mengetahui bahwa agen sedang bekerja saja tidaklah cukup. Seorang agen mungkin bekerja, tetapi tidak melaksanakan tugas yang diberikan. Mari kita bagi komponen agen menjadi beberapa tugas dan periksa apakah setiap tugas agen berhasil.
6. Titik kendali jalan (wadah semua MPC)
Ada banyak titik kendali jalan, jadi mari kita gabungkan semua MPC dalam satu komponen. Ini akan membuatnya lebih mudah untuk membaca data pemantauan. Saat melihat status komponen “sistem ASMO”, akan segera terlihat jelas di mana masalahnya: pada aplikasi, perangkat keras, atau pada sistem kendali maksimum.
7. Titik kendali jalan (satu batas maksimum)
Kami akan menganggap komponen ini dapat diservis jika semua perangkat di MPC ini dapat diservis.
8. Perangkat
Ini adalah kamera video atau stasiun cuaca yang dipasang pada batas konsentrasi maksimum. Penting untuk memeriksa apakah perangkat berfungsi dengan baik.
Pada sistem monitoring, pohon komponen akan terlihat seperti ini:
Pemantauan Aplikasi Web
Jadi, kita telah membagi sistem menjadi beberapa komponen, sekarang kita perlu melakukan pemeriksaan untuk setiap komponen.
Untuk memantau aplikasi web kami menggunakan pemeriksaan berikut:
1. Mengecek pembukaan halaman utama
Pemeriksaan ini dilakukan oleh sistem pemantauan. Untuk menjalankannya, kami menunjukkan alamat halaman, fragmen respons yang diharapkan, dan waktu eksekusi permintaan maksimum.
2. Mengecek batas waktu pembayaran domain
Pemeriksaan yang sangat penting. Jika domain tetap tidak berbayar, pengguna tidak dapat membuka situs. Penyelesaian masalah mungkin memerlukan waktu beberapa hari, karena... Perubahan DNS tidak langsung diterapkan.
3. Pengecekan sertifikat SSL
Saat ini, hampir semua situs web menggunakan protokol https untuk aksesnya. 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 akan berfungsi untuk sebagian besar aplikasi dan tidak memerlukan pengkodean. Ini sangat keren karena Anda dapat mulai memantau aplikasi web apa pun dalam 5 menit. Di bawah ini adalah pemeriksaan tambahan yang dapat dilakukan untuk aplikasi web, namun implementasinya lebih kompleks dan spesifik untuk aplikasi, jadi kami tidak akan membahasnya dalam artikel ini.
Apa lagi yang bisa Anda periksa?
Untuk memantau aplikasi web Anda secara 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 aplikasi web yang gagal (kode respons 404, 500, dll.)
- Waktu eksekusi kueri rata-rata
Memantau layanan windows (agen)
Dalam sistem ASMO, agen berperan sebagai penjadwal tugas, yang menjalankan tugas terjadwal di latar belakang.
Jika semua tugas agen berhasil diselesaikan, berarti agen bekerja dengan baik. Ternyata untuk memantau suatu agen, Anda perlu memantau tugasnya. Oleh karena itu, kami membagi komponen “Agen” menjadi beberapa tugas. Untuk setiap tugas, kami akan membuat komponen terpisah dalam sistem pemantauan, di mana komponen “Agen” akan menjadi “induk”.
Kami membagi komponen Agen menjadi komponen anak (tugas):
Jadi, kami telah memecah komponen kompleks menjadi beberapa komponen sederhana. Sekarang kita perlu melakukan pemeriksaan untuk setiap komponen sederhana. Harap dicatat bahwa komponen induk “Agen” tidak akan menjalani pemeriksaan apa pun, karena sistem pemantauan akan menghitung statusnya secara independen berdasarkan status komponen turunannya. Dengan kata lain, jika semua tugas berhasil diselesaikan, maka agen berhasil berjalan.
Ada lebih dari seratus tugas dalam sistem ASMO, apakah benar-benar perlu dilakukan pemeriksaan unik untuk setiap tugas? Tentu saja, kontrol akan lebih baik jika kita membuat dan menerapkan pemeriksaan khusus kita sendiri untuk setiap tugas agen, namun dalam banyak kasus, cukup menggunakan pemeriksaan universal.
Sistem ASMO hanya menggunakan pemeriksaan tugas universal dan ini cukup untuk memantau kinerja sistem.
Memeriksa kemajuan
Pemeriksaan yang paling sederhana dan efektif adalah pemeriksaan eksekusi. Pemeriksaan memverifikasi bahwa tugas diselesaikan tanpa kesalahan. Semua tugas memiliki pemeriksaan ini.
Algoritma verifikasi
Setelah setiap pelaksanaan tugas, Anda perlu mengirimkan hasil pemeriksaan SUCCESS ke sistem pemantauan jika pelaksanaan tugas berhasil, atau ERROR jika eksekusi selesai dengan kesalahan.
Pemeriksaan ini dapat mendeteksi masalah berikut:
- Tugas berjalan tetapi gagal karena kesalahan.
- Tugas berhenti berjalan, misalnya terhenti.
Mari kita lihat bagaimana masalah ini diselesaikan secara lebih rinci.
Masalah 1 – Tugas berjalan tetapi gagal karena kesalahan
Di bawah ini adalah kasus ketika tugas berjalan tetapi gagal antara pukul 14:00 dan 16:00.
Gambar tersebut menunjukkan bahwa ketika suatu tugas gagal, sinyal segera dikirim ke sistem pemantauan dan status pemeriksaan terkait di sistem pemantauan menjadi alarm.
Perlu diketahui bahwa dalam sistem pemantauan, status komponen bergantung pada status verifikasi. Status alarm pemeriksaan akan mengubah semua komponen tingkat yang lebih tinggi menjadi alarm, lihat gambar di bawah.
Masalah 2 - Tugas berhenti dijalankan (dibekukan)
Bagaimana sistem pemantauan memahami bahwa ada tugas yang terhenti?
Hasil pengecekan mempunyai masa berlaku misalnya 1 jam. Jika satu jam telah berlalu dan tidak ada hasil tes baru, sistem pemantauan akan mengatur status tes menjadi alarm.
Pada gambar di atas, lampu dimatikan pada pukul 14. Pada pukul 00, sistem monitoring akan mendeteksi bahwa hasil tes (mulai pukul 15) busuk, karena Waktu relevansi telah habis (satu jam), namun tidak ada hasil baru, dan pemeriksaan akan dialihkan ke status alarm.
Pukul 16 lampu dinyalakan kembali, program akan menyelesaikan tugas dan mengirimkan hasil eksekusi ke sistem monitoring, status pengujian kembali sukses.
Waktu relevansi pemeriksaan apa yang harus saya gunakan?
Waktu relevansi harus lebih besar dari periode pelaksanaan tugas. Saya sarankan mengatur waktu relevansi 2-3 kali lebih lama dari periode pelaksanaan tugas. Hal ini diperlukan untuk menghindari menerima pemberitahuan palsu ketika, misalnya, suatu tugas memakan waktu lebih lama dari biasanya atau seseorang memuat ulang program.
Memeriksa kemajuan
Sistem ASMO memiliki tugas “Muat Perkiraan”, yang mencoba mengunduh perkiraan baru dari sumber eksternal satu kali dalam satu jam. Belum diketahui waktu pasti munculnya ramalan baru di sistem eksternal, namun diketahui terjadi 2 kali dalam sehari. Ternyata kalau beberapa jam tidak ada ramalan baru, maka hal itu wajar, tapi kalau sehari lebih dari sehari tidak ada ramalan baru, berarti ada yang rusak di suatu tempat. Misalnya, format data dalam sistem perkiraan eksternal dapat berubah, itulah sebabnya ASMO tidak akan melihat rilis perkiraan baru.
Algoritma verifikasi
Tugas mengirimkan hasil pengecekan SUCCESS ke sistem monitoring ketika berhasil mendapatkan kemajuan (mengunduh ramalan cuaca baru). Jika tidak ada kemajuan atau terjadi kesalahan, maka tidak ada yang dikirim ke sistem pemantauan.
Pengecekan tersebut harus mempunyai interval relevansi sedemikian rupa sehingga selama ini dijamin akan menerima kemajuan baru.
Perlu diketahui bahwa kita akan mempelajari masalah ini dengan penundaan, karena sistem pemantauan menunggu hingga masa berlaku hasil pemindaian terakhir berakhir. Oleh karena itu, masa berlaku cek tidak perlu dibuat terlalu lama.
Pemantauan basis data
Untuk mengontrol database di sistem ASMO, kami melakukan pemeriksaan berikut:
- Memverifikasi pembuatan cadangan
- Memeriksa ruang disk kosong
Memverifikasi pembuatan cadangan
Di sebagian besar aplikasi, penting untuk memiliki cadangan basis data terkini sehingga jika server gagal, Anda dapat menyebarkan program ke server baru.
ASMO membuat salinan cadangan seminggu sekali dan mengirimkannya ke penyimpanan. Ketika prosedur ini berhasil diselesaikan, hasil pemeriksaan keberhasilan dikirim ke sistem pemantauan. Hasil verifikasi berlaku selama 9 hari. Itu. Untuk mengontrol pembuatan cadangan, digunakan mekanisme “pemeriksaan kemajuan”, yang telah kita bahas di atas.
Memeriksa ruang disk kosong
Jika tidak ada cukup ruang kosong pada disk, database tidak akan dapat berfungsi dengan baik, jadi penting untuk mengontrol jumlah ruang kosong.
Lebih mudah menggunakan metrik untuk memeriksa parameter numerik.
Metrik adalah variabel numerik, yang nilainya dikirimkan ke sistem pemantauan. Sistem pemantauan memeriksa nilai ambang batas dan menghitung status metrik.
Di bawah ini adalah gambar komponen “Database” pada sistem monitoring:
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 batas: level pertama adalah PERINGATAN, level kedua adalah ALARM.
2. Rata-rata nilai RAM dalam persen per jam
Kami menggunakan rata-rata per jam karena... kami tidak tertarik pada balapan langka.
3. Rata-rata persentase CPU per jam
Kami menggunakan rata-rata per jam karena... kami tidak tertarik pada balapan langka.
4. Periksa ping
Memeriksa apakah server sedang online. Sistem pemantauan dapat melakukan pemeriksaan ini; tidak perlu menulis kode.
Di bawah ini adalah gambar komponen “Server” pada sistem monitoring:
Pemantauan peralatan
Saya akan memberi tahu Anda bagaimana data tersebut diperoleh. Untuk setiap titik kendali jalan (MPC) terdapat tugas di task planner, misalnya “Survei MPC M2 km 200”. Tugas tersebut menerima data dari semua perangkat MPC setiap 30 menit.
Masalah saluran komunikasi
Sebagian besar peralatan berada di luar kota, digunakan jaringan GSM untuk transmisi data, yang tidak berfungsi secara stabil (ada jaringan atau tidak).
Karena seringnya kegagalan jaringan, pada awalnya pemeriksaan survei MPC dalam pemantauan terlihat seperti ini:
Menjadi jelas bahwa ini bukan pilihan yang berhasil, karena ada banyak pemberitahuan palsu tentang masalah. Kemudian diputuskan untuk menggunakan “pemeriksaan kemajuan” untuk setiap perangkat, mis. Hanya sinyal keberhasilan yang dikirim ke sistem pemantauan ketika perangkat disurvei tanpa kesalahan. Waktu relevansi disetel ke 5 jam.
Sekarang pemantauan mengirimkan pemberitahuan tentang masalah hanya ketika perangkat tidak dapat disurvei selama lebih dari 5 jam. Dengan tingkat kemungkinan yang tinggi, hal ini bukanlah alarm palsu, melainkan masalah nyata.
Di bawah ini adalah gambar peralatan pada sistem monitoring:
Penting!
Ketika jaringan GSM berhenti bekerja, semua perangkat MDC tidak disurvei. Untuk mengurangi jumlah email dari sistem pemantauan, teknisi kami berlangganan pemberitahuan tentang masalah komponen dengan jenis “MPC” dan bukan “Perangkat”. Hal ini memungkinkan Anda menerima satu notifikasi untuk setiap MPC, daripada menerima notifikasi terpisah untuk setiap perangkat.
Skema pemantauan ASMO akhir
Mari kita gabungkan semuanya dan lihat skema pemantauan seperti apa yang kita miliki.
Kesimpulan
Mari kita meringkas.
Apa manfaat pemantauan kinerja ASMO bagi kita?
1. Waktu eliminasi cacat berkurang
Kami sebelumnya telah mendengar tentang kerusakan dari pengguna, namun tidak semua pengguna melaporkan kerusakan. Kebetulan kami mengetahui tentang kerusakan komponen sistem seminggu setelah kerusakan itu muncul. Sekarang sistem pemantauan memberi tahu kami tentang masalah segera setelah masalah terdeteksi.
2. Stabilitas sistem meningkat
Karena cacat mulai dihilangkan lebih awal, sistem secara keseluruhan mulai bekerja lebih stabil.
3. Mengurangi jumlah panggilan ke dukungan teknis
Banyak masalah kini telah diperbaiki bahkan sebelum pengguna menyadarinya. Pengguna mulai jarang menghubungi dukungan teknis. Semua ini berdampak baik pada reputasi kita.
4. Meningkatkan loyalitas pelanggan dan pengguna
Pelanggan melihat perubahan positif dalam stabilitas sistem. Pengguna menghadapi lebih sedikit masalah dalam menggunakan sistem.
5. Mengurangi biaya dukungan teknis
Kami telah berhenti melakukan pemeriksaan manual apa pun. Sekarang semua pemeriksaan dilakukan secara otomatis. Sebelumnya kita mengetahui masalah dari pengguna, seringkali sulit memahami masalah apa yang dibicarakan pengguna. Kini, sebagian besar masalah dilaporkan oleh sistem pemantauan; notifikasi berisi data teknis, yang selalu memperjelas apa yang salah dan di mana.
Penting!
Anda tidak dapat menginstal sistem pemantauan di server yang sama tempat aplikasi Anda dijalankan. Jika server mati, aplikasi akan berhenti bekerja dan tidak ada yang memberi tahu tentang hal itu.
Sistem pemantauan harus dijalankan pada server terpisah di pusat data lain.
Jika Anda tidak ingin menggunakan dedicated server 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 dibandingkan menyewa server baru.
Rekomendasi:
- Uraikan aplikasi dan sistem dalam bentuk pohon komponen sedetail mungkin, sehingga akan mudah untuk memahami di mana dan apa yang rusak, dan pengendalian akan lebih lengkap.
- Untuk memeriksa fungsionalitas suatu komponen, gunakan tes. Lebih baik menggunakan banyak pemeriksaan sederhana daripada satu pemeriksaan yang rumit.
- Konfigurasikan ambang batas metrik di sisi sistem pemantauan, daripada menuliskannya dalam kode. Ini akan menyelamatkan Anda dari keharusan mengkompilasi ulang, mengkonfigurasi ulang, atau memulai ulang aplikasi.
- Untuk pemeriksaan khusus, gunakan margin waktu relevansi untuk menghindari menerima pemberitahuan palsu karena beberapa pemeriksaan memerlukan waktu penyelesaian sedikit lebih lama dari biasanya.
- Usahakan komponen pada sistem monitoring berubah menjadi merah hanya jika sudah pasti ada masalah. Jika warnanya berubah menjadi merah tanpa alasan, maka Anda akan berhenti memperhatikan notifikasi sistem pemantauan, maknanya akan hilang.
Jika Anda belum menggunakan sistem pemantauan, mulailah! Ini tidak sesulit kelihatannya. Nikmati sensasi melihat pohon bahan hijau yang Anda tanam sendiri.
Good luck.
Sumber: www.habr.com