Zhvillimi i sistemeve softuerike industriale kërkon vëmendje të madhe ndaj qëndrueshmërisë së produktit përfundimtar, si dhe reagim të shpejtë ndaj dështimeve dhe problemeve, nëse ato ndodhin. Monitorimi, sigurisht, ndihmon në reagimin ndaj dështimeve dhe problemeve në mënyrë më efikase dhe më të shpejtë, por nuk është mjaftueshëm. Së pari, është e vështirë të mbahen nën kontroll një numër të madh serverësh – kërkohet një numër i madh njerëzish. Së dyti, është e nevojshme të kuptohet mirë se si funksionon aplikacioni, për të parashikuar gjendjen e tij. Prandaj, nevojitet shumë njerëz, që kuptojnë mirë sistemet që zhvillojmë, treguesit e tyre dhe karakteristikat e tyre. Të supozosh, edhe nëse gjen një numër të mjaftueshëm njerëzish të gatshëm për të bërë këtë, kërkohet gjithashtu shumë kohë për t’i trajnuar ata.
Çfarë duhet bërë? Këtu na vjen në ndihmë inteligjenca artificiale. Artikulli do të flasë për (predictive maintenance). Ky qasje po fiton popullaritet në mënyrë aktive. Janë shkruar shumë artikuj, përfshirë edhe në Habrë. Kompanitë e mëdha e shpërfaqin në përdorim këtë qasje për të mbajtur në funksion serverat e tyre. Pas studimit të një numri të madh artikujsh, ne vendosëm ta provojmë këtë qasje. Çfarë rezultoi nga kjo?
Hyrje
Sistemi i zhvilluar softuerik, herët a vonë, del në përdorim. Është e rëndësishme për përdoruesin që sistemi të funksionojë pa probleme. Nëse ndonjë situatë e papritur ndodh, ajo duhet të rregullohet me minimumin e vonesave.
Për të thjeshtuar mbështetje teknike të sistemit softuerik, veçanërisht nëse ka shumë serverë, zakonisht përdoren programe monitorimi, të cilat marrin metrika nga sistemi softuerik në funksionim, ofrojnë mundësinë për të diagnostikuar gjendjen e tij dhe ndihmojnë në përcaktimin e asaj që shkaktoi dështimin. Ky proces quhet monitorimi i sistemit softuerik.
Figura 1. Ndërfaqja për monitorimin grafana
Metrikat janë tregues të ndryshëm të sistemit softuerik, mjedisit të tij të ekzekutimit ose kompjuterit fizik në të cilin është instaluar sistemi me etiketën e kohës, momentin kur janë marrë metrikat. Në analizën statike, të dhënat e metrikave quhen seritë kohore. Për të vëzhguar gjendjen e sistemit softuerik, metrikat shfaqen në formën e grafikëve: në boshtin X – koha, dhe në boshtin Y – vlerat (figura 1). Nga një sistem softuerik në funksionim mund të merren disa mijëra metrika (nga çdo nod). Ato formojnë hapësirën e metrikave (seritë e kohshme shumëdimensionale).
Duke qenë se në sistemet softuerike komplekse merren një numër i madh metrikash, monitorimi manual bëhet një detyrë e vështirë. Për të reduktuar vëllimin e të dhënave që analizohen nga administratorët, mjetet e monitorimit përmbajnë mjete për zbulimin e automatik të problemeve të mundshme. Për shembull, mund të konfigurohet një trigger që aktivizohet në rast se hapësira e lirë diskore zvogëlohet deri në një prag të caktuar. Gjithashtu mund të diagnostikohet automatikisht ndalimi i serverit ose ngadalësimi kritik i shpejtësisë së shërbimit. Në praktikë, mjetet e monitorimit përballen mirë me zbulimin e dështimeve që kanë ndodhur ose identifikimin e simboleve të thjeshta të dështimeve të ardhshme, por përgjithësisht parashikimi i dështimeve të mundshme mbetet një gozhdë e vështirë për ta. Parashikimi i dështimeve përmes analizës manuale të metrikave kërkon angazhimin e specialistëve të kualifikuar. Ai është me produktivitet të ulët. shumica e dështimeve të mundshme mund të kalojnë pa u vënë re.
Në vitet e fundit, midis kompanive të mëdha IT që zhvillojnë software, po fiton popullaritet pikërisht mirëmbajtja parashikuese e sistemeve softuerike. Thelbi i këtij qasje është identifikimi i problemeve që çojnë në degradimin e sistemit në fazat e hershme, para dështimit duke përdorur inteligjencën artificiale. Kjo qasje nuk e përjashtan plotësisht monitorimin manual të sistemit. Ai është ndihmës për procesin e monitorimit në tërësi.
Mjeti kryesor për zbatimin e mirëmbajtjes parashikuese është detyra e gjetjes së anomalisë në seritë kohore, pasi në rast se ndodh një anomali në të dhëna, është e mundur që pas një kohe të ndodhë një dështim ose keqfunksionim. Anomalia është një shkëputje e caktuar e treguesve të sistemit softuerik, siç është identifikimi i degradimit të shpejtësisë së ekzekutimit të një lloji kërkese ose ulja e numrit mesatar të kërkesave të shërbimit me një nivel të qëndrueshëm të sesioneve të klientëve.
Detyra e kërkimit të anomalive për sistemet software ka specifikat e saj. Idealisht, për çdo sistem software është e nevojshme zhvillimi ose përmirësimi i metodave ekzistuese, pasi kërkimi i anomalive varet shumë nga të dhënat në të cilat kryhet, ndërsa të dhënat e sistemeve software ndryshojnë ndjeshëm në varësi të mjeteve të zbatimit, deri në atë pikë sa nën sistemin nën të cilin është nisur.
Metodat e kërkimit të anomalive në parashikimin e dështimeve të sistemeve software
Para së gjithash, duhet thënë se ideja e parashikimit të dështimeve u frymëzua nga artikulli . Për të verifikuar efektivitetin e qasjes me kërkimin automatik të anomalive, u zgjodh sistemi software «Web-Konsolidimi», i cili është një prej projekteve të kompanisë NPO «Krista». Për të, më parë ishin kryer monitorime manuale sipas metrikeve të marra. Duke qenë se sistemi është mjaft i komplikuar, për të merren një numër të madh metrikeve: tregues të JVM (ngarkesa e mbledhësit të plehrave), tregues të OS-së nën të cilën ekzekutohet kodi (memoria virtuale, % ngarkesa e CPU-së), tregues të rrjetit (ngarkesa e rrjetit), të serverit vetë (ngarkesa e CPU-së, memorjes), metrike të wildfly dhe metrike të veta të aplikacionit për të gjitha pjesët kritike të sistemit.
Të gjitha metrike merren nga sistemi përmes graphite. Fillimisht, u përdor baza whisper si zgjidhje standarde për grafanën, por me rritjen e bazës së klientëve, graphite nuk arriti më të përballojë ngarkesën e kapacitetit të nën-sistemit të diskut të DC-së. Pas kësaj, u mor vendimi për të kërkuar një zgjidhje më efikase. Zgjedhja ra në favor të , e cila lejoi uljen e ngarkesës në nën-sistemin e diskut me një rend dhe pesë deri në gjashtë herë të zvogëlojë hapësirën e zënë në disk. Më poshtë është paraqitur diagrami i mekanizmit të mbledhjes së metrikeve duke përdorur graphite+clickhouse (figura 2).
Figura 2. Diagrami i marrjes së metrikeve
Diagrama është marrë nga dokumentacioni i brendshëm. Ajo tregon shkëmbimin e të dhënave midis grafanës (ndërfaqja përdoruese për monitorimin që përdorim) dhe graphite. Marrja e metrikeve nga aplikacioni realizohet nga një program i veçantë – . Ai gjithashtu i grumbullon ato në graphite.
Sistemi «Web-Konsolidimi» ka disa karakteristika që krijojnë probleme për parashikimin e dështimeve:
- trendet ndodhin shpesh të ndryshojnë. Për këtë sistem software, lëshohen versione të ndryshme. Çdo njëra nga ato sjell ndryshime në pjesën software të sistemit. Sipas kësaj, zhvilluesit ndikojnë drejtpërdrejt në metrike të këtij sistemi dhe mund të shkaktojnë ndryshimin e trendit;
- karakteristika e zbatimit dhe gjithashtu qëllimet e përdorimit nga klientët e këtij sistemi shpesh shkaktojnë anomalitë pa degradim të mëparshëm;
- pjesa e anomalive në raport me të gjithë grupin e të dhënave është e vogël (< 5%);
- mund të ndodhin ndërprerje në marrjen e treguesve nga sistemi. Në disa periudha të shkurtra, sistemi i monitorimit nuk arrin të marrë metrike. Për shembull, nëse serveri është i ngarkuar. Për trajnimin e rrjeteve nervore, kjo është kritike. Ndodhet nevoja për të plotësuar boshllëqet në mënyrë sintetike;
- Rastet me anomalitë shpesh janë relevante vetëm për një numër / muaji / kohë të caktuar (sezonalitet). Ky sistem ka një rregull të qartë të përdorimit nga përdoruesit e tij. Si rezultat, metrike janë relevante vetëm për një periudhë të caktuar. Sistemi mund të përdoret jo vazhdimisht, por vetëm në disa muaj: përzgjedhur në varësi të vitit. Ndodhin situata kur e njëjta sjellje e metrikeve në një rast mund të çojë në dështimin e sistemit software, ndërsa në një rast tjetër jo.
Fillimisht u analizuan metodat e zbulimit të anomalive në të dhënat e monitorimit të sistemeve software. Në artikujt mbi këtë temë, në përqindje të vogla anomalish në raport me grupin tjetër të dhënash, shpesh sugjerohet përdorimi i rrjeteve nervore.
Logjika kryesore për kërkimin e anomalive me ndihmën e të dhënave të rrjeteve nervore është paraqitur në figurën 3:
Figura 3. Kërkimi i anomalive me ndihmën e rrjetit nervor
Në rezultatin e parashikimit ose rikthimin e dritares aktuale të rrjedhës së metrikeve, llogaritet devijimi nga të dhënat e marra nga sistemi software në punë. Në rast se ka një diferencë të madhe midis trekëndëshave të marra nga sistemi software dhe rrjetit nervor, mund të konkludohet se segmenti aktual i të dhënave është anomali. Ndodhin disa probleme për përdorimin e rrjeteve nervore:
- për funksionimin e saktë në mënyrë të rrjedhshme, të dhënat për trajnimin e modeleve të rrjeteve nervore duhet të përfshijnë vetëm të dhëna «normale»;
- është e nevojshme të kesh një model aktual për të bërë zbulime të sakta. Ndryshimi i trendit dhe sezonalitetit në metrika mund të shkaktojë një numër të madh të sinjaleve false të modelit. Për ta përditësuar atë, është e domosdoshme të përcaktohet qartë koha kur modeli është bërë i vjetëruar. Nëse modeli përditësohet shumë herët ose shumë vonë, probabiliteti i sinjaleve false do të jetë i lartë.
Gjithashtu, nuk duhet harruar kërkimin dhe parandalimin e shfaqjes së shpeshtë të sinjaleve false. Ato pritet të ndodhin më së shpeshti në situata të jashtzakonshme. Megjithatë, ato mund të jenë gjithashtu pasojë e një gabimi në rrjetin nervor për shkak të mësimit të pamjaftueshëm. Duhet të minimizohet numri i sinjaleve false të modelit. Në të kundërt, parashikimet e gabuara do të shpenzojnë shumë kohë të administratorit, e destinuar për të verifikuar sistemin. Më vonë ose më vonë, do të ndodhë që administratorit të ndalojë së reaguar ndaj një sistemi monitorimi 'paranojak'.
Rrjeti nervor rekurent
Për zbulimin e anomalive në seri kohore, mund të përdoret me memorie LSTM. Problemi qëndron vetëm në faktin se ai mund të përdoret vetëm për seri kohore që parashikohen. Në rastin tonë, jo të gjitha metrikat janë të parashikueshme. Përpjekja për të aplikuar RNN LSTM për një seri kohore është paraqitur në figurën 4.
Figura 4. Shembulli i funksionimit të rrjetit nervor rekurent me qeliza memorie LSTM.
Siç duket nga figura 4, RNN LSTM arriti të diagnozojë anomalinë në këtë segment të kohës. Aty ku rezultati ka një gabim të lartë parashikimi (gabimi mesatar), me të vërtetë ndodhi një anomalie në tregues. Përdorimi i vetëm të RNN LSTM do të jetë padyshim i pamjaftueshëm, pasi është i aplikueshëm për një numër të vogël metrikash. Mund të përdoret si një metodë ndihmuese për zbulimin e anomalive.
Auto-koduesi për parashikimin e dështimeve
– në thelb është një rrjet nervor artificial. Shtresa hyrëse është encoder, ndërsa shtresa dalëse është decoder. Disavantazhi i të gjitha rrjeteve nervore të këtij lloji është se ato lokalizojnë ndryshe anomalitë. U zgjodh arkitektura e auto-koduesit të sinkronizuar.
Figura 5. Shembulli i funksionimit të auto-koduesit.
Auto-koduesit trajnohen në të dhëna normale dhe më pas gjejnë diçka anomale në të dhënat e futur në model. Kjo është pikërisht ajo që na nevojitet për këtë detyrë. Tani mbetet vetëm të zgjidhni se cili nga auto-koduesit do të përshtatet më mirë për këtë detyrë. Forma më e thjeshtë arkitektonike e auto-koduesit është një rrjet nervor i drejtpërdrejtë, jo të rikthyeshëm, që është shumë e ngjashme me (multilayer perceptron, MLP), me nivelin hyrës, nivelin dalës dhe një ose disa shtresa të fshehura që i lidhin ato.
Megjithatë, dallimi midis auto-koduesve dhe MLP qëndron në faktin se në auto-koduesin niveli i daljes ka të njëjtin numër nyjesh që ka niveli hyrës, dhe që në vend të mësimit për të parashikuar vlerën e synuar Y, e cila i atribuohet hyrjes X, auto-koduesi mëson të rikonstruktojë vetë X. Prandaj, auto-koduesit janë modele të të mësuarit të pakontrolluar.
Detyra e auto-koduesit është të gjejë indekset kohore r0…rn, të cilat përkojnë me elementet anomale në vektorin hyrës X. Ky efekt arrihet përmes kërkimit të gabimit katror.
Figura 6. Auto-koduesi sinkron.
Për auto-koduesin, u zgjodh . Avantazhet e saj: mundësia e përdorimit të një mode të përpunimit në fluks dhe një numër relativisht më të vogël parametrash të rrjetit nervor në krahasim me arkitektura të tjera.
Mekanizmi i minimizimit të sinjaleve false
Duke pasur parasysh se ndodhin situata të ndryshme jashtëzakonisht, si dhe mund të ndodhë situata e mësimit të pamjaftueshëm të rrjetit nervor, për modelin e zhvilluar të zbulimit të anomalive, u mor një vendim për nevojën e zhvillimit të një mekanizmi për minimizimin e sinjaleve false. Ky mekanizëm bazohet në një bazë modelesh, që e klasifikon administratori.
(algoritmi DTW, nga anglishtja dynamic time warping) lejon të gjejë përputhjen më të optimizuar midis sekuencave të kohës. I pari u aplikua në njohjen e të folurit: u përdor për të përcaktuar se si dy sinjale të të folurit përfaqësojnë të njëjtin frazë të shqiptuar.
Parimi kryesor i minimizimit të alarmeve të rreme është grumbullimi i një baze referencash me ndihmën e një operatori, i cili klasifikon rastet e dyshimta, të zbuluara nga rrjetet nervore. Më pas, bëhet një krahasim i standardit të klasifikuar me rastin që zbuloi sistemi, dhe merret një përfundim nëse rasti është një alarm i rremë apo një që çon në dështim. Pikerisht për krahasimin e dy serive të kohës përdoret algoritmi DTW. Instrumenti kryesor për minimizimin, megjithatë, është klasifikimi. Supozohet se pas grumbullimit të një numri të madh të rastëve të standardeve, sistemi do të fillojë të pyesë më pak operatorin për shkak të ngjashmërisë së shumicës së rasteve dhe shfaqjes së situatave të ngjashme.
Si rezultat i metodave të mësipërme, është ndërtuar një program eksperimental për parashikimin e dështimeve të sistemit "Web-Konsolidimi". Qëllimi i këtij programi ishte, duke përdorur arkivin ekzistues të të dhënave të monitorimit dhe informacionin mbi dështimet e ndodhura, të vlerësojë aftësinë e këtij qasje për sistemet tona softuerike. Skema e funksionimit të programit është paraqitur më poshtë, në figurën 7.
Figura 7. Skema e parashikimit të dështimeve mbi bazën e analizës së hapësirës së metrikave.
Në skemë mund të dallohet dy blloqe kryesore: kërkimi i segmenteve anomale të kohës në fluxin e të dhënave të monitorimit (metrikave) dhe mekanizmi për minimizimin e alarmeve të rreme. Shënim: për qëllime eksperimentale, të dhënat merren përmes lidhjes JDBC nga baza e të dhënave, në të cilën ato ruhen nga graphite.
Më poshtë është paraqitur ndërfaqja rezultante të sistemit të monitorimit të zhvilluar (figura 8).
Figura 8. Ndërfaqja e sistemit eksperimental të monitorimit.
Në ndërfaqe shfaqet përqindja e anomalisë sipas metrikave të marra. Në rastin tonë, marrja simulohet. Ne tashmë kemi të dhëna për disa javë dhe i ngarkojmë ato gradualisht për të kontrolluar rastin me anomali që çon në dështim. Në status barin në fund shfaqet përcenti total i anomalisë së të dhënave në momentin e tanishëm, që përcaktohet me ndihmën e auto-shkoduesit. Gjithashtu për metrikat e parashikuara shfaqet një përqindje e veçantë, e cila llogaritet nga RNN LSTM.
Shembull i zbulimit të anomalisë sipas treguesve CPU me ndihmën e rrjetit nervor RNN LSTM (figura 9).
Figura 9. Zbulimi RNN LSTM.
Një rast mjaft i thjeshtë, në thelb një shpërthim i zakonshëm, megjithatë që çon në dështimin e sistemit, u përcaktua me sukses me ndihmën e RNN LSTM. Treguesi i anomalisë në këtë segment kohe është 85 – 95%, gjithçka mbi 80% (kambani përcaktohet eksperimentalisht) konsiderohet si anomali.
Shembull i zbulimit të anomalisë kur sistemi nuk arriti të ngarkohet pas një përditësimi. Kjo situatë detektohet nga auto-shkoduesi (figura 10).
Figura 10. Shembuj i zbulimit nga auto-shkoduesi.
Siç shihet nga figura, PermGen u ngatërrua në një nivel. Auto-shkoduesi e konsideroi këtë si të çuditshëm, sepse më parë nuk kishte parë asgjë të tillë. Këtu anomalia mbetet e 100% deri sa sistemi të kthehet në gjendje pune. Anomalia shfaqet për të gjitha metrikat. Siç është thënë më parë, auto-shkoduesi nuk di të lokalizojë anomali. Operatorët janë të thirrur për të kryer këtë funksion në këto situata.
Përfundimi
PC "Web-Konsolidimi" është në zhvillim për disa vite. Sistemi është në një gjendje mjaft të qëndrueshme dhe numri i incidenteve të regjistruara është i vogël. Megjithatë, është arritur të identifikohen anomali që çojnë në dështim nga 5 – 10 minuta para ndodhjes së dështimit. Në disa raste, njoftimi për dështimin paraprakisht do kishte ndihmuar në ruajtjen e kohës së rregullt, e cila caktohet për kryerjen e punëve "të riparimit".
Bazuar në eksperimentet që janë kryer, është ende herët për të bërë përfundime përfundimtare. Aktualisht rezultatet janë të kundërta. Në njërën anë, duket se algoritmet e bazuara në rrjetet nervore janë në gjendje të gjejnë anomali "të dobishme". Në anën tjetër, mbetet një përqindje e madhe e alarmeve të rreme, dhe jo të gjitha anomali të zbuluara nga specialistë të kualifikuar arrijnë të identifikohen nga rrjeti nervor. Një nga disavantazhet është se tani rrjeti nervor kërkon mësim me mësues për të punuar normalisht.
Për të avancuar sistemin e parashikimit të dështimeve dhe për ta sjellë në një gjendje të kënaqshme, mund të parashikohen disa rrugë. Kjo është një analizë më e detajuar e rasteve me anomali që çojnë në dështim, përmes kësaj shtese të listës së metrikave të rëndësishme që ndikojnë shumë në gjendjen e sistemit, si dhe heqja e atyre të panevojshme që nuk e ndikojnë atë. Gjithashtu, nëse e ndjekim këtë drejtim, mund të bëjmë përpjekje për specializimin e algoritmeve specifikisht për rastet tona me anomali që çojnë në dështime. Ka dhe një rrugë tjetër. Kjo është përmirësimi i arkitekturave të rrjeteve neurale dhe rritja e saktësisë së zbulimeve përmes kësaj, duke shkurtuar kohën e trajnimet.
Shpreh falënderimin tim ndaj kolegëve që ndihmuan në shkrimin dhe ruajtjen e aktualitetit të këtij artikulli: dhe Sergey Finogenov.
Burimi: habr.com
