Otsime anomaaliaid ja ennustame tõrkeid tehisintellekti abil

Tööstuslike tarkvara arendamine nõuab suurt tähelepanu lõpp-produkti töökindlusele ning kiiret reageerimist, kui tõrkeid ja ebaõnnestumisi ikka juhtub. Jälgimine aitab loomulikult tõrgete ja ebaõnnestumistele efektiivsemalt ja kiiremini reageerida, kuid see ei ole piisav. Esiteks on väga keeruline hallata suurt hulka servereid – selleks on vaja palju inimesi. Teiseks tuleb hästi mõista, kuidas rakendus töötab, et prognoosida selle seisundit. Seega on vaja palju inimesi, kes mõistavad põhjalikult meie arendatavaid süsteeme, nende näitajaid ja eripärasid. Eeldame, et isegi kui leida piisavalt inimesi, kes on valmis sellega tegelema, kulub nende koolitamiseks samuti märkimisväärselt aega.

Mida siis teha? Siin tuleb meile appi tehisintellekt. Artiklis on jutt ennustuslikust hooldusest (predictive maintenance). See lähenemine on aktiivselt populaarsust kogumas. On kirjutatud mitmeid artikleid, sealhulgas ka Habrile. Suured ettevõtted kasutavad seda lähenemist juba täie hooga oma serverite töökindluse tagamiseks. Pärast paljude artiklite uurimist otsustasime proovida seda lähenemist rakendada. Mis sellest välja tuli?

Sissejuhatus

Arendatud tarkvarasüsteem jõuab varem või hiljem kasutusse. Kasutajale on oluline, et süsteem töötaks tõrgeteta. Kui siiski juhtub äärmuslik olukord, peab see olema kõrvaldatud minimaalsete viivitustega.

Tehnilise toe lihtsustamiseks tarkvarasüsteemis, eriti kui servereid on palju, kasutatakse tavaliselt jälgimisprogramme, mis koguvad andmeid töölt olevast tarkvarasüsteemist, võimaldavad diagnoosida selle seisundit ja aitavad määrata, mis tõrkeid põhjustas. Seda protsessi nimetatakse tarkvarasüsteemi jälgimiseks.

Joonis 1. Jälgimise liides Grafanas

Mõõdikud on erinevad näitajad tarkvarasüsteemi, selle töötamise keskkonna või füüsilise arvutimasina kohta, mille all süsteem on, koos ajatempli hetkega, mil mõõdikud saadi. Statistilises analüüsis nimetatakse mõõdikute andmeid ajas tehtud ridadeks. Tarkvarasüsteemi oleku jälgimiseks kuvatakse mõõdikud graafikutena: X- telg – aeg ja Y-telg – väärtused (joonis 1). Töötavas tarkvarasüsteemis saab võtta mitut tuhat mõõdikut (igal sõlmel). Need moodustavad mõõdikute ruumi (mitmemõõtmelised ajas tehtud read).

Kuna keeruliste tarkvarasüsteemide korral kogutakse suuri mõõdikute koguseid, muutub käsitsi jälgimine keeruliseks ülesandeks. Juhtimise andmete hulga vähendamiseks sisaldavad jälgimisvahendid automatisatsiooni tööriistu, mis aitavad tuvastada võimalikke probleeme. Näiteks saab seadistada päästiku, mis aktiveerub, kui vaba kõvakettaruumi hulk langeb alla määratud lävendi. Samuti saab automaatselt diagnoosida serveri seiskumist või teenindamise kiiruse kriitilist aeglustumist. Praktikas suudavad jälgimisvahendid hästi tuvastada juba toimunud väärasid või lihtsaid sümptomeid tulevastest väljasuremistest, kuid kokkuvõttes jääb võimalikud rikete ennustamine neile keeruliseks pähkliks. Ennustamine käsitsi analüüsides mõõdikuid nõuab kvalifitseeritud spetsialistide kaasamist. See on madala tootlikkusega. Enamik võimalikke riketeid võivad jääda märkamatuks.

