A szoftverrendszerek ipari fejlesztése nagy odafigyelést igényel a végtermék hibatűrésére, valamint a meghibásodásokra és esetleges meghibásodásokra való gyors reagálásra. A monitorozás természetesen segít a kudarcokra, meghibásodásokra hatékonyabban és gyorsabban reagálni, de nem eléggé. Először is, nagyon nehéz nyomon követni a nagyszámú szervert - nagyszámú emberre van szükség. Másodszor, jól meg kell értenie az alkalmazás működését, hogy előre jelezze állapotát. Ezért sok emberre van szükségünk, akik jól ismerik az általunk fejlesztendő rendszereket, azok teljesítményét és jellemzőit. Tegyük fel, hogy még ha talál is elég embert, aki hajlandó erre, akkor is sok időbe telik a betanításuk.
Mit kell tenni? Itt jön a segítségünkre a mesterséges intelligencia. A cikk arról fog szólni (prediktív karbantartás). Ez a megközelítés egyre népszerűbb. Számos cikk született, többek között Habréról is. A nagyvállalatok teljes mértékben kihasználják ezt a megközelítést szervereik teljesítményének fenntartása érdekében. Számos cikk tanulmányozása után úgy döntöttünk, hogy kipróbáljuk ezt a megközelítést. mi lett belőle?
Bevezetés
A kifejlesztett szoftverrendszer előbb-utóbb működésbe lép. A felhasználó számára fontos, hogy a rendszer hibamentesen működjön. Ha vészhelyzet történik, azt minimális késéssel kell megoldani.
A szoftverrendszer műszaki támogatásának egyszerűsítésére, különösen sok szerver esetén, általában olyan megfigyelő programokat használnak, amelyek egy futó szoftverrendszertől veszik a mérőszámokat, lehetővé teszik annak állapotának diagnosztizálását, és segítenek meghatározni, hogy pontosan mi okozta a hibát. Ezt a folyamatot szoftverrendszer-felügyeletnek nevezik.
1. ábra Grafana felügyeleti felület
A mérőszámok egy szoftverrendszer, a végrehajtási környezet vagy a fizikai számítógép, amelyen a rendszer fut, különböző mutatói a metrikák fogadásának pillanatának időbélyegével. A statikus elemzésben ezeket a mérőszámokat idősoroknak nevezzük. A szoftverrendszer állapotának nyomon követésére a metrikák grafikonok formájában jelennek meg: az idő az X tengelyen, az értékek pedig az Y tengely mentén (1. ábra). Egy futó szoftverrendszerből (minden csomópontból) több ezer metrika vehető ki. A metrikák (többdimenziós idősorok) terét alkotják.
Mivel az összetett szoftverrendszerekhez nagyszámú mérőszámot gyűjtenek össze, a kézi felügyelet nehéz feladattá válik. Az adminisztrátor által elemzett adatok mennyiségének csökkentése érdekében a felügyeleti eszközök olyan eszközöket tartalmaznak, amelyek automatikusan azonosítják a lehetséges problémákat. Például beállíthat egy triggert, amely akkor aktiválódik, ha a szabad lemezterület egy meghatározott küszöb alá esik. Automatikusan diagnosztizálhatja a kiszolgáló leállását vagy a szolgáltatási sebesség kritikus lelassulását. A gyakorlatban a felügyeleti eszközök jó munkát végeznek a már megtörtént hibák észlelésében vagy a jövőbeni hibák egyszerű tüneteinek azonosításában, de általában a lehetséges meghibásodás előrejelzése továbbra is kemény dió marad számukra. A mérőszámok manuális elemzésével történő előrejelzéshez képzett szakemberek bevonása szükséges. Alacsony termelékenységű. A legtöbb lehetséges hiba észrevétlen marad.
Az utóbbi időben a nagy informatikai szoftverfejlesztő cégek körében egyre népszerűbb a szoftverrendszerek úgynevezett prediktív karbantartása. Ennek a megközelítésnek a lényege, hogy mesterséges intelligencia segítségével megtalálja a rendszer leépüléséhez vezető problémákat a korai szakaszban, még mielőtt az meghibásodik. Ez a megközelítés nem zárja ki teljesen a rendszer kézi felügyeletét. A megfigyelési folyamat egészének kiegészítője.
A prediktív karbantartás megvalósításának fő eszköze az idősorok anomáliáinak felkutatása, hiszen amikor anomália lép fel az adatokban nagy a valószínűsége annak, hogy egy idő után lesz kudarc vagy kudarc. Az anomália egy szoftverrendszer teljesítményének bizonyos eltérése, például egy kéréstípus végrehajtási sebességének romlása vagy a kiszolgált kérések átlagos számának csökkenése az ügyfélmunkamenetek állandó szintjén.
A szoftverrendszerek anomáliáinak felkutatásának megvannak a maga sajátosságai. Elméletileg minden szoftverrendszerhez szükséges a meglévő módszerek fejlesztése vagy finomítása, mivel az anomáliák keresése nagymértékben függ attól, hogy milyen adatokban történik, és a szoftverrendszerek adatai nagymértékben változnak a rendszer megvalósításához használt eszközök függvényében. , attól függően, hogy melyik számítógépen fut.
Anomáliák keresésének módszerei szoftverrendszerek hibáinak előrejelzése során
Először is érdemes elmondani, hogy a kudarcok előrejelzésének ötletét a cikk ihlette . Az automatikus anomáliák kereséssel történő megközelítés hatékonyságának tesztelésére a Web-Consolidation szoftverrendszert választottuk, amely az NPO Krista cég egyik projektje. Korábban kézi felügyeletet végeztek rá a kapott mérőszámok alapján. Mivel a rendszer meglehetősen összetett, nagyszámú mérőszámot használnak hozzá: JVM-mutatók (szemétgyűjtő terhelés), annak az operációs rendszernek a mutatói, amely alatt a kódot végrehajtják (virtuális memória, % OS CPU terhelés), hálózati indikátorok (hálózati terhelés). ), magát a szervert (CPU terhelés, memória), wildfly-metrikákat és az alkalmazás saját mérőszámait az összes kritikus alrendszerhez.
Az összes mérőszámot a rendszerből grafit segítségével veszik. Kezdetben a whisper adatbázist a grafana szabványos megoldásaként használták, de az ügyfélbázis növekedésével a grafit már nem tudott megbirkózni, mivel kimerítette a DC lemez alrendszer kapacitását. Ezek után úgy döntöttek, hogy hatékonyabb megoldást találnak. A választás javára történt , amely lehetővé tette a lemezalrendszer terhelésének nagyságrenddel történő csökkentését, és a lefoglalt lemezterület öt-hatszoros csökkentését. Az alábbiakban egy diagramot mutatunk be a metrikák grafit+clickhouse használatával történő gyűjtésének mechanizmusáról (2. ábra).
2. ábra A mérőszámok gyűjtésének sémája
A diagram a belső dokumentációból származik. Megmutatja a grafana (az általunk használt megfigyelő felület) és a grafit közötti kommunikációt. A mutatók eltávolítása egy alkalmazásból külön szoftverrel történik - . Grafitba rakja őket.
A Web Consolidation rendszer számos olyan funkcióval rendelkezik, amelyek problémákat okoznak a hibák előrejelzésében:
- A tendencia gyakran változik. Ehhez a szoftverrendszerhez különböző verziók állnak rendelkezésre. Mindegyik változtatást hoz a rendszer szoftveres részében. Ennek megfelelően a fejlesztők így közvetlenül befolyásolják az adott rendszer mérőszámait, és trendváltozást okozhatnak;
- a megvalósítási jellemzők, valamint az ügyfelek által a rendszer használatának céljai gyakran okoznak anomáliákat korábbi leromlás nélkül;
- az anomáliák aránya a teljes adathalmazhoz viszonyítva kicsi (< 5%);
- Előfordulhat, hogy hiányosságok vannak az indikátorok rendszertől való fogadásában. Néhány rövid időn belül a felügyeleti rendszer nem képes mérni a mérőszámokat. Például, ha a szerver túlterhelt. Ez kritikus fontosságú a neurális hálózat betanításához. Szükség van a hiányosságok szintetikus pótlására;
- Az anomáliás esetek gyakran csak egy adott dátumra/hónapra/időpontra vonatkoznak (szezonalitás). Ennek a rendszernek egyértelmű szabályozása van a felhasználók általi használatára vonatkozóan. Ennek megfelelően a mérőszámok csak egy adott időre relevánsak. A rendszer nem használható folyamatosan, csak néhány hónapban: évtől függően szelektíven. Olyan helyzetek merülnek fel, amikor a mérőszámok azonos viselkedése az egyik esetben a szoftverrendszer meghibásodásához vezethet, a másikban viszont nem.
Kezdetben a szoftverrendszerek monitorozási adataiban fellelhető anomáliák kimutatására szolgáló módszereket elemeztem. A témával foglalkozó cikkekben, amikor az anomáliák aránya kicsi az adathalmaz többi részéhez képest, leggyakrabban neurális hálózatok használatát javasolják.
Az anomáliák neurális hálózati adatok segítségével történő keresésének alapvető logikája a 3. ábrán látható:
3. ábra Anomáliák keresése neurális hálózat segítségével
Az aktuális metrikafolyam ablakának előrejelzése vagy helyreállítása eredménye alapján számítják ki a futó szoftverrendszertől kapott eltérést. Ha nagy különbség van a szoftverrendszer és a neurális hálózat által kapott metrikák között, akkor arra a következtetésre juthatunk, hogy az aktuális adatszegmens anomáliás. A következő problémák sorozata merül fel a neurális hálózatok használatával kapcsolatban:
- a streaming módban történő helyes működéshez a neurális hálózati modellek betanítására szolgáló adatok csak „normál” adatokat tartalmazhatnak;
- a helyes észleléshez naprakész modell szükséges. A változó trendek és szezonalitás a mutatókban nagyszámú téves pozitív eredményt okozhat a modellben. Frissítéséhez egyértelműen meg kell határozni az időt, amikor a modell elavult. Ha később vagy korábban frissíti a modellt, akkor valószínűleg nagyszámú téves pozitív eredmény következik be.
Nem szabad megfeledkeznünk a hamis pozitív eredmények gyakori előfordulásának felkutatásáról és megelőzéséről sem. Feltételezhető, hogy ezek leggyakrabban vészhelyzetekben fordulnak elő. Ezek azonban az elégtelen képzés miatti neurális hálózati hiba következményei is lehetnek. Minimálisra kell csökkenteni a modell hamis pozitív eredményének számát. Ellenkező esetben a téves előrejelzések sok rendszergazdai időt veszítenek el a rendszer ellenőrzésére. Előbb-utóbb az adminisztrátor egyszerűen nem reagál a „paranoiás” megfigyelőrendszerre.
Ismétlődő neurális hálózat
Az idősorok anomáliáinak észleléséhez használhatja LSTM memóriával. Az egyetlen probléma az, hogy csak előre jelzett idősorokhoz használható. Esetünkben nem minden mérőszám kiszámítható. Az RNN LSTM idősorra történő alkalmazására tett kísérlet a 4. ábrán látható.
4. ábra Példa visszatérő neurális hálózatra LSTM memóriacellákkal
Amint a 4. ábrán látható, az RNN LSTM képes volt megbirkózni az anomáliák keresésével ebben az időszakban. Ahol az eredmény magas előrejelzési hibával (átlagos hibával) rendelkezik, a mutatók anomáliája történt. Egyetlen RNN LSTM használata nyilvánvalóan nem lesz elegendő, mivel kevés metrikára alkalmazható. Kiegészítő módszerként használható anomáliák keresésére.
Autoencoder a hiba előrejelzéséhez
– lényegében mesterséges neurális hálózat. A bemeneti réteg kódoló, a kimeneti réteg dekódoló. Az összes ilyen típusú neurális hálózat hátránya, hogy nem jól lokalizálják az anomáliákat. Szinkron autoencoder architektúrát választottak.
5. ábra Példa az autoencoder működésére
Az automatikus kódolók a normál adatokra vannak kiképezve, majd valami anomáliát találnak a modellbe betáplált adatokban. Pont amire szüksége van ehhez a feladathoz. Csak ki kell választani, hogy melyik automatikus kódoló alkalmas erre a feladatra. Az autoencoder építészetileg legegyszerűbb formája egy előre nem visszatérő neurális hálózat, amely nagyon hasonlít a (többrétegű perceptron, MLP), egy bemeneti réteggel, egy kimeneti réteggel és egy vagy több rejtett réteggel, amely összeköti őket.
Az automatikus kódolók és az MLP-k közötti különbség azonban az, hogy az autoencoderben a kimeneti rétegnek ugyanannyi csomópontja van, mint a bemeneti rétegnek, és ahelyett, hogy egy X bemenet által adott Y célérték előrejelzésére tanítanák, az autoencoder betanításra kerül. hogy rekonstruálja saját X-eit. Ezért az Autoencoderek nem felügyelt tanulási modellek.
Az autoencoder feladata, hogy megtalálja az X bemeneti vektor anomáliás elemeinek megfelelő r0 ... rn időindexeket. Ezt a hatást a négyzetes hiba keresésével érjük el.
6. ábra Szinkron autoencoder
Az automatikus kódolóhoz lett kiválasztva . Előnyei: a streaming feldolgozási mód használatának lehetősége és a többi architektúrához képest viszonylag kisebb számú neurális hálózati paraméter.
A hamis pozitív eredmények minimalizálásának mechanizmusa
Tekintettel arra, hogy a kidolgozás alatt álló anomália-detektáló modellhez különféle rendellenes helyzetek, valamint a neurális hálózat elégtelen képzésének lehetősége adódik, úgy döntöttek, hogy szükséges egy olyan mechanizmus kidolgozása, amely minimalizálja a hamis pozitív eredményeket. Ez a mechanizmus a rendszergazda által besorolt sablonbázison alapul.
(DTW algoritmus, az angol dynamic time warping szóból) lehetővé teszi az idősorok közötti optimális megfelelés megtalálását. Először a beszédfelismerésben használták: annak meghatározására szolgál, hogy két beszédjel hogyan reprezentálja ugyanazt az eredeti kimondott kifejezést. Később más területeken is találtak rá alkalmazást.
A hamis pozitívumok minimalizálásának fő elve a szabványok adatbázisának összegyűjtése egy operátor segítségével, aki osztályozza a neurális hálózatok segítségével észlelt gyanús eseteket. Ezután a minősített szabványt összehasonlítják a rendszer által észlelt esettel, és következtetést vonnak le arról, hogy az eset hamis-e vagy meghibásodáshoz vezet. A DTW algoritmust pontosan két idősor összehasonlítására használják. A fő minimalizálási eszköz továbbra is az osztályozás. Várhatóan nagyszámú referenciaeset összegyűjtése után a rendszer kevesebbet fog kérdezni az üzemeltetőtől, a legtöbb eset hasonlósága és hasonló esetek előfordulása miatt.
Ennek eredményeként a fent leírt neurális hálózati módszerek alapján egy kísérleti program készült a „Web-Consolidation” rendszer hibáinak előrejelzésére. Ennek a programnak az volt a célja, hogy a megfigyelési adatok és a korábbi hibákkal kapcsolatos információk meglévő archívumának felhasználásával értékelje ennek a megközelítésnek a kompetenciáját szoftverrendszereink számára. A program sémáját az alábbiakban a 7. ábra mutatja be.
7. ábra Metrikus térelemzésen alapuló meghibásodás-előrejelzési séma
Az ábrán két fő blokk különböztethető meg: az anomáliás időtartamok keresése a megfigyelési adatfolyamban (metrikák), valamint a hamis pozitívumok minimalizálásának mechanizmusa. Megjegyzés: Kísérleti célokra az adatokat JDBC-kapcsolaton keresztül szerezzük be abból az adatbázisból, amelybe a grafit menti azokat.
Az alábbiakban a fejlesztés eredményeként kapott monitoring rendszer interfészét mutatjuk be (8. ábra).
8. ábra A kísérleti monitoring rendszer interfésze
A felület megjeleníti az anomália százalékos arányát a kapott mérőszámok alapján. Esetünkben a nyugta szimulált. Már több hete megvan az összes adatunk, és fokozatosan töltjük be, hogy ellenőrizzük a meghibásodáshoz vezető rendellenességet. Az alsó állapotsor az adatrendellenességek teljes százalékos arányát jeleníti meg egy adott időpontban, amelyet egy automatikus kódoló határoz meg. Ezenkívül külön százalékos arány jelenik meg az előrejelzett metrikákhoz, amelyeket az RNN LSTM számít ki.
Példa a CPU teljesítményén alapuló anomáliák észlelésére az RNN LSTM neurális hálózat használatával (9. ábra).
9. ábra: RNN LSTM felfedezés
Az RNN LSTM segítségével sikeresen kiszámítottunk egy meglehetősen egyszerű esetet, amely lényegében közönséges kiugró, de rendszerhibához vezetett. Az anomália mutató ebben az időszakban 85-95%, minden 80% feletti (a küszöbértéket kísérletileg határoztuk meg) anomáliának számít.
Példa egy anomália észlelésére, amikor a rendszer nem tudott elindulni egy frissítés után. Ezt a helyzetet az autoencoder észleli (10. ábra).
10. ábra Példa az autoencoder észlelésére
Amint az ábrán látható, a PermGen egy szinten megrekedt. Az autoencoder furcsának találta ezt, mert még soha nem látott ehhez hasonlót. Itt az anomália 100%-os marad, amíg a rendszer vissza nem tér működőképes állapotba. Valamennyi metrika esetében anomália jelenik meg. Mint korábban említettük, az autoencoder nem tudja lokalizálni az anomáliákat. Ilyen helyzetekben a kezelőnek kell elvégeznie ezt a funkciót.
Következtetés
A PC "Web-Consolidation" több éve fejlesztés alatt áll. A rendszer meglehetősen stabil állapotban van, a rögzített incidensek száma csekély. Mindazonáltal 5-10 perccel a hiba bekövetkezése előtt meghibásodáshoz vezető anomáliákat lehetett találni. Egyes esetekben a meghibásodás előzetes bejelentése segít megtakarítani a „javítási” munkák elvégzésére szánt ütemezett időt.
Az elvégzett kísérletek alapján még korai lenne végső következtetéseket levonni. Egyelőre ellentmondásosak az eredmények. Egyrészt egyértelmű, hogy a neurális hálózatokon alapuló algoritmusok képesek „hasznos” anomáliákat találni. Másrészt továbbra is nagy százalékban maradnak hamis pozitívak, és nem minden anomália észlelhető, amelyet egy neurális hálózatban képzett szakember észlel. A hátrányok közé tartozik, hogy a neurális hálózat normál működéséhez tanári képzést igényel.
A meghibásodás-előrejelző rendszer továbbfejlesztésére és kielégítő állapotba hozására több mód is elképzelhető. Ez a kudarchoz vezető anomáliákkal rendelkező esetek részletesebb elemzése a rendszer állapotát nagymértékben befolyásoló fontos mérőszámok listája e kiegészítése és az azt nem befolyásoló feleslegesek elvetése miatt. Továbbá, ha ebbe az irányba haladunk, kísérletet tehetünk arra, hogy algoritmusokat specializáljunk kifejezetten a hibákhoz vezető anomáliák esetén. Van más mód is. Ez a neurális hálózati architektúrák javulását jelenti, és ezáltal növeli az észlelési pontosságot a betanítási idő csökkentésével.
Köszönetemet fejezem ki kollégáimnak, akik segítettek megírni és megőrizni ennek a cikknek a jelentőségét: és Szergej Finogenov.
Forrás: will.com