Industrijski razvoj programskih sistemov zahteva veliko pozornosti toleranci napak končnega izdelka ter hitremu odzivu na okvare in okvare, če do njih pride. Spremljanje seveda pripomore k učinkovitejšemu in hitrejšemu odzivanju na okvare in okvare, a ne dovolj. Prvič, zelo težko je slediti velikemu številu strežnikov - potrebno je veliko število ljudi. Drugič, dobro morate razumeti, kako aplikacija deluje, da lahko predvidite njeno stanje. Zato potrebujemo veliko ljudi, ki dobro razumejo sisteme, ki jih razvijamo, njihovo delovanje in funkcije. Predpostavimo, da tudi če najdete dovolj ljudi, ki so pripravljeni to storiti, še vedno potrebujete veliko časa, da jih usposobite.
Kaj storiti? Tu nam na pomoč priskoči umetna inteligenca. Članek bo govoril o (prediktivno vzdrževanje). Ta pristop aktivno pridobiva na priljubljenosti. Napisanih je bilo veliko število člankov, tudi na Habréju. Velika podjetja v celoti izkoriščajo ta pristop za ohranjanje zmogljivosti svojih strežnikov. Po preučitvi velikega števila člankov smo se odločili poskusiti ta pristop. Kaj je nastalo iz tega?
Predstavitev
Razvit programski sistem prej ali slej začne delovati. Za uporabnika je pomembno, da sistem deluje brez napak. Če pride do izrednega dogodka, ga je treba rešiti čim prej.
Za poenostavitev tehnične podpore programskega sistema, še posebej, če je strežnikov veliko, se običajno uporabljajo nadzorni programi, ki vzamejo meritve iz delujočega programskega sistema, omogočajo diagnosticiranje njegovega stanja in pomagajo ugotoviti, kaj točno je povzročilo okvaro. Ta proces se imenuje spremljanje programskega sistema.
Slika 1. Grafana nadzorni vmesnik
Metrike so različni indikatorji programskega sistema, njegovega izvajalnega okolja ali fizičnega računalnika, pod katerim se sistem izvaja, s časovnim žigom trenutka prejema metrike. V statični analizi se te metrike imenujejo časovne vrste. Za spremljanje stanja programskega sistema so metrike prikazane v obliki grafov: čas je na osi X, vrednosti pa vzdolž osi Y (slika 1). Več tisoč metrik je mogoče vzeti iz delujočega programskega sistema (iz vsakega vozlišča). Tvorijo prostor metrik (večdimenzionalnih časovnih vrst).
Ker se za kompleksne programske sisteme zbira veliko število meritev, postane ročno spremljanje težka naloga. Za zmanjšanje količine podatkov, ki jih analizira skrbnik, orodja za spremljanje vsebujejo orodja za samodejno prepoznavanje morebitnih težav. Na primer, lahko konfigurirate sprožilec, ki se sproži, ko prosti prostor na disku pade pod določeno mejno vrednost. Prav tako lahko samodejno diagnosticirate zaustavitev strežnika ali kritično upočasnitev hitrosti storitve. V praksi se orodja za spremljanje dobro znajdejo pri odkrivanju napak, ki so se že zgodile, ali prepoznavanju preprostih simptomov prihodnjih okvar, vendar je na splošno predvidevanje morebitne napake zanje še vedno trd oreh. Napovedovanje z ročno analizo metrik zahteva sodelovanje usposobljenih strokovnjakov. Je nizka produktivnost. Večina potencialnih napak lahko ostane neopažena.
V zadnjem času je tako imenovano prediktivno vzdrževanje programskih sistemov vse bolj priljubljeno med velikimi podjetji za razvoj IT programske opreme. Bistvo tega pristopa je z uporabo umetne inteligence najti težave, ki vodijo v degradacijo sistema, v zgodnjih fazah, preden ta odpove. Ta pristop ne izključuje popolnoma ročnega spremljanja sistema. Je pomožna pri procesu spremljanja kot celoti.
Glavno orodje za izvajanje prediktivnega vzdrževanja je naloga iskanja anomalij v časovnih serijah, saj ko pride do anomalije v podatkih obstaja velika verjetnost, da čez nekaj bo neuspeh ali neuspeh. Anomalija je določeno odstopanje v delovanju programskega sistema, kot je prepoznavanje poslabšanja hitrosti izvajanja ene vrste zahteve ali zmanjšanje povprečnega števila servisiranih zahtev pri stalni ravni odjemalskih sej.
Naloga iskanja nepravilnosti programskih sistemov ima svoje posebnosti. Teoretično je za vsak programski sistem potrebno razviti ali izpopolniti obstoječe metode, saj je iskanje anomalij zelo odvisno od podatkov, v katerih se izvaja, podatki programskih sistemov pa se zelo razlikujejo glede na orodja za implementacijo sistema. , vse do tega, na katerem računalniku se izvaja.
Metode iskanja anomalij pri napovedovanju okvar programskih sistemov
Najprej je treba povedati, da je ideja o napovedovanju neuspehov navdihnila članek . Za preizkus učinkovitosti pristopa s samodejnim iskanjem anomalij je bil izbran programski sistem Web-Consolidation, ki je eden od projektov podjetja NPO Krista. Prej se je zanj izvajalo ročno spremljanje na podlagi prejetih metrik. Ker je sistem precej zapleten, je zanj vzetih veliko število metrik: indikatorji JVM (obremenitev zbiralnika smeti), indikatorji operacijskega sistema, pod katerim se izvaja koda (virtualni pomnilnik, % obremenitve procesorja OS), indikatorji omrežja (obremenitev omrežja ), sam strežnik (obremenitev procesorja, pomnilnik), meritve divjih muh in lastne meritve aplikacije za vse kritične podsisteme.
Vse metrike so vzete iz sistema z uporabo grafita. Sprva je bila baza podatkov Whisper uporabljena kot standardna rešitev za grafano, toda ko se je baza strank povečala, graphite ni več zmogel, saj je izčrpal zmogljivost diskovnega podsistema DC. Po tem se je odločilo najti učinkovitejšo rešitev. Izbira je bila narejena za , kar je omogočilo zmanjšanje obremenitve diskovnega podsistema za red velikosti in zmanjšanje zasedenega prostora na disku za pet do šestkrat. Spodaj je diagram mehanizma za zbiranje metrik z uporabo graphite+clickhouse (slika 2).
Slika 2. Shema za zbiranje metrik
Diagram je povzet iz interne dokumentacije. Prikazuje komunikacijo med grafano (uporabniškim vmesnikom za spremljanje, ki ga uporabljamo) in grafitom. Odstranjevanje meritev iz aplikacije poteka z ločeno programsko opremo – . Postavi jih v grafit.
Sistem spletne konsolidacije ima številne funkcije, ki povzročajo težave pri napovedovanju napak:
- Trend se pogosto spreminja. Za ta programski sistem so na voljo različne različice. Vsak od njih prinaša spremembe v programskem delu sistema. Skladno s tem razvijalci na ta način neposredno vplivajo na metriko danega sistema in lahko povzročijo spremembo trenda;
- implementacijska značilnost, kot tudi nameni, za katere odjemalci uporabljajo ta sistem, pogosto povzročijo anomalije brez predhodne degradacije;
- odstotek anomalij glede na celoten niz podatkov je majhen (< 5 %);
- Pri prejemanju indikatorjev iz sistema lahko pride do vrzeli. V nekaterih kratkih časovnih obdobjih nadzorni sistem ne uspe pridobiti meritev. Na primer, če je strežnik preobremenjen. To je ključnega pomena za usposabljanje nevronske mreže. Vrzeli je treba sintetično zapolniti;
- Primeri z anomalijami so pogosto pomembni samo za določen datum/mesec/čas (sezonskost). Ta sistem ima jasna pravila za uporabo s strani uporabnikov. V skladu s tem so meritve pomembne samo za določen čas. Sistema ni mogoče stalno uporabljati, ampak samo v nekaterih mesecih: selektivno glede na leto. Pojavijo se situacije, ko lahko enako obnašanje metrik v enem primeru povzroči okvaro programskega sistema, v drugem pa ne.
Za začetek smo analizirali metode za odkrivanje nepravilnosti v podatkih spremljanja programskih sistemov. V člankih na to temo, ko je odstotek anomalij majhen glede na preostali nabor podatkov, se najpogosteje predlaga uporaba nevronskih mrež.
Osnovna logika za iskanje anomalij z uporabo podatkov nevronske mreže je prikazana na sliki 3:
Slika 3. Iskanje anomalij z nevronsko mrežo
Na podlagi rezultata napovedi ali obnovitve okna trenutnega toka metrike se izračuna odstopanje od prejetega od delujočega programskega sistema. Če obstaja velika razlika med meritvami, pridobljenimi iz programskega sistema in nevronske mreže, lahko sklepamo, da je trenutni podatkovni segment nepravilen. Pri uporabi nevronskih mrež se pojavljajo naslednje težave:
- za pravilno delovanje v pretočnem načinu morajo podatki za usposabljanje modelov nevronskih mrež vključevati le »normalne« podatke;
- za pravilno detekcijo je potrebno imeti posodobljen model. Spreminjajoči se trendi in sezonskost v meritvah lahko povzročijo veliko število lažno pozitivnih rezultatov v modelu. Če ga želite posodobiti, je treba jasno določiti čas, ko je model zastarel. Če posodobite model pozneje ali prej, bo najverjetneje sledilo veliko število lažnih pozitivnih rezultatov.
Prav tako ne smemo pozabiti na iskanje in preprečevanje pogostega pojavljanja lažno pozitivnih rezultatov. Predvideva se, da se najpogosteje pojavljajo v izrednih razmerah. Lahko pa so tudi posledica napake nevronske mreže zaradi nezadostne usposobljenosti. Potrebno je čim bolj zmanjšati število lažno pozitivnih rezultatov modela. V nasprotnem primeru bodo napačne napovedi izgubile veliko skrbniškega časa, namenjenega preverjanju sistema. Prej ali slej se bo skrbnik preprosto nehal odzivati na "paranoičen" nadzorni sistem.
Ponavljajoča se nevronska mreža
Za odkrivanje anomalij v časovnih serijah lahko uporabite s pomnilnikom LSTM. Edina težava je, da se lahko uporablja samo za napovedane časovne vrste. V našem primeru vse metrike niso predvidljive. Poskus uporabe RNN LSTM za časovno vrsto je prikazan na sliki 4.
Slika 4. Primer ponavljajoče se nevronske mreže s spominskimi celicami LSTM
Kot je razvidno iz slike 4, je bil RNN LSTM kos iskanju anomalij v tem časovnem obdobju. Če ima rezultat visoko napovedno napako (povprečna napaka), je dejansko prišlo do anomalije v indikatorjih. Uporaba enega samega RNN LSTM očitno ne bo dovolj, saj je uporaben za majhno število metrik. Lahko se uporablja kot pomožna metoda pri iskanju nepravilnosti.
Avtokodirnik za napovedovanje napak
– v bistvu umetna nevronska mreža. Vhodna plast je kodirnik, izhodna plast je dekoder. Pomanjkljivost vseh tovrstnih nevronskih mrež je, da slabo lokalizirajo anomalije. Izbrana je bila arhitektura sinhronega samodejnega kodirnika.
Slika 5. Primer delovanja avtoenkoderja
Samodejni kodirniki se učijo na običajnih podatkih, nato pa najdejo nekaj nenormalnega v podatkih, ki so dovedeni v model. Ravno to, kar potrebujete za to nalogo. Ostaja le še izbrati, kateri samodejni kodirnik je primeren za to nalogo. Arhitekturno najenostavnejša oblika samodejnega kodirnika je nevronska mreža, ki se ne vrača naprej in je zelo podobna (večplastni perceptron, MLP), z vhodno plastjo, izhodno plastjo in eno ali več skritimi plastmi, ki ju povezujejo.
Vendar pa so razlike med samodejnimi kodirniki in MLP-ji v tem, da ima v samodejnem kodirniku izhodna plast enako število vozlišč kot vhodna plast in da je namesto da bi bil usposobljen za napovedovanje ciljne vrednosti Y, podane z vhodom X, samodejni kodirnik usposobljen rekonstruirati lastne X-je. Zato so samodejni kodirniki modeli učenja brez nadzora.
Naloga avtokodirnika je najti časovne indekse r0 ... rn, ki ustrezajo nepravilnim elementom v vhodnem vektorju X. Ta učinek se doseže z iskanjem kvadratne napake.
Slika 6. Sinhroni samodejni kodirnik
Za samodejni kodirnik je bil izbran . Njegove prednosti: možnost uporabe pretočnega načina obdelave in relativno manjše število parametrov nevronske mreže v primerjavi z drugimi arhitekturami.
Mehanizem za zmanjšanje lažnih pozitivnih rezultatov
Zaradi dejstva, da se pojavljajo različne nenormalne situacije, kot tudi možna situacija nezadostne usposobljenosti nevronske mreže, je bilo za model zaznavanja anomalij v razvoju odločeno, da je treba razviti mehanizem za zmanjšanje lažnih pozitivnih rezultatov. Ta mehanizem temelji na osnovi predloge, ki jo razvrsti skrbnik.
(DTW algoritem, iz angleškega dinamičnega časovnega ukrivljanja) vam omogoča, da najdete optimalno ujemanje med časovnimi zaporedji. Prvič uporabljen pri prepoznavanju govora: uporablja se za ugotavljanje, kako dva govorna signala predstavljata isto izvirno izgovorjeno frazo. Kasneje se je zanjo našla uporaba na drugih področjih.
Glavno načelo zmanjševanja lažnih pozitivnih rezultatov je zbiranje podatkovne baze standardov s pomočjo operaterja, ki razvršča sumljive primere, zaznane z nevronskimi mrežami. Nato se klasificirani standard primerja s primerom, ki ga je zaznal sistem, in se sklepa, ali je primer napačen ali vodi do napake. Algoritem DTW se uporablja ravno za primerjavo dveh časovnih vrst. Glavno orodje za minimizacijo je še vedno klasifikacija. Pričakovati je, da bo sistem po zbiranju velikega števila referenčnih primerov operaterja začel manj spraševati zaradi podobnosti večine primerov in pojavljanja podobnih.
Posledično je bil na podlagi zgoraj opisanih metod nevronske mreže zgrajen eksperimentalni program za napovedovanje napak sistema »Web-Consolidation«. Cilj tega programa je bil z uporabo obstoječega arhiva nadzornih podatkov in informacij o prejšnjih okvarah oceniti ustreznost tega pristopa za naše programske sisteme. Shema programa je predstavljena spodaj na sliki 7.
Slika 7. Shema napovedovanja napak na podlagi analize metričnega prostora
V diagramu lahko ločimo dva glavna bloka: iskanje nenormalnih časovnih obdobij v toku spremljanja podatkov (metrike) in mehanizem za zmanjšanje lažnih pozitivnih rezultatov. Opomba: Za eksperimentalne namene se podatki pridobivajo preko povezave JDBC iz baze podatkov, v katero jih bo grafit shranil.
Sledi vmesnik nadzornega sistema, ki je bil pridobljen kot rezultat razvoja (slika 8).
Slika 8. Vmesnik eksperimentalnega nadzornega sistema
Vmesnik prikaže odstotek anomalije na podlagi prejetih meritev. V našem primeru je prejem simuliran. Imamo že vse podatke za več tednov in jih postopoma nalagamo, da preverimo primer anomalije, ki vodi do okvare. Spodnja vrstica stanja prikazuje skupni odstotek podatkovne anomalije v določenem času, ki se določi s samodejnim kodirnikom. Poleg tega je prikazan ločen odstotek za predvideno metriko, ki ga izračuna RNN LSTM.
Primer odkrivanja nepravilnosti na podlagi zmogljivosti procesorja z uporabo nevronske mreže RNN LSTM (slika 9).
Slika 9. Odkritje RNN LSTM
Precej preprost primer, v bistvu navaden izstop, ki pa vodi do okvare sistema, je bil uspešno izračunan z uporabo RNN LSTM. Indikator anomalije v tem obdobju je 85-95%, vse nad 80% (prag je bil določen eksperimentalno) se šteje za anomalijo.
Primer zaznave anomalije, ko se sistem po posodobitvi ni mogel zagnati. To situacijo zazna samodejni kodirnik (slika 10).
Slika 10. Primer zaznave samodejnega kodirnika
Kot lahko vidite na sliki, je PermGen obtičal na eni ravni. Samodejnemu kodirniku se je to zdelo čudno, ker česa podobnega še ni videl. Tu ostane anomalija 100 %, dokler se sistem ne vrne v delovno stanje. Za vse meritve je prikazana anomalija. Kot smo že omenili, samodejni kodirnik ne more lokalizirati nepravilnosti. Operater mora v teh situacijah opraviti to funkcijo.
Zaključek
PC "Web-Consolidation" je bil v razvoju že nekaj let. Sistem je v dokaj stabilnem stanju, število zabeleženih incidentov pa je majhno. Vendar pa je bilo mogoče odkriti nepravilnosti, ki vodijo do okvare, 5 do 10 minut preden je prišlo do okvare. V nekaterih primerih bi vnaprejšnje obvestilo o okvari pomagalo prihraniti načrtovani čas, ki je dodeljen za izvedbo "popravil".
Na podlagi izvedenih poskusov je prezgodaj za končne zaključke. Zaenkrat so si rezultati nasprotujoči. Po eni strani je jasno, da so algoritmi, ki temeljijo na nevronskih mrežah, sposobni najti »uporabne« anomalije. Po drugi strani pa ostaja velik odstotek lažno pozitivnih rezultatov in vseh nepravilnosti, ki jih odkrije usposobljen specialist v nevronski mreži, ni mogoče odkriti. Slabosti vključujejo dejstvo, da zdaj nevronska mreža zahteva usposabljanje z učiteljem za normalno delovanje.
Za nadaljnji razvoj sistema za napovedovanje napak in njegovo spravljanje v zadovoljivo stanje je mogoče predvideti več načinov. Gre za podrobnejšo analizo primerov z anomalijami, ki vodijo v odpoved, zaradi dodajanja seznama pomembnih metrik, ki močno vplivajo na stanje sistema, in zavrženja nepotrebnih, ki nanj ne vplivajo. Tudi, če gremo v to smer, lahko poskusimo specializirati algoritme posebej za naše primere z anomalijami, ki vodijo do napak. Obstaja še en način. To je izboljšava v arhitekturi nevronske mreže in s tem večja natančnost zaznavanja s skrajšanjem časa usposabljanja.
Zahvaljujem se svojim sodelavcem, ki so mi pomagali napisati in ohraniti relevantnost tega članka: in Sergej Finogenov.
Vir: www.habr.com