Viimasel ajal on suurte IT-ettevõtete seas tarkvaraarenduse hullus kasvanud nn ennustava hoolduse populaarsus. Selle lähenemise tuum seisneb tõrgete leidmises, mis viivad süsteemi degradeerumiseni varases faasis, enne rikke teket tehisintellekti kasutades. See lähenemine ei välista täielikult käsitsi süsteemi jälgimist. See on abistav jälgimisprotsessis laiemalt.

Peamine tööriist ennustava hoolduse rakendamiseks on anomaaliate otsimise ülesanne ajas tehtud ridades, kuna anomaalia ilmnemisel andmetes on suur tõenäosus, et mõne aja pärast võib tekkida tõrge või rike. Anomaalia on mingi programmeerimissüsteemi näitaja kõrvalekalle, näiteks ühe tüübi päringu töötlemise aegade halvenemine või keskmise teenindatavate päringute arvu vähenemine pideva kliendiseansside taseme juures.

Anomaaliate otsimise ülesanne programmeerimissüsteemides omab oma eripära. Idee kohaselt on iga programmeerimissüsteemi jaoks vajalik olemasolevate meetodite väljatöötamine või kohandamine, kuna anomaaliate otsimine sõltub väga andmetest, milles see toimub, ja programmeerimissüsteemide andmed erinevad oluliselt sõltuvalt süsteemi teostamisest, sealhulgas sellest, millisel arvutimasinal see töötab.

Anomaaliate otsimise meetodid programmeerimissüsteemide riketegude prognoosimiseks

Esiteks on oluline välja tuua, et riketegude prognoosimise idee sai inspiratsiooni artiklist «Masinõpe IT-monitooringus». Juhul, kui automaatsete anomaaliate otsimise lähenemise tõhusust kontrolliti, valiti programmeerimissüsteemiks „Web-Konsolideerimine”, mis on üks NPO „Krista” projektidest. Selle jaoks tehti varem käsitsi monitooring saadud näitajate põhjal. Kuna süsteem on piisavalt keeruline, jälgitakse selle jaoks suurt hulka näitajaid: JVM-i näitajad (prügikogujate koormus), operatsioonisüsteemi näitajad, mille all kood töötab (virtuaalne mälu, CPU koormuse %), võrgu näitajad (võrgu koormus), serveri näitajad (CPU, mälu koormus), wildfly näitajad ja rakenduse enda näitajad kõikide kriitiliste alamsüsteemide põhjal.

Kõik näitajad kogutakse süsteemist graphite abil. Alguses kasutati whisper andmebaasi standardlahendusena grafana jaoks, kuid klientide arvu kasvades ei suutnud graphite enam koormust taluda, ammendades andmekeskuse kettaaluste läbilaskevõime. Pärast seda tehti otsus otsida tõhusamat lahendust. Valik langes graphite+clickhouse, mis võimaldas oluliselt vähendada koormust kettaalustele ja vähendada ühe kuni kuue korra ketta mahtu. Allpool on esitatud skeem metrikate kogumise mehhanismist graphite+clickhouse abil (joonis 2).

Joonis 2. Metrikate kogumise skeem

Skeem on saadud sisejuhendist. Sellel on kujutatud andmevahetust grafana (kasutajaliides jälgimiseks, mida me kasutame) ja graphite'i vahel. Rakendusest mõõtmete võtmiseks kasutatakse eraldi tarkvara – jmxtrans. See samuti salvestab need graphite'i.
Veebikonsolideerimise süsteemil on mitmeid omadusi, mis tekitavad probleemide ennustamisel:

