Industriel udvikling af softwaresystemer kræver stor opmærksomhed på det færdige produkts fejltolerance, samt hurtig reaktion på fejl og fejl, hvis de opstår. Overvågning hjælper selvfølgelig med at reagere på fejl og fejl mere effektivt og hurtigt, men ikke nok. For det første er det meget svært at holde styr på et stort antal servere – der er brug for et stort antal mennesker. For det andet skal du have en god forståelse af, hvordan applikationen fungerer, for at kunne forudsige dens tilstand. Derfor har vi brug for en masse mennesker, der har en god forståelse for de systemer, vi udvikler, deres ydeevne og funktioner. Lad os antage, at selvom du finder nok folk, der er villige til at gøre dette, tager det stadig meget tid at træne dem.
Hvad skal man gøre? Det er her, kunstig intelligens kommer os til hjælp. Artiklen vil tale om (forudsigende vedligeholdelse). Denne tilgang vinder aktivt popularitet. Der er skrevet en lang række artikler, blandt andet om Habré. Store virksomheder gør fuld brug af denne tilgang til at opretholde ydeevnen på deres servere. Efter at have studeret et stort antal artikler besluttede vi at prøve denne tilgang. Hvad kom der ud af det?
Indledning
Det udviklede softwaresystem går før eller siden i drift. Det er vigtigt for brugeren, at systemet fungerer uden fejl. Hvis en nødsituation opstår, skal den løses med minimal forsinkelse.
For at forenkle teknisk support af et softwaresystem, især hvis der er mange servere, bruges der normalt overvågningsprogrammer, der tager målinger fra et kørende softwaresystem, gør det muligt at diagnosticere dets tilstand og hjælpe med at bestemme, hvad der præcist forårsagede fejlen. Denne proces kaldes softwaresystemovervågning.
Figur 1. Grafana overvågningsgrænseflade
Metrikker er forskellige indikatorer for et softwaresystem, dets eksekveringsmiljø eller den fysiske computer, som systemet kører under med et tidsstempel for det øjeblik, hvor metrikken blev modtaget. I statisk analyse kaldes disse metrikker for tidsserier. For at overvåge softwaresystemets tilstand vises metrikker i form af grafer: tiden er på X-aksen, og værdierne er langs Y-aksen (figur 1). Flere tusinde målinger kan tages fra et kørende softwaresystem (fra hver node). De danner et rum af metrikker (multidimensionelle tidsserier).
Da der indsamles et stort antal målinger for komplekse softwaresystemer, bliver manuel overvågning en vanskelig opgave. For at reducere mængden af data, der analyseres af administratoren, indeholder overvågningsværktøjer værktøjer til automatisk at identificere mulige problemer. For eksempel kan du konfigurere en trigger til at udløse, når ledig diskplads falder under en specificeret tærskel. Du kan også automatisk diagnosticere en servernedlukning eller en kritisk nedgang i servicehastigheden. I praksis gør overvågningsværktøjer et godt stykke arbejde med at opdage fejl, der allerede er opstået, eller identificere simple symptomer på fremtidige fejl, men generelt er det stadig en svær nød at knække for dem at forudsige en mulig fejl. Forudsigelse gennem manuel analyse af metrikker kræver involvering af kvalificerede specialister. Det er lav produktivitet. De fleste potentielle fejl kan gå ubemærket hen.
På det seneste er den såkaldte prædiktive vedligeholdelse af softwaresystemer blevet stadig mere populær blandt store IT-softwareudviklingsvirksomheder. Essensen af denne tilgang er at finde problemer, der fører til systemnedbrydning i de tidlige stadier, før det fejler, ved hjælp af kunstig intelligens. Denne tilgang udelukker ikke fuldstændig manuel overvågning af systemet. Det er en hjælp til overvågningsprocessen som helhed.
Det vigtigste værktøj til at implementere prædiktiv vedligeholdelse er opgaven med at søge efter uregelmæssigheder i tidsserier, da når der opstår en anomali i data er der stor sandsynlighed for, at efter nogen tid der vil være en fiasko eller fiasko. En anomali er en vis afvigelse i ydeevnen af et softwaresystem, såsom at identificere forringelse af udførelseshastigheden af en type anmodning eller et fald i det gennemsnitlige antal servicerede anmodninger på et konstant niveau af klientsessioner.
Opgaven med at søge efter uregelmæssigheder for softwaresystemer har sine egne detaljer. I teorien er det for hvert softwaresystem nødvendigt at udvikle eller forfine eksisterende metoder, da søgningen efter anomalier er meget afhængig af de data, hvori den udføres, og softwaresystemernes data varierer meget afhængigt af værktøjerne til implementering af systemet , ned til hvilken computer den kører på.
Metoder til at søge efter anomalier ved forudsigelse af fejl i softwaresystemer
Først og fremmest er det værd at sige, at ideen om at forudsige fejl var inspireret af artiklen . For at teste effektiviteten af tilgangen med automatisk søgning efter uregelmæssigheder, blev Web-Consolidation-softwaresystemet valgt, som er et af NPO Krista-virksomhedens projekter. Tidligere blev der udført manuel overvågning for det baseret på de modtagne målinger. Da systemet er ret komplekst, tages der et stort antal målinger for det: JVM-indikatorer (skraldesamlerbelastning), indikatorer for det operativsystem, som koden udføres under (virtuel hukommelse, % OS CPU-belastning), netværksindikatorer (netværksbelastning ), selve serveren (CPU-belastning, hukommelse), wildfly-metrics og applikationens egne metrics for alle kritiske undersystemer.
Alle målinger er taget fra systemet ved hjælp af grafit. Oprindeligt blev hviskedatabasen brugt som en standardløsning til grafana, men efterhånden som klientbasen voksede, kunne grafit ikke længere klare sig, efter at have opbrugt kapaciteten af DC-diskundersystemet. Herefter blev det besluttet at finde en mere effektiv løsning. Valget blev truffet til fordel , som gjorde det muligt at reducere belastningen på diskundersystemet med en størrelsesorden og reducere den optagede diskplads med fem til seks gange. Nedenfor er et diagram over mekanismen til indsamling af metrikker ved hjælp af grafit+klikhus (figur 2).
Figur 2. Skema til indsamling af metrikker
Diagrammet er taget fra intern dokumentation. Det viser kommunikationen mellem grafana (det overvågnings-UI, vi bruger) og grafit. Fjernelse af metrics fra en applikation udføres af separat software - . Han lægger dem i grafit.
Webkonsolideringssystemet har en række funktioner, der skaber problemer med at forudsige fejl:
- Tendensen skifter ofte. Forskellige versioner er tilgængelige til dette softwaresystem. Hver af dem bringer ændringer til softwaredelen af systemet. Derfor påvirker udviklere på denne måde direkte metrikken for et givet system og kan forårsage en trendændring;
- implementeringsfunktionen, såvel som de formål, som klienter bruger dette system til, forårsager ofte uregelmæssigheder uden forudgående forringelse;
- procentdelen af anomalier i forhold til hele datasættet er lille (< 5 %);
- Der kan være huller i at modtage indikatorer fra systemet. I nogle korte perioder formår overvågningssystemet ikke at opnå målinger. For eksempel hvis serveren er overbelastet. Dette er afgørende for træning af et neuralt netværk. Der er behov for at udfylde hullerne syntetisk;
- Sager med anomalier er ofte kun relevante for en bestemt dato/måned/tid (sæsonbestemt). Dette system har klare regler for dets brug af brugere. Målingerne er derfor kun relevante for et bestemt tidspunkt. Systemet kan ikke bruges konstant, men kun i nogle måneder: selektivt afhængigt af år. Der opstår situationer, når den samme opførsel af metrikker i ét tilfælde kan føre til en fejl i softwaresystemet, men ikke i et andet.
Til at begynde med blev metoder til at opdage uregelmæssigheder i overvågningsdata af softwaresystemer analyseret. I artikler om dette emne, når procentdelen af anomalier er lille i forhold til resten af datasættet, foreslås det oftest at bruge neurale netværk.
Den grundlæggende logik til at søge efter anomalier ved hjælp af neurale netværksdata er vist i figur 3:
Figur 3. Søgning efter anomalier ved hjælp af et neuralt netværk
Baseret på resultatet af prognosen eller gendannelsen af vinduet for det aktuelle flow af metrikker, beregnes afvigelsen fra den, der modtages fra det kørende softwaresystem. Hvis der er en stor forskel mellem metrikken opnået fra softwaresystemet og det neurale netværk, kan vi konkludere, at det aktuelle datasegment er unormalt. Følgende række problemer opstår ved brugen af neurale netværk:
- for at fungere korrekt i streamingtilstand skal dataene til træning af neurale netværksmodeller kun omfatte "normale" data;
- det er nødvendigt at have en opdateret model for korrekt detektion. Ændring af tendenser og sæsonbestemte målinger kan forårsage et stort antal falske positiver i modellen. For at opdatere det er det nødvendigt klart at bestemme tidspunktet, hvor modellen er forældet. Hvis du opdaterer modellen senere eller tidligere, vil der højst sandsynligt følge et stort antal falske positiver.
Vi må heller ikke glemme at søge efter og forhindre den hyppige forekomst af falske positiver. Det antages, at de oftest vil forekomme i akutte situationer. De kan dog også være en konsekvens af en neural netværksfejl på grund af utilstrækkelig træning. Det er nødvendigt at minimere antallet af falske positive i modellen. Ellers vil falske forudsigelser spilde en masse administratortid beregnet på at tjekke systemet. Før eller siden vil administratoren simpelthen holde op med at reagere på det "paranoide" overvågningssystem.
Tilbagevendende neurale netværk
For at opdage uregelmæssigheder i tidsserier kan du bruge med LSTM-hukommelse. Det eneste problem er, at det kun kan bruges til forudsagte tidsserier. I vores tilfælde er ikke alle målinger forudsigelige. Et forsøg på at anvende RNN LSTM til en tidsserie er vist i figur 4.
Figur 4. Eksempel på et tilbagevendende neuralt netværk med LSTM-hukommelsesceller
Som det kan ses af figur 4, var RNN LSTM i stand til at klare søgningen efter anomalier i denne tidsperiode. Hvor resultatet har en høj forudsigelsesfejl (middelfejl), er der faktisk opstået en anomali i indikatorerne. Brug af en enkelt RNN LSTM vil tydeligvis ikke være nok, da den kan anvendes på et lille antal målinger. Kan bruges som en hjælpemetode til at søge efter anomalier.
Autoencoder til fejlforudsigelse
- i det væsentlige et kunstigt neuralt netværk. Inputlaget er encoder, outputlaget er dekoder. Ulempen ved alle neurale netværk af denne type er, at de ikke lokaliserer anomalier godt. En synkron autoencoder-arkitektur blev valgt.
Figur 5. Eksempel på autoencoder-drift
Autoencodere trænes på normale data og finder derefter noget unormalt i de data, der føres til modellen. Lige hvad du skal bruge til denne opgave. Tilbage er blot at vælge, hvilken autoencoder der er egnet til denne opgave. Den arkitektonisk enkleste form for en autoencoder er et fremadrettet, ikke-tilbagevendende neuralt netværk, som ligner meget (flerlagsperceptron, MLP), med et inputlag, et outputlag og et eller flere skjulte lag, der forbinder dem.
Forskellene mellem autoencodere og MLP'er er imidlertid, at i en autoencoder har outputlaget det samme antal noder som inputlaget, og at autoencoderen trænes i stedet for at blive trænet til at forudsige en målværdi Y givet af et input X. at rekonstruere sine egne X'er. Derfor er Autoencoders uovervågede læringsmodeller.
Autoencoderens opgave er at finde tidsindekserne r0 ... rn svarende til de anomale elementer i inputvektoren X. Denne effekt opnås ved at søge efter den kvadratiske fejl.
Figur 6. Synkron autoencoder
For autoencoder blev valgt . Dens fordele: evnen til at bruge streaming-behandlingstilstand og et relativt mindre antal neurale netværksparametre sammenlignet med andre arkitekturer.
Mekanisme til at minimere falske positiver
På grund af det faktum, at der opstår forskellige unormale situationer, samt en mulig situation med utilstrækkelig træning af det neurale netværk til den anomalidetektionsmodel, der er under udvikling, blev det besluttet, at det var nødvendigt at udvikle en mekanisme til at minimere falske positiver. Denne mekanisme er baseret på en skabelonbase, der er klassificeret af administratoren.
(DTW-algoritme, fra den engelske dynamic time warping) giver dig mulighed for at finde den optimale overensstemmelse mellem tidssekvenser. Først brugt i talegenkendelse: bruges til at bestemme, hvordan to talesignaler repræsenterer den samme originale talte sætning. Efterfølgende er der fundet anvendelse til det på andre områder.
Hovedprincippet for at minimere falske positiver er at indsamle en database med standarder ved hjælp af en operatør, der klassificerer mistænkelige tilfælde opdaget ved hjælp af neurale netværk. Dernæst sammenlignes den klassificerede standard med den sag, som systemet opdagede, og der konkluderes om, hvorvidt sagen er falsk eller fører til en fejl. DTW-algoritmen bruges præcist til at sammenligne to tidsserier. Det vigtigste minimeringsværktøj er stadig klassificering. Det forventes, at systemet efter at have indsamlet et stort antal referencesager vil begynde at spørge operatøren mindre på grund af ligheden i de fleste tilfælde og forekomsten af lignende.
Som et resultat, baseret på de ovenfor beskrevne neurale netværksmetoder, blev der bygget et eksperimentelt program til at forudsige fejl i "Web-Consolidation"-systemet. Målet med dette program var, ved at bruge det eksisterende arkiv af overvågningsdata og information om tidligere fejl, at evaluere kompetencen af denne tilgang til vores softwaresystemer. Skemaet for programmet er præsenteret nedenfor i figur 7.
Figur 7. Fejlforudsigelsesskema baseret på metrisk rumanalyse
I diagrammet kan der skelnes mellem to hovedblokke: søgningen efter unormale tidsperioder i overvågningsdatastrømmen (metrics) og mekanismen til at minimere falske positiver. Bemærk: Til eksperimentelle formål opnås dataene via en JDBC-forbindelse fra databasen, som grafit gemmer dem i.
Det følgende er grænsefladen for overvågningssystemet opnået som et resultat af udviklingen (figur 8).
Figur 8. Interface af det eksperimentelle overvågningssystem
Grænsefladen viser procentdelen af anomali baseret på de modtagne målinger. I vores tilfælde er kvitteringen simuleret. Vi har allerede alle data i flere uger og indlæser dem gradvist for at kontrollere tilfældet med en uregelmæssighed, der fører til fejl. Den nederste statuslinje viser den samlede procentdel af dataanomali på et givet tidspunkt, som bestemmes ved hjælp af en autoencoder. Der vises også en separat procentdel for de forudsagte metrics, som beregnes af RNN LSTM.
Et eksempel på anomalidetektion baseret på CPU-ydeevne ved brug af RNN LSTM neurale netværk (figur 9).
Figur 9. RNN LSTM opdagelse
Et ret simpelt tilfælde, i det væsentlige en almindelig afviger, men som førte til systemfejl, blev med succes beregnet ved hjælp af RNN LSTM. Anomaliindikatoren i denne periode er 85-95%; alt over 80% (tærsklen blev bestemt eksperimentelt) betragtes som en anomali.
Et eksempel på en uregelmæssig registrering, når systemet ikke var i stand til at starte efter en opdatering. Denne situation detekteres af autoencoderen (Figur 10).
Figur 10. Eksempel på autoencoder-detektion
Som du kan se på figuren, sidder PermGen fast på et niveau. Autoencoderen fandt dette mærkeligt, fordi det aldrig havde set noget lignende før. Her forbliver anomalien 100 %, indtil systemet vender tilbage til en arbejdstilstand. Der vises en anomali for alle metrics. Som tidligere nævnt kan autoencoderen ikke lokalisere anomalier. Operatøren opfordres til at udføre denne funktion i disse situationer.
Konklusion
PC "Web-Consolidation" har været under udvikling i flere år. Systemet er i en forholdsvis stabil tilstand, og antallet af registrerede hændelser er lille. Det var dog muligt at finde anomalier, der førte til svigt 5 - 10 minutter før fejlen opstod. I nogle tilfælde vil anmeldelse af en fejl på forhånd hjælpe med at spare den planlagte tid, der er afsat til at udføre "reparations"-arbejde.
På baggrund af de udførte forsøg er det for tidligt at drage endelige konklusioner. Indtil videre er resultaterne modstridende. På den ene side er det klart, at algoritmer baseret på neurale netværk er i stand til at finde "nyttige" anomalier. På den anden side er der stadig en stor procentdel af falske positiver, og ikke alle anomalier opdaget af en kvalificeret specialist i et neuralt netværk kan detekteres. Ulemperne omfatter det faktum, at det neurale netværk nu kræver træning med en lærer til normal drift.
For at videreudvikle fejlforudsigelsessystemet og bringe det til en tilfredsstillende tilstand, kan der tænkes på flere måder. Dette er en mere detaljeret analyse af sager med uregelmæssigheder, der fører til fejl, på grund af denne tilføjelse til listen over vigtige målinger, der i høj grad påvirker systemets tilstand, og kassering af unødvendige, der ikke påvirker det. Hvis vi bevæger os i denne retning, kan vi også gøre forsøg på at specialisere algoritmer specifikt til vores tilfælde med anomalier, der fører til fejl. Der er en anden måde. Dette er en forbedring af neurale netværksarkitekturer og øger derved detektionsnøjagtigheden med en reduktion i træningstid.
Jeg udtrykker min taknemmelighed til mine kolleger, som hjalp mig med at skrive og fastholde relevansen af denne artikel: og Sergei Finogenov.
Kilde: www.habr.com