Industrijski razvoj softverskih sustava zahtijeva veliku pozornost na toleranciju na pogreške finalnog proizvoda, kao i brzu reakciju na kvarove i kvarove ako do njih dođe. Praćenje, naravno, pomaže učinkovitijem i bržem odgovoru na kvarove i kvarove, ali nedovoljno. Prvo, vrlo je teško pratiti veliki broj poslužitelja - potreban je veliki broj ljudi. Drugo, morate dobro razumjeti kako aplikacija radi kako biste predvidjeli njezino stanje. Stoga nam treba puno ljudi koji dobro razumiju sustave koje razvijamo, njihovu izvedbu i značajke. Pretpostavimo da čak i ako nađete dovoljno ljudi voljnih za ovo, još uvijek treba puno vremena da ih obučite.
Što uraditi? Tu nam u pomoć priskače umjetna inteligencija. U članku će se govoriti o (prediktivno održavanje). Ovaj pristup aktivno dobiva na popularnosti. Napisan je velik broj članaka, uključujući i na Habréu. Velike tvrtke u potpunosti koriste ovaj pristup za održavanje performansi svojih poslužitelja. Nakon proučavanja velikog broja članaka, odlučili smo isprobati ovaj pristup. Što je iz toga proizašlo?
Uvod
Razvijeni softverski sustav prije ili kasnije ulazi u rad. Za korisnika je važno da sustav radi bez kvarova. Ako se dogodi hitan slučaj, treba ga riješiti uz minimalno odgađanje.
Kako bi se pojednostavila tehnička podrška softverskog sustava, posebno ako postoji mnogo poslužitelja, obično se koriste programi za nadzor koji uzimaju metriku iz pokrenutog softverskog sustava, omogućuju dijagnosticiranje njegovog stanja i pomažu u određivanju što je točno uzrokovalo kvar. Taj se proces naziva nadzor softverskog sustava.
Slika 1. Grafana sučelje za nadzor
Metrike su različiti pokazatelji softverskog sustava, njegove izvršne okoline ili fizičkog računala pod kojim se sustav izvodi s vremenskom oznakom trenutka kada su metrike primljene. U statičkoj analizi te se metrike nazivaju vremenske serije. Za praćenje stanja softverskog sustava metrike se prikazuju u obliku grafikona: vrijeme je na X osi, a vrijednosti duž Y osi (Slika 1). Nekoliko tisuća metrika može se uzeti iz pokrenutog softverskog sustava (iz svakog čvora). Oni tvore prostor metrike (višedimenzionalne vremenske serije).
Budući da se prikuplja velik broj metrika za složene softverske sustave, ručno praćenje postaje težak zadatak. Kako bi se smanjila količina podataka koje analizira administrator, alati za nadzor sadrže alate za automatsko prepoznavanje mogućih problema. Na primjer, možete konfigurirati aktiviranje okidača kada slobodni prostor na disku padne ispod određenog praga. Također možete automatski dijagnosticirati gašenje poslužitelja ili kritično usporavanje brzine usluge. U praksi, alati za praćenje rade dobar posao otkrivanja kvarova koji su se već dogodili ili identificiranja jednostavnih simptoma budućih kvarova, ali općenito, predviđanje mogućeg kvara za njih ostaje tvrd orah. Predviđanje putem ručne analize metrike zahtijeva uključivanje kvalificiranih stručnjaka. Niska je produktivnost. Većina potencijalnih kvarova može proći nezapaženo.
Nedavno je među velikim tvrtkama za razvoj IT softvera sve popularnije takozvano prediktivno održavanje softverskih sustava. Bit ovog pristupa je pomoću umjetne inteligencije pronaći probleme koji dovode do degradacije sustava u ranim fazama, prije nego on otkaže. Ovaj pristup ne isključuje u potpunosti ručno praćenje sustava. To je pomoćni proces praćenja u cjelini.
Glavni alat za provedbu prediktivnog održavanja je zadatak traženja anomalija u vremenskim serijama, jer kada se dogodi anomalija u podacima postoji velika vjerojatnost da će nakon nekog vremena doći će do neuspjeha ili neuspjeha. Anomalija je određeno odstupanje u performansama softverskog sustava, kao što je identificiranje degradacije u brzini izvršenja jedne vrste zahtjeva ili smanjenje prosječnog broja servisiranih zahtjeva na konstantnoj razini klijentskih sesija.
Zadatak traženja anomalija za programske sustave ima svoje specifičnosti. U teoriji, za svaki softverski sustav potrebno je razviti ili doraditi postojeće metode, budući da je traženje anomalija vrlo ovisno o podacima u kojima se provodi, a podaci softverskih sustava uvelike variraju ovisno o alatima za implementaciju sustava. , sve do toga na kojem računalu radi.
Metode traženja anomalija pri predviđanju kvarova programskih sustava
Prije svega, vrijedi reći da je ideja o predviđanju neuspjeha inspirirana člankom . Za testiranje učinkovitosti pristupa s automatskom pretragom anomalija odabran je programski sustav Web-Consolidation koji je jedan od projekata tvrtke NPO Krista. Prethodno je za njega izvršeno ručno praćenje na temelju primljenih metrika. Budući da je sustav prilično složen, za njega se uzima velik broj metrika: JVM indikatori (opterećenje skupljača smeća), indikatori OS-a pod kojim se kod izvršava (virtualna memorija, % opterećenja OS CPU-a), mrežni indikatori (opterećenje mreže ), samog poslužitelja (opterećenje CPU-a, memorija), metrike divlje muhe i vlastite metrike aplikacije za sve kritične podsustave.
Sve metrike su preuzete iz sustava pomoću grafita. U početku se šapat baza podataka koristila kao standardno rješenje za grafanu, no kako je baza klijenata rasla, graphite se više nije mogao nositi s tim jer je iscrpio kapacitet DC disk podsustava. Nakon toga je odlučeno pronaći učinkovitije rješenje. Izbor je napravljen u korist , što je omogućilo smanjenje opterećenja diskovnog podsustava za red veličine i smanjenje zauzetog prostora na disku za pet do šest puta. Dolje je dijagram mehanizma za prikupljanje metrike pomoću graphite+clickhouse (Slika 2).
Slika 2. Shema za prikupljanje metrike
Dijagram je preuzet iz interne dokumentacije. Prikazuje komunikaciju između grafana (korisničkog sučelja za praćenje koje koristimo) i grafita. Uklanjanje metrike iz aplikacije obavlja zasebni softver - . Stavlja ih u grafit.
Sustav Web Consolidation ima brojne značajke koje stvaraju probleme za predviđanje kvarova:
- Trend se često mijenja. Za ovaj softverski sustav dostupne su različite verzije. Svaki od njih donosi promjene u softverskom dijelu sustava. Sukladno tome, na ovaj način programeri izravno utječu na metriku određenog sustava i mogu izazvati promjenu trenda;
- značajka implementacije, kao i svrhe za koje klijenti koriste ovaj sustav, često uzrokuju anomalije bez prethodne degradacije;
- postotak anomalija u odnosu na cijeli skup podataka je mali (< 5%);
- Mogu postojati praznine u primanju indikatora iz sustava. U nekim kratkim vremenskim razdobljima sustav praćenja ne uspijeva dobiti metriku. Na primjer, ako je poslužitelj preopterećen. Ovo je kritično za treniranje neuronske mreže. Postoji potreba da se sintetički popune praznine;
- Slučajevi s anomalijama često su relevantni samo za određeni datum/mjesec/vrijeme (sezonskost). Ovaj sustav ima jasne propise za korištenje od strane korisnika. Sukladno tome, metrika je relevantna samo za određeno vrijeme. Sustav se ne može koristiti stalno, već samo u pojedinim mjesecima: selektivno ovisno o godini. Dolazi do situacija kada isto ponašanje metrike u jednom slučaju može dovesti do kvara softverskog sustava, ali ne iu drugom.
Za početak su analizirane metode otkrivanja anomalija u podacima praćenja programskih sustava. U člancima na ovu temu, kada je postotak anomalija mali u odnosu na ostatak skupa podataka, najčešće se predlaže korištenje neuronskih mreža.
Osnovna logika za traženje anomalija pomoću podataka neuronske mreže prikazana je na slici 3:
Slika 3. Traženje anomalija pomoću neuronske mreže
Na temelju rezultata prognoze ili obnove prozora trenutnog toka metrike, izračunava se odstupanje od onoga primljenog od pokrenutog softverskog sustava. Ako postoji velika razlika između metrike dobivene iz softverskog sustava i neuronske mreže, možemo zaključiti da je trenutni segment podataka anomalan. Sljedeći niz problema javlja se pri korištenju neuronskih mreža:
- da bi ispravno radili u načinu strujanja, podaci za obuku modela neuronske mreže moraju uključivati samo "normalne" podatke;
- potrebno je imati ažuran model za ispravnu detekciju. Promjenjivi trendovi i sezonalnost metrike mogu uzrokovati veliki broj lažno pozitivnih rezultata u modelu. Da biste ga ažurirali, potrebno je jasno odrediti vrijeme kada je model zastario. Ako ažurirate model kasnije ili ranije, najvjerojatnije će uslijediti veliki broj lažno pozitivnih rezultata.
Također ne smijemo zaboraviti na traženje i sprječavanje česte pojave lažno pozitivnih rezultata. Pretpostavlja se da će se najčešće javljati u izvanrednim situacijama. Međutim, oni također mogu biti posljedica pogreške neuronske mreže zbog nedovoljne obuke. Potrebno je minimizirati broj lažno pozitivnih rezultata modela. Inače će lažna predviđanja izgubiti puno vremena administratora namijenjenog provjeri sustava. Prije ili kasnije administrator će jednostavno prestati odgovarati na "paranoični" nadzorni sustav.
Rekurentna neuronska mreža
Da biste otkrili anomalije u vremenskim serijama, možete koristiti sa LSTM memorijom. Jedini problem je što se može koristiti samo za prognozirane vremenske serije. U našem slučaju nisu sve metrike predvidljive. Pokušaj primjene RNN LSTM na vremensku seriju prikazan je na slici 4.
Slika 4. Primjer rekurentne neuronske mreže s LSTM memorijskim stanicama
Kao što se može vidjeti na slici 4, RNN LSTM se uspio nositi s traženjem anomalija u ovom vremenskom razdoblju. Ako rezultat ima visoku pogrešku predviđanja (srednja pogreška), zapravo je došlo do anomalije u pokazateljima. Korištenje jednog RNN LSTM očito neće biti dovoljno, budući da je primjenjivo na mali broj metrika. Može se koristiti kao pomoćna metoda za traženje anomalija.
Autokoder za predviđanje kvara
– u biti umjetna neuronska mreža. Ulazni sloj je koder, izlazni sloj je dekoder. Nedostatak svih neuronskih mreža ove vrste je što ne lokaliziraju dobro anomalije. Odabrana je arhitektura sinkronog autokodera.
Slika 5. Primjer rada autoenkodera
Autokoderi se obučavaju na normalnim podacima, a zatim pronađu nešto anomalno u podacima koji se šalju modelu. Baš ono što vam je potrebno za ovaj zadatak. Ostaje samo odabrati koji je autoenkoder prikladan za ovaj zadatak. Arhitektonski najjednostavniji oblik autoenkodera je naprijed, nepovratna neuronska mreža, koja je vrlo slična (višeslojni perceptron, MLP), s ulaznim slojem, izlaznim slojem i jednim ili više skrivenih slojeva koji ih povezuju.
Međutim, razlike između autokodera i MLP-ova su u tome što u autokoderu izlazni sloj ima isti broj čvorova kao i ulazni sloj i što umjesto da bude osposobljen za predviđanje ciljne vrijednosti Y koju daje ulaz X, autokoder se osposobljava rekonstruirati vlastite X-ove. Stoga su Autoenkoderi modeli učenja bez nadzora.
Zadatak autoenkodera je pronaći vremenske indekse r0 ... rn koji odgovaraju anomalnim elementima u ulaznom vektoru X. Taj učinak se postiže traženjem kvadrata pogreške.
Slika 6. Sinkroni autokoder
Za autoenkoder je odabran . Njegove prednosti: mogućnost korištenja strujnog načina obrade i relativno manji broj parametara neuronske mreže u usporedbi s drugim arhitekturama.
Mehanizam za minimiziranje lažno pozitivnih rezultata
Zbog činjenice da dolazi do raznih abnormalnih situacija, kao i moguće situacije nedovoljne obučenosti neuronske mreže, za model detekcije anomalija koji se razvija, odlučeno je da je potrebno razviti mehanizam za minimiziranje lažnih pozitivnih rezultata. Ovaj mehanizam se temelji na bazi predložaka koju je klasificirao administrator.
(DTW algoritam, od engleskog dynamic time warping) omogućuje pronalaženje optimalne korespondencije između vremenskih sekvenci. Prvi put korišten u prepoznavanju govora: koristi se za određivanje kako dva govorna signala predstavljaju istu izvornu izgovorenu frazu. Kasnije je nađena njegova primjena u drugim područjima.
Glavno načelo minimiziranja lažnih pozitivnih rezultata je prikupljanje baze podataka standarda uz pomoć operatera koji klasificira sumnjive slučajeve otkrivene pomoću neuronskih mreža. Zatim se klasificirani standard uspoređuje sa slučajem koji je sustav otkrio i donosi se zaključak o tome je li slučaj lažan ili dovodi do kvara. DTW algoritam se koristi upravo za usporedbu dviju vremenskih serija. Glavni alat za minimiziranje i dalje je klasifikacija. Očekuje se da će nakon prikupljanja velikog broja referentnih slučajeva sustav početi manje pitati operatera zbog sličnosti većine slučajeva i pojave sličnih.
Kao rezultat toga, na temelju gore opisanih metoda neuronske mreže, izgrađen je eksperimentalni program za predviđanje kvarova sustava "Web-Consolidation". Cilj ovog programa bio je, koristeći postojeću arhivu podataka praćenja i informacija o prethodnim kvarovima, ocijeniti kompetentnost ovog pristupa za naše softverske sustave. Shema programa prikazana je u nastavku na slici 7.
Slika 7. Shema predviđanja kvara na temelju analize metričkog prostora
U dijagramu se mogu razlikovati dva glavna bloka: potraga za nepravilnim vremenskim razdobljima u toku podataka praćenja (metrika) i mehanizam za minimiziranje lažnih pozitivnih rezultata. Napomena: U eksperimentalne svrhe, podaci se dobivaju putem JDBC veze iz baze podataka u koju će ih graphite pohraniti.
Slijedi sučelje sustava za nadzor dobiveno razvojem (Slika 8).
Slika 8. Sučelje eksperimentalnog nadzornog sustava
Sučelje prikazuje postotak anomalije na temelju primljenih metrika. U našem slučaju, primitak je simuliran. Već imamo sve podatke za nekoliko tjedana i postupno ih učitavamo kako bismo provjerili slučaj anomalije koja dovodi do kvara. Donja statusna traka prikazuje ukupni postotak anomalije podataka u određenom trenutku, koji se utvrđuje pomoću autokodera. Također, poseban postotak se prikazuje za predviđene metrike, koje izračunava RNN LSTM.
Primjer otkrivanja anomalija na temelju performansi procesora pomoću RNN LSTM neuronske mreže (Slika 9).
Slika 9. RNN LSTM otkriće
Prilično jednostavan slučaj, u biti običan outlier, ali koji dovodi do kvara sustava, uspješno je izračunat pomoću RNN LSTM. Indikator anomalije u ovom vremenskom razdoblju je 85-95%, a sve iznad 80% (prag je određen eksperimentalno) smatra se anomalijom.
Primjer otkrivanja anomalije kada se sustav nije mogao pokrenuti nakon ažuriranja. Ovu situaciju detektira autokoder (slika 10).
Slika 10. Primjer detekcije autoenkodera
Kao što možete vidjeti na slici, PermGen je zapeo na jednoj razini. Autokoderu je to bilo čudno jer nikada prije nije vidio ništa slično. Ovdje anomalija ostaje 100% dok se sustav ne vrati u radno stanje. Anomalija se prikazuje za sve metrike. Kao što je ranije spomenuto, autokoder ne može lokalizirati anomalije. Operater je pozvan da izvrši ovu funkciju u tim situacijama.
Zaključak
PC "Web-Consolidation" je u razvoju nekoliko godina. Sustav je u prilično stabilnom stanju, a broj zabilježenih incidenata je mali. Međutim, bilo je moguće pronaći anomalije koje su dovele do kvara 5 - 10 minuta prije nego što se kvar dogodio. U nekim slučajevima, obavijest o kvaru unaprijed pomogla bi uštedjeti planirano vrijeme koje je dodijeljeno za izvođenje radova "popravka".
Na temelju provedenih eksperimenata prerano je donositi konačne zaključke. Zasad su rezultati oprečni. S jedne strane, jasno je da su algoritmi temeljeni na neuronskim mrežama sposobni pronaći “korisne” anomalije. S druge strane, ostaje velik postotak lažno pozitivnih rezultata, a ne mogu se otkriti sve anomalije koje je otkrio kvalificirani stručnjak u neuronskoj mreži. Nedostaci uključuju činjenicu da sada neuronska mreža zahtijeva obuku s učiteljem za normalan rad.
Za daljnji razvoj sustava za predviđanje kvarova i njegovo dovođenje u zadovoljavajuće stanje, može se predvidjeti nekoliko načina. Radi se o detaljnijoj analizi slučajeva s anomalijama koje dovode do kvara, zbog ovog dodavanja popisu važnih metrika koje uvelike utječu na stanje sustava, te odbacivanja nepotrebnih koje na njega ne utječu. Također, ako krenemo u ovom smjeru, možemo pokušati specijalizirati algoritme posebno za naše slučajeve s anomalijama koje dovode do kvarova. Postoji još jedan način. Ovo je poboljšanje u arhitekturi neuronskih mreža i time povećanje točnosti detekcije uz smanjenje vremena obuke.
Izražavam svoju zahvalnost svojim kolegama koji su mi pomogli da napišem i održim relevantnost ovog članka: i Sergej Finogenov.
Izvor: www.habr.com