1. trendide vahetamine toimub sageli. Sellel tarkvarasüsteemil ilmuvad erinevad versioonid. Igas neist on muudatused süsteemi programmitasandil. Seega mõjutavad arendajad otse selle süsteemi mõõtmeid ja võivad põhjustada trendide muutumist;
2. rakenduse eripära, samuti süsteemi klientide kasutusmotiivid toovad sageli esile anomaaliaid ilma eelneva degradatsioonita;
3. anomaaliate osakaal kogu andmekogus on väike (< 5%);
4. kõige mõõtmete saamisel võib esineda katkestusi. Mõnel lühikesel ajaperioodil ei suuda jälgimissüsteem mõõtmeid hankida. Näiteks, kui server on üle koormatud. Kuidas see mõjutab närvivõrku, on kriitiline. Tekkib vajadus täita lünki sünteesiliselt;
5. Anomaaliad on sageli olulised ainult konkreetse arvu/kuid/aja jaoks (hooaegsus). Sellel süsteemil on selged reeglid kasutamiseks. Seega on mõõdud актуальны только конкретному времени. Süsteemi võib kasutada mitte pidevalt, vaid ainult teatud kuudel: valikuliselt sõltuvalt aastast. Tekkivad olukorrad, kus sama mõõtmete käitumine ühes olukorras võib põhjustada tarkvarasüsteemi tõrke, samas kui teises see ei pruugi;
   Alustuseks analüüsiti meetodeid anomaalide avastamiseks tarkvarasüsteemide jälgimisandmetes. Seda teemat käsitlevates artiklites, kui anomaaliate osakaal on väike, on sageli soovitatud kasutada närvivõrke.

Peamine loogika anomaaliate leidmiseks närvivõrkude abil on kujutatud joonisel 3:

Joonis 3. Anomaaliate leidmine närvivõrgu abil

Prognoosi või hetkevoo metrikate taastamise tulemuses arvutatakse kõrvalekalle saadud andmetest aktiivse tarkvarasüsteemi puhul. Suure erinevuse korral saadud metrikate ja närvivõrgu vahel võib järeldada, et käesolev andmeosa on ebanormaalne. Tekivad järgmised probleemid närvivõrkude kasutamisel:

1. korrektseks tööks voogesituse režiimis peavad närvivõrkude mudelite koolitamiseks kasutatavad andmed sisaldama vaid "normaalseid" andmeid;
2. peab olema olemas ajakohane mudel korrektseks avastamiseks. Suundumuse ja hooajalisuse muutmine metrikates võib põhjustada palju valehäireid mudelis. Selle värskendamiseks on vajalik selgelt määratleda aeg, millal mudel muutub aegunuks. Kui mudel uuendatakse liiga vara või liiga hilja, siis on tõenäoliselt tagajärjeks suur hulk valehäireid.
   Samuti ei tohi unustada valehäirete sagedase esinemise otsimist ja ennetamist. Eeldatakse, et need esinevad kõige sagedamini avariiliste olukordade korral. Kuid need võivad olla ka närvivõrgu vea tagajärg selle ebapiisava koolituse tõttu. On oluline vähendada mudeli valehäirete arvu. Vastasel juhul kulutavad valeprognoosid palju administraatori aega süsteemi kontrollimiseks. Varem või hiljem jõuab see sinnamaale, et administraator lõpetab lihtsalt "paranoilise" jälgimissüsteemi jälgimise.

Rekurentsne närvivõrk

Ajavahemike anomaaliate avastamiseks võib kasutada rekurentsset närvivõrku LSTM mäluga. Probleem on vaid selles, et seda saab kasutada ainult prognoositavate ajavahemike puhul. Meie juhul ei ole kõik metrikad prognoositavad. Katse kasutada RNN LSTM-i ajavahemiku jaoks on esitatud joonisel 4.

Joonis 4. Näide rekurentsse närvivõrgust LSTM mäluelementidega

Nagu jooniselt 4 nähtub, suutis RNN LSTM tuvastada anomaalia selle ajavahemiku jooksul. Seal, kus tulemuste prognoosimisviga (keskmine viga) on kõrge, toimus tõeliselt anomaalia. Ühe RNN LSTM kasutamine on selgelt ebapiisav, kuna see sobib ainult väikese arvu mõõdikute rakendamiseks. Anomaaliate tuvastamiseks võib kasutada kõrvalmeetodina.

Autokooder riketega prognoosimiseks

