Pembangunan industri sistem perisian memerlukan perhatian yang besar terhadap toleransi kesalahan produk akhir, serta tindak balas pantas terhadap kegagalan dan kegagalan jika ia berlaku. Pemantauan, sudah tentu, membantu untuk bertindak balas terhadap kegagalan dan kegagalan dengan lebih cekap dan cepat, tetapi tidak mencukupi. Pertama, adalah sangat sukar untuk menjejaki sejumlah besar pelayan - sejumlah besar orang diperlukan. Kedua, anda perlu mempunyai pemahaman yang baik tentang cara aplikasi berfungsi untuk meramalkan keadaannya. Oleh itu, kami memerlukan ramai orang yang mempunyai pemahaman yang baik tentang sistem yang kami bangunkan, prestasi dan ciri mereka. Mari kita anggap bahawa walaupun anda mendapati cukup orang yang bersedia untuk melakukan ini, ia masih memerlukan banyak masa untuk melatih mereka.
Apa nak buat? Di sinilah kecerdasan buatan membantu kami. Artikel itu akan bercakap tentang (penyelenggaraan ramalan). Pendekatan ini secara aktif mendapat populariti. Sebilangan besar artikel telah ditulis, termasuk mengenai HabrΓ©. Syarikat besar menggunakan sepenuhnya pendekatan ini untuk mengekalkan prestasi pelayan mereka. Selepas mengkaji sejumlah besar artikel, kami memutuskan untuk mencuba pendekatan ini. Apa yang datang daripadanya?
Pengenalan
Sistem perisian yang dibangunkan lambat laun akan mula beroperasi. Adalah penting bagi pengguna bahawa sistem berfungsi tanpa kegagalan. Sekiranya kecemasan berlaku, ia harus diselesaikan dengan kelewatan yang minimum.
Untuk memudahkan sokongan teknikal sistem perisian, terutamanya jika terdapat banyak pelayan, program pemantauan biasanya digunakan yang mengambil metrik daripada sistem perisian yang sedang berjalan, membolehkan untuk mendiagnosis keadaannya dan membantu menentukan apa sebenarnya yang menyebabkan kegagalan. Proses ini dipanggil pemantauan sistem perisian.
Rajah 1. Antara muka pemantauan Grafana
Metrik ialah pelbagai penunjuk sistem perisian, persekitaran pelaksanaannya atau komputer fizikal di mana sistem berjalan dengan cap masa saat metrik diterima. Dalam analisis statik, metrik ini dipanggil siri masa. Untuk memantau keadaan sistem perisian, metrik dipaparkan dalam bentuk graf: masa berada pada paksi X, dan nilai berada di sepanjang paksi Y (Rajah 1). Beberapa ribu metrik boleh diambil daripada sistem perisian yang sedang berjalan (dari setiap nod). Mereka membentuk ruang metrik (siri masa pelbagai dimensi).
Memandangkan sejumlah besar metrik dikumpulkan untuk sistem perisian yang kompleks, pemantauan manual menjadi tugas yang sukar. Untuk mengurangkan jumlah data yang dianalisis oleh pentadbir, alat pemantauan mengandungi alat untuk mengenal pasti masalah yang mungkin berlaku secara automatik. Sebagai contoh, anda boleh mengkonfigurasi pencetus untuk menyala apabila ruang cakera kosong berada di bawah ambang yang ditentukan. Anda juga boleh mendiagnosis penutupan pelayan secara automatik atau kelembapan kritikal dalam kelajuan perkhidmatan. Dalam amalan, alat pemantauan melakukan tugas yang baik untuk mengesan kegagalan yang telah berlaku atau mengenal pasti simptom mudah kegagalan masa hadapan, tetapi secara umum, meramalkan kemungkinan kegagalan masih menjadi masalah yang sukar untuk dipecahkan untuk mereka. Ramalan melalui analisis manual metrik memerlukan penglibatan pakar yang berkelayakan. Ia adalah produktiviti yang rendah. Kebanyakan potensi kegagalan mungkin tidak disedari.
Baru-baru ini, apa yang dipanggil penyelenggaraan ramalan sistem perisian telah menjadi semakin popular di kalangan syarikat pembangunan perisian IT yang besar. Intipati pendekatan ini adalah untuk mencari masalah yang membawa kepada kemerosotan sistem pada peringkat awal, sebelum ia gagal, menggunakan kecerdasan buatan. Pendekatan ini tidak sepenuhnya mengecualikan pemantauan manual sistem. Ia adalah tambahan kepada proses pemantauan secara keseluruhan.
Alat utama untuk melaksanakan penyelenggaraan ramalan ialah tugas mencari anomali dalam siri masa, sejak apabila anomali berlaku dalam data terdapat kebarangkalian yang tinggi bahawa selepas beberapa lama akan ada kegagalan atau kegagalan. Anomali ialah penyelewengan tertentu dalam prestasi sistem perisian, seperti mengenal pasti kemerosotan dalam kelajuan pelaksanaan satu jenis permintaan atau penurunan dalam purata bilangan permintaan yang diservis pada tahap tetap sesi klien.
Tugas mencari anomali untuk sistem perisian mempunyai spesifiknya sendiri. Secara teori, bagi setiap sistem perisian adalah perlu untuk membangunkan atau memperhalusi kaedah sedia ada, kerana pencarian anomali sangat bergantung pada data di mana ia dilakukan, dan data sistem perisian sangat berbeza bergantung pada alat untuk melaksanakan sistem. , hingga ke komputer yang sedang digunakan.
Kaedah untuk mencari anomali semasa meramalkan kegagalan sistem perisian
Pertama sekali, patut dikatakan bahawa idea meramalkan kegagalan telah diilhamkan oleh artikel itu . Untuk menguji keberkesanan pendekatan dengan carian automatik untuk anomali, sistem perisian Web-Consolidation telah dipilih, yang merupakan salah satu projek syarikat NPO Krista. Sebelum ini, pemantauan manual telah dijalankan untuknya berdasarkan metrik yang diterima. Oleh kerana sistem ini agak kompleks, sejumlah besar metrik diambil untuknya: Penunjuk JVM (beban pemungut sampah), penunjuk OS di mana kod itu dilaksanakan (memori maya, % beban CPU OS), penunjuk rangkaian (beban rangkaian ), pelayan itu sendiri (muatan CPU, memori), metrik lalat liar dan metrik aplikasi sendiri untuk semua subsistem kritikal.
Semua metrik diambil daripada sistem menggunakan grafit. Pada mulanya, pangkalan data bisikan digunakan sebagai penyelesaian standard untuk grafana, tetapi apabila pangkalan pelanggan berkembang, grafit tidak lagi dapat menampung, setelah kehabisan kapasiti subsistem cakera DC. Selepas ini, diputuskan untuk mencari penyelesaian yang lebih berkesan. Pilihan dibuat memihak , yang memungkinkan untuk mengurangkan beban pada subsistem cakera mengikut susunan magnitud dan mengurangkan ruang cakera yang diduduki sebanyak lima hingga enam kali. Di bawah ialah gambar rajah mekanisme untuk mengumpul metrik menggunakan grafit+clickhouse (Rajah 2).
Rajah 2. Skim untuk mengumpul metrik
Gambar rajah diambil daripada dokumentasi dalaman. Ia menunjukkan komunikasi antara grafana (UI pemantauan yang kami gunakan) dan grafit. Mengalih keluar metrik daripada aplikasi dilakukan oleh perisian berasingan - . Dia meletakkannya dalam grafit.
Sistem Web Consolidation mempunyai beberapa ciri yang menimbulkan masalah untuk meramalkan kegagalan:
- Trend sering berubah. Pelbagai versi tersedia untuk sistem perisian ini. Setiap daripada mereka membawa perubahan pada bahagian perisian sistem. Sehubungan itu, dengan cara ini, pembangun secara langsung mempengaruhi metrik sistem tertentu dan boleh menyebabkan perubahan arah aliran;
- ciri pelaksanaan, serta tujuan pelanggan menggunakan sistem ini, sering menyebabkan anomali tanpa kemerosotan sebelumnya;
- peratusan anomali berbanding keseluruhan set data adalah kecil (< 5%);
- Mungkin terdapat jurang dalam menerima penunjuk daripada sistem. Dalam beberapa tempoh masa yang singkat, sistem pemantauan gagal mendapatkan metrik. Contohnya, jika pelayan terlebih beban. Ini penting untuk melatih rangkaian saraf. Terdapat keperluan untuk mengisi jurang secara sintetik;
- Kes dengan anomali selalunya berkaitan hanya untuk tarikh/bulan/masa tertentu (bermusim). Sistem ini mempunyai peraturan yang jelas untuk kegunaannya oleh pengguna. Sehubungan itu, metrik hanya relevan untuk masa tertentu. Sistem ini tidak boleh digunakan secara berterusan, tetapi hanya dalam beberapa bulan: secara terpilih bergantung pada tahun. Situasi timbul apabila kelakuan metrik yang sama dalam satu kes boleh menyebabkan kegagalan sistem perisian, tetapi tidak dalam yang lain.
Sebagai permulaan, kaedah untuk mengesan anomali dalam data pemantauan sistem perisian telah dianalisis. Dalam artikel mengenai topik ini, apabila peratusan anomali adalah kecil berbanding set data yang lain, ia paling kerap dicadangkan untuk menggunakan rangkaian saraf.
Logik asas untuk mencari anomali menggunakan data rangkaian saraf ditunjukkan dalam Rajah 3:
Rajah 3. Mencari anomali menggunakan rangkaian saraf
Berdasarkan hasil ramalan atau pemulihan tetingkap aliran semasa metrik, sisihan daripada yang diterima daripada sistem perisian yang sedang berjalan dikira. Sekiranya terdapat perbezaan besar antara metrik yang diperoleh daripada sistem perisian dan rangkaian saraf, kita boleh membuat kesimpulan bahawa segmen data semasa adalah anomali. Siri masalah berikut timbul untuk penggunaan rangkaian saraf:
- untuk berfungsi dengan betul dalam mod penstriman, data untuk melatih model rangkaian saraf mesti termasuk hanya data "biasa";
- adalah perlu untuk mempunyai model terkini untuk pengesanan yang betul. Perubahan arah aliran dan kemusim dalam metrik boleh menyebabkan sejumlah besar positif palsu dalam model. Untuk mengemas kininya, adalah perlu untuk menentukan dengan jelas masa apabila model itu ketinggalan zaman. Jika anda mengemas kini model kemudian atau lebih awal, maka, kemungkinan besar, sejumlah besar positif palsu akan mengikuti.
Kita juga tidak boleh lupa tentang mencari dan mencegah kejadian positif palsu yang kerap. Diandaikan bahawa ia paling kerap berlaku dalam situasi kecemasan. Walau bagaimanapun, ia juga mungkin akibat daripada ralat rangkaian saraf akibat latihan yang tidak mencukupi. Ia adalah perlu untuk meminimumkan bilangan positif palsu model. Jika tidak, ramalan palsu akan membuang banyak masa pentadbir yang bertujuan untuk menyemak sistem. Lambat laun pentadbir hanya akan berhenti bertindak balas kepada sistem pemantauan "paranoid".
Rangkaian saraf berulang
Untuk mengesan anomali dalam siri masa, anda boleh gunakan dengan ingatan LSTM. Satu-satunya masalah ialah ia hanya boleh digunakan untuk siri masa yang diramalkan. Dalam kes kami, tidak semua metrik boleh diramal. Percubaan untuk menggunakan RNN LSTM pada siri masa ditunjukkan dalam Rajah 4.
Rajah 4. Contoh rangkaian saraf berulang dengan sel memori LSTM
Seperti yang dapat dilihat daripada Rajah 4, RNN LSTM dapat mengatasi pencarian anomali dalam tempoh masa ini. Di mana keputusan mempunyai ralat ramalan yang tinggi (min ralat), anomali dalam penunjuk sebenarnya telah berlaku. Menggunakan satu RNN LSTM jelas tidak mencukupi, kerana ia boleh digunakan pada sebilangan kecil metrik. Boleh digunakan sebagai kaedah tambahan untuk mencari anomali.
Autoencoder untuk ramalan kegagalan
β pada asasnya rangkaian saraf tiruan. Lapisan input ialah pengekod, lapisan keluaran ialah penyahkod. Kelemahan semua rangkaian saraf jenis ini ialah mereka tidak menyetempatkan anomali dengan baik. Seni bina pengekod automatik segerak telah dipilih.
Rajah 5. Contoh operasi pengekod automatik
Pengekod auto dilatih pada data biasa dan kemudian mencari sesuatu yang tidak normal dalam data yang disalurkan kepada model. Hanya apa yang anda perlukan untuk tugas ini. Apa yang tinggal ialah memilih pengekod automatik yang sesuai untuk tugas ini. Bentuk autoenkoder yang paling mudah dari segi seni bina ialah rangkaian neural ke hadapan, tidak kembali, yang hampir sama dengan (perceptron berbilang lapisan, MLP), dengan lapisan input, lapisan output dan satu atau lebih lapisan tersembunyi yang menghubungkannya.
Walau bagaimanapun, perbezaan antara pengekod auto dan MLP ialah dalam pengekod auto, lapisan keluaran mempunyai bilangan nod yang sama dengan lapisan input, dan bukannya dilatih untuk meramalkan nilai sasaran Y yang diberikan oleh input X, pengekod auto dilatih. untuk membina semula X sendiri. Oleh itu, Autoencoder ialah model pembelajaran tanpa pengawasan.
Tugas pengekod auto ialah mencari indeks masa r0 ... rn sepadan dengan unsur anomali dalam vektor input X. Kesan ini dicapai dengan mencari ralat kuasa dua.
Rajah 6. Pengekod auto segerak
Untuk pengekod auto telah dipilih . Kelebihannya: keupayaan untuk menggunakan mod pemprosesan penstriman dan bilangan parameter rangkaian saraf yang agak kecil berbanding dengan seni bina lain.
Mekanisme untuk meminimumkan positif palsu
Disebabkan fakta bahawa pelbagai situasi tidak normal timbul, serta kemungkinan situasi latihan rangkaian saraf yang tidak mencukupi, untuk model pengesanan anomali yang sedang dibangunkan, diputuskan bahawa adalah perlu untuk membangunkan mekanisme untuk meminimumkan positif palsu. Mekanisme ini adalah berdasarkan asas templat yang diklasifikasikan oleh pentadbir.
(Algoritma DTW, daripada ledingan masa dinamik bahasa Inggeris) membolehkan anda mencari korespondensi optimum antara jujukan masa. Mula-mula digunakan dalam pengecaman pertuturan: digunakan untuk menentukan cara dua isyarat pertuturan mewakili frasa pertuturan asal yang sama. Selepas itu, permohonan didapati untuknya di kawasan lain.
Prinsip utama meminimumkan positif palsu ialah mengumpul pangkalan data piawaian dengan bantuan pengendali yang mengklasifikasikan kes mencurigakan yang dikesan menggunakan rangkaian saraf. Seterusnya, piawaian terperingkat dibandingkan dengan kes yang dikesan sistem, dan kesimpulan dibuat tentang sama ada kes itu palsu atau membawa kepada kegagalan. Algoritma DTW digunakan dengan tepat untuk membandingkan dua siri masa. Alat pengecilan utama masih klasifikasi. Dijangkakan bahawa selepas mengumpul sejumlah besar kes rujukan, sistem akan mula meminta operator kurang kerana persamaan kebanyakan kes dan kejadian yang serupa.
Akibatnya, berdasarkan kaedah rangkaian saraf yang diterangkan di atas, program percubaan telah dibina untuk meramalkan kegagalan sistem "Penyatuan Web". Matlamat program ini adalah, menggunakan arkib sedia ada data pemantauan dan maklumat tentang kegagalan sebelumnya, untuk menilai kecekapan pendekatan ini untuk sistem perisian kami. Skim program dibentangkan di bawah dalam Rajah 7.
Rajah 7. Skim ramalan kegagalan berdasarkan analisis ruang metrik
Dalam rajah, dua blok utama boleh dibezakan: pencarian tempoh masa anomali dalam aliran data pemantauan (metrik) dan mekanisme untuk meminimumkan positif palsu. Nota: Untuk tujuan percubaan, data diperoleh melalui sambungan JDBC daripada pangkalan data yang mana grafit akan menyimpannya.
Berikut adalah antara muka sistem pemantauan yang diperoleh hasil pembangunan (Rajah 8).
Rajah 8. Antara muka sistem pemantauan eksperimen
Antara muka memaparkan peratusan anomali berdasarkan metrik yang diterima. Dalam kes kami, resit disimulasikan. Kami sudah mempunyai semua data selama beberapa minggu dan memuatkannya secara beransur-ansur untuk memeriksa kes anomali yang membawa kepada kegagalan. Bar status yang lebih rendah memaparkan peratusan keseluruhan anomali data pada masa tertentu, yang ditentukan menggunakan pengekod automatik. Selain itu, peratusan berasingan dipaparkan untuk metrik yang diramalkan, yang dikira oleh RNN LSTM.
Contoh pengesanan anomali berdasarkan prestasi CPU menggunakan rangkaian saraf RNN LSTM (Rajah 9).
Rajah 9. Penemuan RNN LSTM
Kes yang agak mudah, pada asasnya adalah outlier biasa, tetapi membawa kepada kegagalan sistem, telah berjaya dikira menggunakan RNN LSTM. Penunjuk anomali dalam tempoh masa ini ialah 85β95%; semua yang melebihi 80% (ambang ditentukan secara eksperimen) dianggap sebagai anomali.
Contoh pengesanan anomali apabila sistem tidak dapat boot selepas kemas kini. Keadaan ini dikesan oleh pengekod auto (Rajah 10).
Rajah 10. Contoh pengesanan autoencoder
Seperti yang anda lihat dari rajah, PermGen tersekat pada satu tahap. Pengekod auto mendapati perkara ini pelik kerana ia tidak pernah melihat perkara seperti itu sebelum ini. Di sini anomali kekal 100% sehingga sistem kembali ke keadaan berfungsi. Anomali dipaparkan untuk semua metrik. Seperti yang dinyatakan sebelum ini, pengekod auto tidak boleh menyetempatkan anomali. Operator dipanggil untuk melaksanakan fungsi ini dalam situasi ini.
Kesimpulan
PC "Web-Consolidation" telah dibangunkan selama beberapa tahun. Sistem ini berada dalam keadaan yang agak stabil, dan bilangan insiden yang direkodkan adalah kecil. Walau bagaimanapun, adalah mungkin untuk mencari anomali yang membawa kepada kegagalan 5 - 10 minit sebelum kegagalan berlaku. Dalam sesetengah kes, pemberitahuan kegagalan lebih awal akan membantu menjimatkan masa yang dijadualkan yang diperuntukkan untuk menjalankan kerja "pembaikan".
Berdasarkan eksperimen yang telah dijalankan, masih terlalu awal untuk membuat kesimpulan akhir. Setakat ini, keputusannya bercanggah. Di satu pihak, jelas bahawa algoritma berdasarkan rangkaian saraf mampu mencari anomali "berguna". Sebaliknya, masih terdapat peratusan besar positif palsu, dan tidak semua anomali yang dikesan oleh pakar yang berkelayakan dalam rangkaian saraf dapat dikesan. Kelemahannya termasuk hakikat bahawa kini rangkaian saraf memerlukan latihan dengan guru untuk operasi biasa.
Untuk membangunkan lagi sistem ramalan kegagalan dan membawanya ke keadaan yang memuaskan, beberapa cara boleh difikirkan. Ini adalah analisis yang lebih terperinci tentang kes dengan anomali yang membawa kepada kegagalan, disebabkan penambahan ini kepada senarai metrik penting yang sangat mempengaruhi keadaan sistem, dan membuang yang tidak perlu yang tidak menjejaskannya. Selain itu, jika kami bergerak ke arah ini, kami boleh membuat percubaan untuk mengkhususkan algoritma khusus untuk kes kami dengan anomali yang membawa kepada kegagalan. Ada cara lain. Ini adalah peningkatan dalam seni bina rangkaian saraf dan dengan itu meningkatkan ketepatan pengesanan dengan pengurangan masa latihan.
Saya mengucapkan terima kasih kepada rakan sekerja saya yang membantu saya menulis dan mengekalkan kaitan artikel ini: dan Sergei Finogenov.
Sumber: www.habr.com