Průmyslový vývoj softwarových systémů vyžaduje velkou pozornost vůči chybové toleranci konečného produktu, stejně jako rychlou reakci na poruchy a poruchy, pokud k nim dojde. Monitoring samozřejmě pomáhá reagovat na poruchy a poruchy efektivněji a rychleji, ale ne dostatečně. Za prvé, je velmi obtížné sledovat velký počet serverů - je potřeba velké množství lidí. Za druhé, musíte dobře rozumět tomu, jak aplikace funguje, abyste mohli předvídat její stav. Proto potřebujeme hodně lidí, kteří dobře rozumí systémům, které vyvíjíme, jejich výkonu a funkcím. Předpokládejme, že i když najdete dostatek lidí ochotných to udělat, jejich zaškolení zabere ještě hodně času.
Co dělat? Zde nám přichází na pomoc umělá inteligence. Článek bude mluvit o (prediktivní údržba). Tento přístup si aktivně získává popularitu. Bylo napsáno velké množství článků, včetně článků o Habrém. Velké společnosti tento přístup plně využívají k udržení výkonu svých serverů. Po prostudování velkého množství článků jsme se rozhodli tento přístup vyzkoušet. co z toho vzešlo?
úvod
Vyvinutý softwarový systém dříve nebo později jde do provozu. Pro uživatele je důležité, aby systém fungoval bez poruch. Pokud dojde k mimořádné události, měla by být vyřešena s minimálním zpožděním.
Pro zjednodušení technické podpory softwarového systému, zejména pokud je zde mnoho serverů, se obvykle používají monitorovací programy, které berou metriky z běžícího softwarového systému, umožňují diagnostikovat jeho stav a pomáhají určit, co přesně způsobilo selhání. Tento proces se nazývá monitorování softwarového systému.
Obrázek 1. Monitorovací rozhraní Grafana
Metriky jsou různé indikátory softwarového systému, jeho spouštěcího prostředí nebo fyzického počítače, pod kterým systém běží, s časovým razítkem okamžiku, kdy byly metriky přijaty. Ve statické analýze se tyto metriky nazývají časové řady. Pro sledování stavu softwarového systému se metriky zobrazují ve formě grafů: čas je na ose X a hodnoty jsou na ose Y (obrázek 1). Z běžícího softwarového systému (z každého uzlu) lze převzít několik tisíc metrik. Tvoří prostor metrik (vícerozměrné časové řady).
Vzhledem k tomu, že se pro komplexní softwarové systémy shromažďuje velké množství metrik, stává se ruční monitorování obtížným úkolem. Pro snížení množství dat analyzovaných správcem obsahují monitorovací nástroje nástroje pro automatickou identifikaci možných problémů. Můžete například nakonfigurovat spouštěč tak, aby se spustil, když volné místo na disku klesne pod zadanou prahovou hodnotu. Můžete také automaticky diagnostikovat vypnutí serveru nebo kritické zpomalení rychlosti služby. V praxi monitorovací nástroje odvádějí dobrou práci při odhalování již vzniklých poruch nebo identifikování jednoduchých příznaků budoucích poruch, ale obecně pro ně předpovídání možné poruchy zůstává tvrdým oříškem. Predikce pomocí manuální analýzy metrik vyžaduje zapojení kvalifikovaných specialistů. Je to nízká produktivita. Většina potenciálních poruch může zůstat bez povšimnutí.
Mezi velkými společnostmi zabývajícími se vývojem IT softwaru je v poslední době stále populárnější tzv. prediktivní údržba softwarových systémů. Podstatou tohoto přístupu je pomocí umělé inteligence najít problémy vedoucí k degradaci systému v raných fázích, ještě před jeho selháním. Tento přístup zcela nevylučuje manuální monitorování systému. Je to pomocná látka k procesu monitorování jako celku.
Hlavním nástrojem pro implementaci prediktivní údržby je úkol vyhledávat anomálie v časových řadách, od r když dojde k anomálii v datech je vysoká pravděpodobnost, že po nějaké době dojde k selhání nebo selhání. Anomálie je určitá odchylka ve výkonu softwarového systému, jako je identifikace zhoršení rychlosti provádění jednoho typu požadavku nebo snížení průměrného počtu obsluhovaných požadavků při konstantní úrovni klientských relací.
Úkol hledání anomálií pro softwarové systémy má svá specifika. Teoreticky je pro každý softwarový systém nutné vyvinout nebo zdokonalit existující metody, protože vyhledávání anomálií je velmi závislé na datech, ve kterých se provádí, a data softwarových systémů se velmi liší v závislosti na nástrojích pro implementaci systému. až po počítač, na kterém běží.
Metody vyhledávání anomálií při predikci poruch softwarových systémů
Za prvé, stojí za to říci, že myšlenka předvídat selhání byla inspirována článkem . Pro testování efektivity přístupu s automatickým vyhledáváním anomálií byl zvolen softwarový systém Web-Consolidation, který je jedním z projektů společnosti NPO Krista. Dříve se u něj provádělo manuální sledování na základě přijatých metrik. Protože je systém poměrně složitý, bere se pro něj velké množství metrik: indikátory JVM (zatížení kolektoru odpadu), indikátory operačního systému, pod kterým je kód spouštěn (virtuální paměť, % zatížení CPU OS), indikátory sítě (zatížení sítě ), samotný server (zatížení CPU, paměť), metriky divokého letu a vlastní metriky aplikace pro všechny kritické subsystémy.
Všechny metriky jsou převzaty ze systému pomocí grafitu. Zpočátku byla databáze whisper používána jako standardní řešení pro grafana, ale jak se klientská základna rozrůstala, grafit to již nezvládal, protože vyčerpal kapacitu diskového subsystému DC. Poté bylo rozhodnuto najít efektivnější řešení. Volba byla učiněna ve prospěch , což umožnilo řádově snížit zátěž diskového subsystému a pětkrát až šestkrát zmenšit obsazené místo na disku. Níže je schéma mechanismu pro shromažďování metrik pomocí grafitu+clickhouse (obrázek 2).
Obrázek 2. Schéma pro sběr metrik
Schéma je převzato z interní dokumentace. Ukazuje komunikaci mezi grafanou (námi používané monitorovací uživatelské rozhraní) a grafitem. Odstranění metrik z aplikace se provádí pomocí samostatného softwaru – . Dává je do grafitu.
Systém Web Consolidation má řadu funkcí, které způsobují problémy s předpovídáním selhání:
- Trend se často mění. Pro tento softwarový systém jsou k dispozici různé verze. Každý z nich přináší změny do softwarové části systému. V souladu s tím vývojáři tímto způsobem přímo ovlivňují metriky daného systému a mohou způsobit změnu trendu;
- implementační funkce, stejně jako účely, pro které klienti tento systém používají, často způsobují anomálie bez předchozí degradace;
- procento anomálií vzhledem k celému souboru dat je malé (< 5 %);
- Mohou existovat mezery v přijímání indikátorů ze systému. V některých krátkých časových obdobích se monitorovacímu systému nepodaří získat metriky. Například pokud je server přetížený. To je důležité pro trénování neuronové sítě. Je potřeba synteticky vyplnit mezery;
- Případy s anomálií jsou často relevantní pouze pro konkrétní datum/měsíc/čas (sezónnost). Tento systém má jasná pravidla pro jeho používání uživateli. Metriky jsou tedy relevantní pouze pro určitý čas. Systém nelze používat neustále, ale pouze v některých měsících: selektivně v závislosti na roce. Nastávají situace, kdy stejné chování metrik v jednom případě může vést k selhání softwarového systému, v jiném nikoli.
Nejprve byly analyzovány metody detekce anomálií v monitorovacích datech softwarových systémů. V článcích na toto téma, když je procento anomálií malé vzhledem ke zbytku souboru dat, se nejčastěji navrhuje použít neuronové sítě.
Základní logiku vyhledávání anomálií pomocí dat neuronové sítě ukazuje obrázek 3:
Obrázek 3. Vyhledávání anomálií pomocí neuronové sítě
Na základě výsledku prognózy nebo obnovení okna aktuálního toku metrik je vypočítána odchylka od té, kterou obdrží od běžícího softwarového systému. Pokud existuje velký rozdíl mezi metrikami získanými ze softwarového systému a neuronové sítě, můžeme dojít k závěru, že aktuální datový segment je anomální. Při použití neuronových sítí vzniká následující řada problémů:
- pro správnou funkci v režimu streamování musí data pro trénovací modely neuronové sítě obsahovat pouze „normální“ data;
- pro správnou detekci je nutné mít aktuální model. Měnící se trendy a sezónnost v metrikách mohou způsobit velké množství falešně pozitivních výsledků v modelu. Pro jeho aktualizaci je nutné jasně určit dobu, kdy je model zastaralý. Pokud aktualizujete model později nebo dříve, s největší pravděpodobností bude následovat velké množství falešných poplachů.
Nesmíme zapomínat ani na vyhledávání a prevenci častého výskytu falešných poplachů. Předpokládá se, že se budou nejčastěji vyskytovat v mimořádných situacích. Mohou však být také důsledkem chyby neuronové sítě v důsledku nedostatečného školení. Je nutné minimalizovat počet falešných poplachů modelu. V opačném případě ztratí falešné předpovědi spoustu času administrátora určeného ke kontrole systému. Dříve nebo později administrátor jednoduše přestane reagovat na „paranoidní“ monitorovací systém.
Rekurentní neuronová síť
Pro detekci anomálií v časových řadách můžete použít s pamětí LSTM. Jediným problémem je, že jej lze použít pouze pro prognózované časové řady. V našem případě nejsou všechny metriky předvídatelné. Pokus o aplikaci RNN LSTM na časovou řadu je znázorněn na obrázku 4.
Obrázek 4. Příklad rekurentní neuronové sítě s paměťovými buňkami LSTM
Jak je vidět z obrázku 4, RNN LSTM si v tomto časovém období dokázala poradit s hledáním anomálií. Pokud má výsledek vysokou chybu predikce (střední chyba), došlo ve skutečnosti k anomálii v indikátorech. Použití jediného RNN LSTM zjevně nebude stačit, protože je použitelné pro malý počet metrik. Lze použít jako pomocnou metodu pro vyhledávání anomálií.
Autokodér pro předpověď selhání
– v podstatě umělá neuronová síť. Vstupní vrstva je kodér, výstupní vrstva je dekodér. Nevýhodou všech neuronových sítí tohoto typu je, že špatně lokalizují anomálie. Byla zvolena architektura synchronního autokodéru.
Obrázek 5. Příklad činnosti autoenkodéru
Autokodéry jsou trénovány na normálních datech a pak najdou něco anomálního v datech přiváděných do modelu. Přesně to, co pro tento úkol potřebujete. Zbývá jen vybrat, který autokodér je pro tento úkol vhodný. Architektonicky nejjednodušší formou autokodéru je dopředná, nevratná neuronová síť, která je velmi podobná (multilayer perceptron, MLP), se vstupní vrstvou, výstupní vrstvou a jednou nebo více skrytými vrstvami, které je spojují.
Rozdíly mezi autokodéry a MLP jsou však v tom, že v autokodéru má výstupní vrstva stejný počet uzlů jako vstupní vrstva a že místo toho, aby byl trénován k predikci cílové hodnoty Y dané vstupem X, je autokodér trénován. rekonstruovat své vlastní X. Autokodéry jsou proto modely učení bez dozoru.
Úkolem autoenkodéru je najít časové indexy r0 ... rn odpovídající anomálním prvkům ve vstupním vektoru X. Tohoto efektu je dosaženo hledáním druhé mocniny chyby.
Obrázek 6. Synchronní autoenkodér
Pro autoencoder byl vybrán . Jeho výhody: možnost využití režimu zpracování streamingu a relativně menší počet parametrů neuronové sítě ve srovnání s jinými architekturami.
Mechanismus pro minimalizaci falešných poplachů
Vzhledem k tomu, že pro vyvíjený model detekce anomálií dochází k různým abnormálním situacím a také možné situaci nedostatečného trénování neuronové sítě, bylo rozhodnuto, že je nutné vyvinout mechanismus pro minimalizaci falešných poplachů. Tento mechanismus je založen na šabloně, kterou klasifikuje správce.
(DTW algoritmus, z anglického dynamic time warping) umožňuje najít optimální shodu mezi časovými sekvencemi. Poprvé použito při rozpoznávání řeči: používá se k určení, jak dva řečové signály reprezentují stejnou původní mluvenou frázi. Následně se pro něj našlo uplatnění v dalších oblastech.
Hlavním principem minimalizace falešných poplachů je sběr databáze standardů za pomoci operátora, který klasifikuje podezřelé případy zjištěné pomocí neuronových sítí. Dále je klasifikovaný standard porovnán s případem, který systém detekoval, a je učiněn závěr o tom, zda je případ nepravdivý nebo vede k selhání. Algoritmus DTW se používá přesně k porovnání dvou časových řad. Hlavním nástrojem minimalizace je stále klasifikace. Očekává se, že po nasbírání velkého množství referenčních případů se systém začne operátora ptát méně kvůli podobnosti většiny případů a výskytu podobných.
Výsledkem bylo, že na základě výše popsaných metod neuronové sítě byl sestaven experimentální program pro predikci selhání systému „Web-Consolidation“. Cílem tohoto programu bylo s využitím stávajícího archivu monitorovacích dat a informací o předchozích poruchách vyhodnotit způsobilost tohoto přístupu pro naše softwarové systémy. Schéma programu je uvedeno níže na obrázku 7.
Obrázek 7. Schéma predikce poruch založené na analýze metrického prostoru
V diagramu lze rozlišit dva hlavní bloky: hledání anomálních časových úseků v toku dat monitorování (metriky) a mechanismus pro minimalizaci falešných poplachů. Poznámka: Pro experimentální účely jsou data získávána přes JDBC spojení z databáze, do které je grafit uloží.
Následuje rozhraní monitorovacího systému získaného jako výsledek vývoje (obrázek 8).
Obrázek 8. Rozhraní experimentálního monitorovacího systému
Rozhraní zobrazuje procento anomálií na základě přijatých metrik. V našem případě je účtenka simulovaná. Všechna data již máme několik týdnů a postupně je načítáme, abychom prověřili případ anomálie vedoucí k selhání. Spodní stavový řádek zobrazuje celkové procento datových anomálií v daném čase, které je určeno pomocí automatického kodéru. Pro předpokládané metriky je také zobrazeno samostatné procento, které vypočítává RNN LSTM.
Příklad detekce anomálií na základě výkonu CPU pomocí neuronové sítě RNN LSTM (obrázek 9).
Obrázek 9. Objev RNN LSTM
Poměrně jednoduchý případ, v podstatě obyčejná odlehlá hodnota, která však vedla k selhání systému, byl úspěšně vypočten pomocí RNN LSTM. Ukazatel anomálie v tomto časovém období je 85–95 %, za anomálii se považuje vše nad 80 % (prahová hodnota byla stanovena experimentálně).
Příklad detekce anomálie, kdy se systém po aktualizaci nepodařilo spustit. Tuto situaci detekuje autokodér (obrázek 10).
Obrázek 10. Příklad detekce autoenkodéru
Jak můžete vidět z obrázku, PermGen se zasekl na jedné úrovni. Autokodéru to přišlo divné, protože nikdy předtím nic podobného neviděl. Zde anomálie zůstává 100%, dokud se systém nevrátí do funkčního stavu. Pro všechny metriky se zobrazí anomálie. Jak již bylo zmíněno dříve, autokodér nedokáže lokalizovat anomálie. K provedení této funkce je v těchto situacích vyzván operátor.
Závěr
PC "Web-Consolidation" se vyvíjí již několik let. Systém je v poměrně stabilním stavu a počet zaznamenaných incidentů je malý. Bylo však možné najít anomálie vedoucí k poruše 5 - 10 minut předtím, než k poruše došlo. V některých případech by oznámení o poruše předem pomohlo ušetřit plánovaný čas, který je vyhrazen pro provádění „opravných“ prací.
Na základě provedených experimentů je příliš brzy na konečné závěry. Zatím jsou výsledky rozporuplné. Na jednu stranu je jasné, že algoritmy založené na neuronových sítích jsou schopny najít „užitečné“ anomálie. Na druhou stranu zůstává velké procento falešně pozitivních výsledků a ne všechny anomálie detekované kvalifikovaným specialistou v neuronové síti lze odhalit. Mezi nevýhody patří fakt, že nyní neuronová síť vyžaduje pro běžný provoz školení s učitelem.
Pro další rozvoj systému predikce poruch a jeho uvedení do uspokojivého stavu lze předpokládat několik způsobů. Jedná se o podrobnější rozbor případů s anomáliemi, které vedou k selhání, díky tomuto přidání do seznamu důležitých metrik, které výrazně ovlivňují stav systému, a vyřazení nepotřebných, které jej neovlivňují. Také, pokud půjdeme tímto směrem, můžeme se pokusit specializovat algoritmy speciálně pro naše případy s anomáliemi, které vedou k selhání. Existuje i jiný způsob. Jedná se o vylepšení v architektuře neuronových sítí a tím o zvýšení přesnosti detekce se zkrácením doby trénování.
Vyjadřuji svou vděčnost svým kolegům, kteří mi pomohli napsat a udržet relevanci tohoto článku: a Sergej Finogenov.
Zdroj: www.habr.com