Autokooder – sisuliselt tehisneurovõrk. Sissevoolu kiht – kodeerija, väljundkiht – dekodeerija. Kõikide antud tüüpi närvivõrkude puuduseks on halvasti lokaliseeritud anomaaliad. Valiti sünkroonse autokooderi arhitektuur.

Joonis 5. Autokooderi töö näide

Autokooderid koolitatakse normaaldatasetel ja seejärel tuvastavad nad mudelile sisendatud andmeväli anomaaliad. Just see, mida antud ülesanne vajab. Peab ainult valima, milline autokooder sobib antud ülesande jaoks. Arhitektiilis kõige lihtsam autokooder on sirge, tagasipöördumatud närvivõrk, mis on väga sarnane multikiht-perceptroniga (multilayer perceptron, MLP), millel on sisendkiht, väljundkiht ja üks või mitu peidetud kihti, mis neid ühendavad.
Kuid erinevused autokooderite ja MLP vahel seisnevad selles, et autokooderi väljundkiht sisaldab sama palju sõlmi kui sisendkiht ning et autokooder õpib rekonstrueerima oma X väärtusi, mitte prognoosima sihtväärtust Y, mis on määratud sisendi X järgi. Seega on autokooderid mittetäieliku juhendamisega õppe mudelid.

Autokooderi ülesanne on leida ajaliselt indekseid r0 ... rn, mis vastavad anomaalsetele elementidele sisendvektoris X. See efekt saavutatakse kvadratuurse vea otsimise kaudu.

Joonis 6. Sünkroonne autokooder

Autokooderi jaoks valiti sünkroonne arhitektuur. Selle eelised: voogude töötlemise režiimi kasutamise võimalus ning võrreldes teiste arhitektuuridega on närvivõrgu parameetreid märgatavalt vähem.

Valehäirete minimeerimise mehhanism

Seoses erinevate erandlike olukordade esinemise ja tehisintellekti koolituse võimalikest puudustest, on välja töötatavatele anomaaliate avastamise mudelitele otsustatud luua valehäirete minimeerimise mehhanism. See mehhanism põhineb administraatori klassifitseeritud mallide andmebaasil.

Dünaamilise ajaskaalatansformatsiooni algoritm (DTW-algoritm, inglise keeles dynamic time warping) võimaldab leida optimaalse vaste ajajärjendite vahel. Esmakordselt rakendati seda kõnetuvastuses, et määrata, kuidas kaks kõnesignaalivid esindavad sama algset hääldatud fraasi. Hiljem leiti selle jaoks rakendusi ka teistes valdkondades.

Valehäirete minimeerimise põhialus on referentside kogumine operaatori abil, kes klassifitseerib kahtlased juhtumid, mis on tuvastatud närvivõrkude abil. Seejärel võrreldakse klassifitseeritud referentsi juhtumiga, mille süsteem avastas, ning tehakse järeldus, kas juhtum on valehäire või tõrke põhjustaja. Just kahe ajajärgu võrdlemiseks kasutatakse DTW algoritmi. Peamine tööriist valehäirete minimeerimiseks on siiski klassifitseerimine. Eeldatakse, et pärast suure hulga referentsjuhtumite kogumist hakkab süsteem operaatorilt vähem küsima, kuna enamik juhtumeid on sarnased ja esinevad sarnased.

Tulemusena, tuginedes ülaltoodud närvivõrkude meetoditele, on loodud eksperimentaalne programm „Web-Konsolideerimine” süsteemi tõrgete prognoosimiseks. Selle programmi eesmärk oli kasutada olemasolevat jälgimisandmete arhiivi ja juba toimunud tõrgete teavet, et hinnata selle lähenemise sobivust meie tarkvarasüsteemide jaoks. Programa töö skeem on esitatud allpool, joonisel 7.

Joonis 7. Tõrgete prognoosimise skeem metrikate ruumi analüüsi põhjal

Skeemil võib eristada kahte põhiblokki: anomaliseeritud ajavahemike otsimine jälgimisandmete (metrikate) voos ja valehäirete minimeerimise mehhanism. Märkus: eksperimentaalsetes eesmärkides saadakse andmed JDBC-ühenduse kaudu andmebaasist, kuhu need salvestatakse graphite.
Allpool on esitatud arendatud monitooringusüsteemi liides (joonis 8).

