Zhvillimi industrial i sistemeve softuerike kërkon vëmendje të madhe ndaj tolerancës së gabimeve të produktit përfundimtar, si dhe reagim të shpejtë ndaj dështimeve dhe dështimeve nëse ato ndodhin. Monitorimi, sigurisht, ndihmon për t'iu përgjigjur dështimeve dhe dështimeve në mënyrë më efikase dhe të shpejtë, por jo mjaftueshëm. Së pari, është shumë e vështirë të mbash gjurmët e një numri të madh serverësh - nevojiten një numër i madh njerëzish. Së dyti, ju duhet të kuptoni mirë se si funksionon aplikacioni në mënyrë që të parashikoni gjendjen e tij. Prandaj, ne kemi nevojë për shumë njerëz që të kenë një kuptim të mirë të sistemeve që po zhvillojmë, performancën dhe veçoritë e tyre. Le të supozojmë se edhe nëse gjeni mjaft njerëz të gatshëm për ta bërë këtë, duhet ende 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 (mirëmbajtje parashikuese). Kjo qasje po fiton në mënyrë aktive popullaritet. Janë shkruar një numër i madh artikujsh, duke përfshirë Habré. Kompanitë e mëdha e përdorin plotësisht këtë qasje për të ruajtur performancën e serverëve të tyre. Pasi studiuam një numër të madh artikujsh, vendosëm të provojmë këtë qasje. Çfarë erdhi nga ajo?
Paraqitje
Sistemi i softuerit të zhvilluar herët a vonë hyn në veprim. Është e rëndësishme për përdoruesin që sistemi të funksionojë pa dështime. Nëse ndodh një emergjencë, ajo duhet të zgjidhet me vonesë minimale.
Për të thjeshtuar mbështetjen teknike të një sistemi softuerësh, veçanërisht nëse ka shumë serverë, zakonisht përdoren programe monitorimi që marrin metrikë nga një sistem softuer që funksionon, bëjnë të mundur diagnostikimin e gjendjes së tij dhe ndihmojnë në përcaktimin se çfarë e shkaktoi saktësisht dështimin. Ky proces quhet monitorimi i sistemit të softuerit.
Figura 1. Ndërfaqja e monitorimit Grafana
Metrikat janë tregues të ndryshëm të një sistemi softuerik, mjedisit të ekzekutimit të tij ose kompjuterit fizik nën të cilin funksionon sistemi me një vulë kohore të momentit kur janë marrë metrikat. Në analizën statike, këto metrika quhen seri kohore. Për të monitoruar gjendjen e sistemit të softuerit, metrikat shfaqen në formën e grafikëve: koha është në boshtin X dhe vlerat janë përgjatë boshtit Y (Figura 1). Disa mijëra metrikë mund të merren nga një sistem softuerik që funksionon (nga çdo nyje). Ato formojnë një hapësirë metrike (seri kohore shumëdimensionale).
Meqenëse një numër i madh metrikash mblidhen për sisteme komplekse softuerike, monitorimi manual bëhet një detyrë e vështirë. Për të zvogëluar sasinë e të dhënave të analizuara nga administratori, mjetet e monitorimit përmbajnë mjete për të identifikuar automatikisht problemet e mundshme. Për shembull, mund të konfiguroni një shkas që të aktivizohet kur hapësira e lirë e diskut bie nën një prag të caktuar. Ju gjithashtu mund të diagnostikoni automatikisht një mbyllje të serverit ose një ngadalësim kritik të shpejtësisë së shërbimit. Në praktikë, mjetet e monitorimit bëjnë një punë të mirë për të zbuluar dështimet që kanë ndodhur tashmë ose për të identifikuar simptoma të thjeshta të dështimeve të ardhshme, por në përgjithësi, parashikimi i një dështimi të mundshëm mbetet një arrë e vështirë për ta. Parashikimi nëpërmjet analizës manuale të metrikës kërkon përfshirjen e specialistëve të kualifikuar. Është produktivitet i ulët. Shumica e dështimeve të mundshme mund të kalojnë pa u vënë re.
Kohët e fundit, e ashtuquajtura mirëmbajtje parashikuese e sistemeve softuerike është bërë gjithnjë e më e popullarizuar në mesin e kompanive të mëdha të zhvillimit të softuerit IT. Thelbi i kësaj qasjeje është gjetja e problemeve që çojnë në degradimin e sistemit në fazat e hershme, përpara se ai të dështojë, duke përdorur inteligjencën artificiale. Kjo qasje nuk e përjashton 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 kërkimit të anomalive në seritë kohore, pasi kur ndodh një anomali në të dhëna ka një probabilitet të lartë që pas njëfarë kohe do të ketë një dështim ose dështim. Një anomali është një devijim i caktuar në performancën e një sistemi softuerësh, siç është identifikimi i degradimit në shpejtësinë e ekzekutimit të një lloji të kërkesës ose një ulje e numrit mesatar të kërkesave të shërbimit në një nivel konstant të seancave të klientit.
Detyra e kërkimit të anomalive për sistemet softuerike ka specifikat e veta. Teorikisht, për çdo sistem softuerësh është e nevojshme të zhvillohen ose të përsosin metodat ekzistuese, pasi kërkimi i anomalive varet shumë nga të dhënat në të cilat kryhet, dhe të dhënat e sistemeve softuerike ndryshojnë shumë në varësi të mjeteve për zbatimin e sistemit. , deri në çfarë kompjuteri po funksionon.
Metodat për kërkimin e anomalive gjatë parashikimit të dështimeve të sistemeve softuerike
Para së gjithash, vlen të thuhet se ideja e parashikimit të dështimeve u frymëzua nga artikulli . Për të testuar efektivitetin e qasjes me kërkimin automatik të anomalive, u zgjodh sistemi softuerik Web-Consolidation, i cili është një nga projektet e kompanisë NPO Krista. Më parë për të është kryer monitorim manual bazuar në metrikat e marra. Meqenëse sistemi është mjaft kompleks, për të merren një numër i madh metrikash: treguesit JVM (ngarkesa e grumbulluesit të mbeturinave), treguesit e sistemit operativ nën të cilin ekzekutohet kodi (memoria virtuale, % ngarkesa e CPU-së OS), treguesit e rrjetit (ngarkesa e rrjetit ), vetë serveri (ngarkesa e CPU-së, memoria), metrikat e fluturave të egra dhe metrikat e vetë aplikacionit për të gjitha nënsistemet kritike.
Të gjitha metrikat merren nga sistemi duke përdorur grafit. Fillimisht, baza e të dhënave whisper u përdor si një zgjidhje standarde për grafana, por ndërsa baza e klientit u rrit, grafiti nuk mund ta përballonte më, pasi kishte shteruar kapacitetin e nënsistemit të diskut DC. Pas kësaj, u vendos për të gjetur një zgjidhje më efektive. Zgjedhja u bë në favor , e cila bëri të mundur zvogëlimin e ngarkesës në nënsistemin e diskut me një renditje të madhësisë dhe zvogëlimin e hapësirës së zënë në disk nga pesë deri në gjashtë herë. Më poshtë është një diagram i mekanizmit për mbledhjen e metrikës duke përdorur grafit+clickhouse (Figura 2).
Figura 2. Skema për mbledhjen e metrikës
Diagrami është marrë nga dokumentacioni i brendshëm. Ai tregon komunikimin midis grafana (UI monitoruese që përdorim) dhe grafitit. Heqja e metrikës nga një aplikacion bëhet me softuer të veçantë - . Ai i vendos ato në grafit.
Sistemi i Konsolidimit të Uebit ka një sërë veçorish që krijojnë probleme për parashikimin e dështimeve:
- Trendi shpesh ndryshon. Versione të ndryshme janë të disponueshme për këtë sistem softuerësh. Secila prej tyre sjell ndryshime në pjesën softuerike të sistemit. Prandaj, në këtë mënyrë, zhvilluesit ndikojnë drejtpërdrejt në matjet e një sistemi të caktuar dhe mund të shkaktojnë një ndryshim trendi;
- tipari i zbatimit, si dhe qëllimet për të cilat klientët përdorin këtë sistem, shpesh shkaktojnë anomali pa degradim të mëparshëm;
- përqindja e anomalive në raport me të gjithë grupin e të dhënave është e vogël (< 5%);
- Mund të ketë boshllëqe në marrjen e treguesve nga sistemi. Në disa periudha të shkurtra kohore, sistemi i monitorimit nuk arrin të marrë metrikë. Për shembull, nëse serveri është i mbingarkuar. Kjo është kritike për trajnimin e një rrjeti nervor. Ekziston nevoja për të plotësuar boshllëqet në mënyrë sintetike;
- Rastet me anomali shpesh janë të rëndësishme vetëm për një datë/muaj/kohë specifike (sezonaliteti). Ky sistem ka rregulla të qarta për përdorimin e tij nga përdoruesit. Prandaj, metrikat janë të rëndësishme vetëm për një kohë të caktuar. Sistemi nuk mund të përdoret vazhdimisht, por vetëm në disa muaj: në mënyrë selektive në varësi të vitit. Situatat lindin kur e njëjta sjellje e metrikës në një rast mund të çojë në një dështim të sistemit softuer, por jo në një tjetër.
Fillimisht, u analizuan metodat për zbulimin e anomalive në monitorimin e të dhënave të sistemeve softuerike. Në artikujt mbi këtë temë, kur përqindja e anomalive është e vogël në krahasim me pjesën tjetër të grupit të të dhënave, më së shpeshti propozohet përdorimi i rrjeteve nervore.
Logjika bazë për kërkimin e anomalive duke përdorur të dhënat e rrjetit nervor është paraqitur në Figurën 3:
Figura 3. Kërkimi i anomalive duke përdorur një rrjet nervor
Bazuar në rezultatin e parashikimit ose restaurimit të dritares së rrjedhës aktuale të metrikës, llogaritet devijimi nga ai i marrë nga sistemi i softuerit që funksionon. Nëse ka një ndryshim të madh midis matjeve të marra nga sistemi softuer dhe rrjeti nervor, mund të konkludojmë se segmenti aktual i të dhënave është anormal. Seritë e mëposhtme të problemeve lindin për përdorimin e rrjeteve nervore:
- për të punuar si duhet në modalitetin e transmetimit, të dhënat për modelet e trajnimit të rrjeteve nervore duhet të përfshijnë vetëm të dhëna "normale";
- është e nevojshme të kemi një model të përditësuar për zbulimin e saktë. Ndryshimet e tendencave dhe sezonaliteti në metrikë mund të shkaktojnë një numër të madh të rezultateve false në model. Për ta përditësuar atë, është e nevojshme të përcaktohet qartë koha kur modeli është i vjetëruar. Nëse e përditësoni modelin më vonë ose më herët, atëherë, ka shumë të ngjarë, do të pasojnë një numër i madh pozitivësh të rremë.
Gjithashtu nuk duhet të harrojmë kërkimin dhe parandalimin e shfaqjes së shpeshtë të pozitivëve të rremë. Supozohet se ato do të ndodhin më shpesh në situata emergjente. Megjithatë, ato mund të jenë gjithashtu pasojë e një gabimi të rrjetit nervor për shkak të trajnimit të pamjaftueshëm. Është e nevojshme të minimizohet numri i pozitivëve të rremë të modelit. Përndryshe, parashikimet e rreme do të humbin shumë kohë nga administratori për të kontrolluar sistemin. Herët a vonë administratori thjesht do të ndalojë së përgjigjuri ndaj sistemit të monitorimit "paranojak".
Rrjeti nervor i përsëritur
Për të zbuluar anomalitë në seritë kohore, mund të përdorni me memorie LSTM. Problemi i vetëm është se mund të përdoret vetëm për seritë kohore të parashikuara. Në rastin tonë, jo të gjitha metrikat janë të parashikueshme. Një përpjekje për të aplikuar RNN LSTM në një seri kohore është paraqitur në Figurën 4.
Figura 4. Shembull i një rrjeti nervor të përsëritur me qeliza memorie LSTM
Siç mund të shihet nga Figura 4, RNN LSTM ishte në gjendje të përballonte kërkimin për anomali në këtë periudhë kohore. Aty ku rezultati ka një gabim të lartë parashikimi (gabim mesatar), në të vërtetë ka ndodhur një anomali në tregues. Përdorimi i një RNN LSTM të vetme nuk do të jetë i mjaftueshëm, pasi është i zbatueshëm për një numër të vogël metrikë. Mund të përdoret si një metodë ndihmëse për kërkimin e anomalive.
Autoenkoder për parashikimin e dështimit
– në thelb një rrjet nervor artificial. Shtresa hyrëse është kodues, shtresa e daljes është dekoder. Disavantazhi i të gjitha rrjeteve nervore të këtij lloji është se ato nuk i lokalizojnë mirë anomalitë. U zgjodh një arkitekturë autoenkoder sinkron.
Figura 5. Shembull i funksionimit të autoenkoderit
Autoenkoderët trajnohen me të dhëna normale dhe më pas gjejnë diçka anormale në të dhënat e dhëna modelit. Vetëm ajo që ju nevojitet për këtë detyrë. E tëra që mbetet është të zgjidhni se cili kodues automatik është i përshtatshëm për këtë detyrë. Forma më e thjeshtë arkitekturore e një autoenkoderi është një rrjet nervor përpara, pa kthim, i cili është shumë i ngjashëm me (perceptron me shumë shtresa, MLP), me një shtresë hyrëse, një shtresë dalëse dhe një ose më shumë shtresa të fshehura që i lidhin ato.
Sidoqoftë, ndryshimet midis kodifikuesve automatikë dhe MLP-ve janë se në një kodues automatik, shtresa e daljes ka të njëjtin numër nyjesh si shtresa hyrëse, dhe se në vend që të trajnohet për të parashikuar një vlerë të synuar Y të dhënë nga një hyrje X, autoenkoder është trajnuar. për të rindërtuar X-të e veta. Prandaj, Autoencoders janë modele mësimi të pambikëqyrur.
Detyra e autoenkoderit është të gjejë indekset kohore r0 ... rn që korrespondojnë me elementët anormalë në vektorin hyrës X. Ky efekt arrihet duke kërkuar gabimin në katror.
Figura 6. Autoenkoder sinkron
Për autoencoder u zgjodh . Përparësitë e tij: aftësia për të përdorur mënyrën e përpunimit të transmetimit dhe një numër relativisht më i vogël i parametrave të rrjetit nervor në krahasim me arkitekturat e tjera.
Mekanizmi për minimizimin e pozitivëve të rremë
Për shkak të faktit se lindin situata të ndryshme jonormale, si dhe një situatë e mundshme e trajnimit të pamjaftueshëm të rrjetit nervor, për modelin e zbulimit të anomalive që po zhvillohet, u vendos që ishte e nevojshme të zhvillohej një mekanizëm për minimizimin e pozitivëve të rremë. Ky mekanizëm bazohet në një bazë shabllone që klasifikohet nga administratori.
(Algoritmi DTW, nga deformimi dinamik i kohës angleze) ju lejon të gjeni korrespondencën optimale midis sekuencave kohore. Përdorur për herë të parë në njohjen e të folurit: përdoret për të përcaktuar se si dy sinjale të të folurit përfaqësojnë të njëjtën frazë origjinale të folur. Më pas, u gjet aplikim për të në zona të tjera.
Parimi kryesor i minimizimit të rezultateve false është mbledhja e një baze të dhënash të standardeve me ndihmën e një operatori që klasifikon rastet e dyshimta të zbuluara duke përdorur rrjetet nervore. Më pas, standardi i klasifikuar krahasohet me rastin që zbuloi sistemi dhe nxirret një përfundim nëse rasti është i rremë ose çon në një dështim. Algoritmi DTW përdoret pikërisht për të krahasuar dy seri kohore. Mjeti kryesor i minimizimit është ende klasifikimi. Pritet që pas grumbullimit të një numri të madh të rasteve referuese, sistemi të fillojë të kërkojë më pak operatorin për shkak të ngjashmërisë së shumicës së rasteve dhe shfaqjes së të ngjashme.
Si rezultat, bazuar në metodat e rrjetit nervor të përshkruar më sipër, u ndërtua një program eksperimental për të parashikuar dështimet e sistemit "Web-Consolidation". Qëllimi i këtij programi ishte, duke përdorur arkivin ekzistues të të dhënave të monitorimit dhe informacionit për dështimet e mëparshme, për të vlerësuar kompetencën e kësaj qasjeje për sistemet tona softuerike. Skema e programit është paraqitur më poshtë në Figurën 7.
Figura 7. Skema e parashikimit të dështimit bazuar në analizën e hapësirës metrike
Në diagram, mund të dallohen dy blloqe kryesore: kërkimi i periudhave anormale kohore në rrjedhën e të dhënave të monitorimit (metrika) dhe mekanizmi për minimizimin e rezultateve false. Shënim: Për qëllime eksperimentale, të dhënat merren nëpërmjet një lidhjeje JDBC nga baza e të dhënave në të cilën grafiti do t'i ruajë ato.
Më poshtë është ndërfaqja e sistemit të monitorimit të marrë si rezultat i zhvillimit (Figura 8).
Figura 8. Ndërfaqja e sistemit të monitorimit eksperimental
Ndërfaqja shfaq përqindjen e anomalive bazuar në metrikat e marra. Në rastin tonë, fatura është simuluar. Ne i kemi tashmë të gjitha të dhënat për disa javë dhe po i ngarkojmë gradualisht për të kontrolluar rastin e një anomalie që çon në dështim. Shiriti i statusit më të ulët shfaq përqindjen e përgjithshme të anomalive të të dhënave në një kohë të caktuar, e cila përcaktohet duke përdorur një kodues automatik. Gjithashtu, një përqindje e veçantë shfaqet për matjet e parashikuara, e cila llogaritet nga RNN LSTM.
Një shembull i zbulimit të anomalive bazuar në performancën e CPU duke përdorur rrjetin nervor RNN LSTM (Figura 9).
Figura 9. Zbulimi i RNN LSTM
Një rast mjaft i thjeshtë, në thelb një ndryshim i zakonshëm, por që çon në dështim të sistemit, u llogarit me sukses duke përdorur RNN LSTM. Treguesi i anomalisë në këtë periudhë kohore është 85-95%; çdo gjë mbi 80% (pragu u përcaktua eksperimentalisht) konsiderohet anomali.
Një shembull i zbulimit të anomalive kur sistemi nuk mund të nisej pas një përditësimi. Kjo situatë zbulohet nga autoenkoderi (Figura 10).
Figura 10. Shembull i zbulimit të autoenkoderit
Siç mund ta shihni nga figura, PermGen është mbërthyer në një nivel. Autoencoder e gjeti këtë të çuditshme sepse nuk kishte parë kurrë diçka të tillë më parë. Këtu anomalia mbetet 100% derisa sistemi të kthehet në gjendje pune. Shfaqet një anomali për të gjitha metrikat. Siç u përmend më herët, autoencoder nuk mund të lokalizojë anomalitë. Operatori thirret për të kryer këtë funksion në këto situata.
Përfundim
PC "Web-Consolidation" ka qenë në zhvillim për disa vite. Sistemi është në një gjendje mjaft stabile dhe numri i incidenteve të regjistruara është i vogël. Sidoqoftë, ishte e mundur të zbuloheshin anomali që çonin në dështim 5 - 10 minuta përpara se të ndodhte dështimi. Në disa raste, njoftimi paraprak i një dështimi do të ndihmonte në kursimin e kohës së planifikuar që është caktuar për kryerjen e punës "riparuese".
Bazuar në eksperimentet e kryera, është shumë herët për të nxjerrë përfundime përfundimtare. Deri më tani, rezultatet janë kontradiktore. Nga njëra anë, është e qartë se algoritmet e bazuara në rrjetet nervore janë në gjendje të gjejnë anomali "të dobishme". Nga ana tjetër, mbetet një përqindje e madhe e false pozitive dhe jo të gjitha anomalitë e zbuluara nga një specialist i kualifikuar në një rrjet nervor mund të zbulohen. Disavantazhet përfshijnë faktin se tani rrjeti nervor kërkon trajnim me një mësues për funksionimin normal.
Për të zhvilluar më tej sistemin e parashikimit të dështimit dhe për ta sjellë atë në një gjendje të kënaqshme, mund të parashikohen disa mënyra. Kjo është një analizë më e detajuar e rasteve me anomali që çojnë në dështim, për shkak të kësaj shtese në listën e metrikave të rëndësishme që ndikojnë shumë në gjendjen e sistemit dhe hedhjes së të panevojshmeve që nuk e ndikojnë atë. Gjithashtu, nëse ecim në këtë drejtim, mund të bëjmë përpjekje për të specializuar algoritme posaçërisht për rastet tona me anomali që çojnë në dështime. Ka një mënyrë tjetër. Ky është një përmirësim në arkitekturat e rrjeteve nervore dhe duke rritur saktësinë e zbulimit me një reduktim të kohës së trajnimit.
Unë shpreh mirënjohjen time për kolegët e mi që më ndihmuan të shkruaj dhe të ruaj rëndësinë e këtij artikulli: dhe Sergei Finogenov.
Burimi: www.habr.com