Pengembangan industri sistem perangkat lunak memerlukan perhatian besar terhadap toleransi kesalahan produk akhir, serta respons cepat terhadap kegagalan dan kegagalan jika hal itu benar-benar terjadi. Pemantauan, tentu saja, membantu merespons kegagalan dan kegagalan dengan lebih efisien dan cepat, namun tidak cukup. Pertama, sangat sulit untuk melacak sejumlah besar server - dibutuhkan banyak orang. Kedua, Anda perlu memiliki pemahaman yang baik tentang cara kerja aplikasi untuk memprediksi statusnya. Oleh karena itu, kami memerlukan banyak orang yang memiliki pemahaman yang baik tentang sistem yang kami kembangkan, kinerja dan fitur-fiturnya. Mari kita asumsikan bahwa meskipun Anda menemukan cukup banyak orang yang bersedia melakukan hal ini, masih diperlukan banyak waktu untuk melatih mereka.
Apa yang harus dilakukan? Di sinilah kecerdasan buatan dapat membantu kita. Artikel ini akan membahasnya (pemeliharaan prediktif). Pendekatan ini secara aktif mendapatkan popularitas. Banyak artikel telah ditulis, termasuk tentang HabrΓ©. Perusahaan besar memanfaatkan sepenuhnya pendekatan ini untuk menjaga kinerja server mereka. Setelah mempelajari banyak artikel, kami memutuskan untuk mencoba pendekatan ini. Apa hasilnya?
pengenalan
Sistem perangkat lunak yang dikembangkan cepat atau lambat akan dioperasikan. Penting bagi pengguna agar sistem bekerja tanpa kegagalan. Jika terjadi keadaan darurat, hal tersebut harus diselesaikan dengan penundaan minimal.
Untuk menyederhanakan dukungan teknis suatu sistem perangkat lunak, terutama jika terdapat banyak server, biasanya digunakan program pemantauan yang mengambil metrik dari sistem perangkat lunak yang sedang berjalan, memungkinkan untuk mendiagnosis kondisinya dan membantu menentukan apa sebenarnya yang menyebabkan kegagalan. Proses ini disebut pemantauan sistem perangkat lunak.
Gambar 1. Antarmuka pemantauan Grafana
Metrik adalah berbagai indikator sistem perangkat lunak, lingkungan eksekusinya, atau komputer fisik tempat sistem berjalan dengan stempel waktu saat metrik diterima. Dalam analisis statis, metrik ini disebut deret waktu. Untuk memantau keadaan sistem perangkat lunak, metrik ditampilkan dalam bentuk grafik: waktu berada pada sumbu X, dan nilai berada pada sumbu Y (Gambar 1). Beberapa ribu metrik dapat diambil dari sistem perangkat lunak yang sedang berjalan (dari setiap node). Mereka membentuk ruang metrik (deret waktu multidimensi).
Karena sejumlah besar metrik dikumpulkan untuk sistem perangkat lunak yang kompleks, pemantauan manual menjadi tugas yang sulit. Untuk mengurangi jumlah data yang dianalisis oleh administrator, alat pemantauan berisi alat untuk secara otomatis mengidentifikasi kemungkinan masalah. Misalnya, Anda dapat mengonfigurasi pemicu untuk diaktifkan ketika ruang disk kosong berada di bawah ambang batas yang ditentukan. Anda juga dapat secara otomatis mendiagnosis server mati atau penurunan kecepatan layanan yang kritis. Dalam praktiknya, alat pemantauan berfungsi dengan baik dalam mendeteksi kegagalan yang telah terjadi atau mengidentifikasi gejala sederhana dari kegagalan di masa depan, namun secara umum, memprediksi kemungkinan kegagalan masih merupakan hal yang sulit untuk dipecahkan. Prediksi melalui analisis metrik secara manual memerlukan keterlibatan spesialis yang berkualifikasi. Ini adalah produktivitas yang rendah. Sebagian besar potensi kegagalan mungkin luput dari perhatian.
Baru-baru ini, apa yang disebut pemeliharaan prediktif sistem perangkat lunak menjadi semakin populer di kalangan perusahaan pengembangan perangkat lunak TI besar. Inti dari pendekatan ini adalah menemukan permasalahan yang mengarah pada degradasi sistem pada tahap awal, sebelum gagal, dengan menggunakan kecerdasan buatan. Pendekatan ini tidak sepenuhnya mengecualikan pemantauan manual terhadap sistem. Ini adalah tambahan untuk proses pemantauan secara keseluruhan.
Alat utama untuk menerapkan pemeliharaan prediktif adalah tugas mencari anomali dalam deret waktu ketika anomali terjadi dalam data ada kemungkinan besar bahwa setelah beberapa waktu akan ada kegagalan atau kegagalan. Anomali adalah penyimpangan tertentu dalam kinerja sistem perangkat lunak, seperti identifikasi penurunan kecepatan eksekusi satu jenis permintaan atau penurunan jumlah rata-rata permintaan yang dilayani pada tingkat sesi klien yang konstan.
Tugas mencari anomali pada sistem perangkat lunak memiliki kekhasan tersendiri. Secara teori, untuk setiap sistem perangkat lunak perlu dikembangkan atau disempurnakan metode yang ada, karena pencarian anomali sangat bergantung pada data yang dilakukan, dan data sistem perangkat lunak sangat bervariasi tergantung pada alat untuk mengimplementasikan sistem. , hingga ke komputer apa yang menjalankannya.
Metode untuk mencari anomali ketika memprediksi kegagalan sistem perangkat lunak
Pertama-tama, perlu dikatakan bahwa gagasan memprediksi kegagalan terinspirasi oleh artikel tersebut . Untuk menguji efektivitas pendekatan dengan pencarian anomali otomatis, dipilih sistem perangkat lunak Konsolidasi Web, yang merupakan salah satu proyek perusahaan NPO Krista. Sebelumnya, pemantauan manual dilakukan berdasarkan metrik yang diterima. Karena sistem ini cukup kompleks, sejumlah besar metrik diambil untuk itu: indikator JVM (beban pengumpul sampah), indikator OS di mana kode dijalankan (memori virtual, % beban CPU OS), indikator jaringan (beban jaringan ), server itu sendiri (beban CPU, memori), metrik lalat liar, dan metrik aplikasi itu sendiri untuk semua subsistem penting.
Semua metrik diambil dari sistem menggunakan grafit. Awalnya, database bisikan digunakan sebagai solusi standar untuk grafana, tetapi seiring dengan berkembangnya basis klien, grafit tidak dapat lagi mengatasinya, karena telah menghabiskan kapasitas subsistem disk DC. Setelah itu, diputuskan untuk mencari solusi yang lebih efektif. Pilihan dibuat menguntungkan , yang memungkinkan untuk mengurangi beban pada subsistem disk sebanyak urutan besarnya dan mengurangi ruang disk yang ditempati sebanyak lima hingga enam kali lipat. Di bawah ini adalah diagram mekanisme pengumpulan metrik menggunakan grafit+clickhouse (Gambar 2).
Gambar 2. Skema pengumpulan metrik
Diagram diambil dari dokumentasi internal. Ini menunjukkan komunikasi antara grafana (UI pemantauan yang kami gunakan) dan grafit. Menghapus metrik dari aplikasi dilakukan oleh perangkat lunak terpisah - . Dia memasukkannya ke dalam grafit.
Sistem Konsolidasi Web memiliki sejumlah fitur yang menimbulkan masalah dalam memprediksi kegagalan:
- Trennya sering berubah. Berbagai versi tersedia untuk sistem perangkat lunak ini. Masing-masing membawa perubahan pada bagian perangkat lunak dari sistem. Oleh karena itu, dengan cara ini, pengembang secara langsung mempengaruhi metrik sistem tertentu dan dapat menyebabkan perubahan tren;
- fitur implementasi, serta tujuan klien menggunakan sistem ini, sering kali menyebabkan anomali tanpa degradasi sebelumnya;
- persentase anomali relatif terhadap keseluruhan kumpulan data kecil (<5%);
- Mungkin terdapat kesenjangan dalam penerimaan indikator dari sistem. Dalam beberapa periode waktu yang singkat, sistem pemantauan gagal memperoleh metrik. Misalnya saja servernya kelebihan beban. Ini penting untuk melatih jaringan saraf. Ada kebutuhan untuk mengisi kekosongan tersebut secara sintetis;
- Kasus dengan anomali seringkali hanya relevan untuk tanggal/bulan/waktu tertentu (musiman). Sistem ini memiliki peraturan yang jelas dalam penggunaannya oleh pengguna. Oleh karena itu, metrik tersebut hanya relevan untuk waktu tertentu. Sistem tidak dapat digunakan terus-menerus, tetapi hanya dalam beberapa bulan: selektif tergantung tahun. Situasi muncul ketika perilaku metrik yang sama dalam satu kasus dapat menyebabkan kegagalan sistem perangkat lunak, namun tidak pada kasus lain.
Untuk memulainya, metode untuk mendeteksi anomali dalam data pemantauan sistem perangkat lunak dianalisis. Dalam artikel tentang topik ini, ketika persentase anomali relatif kecil dibandingkan kumpulan data lainnya, penggunaan jaringan saraf paling sering diusulkan.
Logika dasar untuk mencari anomali menggunakan data jaringan saraf ditunjukkan pada Gambar 3:
Gambar 3. Pencarian anomali menggunakan jaringan syaraf tiruan
Berdasarkan hasil perkiraan atau pemulihan jendela aliran metrik saat ini, penyimpangan dari yang diterima dari sistem perangkat lunak yang sedang berjalan dihitung. Jika terdapat perbedaan besar antara metrik yang diperoleh dari sistem perangkat lunak dan jaringan saraf, kita dapat menyimpulkan bahwa segmen data saat ini adalah anomali. Serangkaian masalah berikut muncul dalam penggunaan jaringan saraf:
- agar berfungsi dengan benar dalam mode streaming, data untuk melatih model jaringan saraf harus hanya menyertakan data "normal";
- perlu adanya model terkini untuk pendeteksian yang benar. Perubahan tren dan musim dalam metrik dapat menyebabkan banyak kesalahan positif pada model. Untuk memperbaruinya, perlu ditentukan dengan jelas kapan model tersebut menjadi usang. Jika Anda memperbarui model lebih lambat atau lebih awal, kemungkinan besar, sejumlah besar kesalahan positif akan terjadi.
Kita juga tidak boleh lupa untuk mencari dan mencegah seringnya terjadinya kesalahan positif. Diasumsikan bahwa hal ini paling sering terjadi dalam situasi darurat. Namun, hal ini mungkin juga disebabkan oleh kesalahan jaringan saraf karena pelatihan yang tidak memadai. Hal ini diperlukan untuk meminimalkan jumlah positif palsu dari model. Jika tidak, prediksi yang salah akan membuang banyak waktu administrator untuk memeriksa sistem. Cepat atau lambat administrator akan berhenti merespons sistem pemantauan βparanoidβ.
Jaringan saraf berulang
Untuk mendeteksi anomali dalam deret waktu, Anda dapat menggunakan dengan memori LSTM. Satu-satunya masalah adalah bahwa ini hanya dapat digunakan untuk rangkaian waktu yang diperkirakan. Dalam kasus kami, tidak semua metrik dapat diprediksi. Upaya penerapan RNN LSTM pada deret waktu ditunjukkan pada Gambar 4.
Gambar 4. Contoh jaringan saraf berulang dengan sel memori LSTM
Terlihat pada Gambar 4, RNN LSTM mampu mengatasi pencarian anomali pada periode waktu tersebut. Apabila hasilnya mempunyai kesalahan prediksi (mean error) yang tinggi, maka sebenarnya telah terjadi anomali pada indikatornya. Menggunakan satu RNN LSTM jelas tidak akan cukup, karena ini dapat diterapkan pada sejumlah kecil metrik. Dapat digunakan sebagai metode tambahan untuk mencari anomali.
Autoencoder untuk prediksi kegagalan
β pada dasarnya adalah jaringan saraf tiruan. Lapisan masukan adalah encoder, lapisan keluaran adalah decoder. Kerugian dari semua jaringan saraf jenis ini adalah mereka tidak melokalisasi anomali dengan baik. Arsitektur autoencoder sinkron dipilih.
Gambar 5. Contoh operasi autoencoder
Autoencoder dilatih pada data normal dan kemudian menemukan sesuatu yang anomali dalam data yang dimasukkan ke model. Apa yang Anda perlukan untuk tugas ini. Yang tersisa hanyalah memilih autoencoder mana yang cocok untuk tugas ini. Bentuk autoencoder yang secara arsitektur paling sederhana adalah jaringan saraf maju dan tidak kembali, yang sangat mirip dengan (multilayer perceptron, MLP), dengan lapisan masukan, lapisan keluaran, dan satu atau lebih lapisan tersembunyi yang menghubungkannya.
Namun, perbedaan antara autoencoder dan MLP adalah bahwa dalam autoencoder, lapisan keluaran memiliki jumlah node yang sama dengan lapisan masukan, dan alih-alih dilatih untuk memprediksi nilai target Y yang diberikan oleh masukan X, autoencoder dilatih untuk merekonstruksi X-nya sendiri. Oleh karena itu, Autoencoder adalah model pembelajaran tanpa pengawasan.
Tugas autoencoder adalah menemukan indeks waktu r0...rn yang sesuai dengan elemen anomali dalam vektor masukan X. Efek ini dicapai dengan mencari kesalahan kuadrat.
Gambar 6. Autoencoder sinkron
Untuk autoencoder dipilih . Keunggulannya: kemampuan untuk menggunakan mode pemrosesan streaming dan jumlah parameter jaringan saraf yang relatif lebih kecil dibandingkan arsitektur lain.
Mekanisme untuk meminimalkan positif palsu
Karena kenyataan bahwa berbagai situasi abnormal muncul, serta kemungkinan situasi pelatihan jaringan saraf yang tidak memadai, untuk model deteksi anomali yang sedang dikembangkan, diputuskan bahwa perlu untuk mengembangkan mekanisme untuk meminimalkan kesalahan positif. Mekanisme ini didasarkan pada basis template yang diklasifikasikan oleh administrator.
(Algoritma DTW, dari bahasa Inggris Dynamic Time Warping) memungkinkan Anda menemukan korespondensi optimal antara urutan waktu. Pertama kali digunakan dalam pengenalan ucapan: digunakan untuk menentukan bagaimana dua sinyal ucapan mewakili frasa lisan asli yang sama. Selanjutnya, penerapannya ditemukan di daerah lain.
Prinsip utama meminimalkan kesalahan positif adalah mengumpulkan database standar dengan bantuan operator yang mengklasifikasikan kasus mencurigakan yang terdeteksi menggunakan jaringan saraf. Selanjutnya, standar yang diklasifikasikan dibandingkan dengan kasus yang terdeteksi oleh sistem, dan kesimpulan dibuat tentang apakah kasus tersebut salah atau menyebabkan kegagalan. Algoritma DTW digunakan secara tepat untuk membandingkan dua deret waktu. Alat minimalisasi utama masih berupa klasifikasi. Diharapkan setelah mengumpulkan sejumlah besar kasus referensi, sistem akan mulai meminta lebih sedikit kepada operator karena kesamaan sebagian besar kasus dan terjadinya kasus serupa.
Hasilnya, berdasarkan metode jaringan saraf yang dijelaskan di atas, sebuah program eksperimental dibangun untuk memprediksi kegagalan sistem βKonsolidasi Webβ. Tujuan dari program ini adalah, dengan menggunakan arsip data pemantauan dan informasi yang ada tentang kegagalan sebelumnya, untuk mengevaluasi kompetensi pendekatan ini untuk sistem perangkat lunak kami. Skema program disajikan di bawah ini pada Gambar 7.
Gambar 7. Skema prediksi kegagalan berdasarkan analisis ruang metrik
Dalam diagram, dua blok utama dapat dibedakan: pencarian periode waktu yang tidak wajar dalam aliran data pemantauan (metrik) dan mekanisme untuk meminimalkan kesalahan positif. Catatan: Untuk tujuan percobaan, data diperoleh melalui koneksi JDBC dari database tempat grafit akan menyimpannya.
Berikut antarmuka sistem monitoring yang diperoleh dari hasil pengembangan (Gambar 8).
Gambar 8. Antarmuka sistem pemantauan eksperimental
Antarmuka menampilkan persentase anomali berdasarkan metrik yang diterima. Dalam kasus kami, tanda terima disimulasikan. Kami telah memiliki semua data selama beberapa minggu dan memuatnya secara bertahap untuk memeriksa kasus anomali yang menyebabkan kegagalan. Bilah status bawah menampilkan persentase keseluruhan anomali data pada waktu tertentu, yang ditentukan menggunakan autoencoder. Selain itu, persentase terpisah ditampilkan untuk metrik prediksi, yang dihitung oleh RNN LSTM.
Contoh deteksi anomali berdasarkan kinerja CPU menggunakan jaringan saraf RNN LSTM (Gambar 9).
Gambar 9. Penemuan RNN LSTM
Kasus yang cukup sederhana, pada dasarnya merupakan outlier biasa, tetapi menyebabkan kegagalan sistem, berhasil dihitung menggunakan RNN LSTM. Indikator anomali dalam periode waktu ini adalah 85β95%; segala sesuatu di atas 80% (ambang batas ditentukan secara eksperimental) dianggap sebagai anomali.
Contoh deteksi anomali ketika sistem tidak dapat melakukan booting setelah pembaruan. Situasi ini terdeteksi oleh autoencoder (Gambar 10).
Gambar 10. Contoh deteksi autoencoder
Seperti yang Anda lihat dari gambar, PermGen terjebak pada satu level. Autoencoder menganggap ini aneh karena belum pernah melihat yang seperti ini sebelumnya. Di sini anomalinya tetap 100% hingga sistem kembali ke kondisi berfungsi. Anomali ditampilkan untuk semua metrik. Seperti disebutkan sebelumnya, autoencoder tidak dapat melokalisasi anomali. Operator dipanggil untuk menjalankan fungsi ini dalam situasi ini.
Kesimpulan
PC "Konsolidasi Web" telah dikembangkan selama beberapa tahun. Sistem berada dalam keadaan cukup stabil, dan jumlah insiden yang tercatat sedikit. Namun, anomali yang menyebabkan kegagalan dapat ditemukan 5 - 10 menit sebelum kegagalan terjadi. Dalam beberapa kasus, pemberitahuan kegagalan terlebih dahulu akan membantu menghemat waktu yang dijadwalkan yang dialokasikan untuk melaksanakan pekerjaan βperbaikanβ.
Berdasarkan percobaan yang dilakukan, masih terlalu dini untuk menarik kesimpulan akhir. Sejauh ini, hasilnya masih bertentangan. Di satu sisi, jelas bahwa algoritme yang didasarkan pada jaringan saraf mampu menemukan anomali yang βbergunaβ. Di sisi lain, masih terdapat persentase positif palsu yang besar, dan tidak semua anomali yang terdeteksi oleh spesialis jaringan saraf yang berkualifikasi dapat dideteksi. Kerugiannya termasuk fakta bahwa sekarang jaringan saraf memerlukan pelatihan dengan seorang guru untuk pengoperasian normal.
Untuk lebih mengembangkan sistem prediksi kegagalan dan membawanya ke kondisi yang memuaskan, beberapa cara dapat dipertimbangkan. Ini adalah analisis yang lebih rinci tentang kasus-kasus dengan anomali yang menyebabkan kegagalan, karena penambahan daftar metrik penting yang sangat mempengaruhi keadaan sistem, dan membuang metrik yang tidak perlu yang tidak mempengaruhinya. Selain itu, jika kita bergerak ke arah ini, kita dapat melakukan upaya untuk mengkhususkan algoritma khusus untuk kasus kita dengan anomali yang menyebabkan kegagalan. Ada cara lain. Ini merupakan peningkatan dalam arsitektur jaringan saraf dan dengan demikian meningkatkan akurasi deteksi dengan pengurangan waktu pelatihan.
Saya mengucapkan terima kasih kepada rekan-rekan saya yang membantu saya menulis dan menjaga relevansi artikel ini: dan Sergei Finogenov.
Sumber: www.habr.com