Joonis 8. Eksperimentaalse monitooringusüsteemi liides

Liideses kuvatakse saadud meetmete anomaalsuse protsent. Meie puhul simuleeritakse saadud andmeid. Meil on juba olemas andmed mitme nädala jooksul ja laadime need järk-järgult, et kontrollida juhtumit, millega kaasneb rike. Alumises staatusteenuses kuvatakse andmete üldine anomaalsuse protsent antud ajahetkel, mis määratakse automaatkooderija abil. Samuti kuvatakse prognoositavate meetmete jaoks eraldi protsent, mida arvutab RNN LSTM.

Näide CPU näitajate anomaalsuse tuvastamisest RNN LSTM närvivõrgu abil (joonis 9).

Joonis 9. RNN LSTM tuvastamine

Suhteliselt lihtne juhtum, põhimõtteliselt tavaline väljajätmine, kuid süsteemi rikke põhjustav, tuvastati edukalt RNN LSTM abil. Anomaalsuse näitaja sel ajal oli 85 – 95%, kõik, mis ületab 80% (lävi määratleti eksperimentaalselt), loetakse anomaaliaks.
Näide anomaalsuse tuvastamisest, kui süsteem ei suutnud pärast värskendust käivituda. Antud olukorra tuvastab automaatkooderija (joonis 10).

Joonis 10. Näide automaatkooderija tuvastamisest

Nagu jooniselt näha, jäi PermGen ühele tasemele. Automaatkooderija pidas seda kummaliseks, kuna ta ei olnud varem midagi sarnast näinud. Siin hoiab anomaalsus 100% kuni süsteemi töövõime taastumiseni. Anomaalsus kuvatakse kõikide meetmete puhul. Nagu mainitud, ei oska automaatkooderija anomaaliat lokaliseerida. Operaatoreid ootab see funktsioon antud olukordades.

Kokkuvõte

PC "Web-Konsolideerimine" on arendatud mitte esimest aastat. Süsteem on piisavalt stabiilses seisundis ja registreeritavate intsidentide arv on väike. Siiski on õnnestunud tuvastada anomaaliad, mis viivad rikkeni 5 – 10 minutit enne rikke tekkimist. Mitmetel juhtudel aitaks rikkehoiatus aegsasti kokku hoida regulatiivset aega, mis on eraldatud "remonditööde" tegemiseks.

Käteval põhinevad katsed on näidanud, et lõplikke järeldusi on veel vara teha. Praegused tulemused on vastuolulised. Ühelt poolt on näha, et närvivõrgupõhised algoritmid suudavad tuvastada "kasulikke" anomaaliaid. Teiselt poolt jääb suur osa valehäireid ja kõik anomaaliad, mille kvalifitseeritud spetsialist tuvastab, ei pruugi närvivõrk suuta avastada. Negatiivseks küljeks on samuti see, et praegu vajab närvivõrk normaalseks toimimiseks õpetajaga õpetamist.

Süsteemi rikkeennustuse edasiseks arendamiseks ja selle viimiseks rahuldavale tasemele on võimalik kaaluda mitmeid teid. Need hõlmavad üksikasjalikumat analüüsi anomaaliatest, mis põhjustavad rikkeid, muutes oluliseks metrikate loetelu, mis tugevalt mõjutavad süsteemi seisundit, ning kõrvaldades need, mis ei mõjuta seda. Kui liikuda sellel teel edasi, võiks proovida spetsialiseerida algoritme just meie anomaaliate juhtumitele, mis põhjustavad rikkeid. On ka teine tee. See on närvivõrkude arhitektuuride täiustamine ja seeläbi avastuste täpsuse tõstmine, vähendades samal ajal õpikestuse aega.

Tänan kolleege, kes aitasid mul selle artikli kirjutamisel ja ajakohasena hoidmisel: Viktor Verbitski ja Sergei Finogenov.

Allikas: habr.com