Priemyselný vývoj softvérových systémov si vyžaduje veľkú pozornosť odolnosti voči chybám konečného produktu, ako aj rýchlu reakciu na poruchy a zlyhania, ak sa vyskytnú. Monitoring samozrejme pomáha efektívnejšie a rýchlejšie reagovať na zlyhania a zlyhania, ale nie dostatočne. Po prvé, je veľmi ťažké sledovať veľký počet serverov - je potrebný veľký počet ľudí. Po druhé, musíte dobre pochopiť, ako aplikácia funguje, aby ste mohli predpovedať jej stav. Preto potrebujeme veľa ľudí, ktorí dobre rozumejú systémom, ktoré vyvíjame, ich výkonu a funkciám. Predpokladajme, že aj keď nájdete dostatok ľudí ochotných to urobiť, ich zaškolenie si vyžaduje veľa času.
Čo robiť? Tu nám prichádza na pomoc umelá inteligencia. Článok bude hovoriť o (prediktívna údržba). Tento prístup aktívne získava na popularite. Bolo napísaných veľké množstvo článkov, vrátane Habrého. Veľké spoločnosti plne využívajú tento prístup na udržanie výkonu svojich serverov. Po preštudovaní veľkého množstva článkov sme sa rozhodli vyskúšať tento prístup. čo z toho vzniklo?
Úvod
Vyvinutý softvérový systém sa skôr či neskôr uvedie do prevádzky. Pre užívateľa je dôležité, aby systém fungoval bez porúch. Ak sa vyskytne núdzová situácia, mala by sa vyriešiť s minimálnym oneskorením.
Na zjednodušenie technickej podpory softvérového systému, najmä ak existuje veľa serverov, sa zvyčajne používajú monitorovacie programy, ktoré berú metriky zo spusteného softvérového systému, umožňujú diagnostikovať jeho stav a pomáhajú určiť, čo presne spôsobilo poruchu. Tento proces sa nazýva softvérové monitorovanie systému.
Obrázok 1. Monitorovacie rozhranie Grafana
Metriky sú rôzne indikátory softvérového systému, jeho vykonávacieho prostredia alebo fyzického počítača, pod ktorým systém beží, s časovou pečiatkou okamihu, kedy boli metriky prijaté. V statickej analýze sa tieto metriky nazývajú časové rady. Na monitorovanie stavu softvérového systému sa metriky zobrazujú vo forme grafov: čas je na osi X a hodnoty sú pozdĺž osi Y (obrázok 1). Z bežiaceho softvérového systému (z každého uzla) možno prevziať niekoľko tisíc metrík. Tvoria priestor metrík (viacrozmerné časové rady).
Keďže sa pre komplexné softvérové systémy zhromažďuje veľké množstvo metrík, manuálne monitorovanie sa stáva náročnou úlohou. Aby sa znížilo množstvo údajov analyzovaných správcom, monitorovacie nástroje obsahujú nástroje na automatickú identifikáciu možných problémov. Môžete napríklad nakonfigurovať spúšťač, ktorý sa spustí, keď voľné miesto na disku klesne pod určený prah. Môžete tiež automaticky diagnostikovať vypnutie servera alebo kritické spomalenie rýchlosti služby. V praxi monitorovacie nástroje odvedú dobrú prácu pri odhaľovaní porúch, ktoré sa už vyskytli, alebo identifikácii jednoduchých symptómov budúcich porúch, no vo všeobecnosti pre ne zostáva predpovedanie možného zlyhania tvrdým orieškom. Predpovedanie prostredníctvom manuálnej analýzy metrík si vyžaduje zapojenie kvalifikovaných špecialistov. Je to nízka produktivita. Väčšina potenciálnych porúch môže zostať nepovšimnutá.
Medzi veľkými spoločnosťami zaoberajúcimi sa vývojom IT softvéru je v poslednom čase čoraz populárnejšia takzvaná prediktívna údržba softvérových systémov. Podstatou tohto prístupu je pomocou umelej inteligencie nájsť problémy vedúce k degradácii systému v skorých štádiách, ešte pred jeho zlyhaním. Tento prístup úplne nevylučuje manuálne monitorovanie systému. Je to pomocná látka pre proces monitorovania ako celku.
Hlavným nástrojom implementácie prediktívnej údržby je úloha vyhľadávania anomálií v časových radoch, od r keď dôjde k anomálii v údajoch je vysoká pravdepodobnosť, že po určitom čase dôjde k zlyhaniu alebo zlyhaniu. Anomália je určitá odchýlka vo výkone softvérového systému, ako je identifikácia zníženia rýchlosti vykonávania jedného typu požiadavky alebo zníženie priemerného počtu obsluhovaných požiadaviek pri konštantnej úrovni klientskych relácií.
Úloha hľadania anomálií pre softvérové systémy má svoje špecifiká. Teoreticky je pre každý softvérový systém potrebné vyvinúť alebo zdokonaliť existujúce metódy, pretože vyhľadávanie anomálií je veľmi závislé od údajov, v ktorých sa vykonáva, a údaje softvérových systémov sa značne líšia v závislosti od nástrojov na implementáciu systému. až po počítač, na ktorom beží.
Metódy hľadania anomálií pri predpovedaní porúch softvérových systémov
V prvom rade stojí za to povedať, že myšlienka predpovedania zlyhaní bola inšpirovaná článkom . Na testovanie efektivity prístupu s automatickým vyhľadávaním anomálií bol zvolený softvérový systém Web-Consolidation, ktorý je jedným z projektov spoločnosti NPO Krista. Predtým sa pre ňu vykonávalo manuálne monitorovanie na základe prijatých metrík. Keďže je systém pomerne zložitý, berie sa naň veľké množstvo metrík: indikátory JVM (zaťaženie zberača odpadu), indikátory operačného systému, pod ktorým sa kód spúšťa (virtuálna pamäť, % zaťaženie procesora OS), indikátory siete (zaťaženie siete ), samotný server (zaťaženie CPU, pamäť), metriky divokého letu a vlastné metriky aplikácie pre všetky kritické podsystémy.
Všetky metriky sú prevzaté zo systému pomocou grafitu. Spočiatku sa ako štandardné riešenie pre grafana používala whisper databáza, ale ako sa klientská základňa rozrastala, grafit to už nezvládal, pretože vyčerpal kapacitu diskového subsystému DC. Potom sa rozhodlo nájsť efektívnejšie riešenie. Voľba bola urobená v prospech , čo umožnilo rádovo znížiť zaťaženie diskového subsystému a päť- až šesťnásobne zmenšiť obsadené miesto na disku. Nižšie je uvedený diagram mechanizmu zhromažďovania metrík pomocou grafitu+kliknutia (obrázok 2).
Obrázok 2. Schéma zberu metrík
Schéma je prevzatá z internej dokumentácie. Zobrazuje komunikáciu medzi grafanom (nami používané monitorovacie používateľské rozhranie) a grafitom. Odstránenie metrík z aplikácie sa vykonáva pomocou samostatného softvéru – . Vkladá ich do grafitu.
Systém Web Consolidation má množstvo funkcií, ktoré spôsobujú problémy pri predpovedaní zlyhaní:
- Trend sa často mení. Pre tento softvérový systém sú k dispozícii rôzne verzie. Každý z nich prináša zmeny do softvérovej časti systému. V súlade s tým vývojári týmto spôsobom priamo ovplyvňujú metriky daného systému a môžu spôsobiť zmenu trendu;
- implementačná vlastnosť, ako aj účely, na ktoré klienti tento systém používajú, často spôsobujú anomálie bez predchádzajúcej degradácie;
- percento anomálií vzhľadom na celý súbor údajov je malé (< 5 %);
- V prijímaní ukazovateľov zo systému môžu existovať medzery. V niektorých krátkych časových úsekoch monitorovací systém nedokáže získať metriky. Napríklad, ak je server preťažený. To je dôležité pre trénovanie neurónovej siete. Je potrebné vyplniť medzery synteticky;
- Prípady s anomáliami sú často relevantné len pre konkrétny dátum/mesiac/čas (sezónnosť). Tento systém má jasné pravidlá pre jeho používanie užívateľmi. Metriky sú teda relevantné iba pre určitý čas. Systém nie je možné používať neustále, ale iba v niektorých mesiacoch: selektívne v závislosti od roku. Situácie nastávajú, keď rovnaké správanie metrík v jednom prípade môže viesť k zlyhaniu softvérového systému, ale nie v inom.
Najprv boli analyzované metódy na zisťovanie anomálií v monitorovacích údajoch softvérových systémov. V článkoch na túto tému, keď je percento anomálií malé v porovnaní so zvyškom súboru údajov, sa najčastejšie navrhuje použiť neurónové siete.
Základná logika vyhľadávania anomálií pomocou dát neurónovej siete je znázornená na obrázku 3:
Obrázok 3. Vyhľadávanie anomálií pomocou neurónovej siete
Na základe výsledku predpovede alebo obnovenia okna aktuálneho toku metrík sa vypočíta odchýlka od toho, ktorý dostane od spusteného softvérového systému. Ak existuje veľký rozdiel medzi metrikami získanými zo softvérového systému a neurónovej siete, môžeme konštatovať, že aktuálny segment údajov je anomálny. Pri používaní neurónových sietí vzniká nasledujúci rad problémov:
- na správne fungovanie v režime streamovania musia údaje pre modely trénovania neurónových sietí obsahovať iba „normálne“ údaje;
- pre správnu detekciu je potrebné mať aktuálny model. Meniace sa trendy a sezónnosť v metrikách môžu spôsobiť veľké množstvo falošne pozitívnych výsledkov v modeli. Na jeho aktualizáciu je potrebné jasne určiť čas, kedy je model zastaraný. Ak aktualizujete model neskôr alebo skôr, s najväčšou pravdepodobnosťou bude nasledovať veľké množstvo falošných poplachov.
Netreba zabúdať ani na vyhľadávanie a predchádzanie častému výskytu falošných poplachov. Predpokladá sa, že najčastejšie sa budú vyskytovať v núdzových situáciách. Môžu však byť aj dôsledkom chyby neurónovej siete v dôsledku nedostatočného tréningu. Je potrebné minimalizovať počet falošných poplachov modelu. V opačnom prípade falošné predpovede stratia veľa času správcu určeného na kontrolu systému. Skôr či neskôr administrátor jednoducho prestane reagovať na „paranoidný“ monitorovací systém.
Rekurentná neurónová sieť
Na zistenie anomálií v časových radoch môžete použiť s pamäťou LSTM. Jediným problémom je, že ho možno použiť iba pre prognózované časové rady. V našom prípade nie sú všetky metriky predvídateľné. Pokus o aplikáciu RNN LSTM na časový rad je znázornený na obrázku 4.
Obrázok 4. Príklad rekurentnej neurónovej siete s pamäťovými bunkami LSTM
Ako je možné vidieť na obrázku 4, RNN LSTM si v tomto časovom období dokázala poradiť s hľadaním anomálií. Ak má výsledok vysokú chybu predikcie (priemernú chybu), v indikátoroch skutočne nastala anomália. Použitie jedného RNN LSTM zjavne nebude stačiť, pretože je použiteľné pre malý počet metrík. Môže byť použitý ako pomocná metóda na vyhľadávanie anomálií.
Autokodér na predpovedanie zlyhania
– v podstate umelá neurónová sieť. Vstupná vrstva je kodér, výstupná vrstva je dekodér. Nevýhodou všetkých neurónových sietí tohto typu je, že zle lokalizujú anomálie. Bola zvolená architektúra synchrónneho autokódera.
Obrázok 5. Príklad činnosti autokódera
Autokodéry sú trénované na normálnych údajoch a potom nájdu niečo neobvyklé v údajoch privádzaných do modelu. Presne to, čo potrebujete pre túto úlohu. Zostáva len vybrať, ktorý autokóder je vhodný pre túto úlohu. Architektonicky najjednoduchšia forma autokódera je dopredná, nevracajúca sa neurónová sieť, ktorá je veľmi podobná (multilayer perceptron, MLP), so vstupnou vrstvou, výstupnou vrstvou a jednou alebo viacerými skrytými vrstvami, ktoré ich spájajú.
Rozdiely medzi automatickými kódovačmi a MLP sú však v tom, že v autokódovači má výstupná vrstva rovnaký počet uzlov ako vstupná vrstva a namiesto toho, aby bol trénovaný na predpovedanie cieľovej hodnoty Y danej vstupom X, je autokódovač trénovaný. na rekonštrukciu vlastných X. Autoenkódery sú preto modely učenia bez dozoru.
Úlohou autoenkódera je nájsť časové indexy r0 ... rn zodpovedajúce anomálnym prvkom vo vstupnom vektore X. Tento efekt sa dosiahne hľadaním druhej mocniny chyby.
Obrázok 6. Synchrónny autoenkodér
Pre automatický kódovač bol vybraný . Jeho výhody: možnosť využiť režim spracovania streamingu a relatívne menší počet parametrov neurónovej siete v porovnaní s inými architektúrami.
Mechanizmus na minimalizáciu falošných poplachov
Vzhľadom na to, že pre vyvíjaný model detekcie anomálií vznikajú rôzne abnormálne situácie, ako aj možná situácia nedostatočného tréningu neurónovej siete, bolo rozhodnuté, že je potrebné vyvinúť mechanizmus na minimalizáciu falošných poplachov. Tento mechanizmus je založený na šablóne, ktorú klasifikuje správca.
(DTW algoritmus, z anglického dynamic time warping) umožňuje nájsť optimálnu zhodu medzi časovými postupnosťami. Prvýkrát použité pri rozpoznávaní reči: používa sa na určenie toho, ako dva rečové signály predstavujú rovnakú pôvodnú hovorenú frázu. Následne sa pre ňu našlo uplatnenie aj v iných oblastiach.
Hlavným princípom minimalizácie falošných poplachov je zber databázy štandardov pomocou operátora, ktorý klasifikuje podozrivé prípady zistené pomocou neurónových sietí. Ďalej sa klasifikovaný štandard porovná s prípadom, ktorý systém zistil, a urobí sa záver o tom, či je prípad nepravdivý alebo vedie k zlyhaniu. Algoritmus DTW sa používa presne na porovnanie dvoch časových radov. Hlavným nástrojom minimalizácie je stále klasifikácia. Očakáva sa, že po zozbieraní veľkého počtu referenčných prípadov si systém začne od operátora pýtať menej kvôli podobnosti väčšiny prípadov a výskytu podobných.
Výsledkom bolo, že na základe vyššie opísaných metód neurónových sietí bol zostavený experimentálny program na predpovedanie porúch systému „Web-Consolidation“. Cieľom tohto programu bolo s využitím existujúceho archívu monitorovacích údajov a informácií o predchádzajúcich poruchách zhodnotiť kompetentnosť tohto prístupu pre naše softvérové systémy. Schéma programu je uvedená nižšie na obrázku 7.
Obrázok 7. Schéma predikcie porúch založená na analýze metrického priestoru
V diagrame možno rozlíšiť dva hlavné bloky: hľadanie anomálnych časových úsekov v toku údajov monitorovania (metriky) a mechanizmus minimalizácie falošných poplachov. Poznámka: Pre experimentálne účely sa dáta získavajú cez JDBC spojenie z databázy, do ktorej ich grafit uloží.
Nasleduje rozhranie monitorovacieho systému získaného ako výsledok vývoja (obrázok 8).
Obrázok 8. Rozhranie experimentálneho monitorovacieho systému
Rozhranie zobrazuje percento anomálií na základe prijatých metrík. V našom prípade je príjem simulovaný. Všetky údaje už máme niekoľko týždňov a postupne ich načítavame, aby sme preverili prípad anomálie vedúcej k zlyhaniu. Spodný stavový riadok zobrazuje celkové percento anomálií údajov v danom čase, ktoré sa určuje pomocou automatického kódovača. Pre predpovedané metriky sa zobrazuje aj samostatné percento, ktoré vypočítava RNN LSTM.
Príklad detekcie anomálií na základe výkonu CPU pomocou neurónovej siete RNN LSTM (obrázok 9).
Obrázok 9. Objav RNN LSTM
Pomerne jednoduchý prípad, v podstate obyčajná odľahlá hodnota, ktorá však viedla k zlyhaniu systému, bol úspešne vypočítaný pomocou RNN LSTM. Indikátor anomálie v tomto časovom období je 85–95 %, všetko nad 80 % (prah bol stanovený experimentálne) sa považuje za anomáliu.
Príklad detekcie anomálie, keď sa systém po aktualizácii nepodarilo zaviesť. Túto situáciu deteguje autokóder (obrázok 10).
Obrázok 10. Príklad detekcie autoenkodéra
Ako môžete vidieť na obrázku, PermGen je zaseknutý na jednej úrovni. Autokodér to považoval za zvláštne, pretože nikdy predtým nič podobné nevidel. Tu anomália zostáva 100%, kým sa systém nevráti do funkčného stavu. Pre všetky metriky sa zobrazí anomália. Ako už bolo spomenuté, autokóder nedokáže lokalizovať anomálie. Operátor je v týchto situáciách vyzvaný, aby túto funkciu vykonal.
Záver
PC "Web-Consolidation" sa vyvíja už niekoľko rokov. Systém je v pomerne stabilnom stave a počet zaznamenaných incidentov je malý. Podarilo sa však nájsť anomálie vedúce k poruche 5 - 10 minút predtým, ako k poruche došlo. V niektorých prípadoch by oznámenie o poruche vopred pomohlo ušetriť plánovaný čas, ktorý je vyčlenený na vykonanie „opravných“ prác.
Na základe vykonaných experimentov je priskoro robiť konečné závery. Zatiaľ sú výsledky rozporuplné. Na jednej strane je jasné, že algoritmy založené na neurónových sieťach sú schopné nájsť „užitočné“ anomálie. Na druhej strane zostáva veľké percento falošne pozitívnych výsledkov a nie všetky anomálie zistené kvalifikovaným špecialistom v neurónovej sieti sa dajú odhaliť. Medzi nevýhody patrí skutočnosť, že teraz neurónová sieť vyžaduje školenie s učiteľom na bežnú prevádzku.
Na ďalší rozvoj systému predpovedania porúch a jeho uvedenie do uspokojivého stavu možno predpokladať niekoľko spôsobov. Ide o podrobnejšiu analýzu prípadov s anomáliami, ktoré vedú k zlyhaniu vďaka tomuto pridaniu do zoznamu dôležitých metrík, ktoré výrazne ovplyvňujú stav systému, a vyradeniu nepotrebných, ktoré ho neovplyvňujú. Taktiež, ak sa pohneme týmto smerom, môžeme sa pokúsiť špecializovať algoritmy špeciálne pre naše prípady s anomáliami, ktoré vedú k zlyhaniam. Existuje aj iný spôsob. Ide o vylepšenie architektúry neurónových sietí a tým zvýšenie presnosti detekcie so skrátením času tréningu.
Vyjadrujem vďaku svojim kolegom, ktorí mi pomohli napísať a udržiavať relevantnosť tohto článku: a Sergej Finogenov.
Zdroj: hab.com