Zhvillimi industrial i sistemeve softuerike 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 më efikas dhe më të shpejtë, por nuk është mjaftueshëm. Së pari, është shumë e vështirë të kontrollohet një numër i madh serverësh – nevojitet një numër i madh njerëzish. Së dyti, është e nevojshme të kuptosh mirë se si është ndërtuar aplikacioni, për të parashikuar gjendjen e tij. Prandaj, nevojiten shumë njerëz që kuptojnë mirë sistemet që po zhvillojmë, treguesit dhe veçoritë e tyre. Le të supozojmë se madje nëse gjenden mjaft njerëz që duan të merren me këtë, kërkohet aq kohë për t'i trajnuar ato.
Çfarë të bëjmë? Këtu na vjen në ndihmë Inteligjenca Artificiale. Artikulli do të flasë për (predictive maintenance). Ky qasje po fiton vazhdimisht popullaritet. Janë shkruar shumë artikuj, duke përfshirë edhe në Habra. Kompanitë e mëdha po e përdorin këtë qasje për të mbështetur funksionimin e serverëve të tyre. Pas studimit të një numri të madh artikujsh, ne vendosëm ta provojmë këtë qasje. Çfarë doli nga kjo?
Hyrje
Sistemi softuerik të zhvilluar herët ose vonë del në përdorim. Është e rëndësishme për përdoruesin që sistemi të funksionojë pa prishje. Nëse ndodhin situata të jashtëzakonshme, ato duhet të eliminohen me vonesa minimale.
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 që punon, ofrojnë mundësi për të diagnostikuar gjendjen e saj dhe ndihmojnë në përcaktimin e asaj që shkaktoi prishjen. Ky proces quhet monitorimi i sistemit softuerik.
Figura 1. Ndërfaqja për monitorimin grafana
Metodat janë tregues të ndryshëm të një sistemi programor, mjedisi të ekzekutimit të tij ose të një makine përpunuese fizike, nën të cilën funksionon sistemi me një etiketë kohe, në momentin kur janë marrë metodat. Në analizën statike, të dhënat e metrikave quhen serira temporale. Për të vëzhguar gjendjen e sistemit programor, metrikat paraqiten në formë graforesh: në akset X – koha, dhe në akset Y – vlerat (figura 1). Një sistem programor në funksion mund të regjistrojë disa mijëra metrika (nga çdo nyjë). Ato formojnë një hapësirë të metrikave (serira temporale shumëdimensionale).
Për shkak se sistemet programore komplekse regjistrojnë një numër të madh metrikash, monitorimi manual bëhet një detyrë e komplikuar. Për të reduktuar sasinë e të dhënave të analizuar nga administratori, mjetet e monitorimit përmbajnë mjete për identifikimin automatik të problemeve të mundshme. Për shembull, mund të konfigurohet një tregues që aktivizohet në rast se hapësira e lirë në disk zvogëlohet nën një prag të caktuar. Gjithashtu, mund të diagnostikohet automatikisht ndalimi i serverit ose ngadalësimi kritik i shërbimit. Në praktikë, mjetet e monitorimit munden mirë me zbulimin e dështimeve të ndodhura tashmë ose identifikimin e simptomave të thjeshta të dështimeve të ardhshme, por në përgjithësi parashikimi i dështimeve të mundshme mbetet një sfidë për ta. Parashikimi përmes analizës manuale të metrikave kërkon angazhimin e specialistëve të kualifikuar. Ky proces është me prodhueshmëri të ulët. Shumica e dështimeve të mundshme mund të mbeten të paivestuara.
Së fundmi, mes kompanive të mëdha IT që zhvillojnë software ka pasur një rritje të njohjes për atë që quhet shërbim parashikues i sistemeve programore. Thelbi i këtij qasje është identifikimi i defekteve që çojnë në degradimin e sistemit në faza të hershme, para se ai të dështojë, duke përdorur inteligjencën artificiale. Ky qasje nuk përjashton plotësisht monitorimin manual të sistemit. Ai është ndihmës për procesin e monitorimit në përgjithësi.
Instrumenti kryesor për realizimin e shërbimit parashikues është detyra e gjetjes së anomalisë në seritë temporale, pasi në rast të shfaqjes së një anomalie në të dhëna ka një probabilitet të lartë që pas pak kohësh do të ndodhi një dështim ose defekt. Anomalitë janë disa devijime të treguesve të sistemit programor, siç është identifikimi i degradimit të shpejtësisë në ekzekutimin e një lloj kërkese ose ulja e numrit mesatar të kërkesave të trajtuara në një nivel të caktuar të seancave të klientëve.
Detyra e gjetjes së anomali në sistemet programore ka specifikën e saj. Në parim, për çdo sistem programor duhet zhvilluar ose përmirësuar metodat ekzistuese, sepse gjetja e anomali varet shumë nga të dhënat, në të cilat kryhet, dhe të dhënat e sistemeve programore ndryshojnë shumë varësisht nga mjetet e implementimit të sistemit deri tek makina kompjuterike nën të cilën është ekzekutuar.
Metodat e gjetjes së anomali në parashikimin e dështimeve të sistemeve programore
Në radhë të parë, duhet të thuhet se ideja e parashikimit të dështimeve është frymëzuar nga artikulli . Për të provuar efektivitetin e qasjes me kërkimin automatik të anomali, u zgjodh sistemi programor «Web-Konsolidimi», i cili është një nga projektet e kompanisë NPO «Krista». Për të, më parë është kryer monitorim manual i metrikave të marra. Duke qenë se sistemi është mjaft i ndërlikuar, për të merret një numër i madh metrikash: treguesit e JVM (ngarkesa e mbledhësit të plehrave), treguesit e OS-së nën të cilën ekzekutohet kodi (memoria virtuale, % ngarkesa e CPU-së), treguesit e rrjetit (ngarkesa e rrjetit), të serverit vetë (ngarkesa e CPU-së, memories), metrikat e wildfly dhe metrikat e veta të aplikacionit për të gjitha subsistemet kritike.
Të gjitha metrikat merren nga sistemi me ndihmën e graphite. Fillimisht u përdor baza whisper si zgjidhje standarde për grafanë, por me rritjen e bazës së klientëve, graphite nuk përballoi më, duke shteruar kapacitetin e sistemit disk të DC. Pas kësaj, u mor vendimi për gjetjen e një zgjidhjeje më efikase. Zgjedhja u bë për , e cila lehtësoi ndjeshëm ngarkesën mbi sistemin disk dhe e reduktoi në pesë deri në gjashtë herë hapësirën e përdorur në disk. Më poshtë është paraqitur skema e mekanizmit të mbledhjes së metrikave me përdorimin e graphite+clickhouse (figurë 2).
Figura 2. Skema e marrjes së metrikave
Skema është marrë nga dokumentacioni internal. Ajo tregon shkëmbimin e të dhënave midis grafana (ndërfaqja e përdoruesit për monitorim, që ne përdorim) dhe graphite. Marrja e metrikeve nga aplikacioni realizohet nga një software i veçantë – . Ai gjithashtu i ruan ato në graphite.
Sistemi 'Web-Konsolidim' ka një sërë veçorish që krijojnë probleme për parashikimin e dështimeve:
- shpesh ndodh ndryshimi i trendit. Për këtë sistem programor lëshohen versione të ndryshme. Çdo njëra nga ato sjell ndryshime në pjesën programore të sistemit. Në përputhje me këtë, zhvilluesit ndikojnë drejtpërdrejt në metrikat e këtij sistemi dhe mund të shkaktojnë ndryshimin e trendit;
- veçoria e realizimit, si dhe qëllimet e përdoruesve të këtij sistemi shpesh shkaktojnë anomali pa degrada të mëparshme;
- përqindja 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ë shkurtër kohore, sistemi i monitorimit nuk arrin të marrë metrikat. Për shembull, nëse serveri është i ngarkuar. Kjo është kritike për trajnimet e rrjeteve nervore. Paraqitet nevoja për të plotësuar boshllëqet sintetikisht;
- Rastet me anomali shpesh janë të rëndësishme vetëm për një numër/muaj/kohe specifike (sezonalisht). Ky sistem ka një rregull të qartë përdorimi nga përdoruesit e tij. Për pasojë, metrikat janë të rëndësishme vetëm për kohë specifike. Sistemi mund të përdoret jo vazhdimisht, por vetëm në disa muaj: selektivisht në varësi të vitit. Ndodhin situata kur e njëjta sjellje e metrikave në një rast mund të çojë në dështimin e sistemit programor, kur në një rast tjetër nuk ndodh.
Nga fillimi janë analizuar metodat e zbuluar të anomalive në të dhënat e monitorimit të sistemeve programore. Në artikujt mbi këtë temë, me përqindje të vogla anomali në raport me grupin tjetër të të dhënave, shpesh sugjerohet të përdoren rrjetet nervore.
Logjika kryesore për kërkimin e anomalive përmes të dhënave të këtyre rrjeteve nervore është paraqitur në figurën 3:
Figura 3. Kërkimi i anomalive përmes rrjetit nervor
Rezultati të parashikimit ose rikuperimit të dritares së rrjedhës aktuale të metrikave llogariten devijimin nga ato të marra nga sistemi softuerik funksional. Në rast se ka një ndryshim të madh midis metrikave të marra nga sistemi softuerik dhe rrjetit nervor, mund të nxirret përfundimi për anomalinë e segmentit aktual të të dhënave. Lind një sërë problemesh për përdorimin e rrjeteve nervore:
- për të punuar siç duhet në modalitetin e rrjedhës, të dhënat për trajnimin e modeleve të rrjeteve nervore duhet të përfshijnë vetëm të dhëna "normale";
- duhet të kemi një model aktual për zbulimin e saktë. Ndryshimi i trendëve dhe sezonave në metrika mund të shkaktojë një numër të madh të aktivizimeve të gabuara të modelit. Për ta përditësuar atë, është e nevojshme të përcaktohet saktësisht koha kur modeli është bërë i vjetruar. Nëse modeli përditësohet vonë ose herët, me siguri do të ndodhin një numër i madh i aktivizimeve të gabuara.
Gjithashtu, nuk duhet harruar të kërkoni dhe parandaloni shfaqjen e shpeshtë të aktivizimeve të gabuara. Supozohet se ato do të ndodhin më shpesh në situata të jashtëzakonshme. Megjithatë, ato gjithashtu mund të jenë një pasojë e gabimit të rrjetit nervor për shkak të mjaftueshmërisë së dobët të trajnimit të tij. Është e nevojshme të minimizohet numri i aktivizimeve të gabuara të modelit. Në të kundërt, parashikimet e gabuara do të shpenzojnë shumë kohë të administratorit, e cila është e destinuar për verifikimin e sistemit. Herët ose vonë do të përfundojë që administratori thjesht do të ndalojë reagimin ndaj sistemit të monitorimit "paranoik".
Rrjeti nervor rekurent
Për zbulimin e anomaliave në seritë e kohës mund të aplikohet me memorie LSTM. Problemi është se ajo mund të aplikohet vetëm për seritë e kohës që parashikohen. Në rastin tonë, jo të gjitha metrikat janë të parashikueshme. Përpjekja për të aplikuar RNN LSTM për serinë e kohës është paraqitur në figurën 4.
Figura 4. Shembulli i punës së rrjetit nervor rekurent me qelizat e memories LSTM
Siç duket nga figura 4, RNN LSTM arriti të përballojë kërkimin e anomalive në këtë periudhë kohe. Aty ku rezultati ka një gabim të lartë në parashikim (gabimi mesatar), në të vërtetë ka ndodhur një anomali në treguesit. Përdorimi i vetëm të RNN LSTM është qartë i pasufishëm, pasi ajo është e aplikueshme për një numër të vogël metrikash. Mund të përdoret si një metodë ndihmëse për kërkimin e anomalive.
Auto-koduesi për parashikimin e dështimeve
– në thelb është një rrjet nervor artificial. Shtresa hyrëse – encoder, shtresa dalëse – decoder. Disavantazhi i të gjitha rrjeteve nervore të këtij lloji është se ato lokalizojnë dobët anomalitë. U zgjodh arkitektura e auto-koduesit sinkron.
Figura 5. Shembulli i funksionimit të auto-koduesit
Auto-koduesit mësohen mbi të dhënat normale dhe pastaj gjejnë diçka anormale në të dhënat e paraqitura në model. Pikërisht ajo që nevojitet për këtë detyrë. Tani mbetet vetëm të zgjidhet se cili nga auto-koduesit do të përshtatet për këtë detyrë. Forma arkitektonikisht më e thjeshtë e auto-koduesit është një rrjet nervor i drejtpërdrejtë, i njëanshëm, shumë i ngjashëm me (multilayer perceptron, MLP), me një nivel hyrës, nivel dalës dhe një ose më shumë shtresa të fshehta që i lidhin ato.
Megjithatë, ndryshimet midis auto-koduesve dhe MLP qëndrojnë në atë që në auto-koduesin niveli dalës ka të njëjtin numër nyjesh si niveli hyrës, dhe se në vend që të mësohet të parashikojë vlerën e synuar Y, të dhënë nga hyrja X, auto-koduesi mësohet të rikonstruktojë X-in e vet. Prandaj, auto-koduesit janë modele të të mësuarit pa mbikëqyrje.
Detyra e auto-koduesit është të gjejë indekset e kohës r0 … rn, që korrespondon me elementet anormale në vektorin hyrës X. Ky efekt arrihet duke kërkuar gabimin katror.
Figura 6. Auto-koduesi sinkron
Për auto-koduesin u zgjodh . Avantazhet e saj: mundësia e përdorimit të modit të procesimit të rrjedhës dhe numri relativisht më i vogël i parametrave të rrjetit nervor në krahasim me arkitektura të tjera.
Mekanizmi i minimizimit të alarmëve fals
Duke marrë parasysh se ndodhin situata të ndryshme jashtëzakonisht, si dhe mundësia e mungesës së trajnimit të duhur të rrjetit nervor, për modelin e zhvilluar të zbulimit të anomalive u mor vendim për nevojën e zhvillimit të një mekanizmi për minimizimin e sinjaleve të rreme. Ky mekanizëm bazon në një bazë të modeleve, të cilën e klasifikon administratori.
(Algoritmi DTW, nga anglishtja dynamic time warping) lejon të gjejë përputhjen optimale midis sekuencave të kohës. U aplikua për herë të parë në njohjen e zërit: u përdor për të përcaktuar se si dy sinjale të zërit paraqesin të njëjtën frazë të thënë. Më vonë u gjet një aplikim edhe në fusha të tjera.
Principi kryesor i minimizimit të sinjaleve të rreme është mbledhja e një baze etalonësh nga një operator, i cili klasifikon rastet e dyshuara, të zbuluara nga rrjetet nervore. Më pas, bëhet krahasimi i etalonit të klasifikuar me rastin që sistemi e zbuloi, dhe merret një përfundim mbi se a i përket rasti një sinjali të rremë apo një dështimi. Pikërisht për krahasimin e dy serive të kohës përdoret algoritmi DTW. Instrumenti kryesor për minimizim megjithatë mbetet klasifikimi. Supozohet se pas mbledhjes së një sasie të madhe rastesh etalon, sistemi do të fillojë të pyesë më pak operatorin në shkak të ngjashmërisë së shumicës së rasteve dhe shpërthimit të ngjashëm.
Si përfundim, mbi bazën e metodave të përshkruara më sipër, u ndërtua një program eksperimental për parashikimin e dështimeve të sistemit "Web-Konsolidimi". Qëllimi i këtij programi ishte, duke përdorur arkuimin ekzistues të të dhënave të monitorimit dhe informacionin mbi dështimet që kishin ndodhur, për të vlerësuar kompetencën e këtij qasje për sistemet tona programore. Skema e punës së programit përshkruhet 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ë metrikeve
Në skemë mund të identifikohen dy blloqe kryesore: kërkimi i segmenteve anomale të kohës në rrjedhën e të dhënave të monitorimit (metrikat) dhe mekanizmi i minimizimit të sinjaleve 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 ruhet graphite.
Këtu është ndërfaqja e sistemit të monitorimit të zhvilluar (figura 8).
Figura 8. Ndërfaqja e sistemit eksperimental të monitorimit
Në ndërfaqe tregohet përqindja e anomalisë për metrikat e marra. Në rastin tonë, marrja simulohet. Ne tashmë kemi të gjitha të dhënat për disa javë dhe po i ngarkojmë gradualisht për të verifikuar rastin me anomali që çon në dështim. Në shiritin e statusit të poshtëm tregohet përqindja totale e anomalisë së të dhënave në këtë moment, e cila përcaktohet me ndihmën e auto-koduesit. Po ashtu, për metrikat e parashikuara tregohet një përqindje e veçantë, e cila llogaritet nga RNN LSTM.
Shembulli i zbulimit të anomalisë në treguesit e CPU-së me ndihmën e rrjetit nervor RNN LSTM (figura 9).
Figura 9. Zbulimi me RNN LSTM
Një rast mjaft i thjeshtë, në thelb një shpërthim i zakonshëm, por që çon në dështimin e sistemit, u zbulua me sukses me ndihmën e RNN LSTM. Treguesi i anomalisë në këtë periudhë kohore është 85 – 95%, gjithçka mbi 80% (kjo prag është përcaktuar eksperimentalisht) konsiderohet një anomali.
Shembulli i zbulimit të anomalisë kur sistemi nuk ishte në gjendje të ngarkohej pas përditësimit. Kjo situatë identifikohet nga auto-koduesi (figura 10).
Figura 10. Shembulli i zbulimit nga auto-koduesi
Siç duket nga figura, PermGen u ngatërrua në një nivel. Auto-koduesi e konsideroi këtë të çuditshëm, pasi nuk kishte parë asgjë të ngjashme më parë. Këtu anomalia mbahet në 100% deri në rikthimin e sistemit në gjendje funksionale. Anomalia tregohet për të gjitha metrikat. Siç u përmend më parë, auto-koduesi nuk është në gjendje të lokalizojë anomali. Operatorët janë të thirrur për të kryer këtë funksion në këto situata.
Përfundim
PC «Web-Konsolidimi» po zhvillohet 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ë gjenden anomali që çojnë në dështim për 5 – 10 minuta para se ndodhi dështimi. Në disa raste, njoftimi për dështim do të ndihmonte të kurseni kohën e paraparë që i është kushtuar kryerjes së punimeve "reparimtare".
Në eksperimet që arritëm të kryejmë, është akoma herët për të bërë përfundime përfundimtare. Deri më tani, rezultatet janë kontradiktore. Nga njëra anë, është e qartë se algoritmet e bazuara në rrjete neurale janë në gjendje të zbulojnë anomali "të dobishme". Nga ana tjetër, mbetet një përqindje e madhe e alarmëve të rremë, dhe nuk të gjitha anomali që një specialist i kualifikuar i zbulohet rrjetit nervor arrijnë të duken. Një mangësi është se tani për tani rrjeti nervor kërkon mësim të udhëhequr për të funksionuar normalisht.
Për zhvillimin e mëtejshëm të sistemit të parashikimit të defekteve dhe për t'i dhënë atij një gjendje të kënaqshme, mund të parashikohet disa rrugë. Kjo është një analizë më e detajuar e rasteve me anomali që çojnë në dështim, duke e pasuruar kështu listën e metrikave të rëndësishme që ndikojnë shumë në gjendjen e sistemit, dhe duke hequr ato të tepërta që nuk kanë ndikim në të. Gjithashtu, nëse ecet në këtë drejtim, mund të bëhen përpjekje për të specializuar algoritmet konkretisht për rastet tona me anomali që çojnë në defekte. Ka edhe një rrugë tjetër. Kjo është përmirësimi i strukturave të rrjeteve neurale dhe rritja e saktësisë së zbulesave duke reduktuar kohën e mësimit.
Shpreh mirënjohjen time ndaj kolegëve që më ndihmuan me shkruan dhe mbajtjen e aktualitetit të këtij artikulli: dhe Sergey Finogenov.
Burimi: habr.com
