Industriell utvikling av programvaresystemer krever stor oppmerksomhet på feiltoleransen til sluttproduktet, samt rask respons på feil og feil hvis de oppstår. Overvåking bidrar selvfølgelig til å reagere på feil og feil mer effektivt og raskt, men ikke nok. For det første er det veldig vanskelig å holde styr på et stort antall servere – det trengs et stort antall mennesker. For det andre må du ha en god forståelse av hvordan applikasjonen fungerer for å kunne forutsi tilstanden. Derfor trenger vi mange mennesker som har god forståelse for systemene vi utvikler, deres ytelse og funksjoner. La oss anta at selv om du finner nok folk som er villige til å gjøre dette, tar det fortsatt mye tid å trene dem.
Hva å gjøre? Det er her kunstig intelligens kommer oss til hjelp. Artikkelen vil snakke om (prediktivt vedlikehold). Denne tilnærmingen vinner aktivt popularitet. Det er skrevet en lang rekke artikler, blant annet om Habré. Store selskaper utnytter denne tilnærmingen til fulle for å opprettholde ytelsen til serverne sine. Etter å ha studert et stort antall artikler, bestemte vi oss for å prøve denne tilnærmingen. Hva kom ut av det?
Innledning
Det utviklede programvaresystemet går før eller siden i drift. Det er viktig for brukeren at systemet fungerer uten feil. Hvis en nødsituasjon oppstår, bør den løses med minimal forsinkelse.
For å forenkle teknisk støtte for et programvaresystem, spesielt hvis det er mange servere, brukes vanligvis overvåkingsprogrammer som tar beregninger fra et kjørende programvaresystem, gjør det mulig å diagnostisere tilstanden og hjelpe med å finne ut hva som forårsaket feilen. Denne prosessen kalles programvaresystemovervåking.
Figur 1. Grafana overvåkingsgrensesnitt
Beregninger er forskjellige indikatorer på et programvaresystem, dets utførelsesmiljø eller den fysiske datamaskinen som systemet kjører under med et tidsstempel for øyeblikket da beregningene ble mottatt. I statisk analyse kalles disse beregningene tidsserier. For å overvåke tilstanden til programvaresystemet, vises beregninger i form av grafer: tiden er på X-aksen, og verdiene er langs Y-aksen (figur 1). Flere tusen beregninger kan hentes fra et kjørende programvaresystem (fra hver node). De danner et rom av metrikker (flerdimensjonale tidsserier).
Siden et stort antall beregninger samles inn for komplekse programvaresystemer, blir manuell overvåking en vanskelig oppgave. For å redusere mengden data som analyseres av administratoren, inneholder overvåkingsverktøy verktøy for automatisk å identifisere mulige problemer. Du kan for eksempel konfigurere en utløser til å utløses når ledig diskplass faller under en spesifisert terskel. Du kan også automatisk diagnostisere en serveravslutning eller en kritisk nedgang i tjenestehastighet. I praksis gjør overvåkingsverktøy en god jobb med å oppdage feil som allerede har oppstått eller identifisere enkle symptomer på fremtidige feil, men generelt sett er det fortsatt en vanskelig nøtt å forutsi en mulig feil for dem. Prediksjon gjennom manuell analyse av beregninger krever involvering av kvalifiserte spesialister. Det er lav produktivitet. De fleste potensielle feil kan gå ubemerket hen.
I det siste har det såkalte prediktive vedlikeholdet av programvaresystemer blitt stadig mer populært blant store IT-programvareutviklingsselskaper. Essensen av denne tilnærmingen er å finne problemer som fører til systemforringelse i de tidlige stadiene, før den mislykkes, ved hjelp av kunstig intelligens. Denne tilnærmingen utelukker ikke fullstendig manuell overvåking av systemet. Det er et hjelpemiddel for overvåkingsprosessen som helhet.
Hovedverktøyet for å implementere prediktivt vedlikehold er oppgaven med å søke etter anomalier i tidsserier, siden når en anomali oppstår i dataene er det stor sannsynlighet for at etter noe tid det vil være en fiasko eller fiasko. En anomali er et visst avvik i ytelsen til et programvaresystem, for eksempel å identifisere forringelse i utførelseshastigheten til én type forespørsel eller en reduksjon i gjennomsnittlig antall betjente forespørsler på et konstant nivå av klientøkter.
Oppgaven med å søke etter uregelmessigheter for programvaresystemer har sine egne detaljer. I teorien er det nødvendig for hvert programvaresystem å utvikle eller avgrense eksisterende metoder, siden søket etter anomalier er veldig avhengig av dataene det utføres i, og dataene til programvaresystemer varierer sterkt avhengig av verktøyene for å implementere systemet , ned til hvilken datamaskin den kjører på.
Metoder for å søke etter anomalier ved forutsigelse av feil i programvaresystemer
Først av alt er det verdt å si at ideen om å forutsi feil ble inspirert av artikkelen . For å teste effektiviteten til tilnærmingen med automatisk søk etter anomalier, ble programvaresystemet Web-Consolidation valgt, som er et av prosjektene til NPO Krista-selskapet. Tidligere ble det utført manuell overvåking for den basert på de mottatte beregningene. Siden systemet er ganske komplekst, tas det et stort antall beregninger for det: JVM-indikatorer (søppeloppsamlerbelastning), indikatorer for operativsystemet som koden utføres under (virtuelt minne, % OS CPU-belastning), nettverksindikatorer (nettverksbelastning ), selve serveren (CPU-belastning, minne), wildfly-beregninger og applikasjonens egne beregninger for alle kritiske undersystemer.
Alle beregninger er hentet fra systemet ved bruk av grafitt. Opprinnelig ble hviskedatabasen brukt som en standardløsning for grafana, men etter hvert som klientbasen vokste, klarte grafitten ikke lenger, etter å ha brukt opp kapasiteten til DC-diskundersystemet. Etter dette ble det besluttet å finne en mer effektiv løsning. Valget ble tatt til fordel , som gjorde det mulig å redusere belastningen på diskundersystemet med en størrelsesorden og redusere den okkuperte diskplassen med fem til seks ganger. Nedenfor er et diagram over mekanismen for å samle inn beregninger ved bruk av grafitt+klikkhus (figur 2).
Figur 2. Opplegg for innsamling av beregninger
Diagrammet er hentet fra intern dokumentasjon. Den viser kommunikasjonen mellom grafana (overvåkingsgrensesnittet vi bruker) og grafitt. Fjerning av beregninger fra en applikasjon gjøres med separat programvare - . Han legger dem i grafitt.
Webkonsolideringssystemet har en rekke funksjoner som skaper problemer for å forutsi feil:
- Trenden endrer seg ofte. Ulike versjoner er tilgjengelige for dette programvaresystemet. Hver av dem bringer endringer i programvaredelen av systemet. Følgelig, på denne måten, påvirker utviklere direkte beregningene til et gitt system og kan forårsake en trendendring;
- implementeringsfunksjonen, så vel som formålene som klienter bruker dette systemet til, forårsaker ofte uregelmessigheter uten tidligere degradering;
- prosentandelen av anomalier i forhold til hele datasettet er liten (< 5 %);
- Det kan være hull i mottak av indikatorer fra systemet. I noen korte perioder klarer ikke overvåkingssystemet å innhente beregninger. For eksempel hvis serveren er overbelastet. Dette er avgjørende for å trene et nevralt nettverk. Det er behov for å fylle ut hullene syntetisk;
- Saker med uregelmessigheter er ofte kun relevante for en bestemt dato/måned/tid (sesongvariasjon). Dette systemet har klare regler for bruk av brukere. Følgelig er beregningene bare relevante for en bestemt tid. Systemet kan ikke brukes konstant, men bare i noen måneder: selektivt avhengig av år. Situasjoner oppstår når den samme oppførselen til beregninger i ett tilfelle kan føre til feil i programvaresystemet, men ikke i et annet.
Til å begynne med ble metoder for å oppdage anomalier i overvåkingsdata av programvaresystemer analysert. I artikler om dette emnet, når prosentandelen av anomalier er liten i forhold til resten av datasettet, foreslås det oftest å bruke nevrale nettverk.
Den grunnleggende logikken for å søke etter anomalier ved å bruke nevrale nettverksdata er vist i figur 3:
Figur 3. Søke etter anomalier ved hjelp av et nevralt nettverk
Basert på resultatet av prognosen eller gjenopprettingen av vinduet for gjeldende flyt av metrikker, beregnes avviket fra det mottatt fra det kjørende programvaresystemet. Hvis det er stor forskjell mellom metrikkene hentet fra programvaresystemet og det nevrale nettverket, kan vi konkludere med at det nåværende datasegmentet er unormalt. Følgende serie problemer oppstår for bruk av nevrale nettverk:
- for å fungere riktig i strømmemodus, må dataene for trening av nevrale nettverksmodeller bare inneholde "normale" data;
- det er nødvendig å ha en oppdatert modell for korrekt deteksjon. Endring av trender og sesongvariasjoner i beregninger kan forårsake et stort antall falske positiver i modellen. For å oppdatere den, er det nødvendig å tydelig bestemme tidspunktet når modellen er utdatert. Hvis du oppdaterer modellen senere eller tidligere, vil sannsynligvis et stort antall falske positiver følge.
Vi må heller ikke glemme å søke etter og forhindre hyppig forekomst av falske positiver. Det antas at de oftest vil oppstå i akutte situasjoner. Imidlertid kan de også være en konsekvens av en nevrale nettverksfeil på grunn av utilstrekkelig trening. Det er nødvendig å minimere antallet falske positive til modellen. Ellers vil falske spådommer kaste bort mye administratortid beregnet på å sjekke systemet. Før eller siden vil administratoren ganske enkelt slutte å svare på det "paranoide" overvåkingssystemet.
Tilbakevendende nevrale nettverk
For å oppdage anomalier i tidsserier kan du bruke med LSTM-minne. Det eneste problemet er at det bare kan brukes til prognoserte tidsserier. I vårt tilfelle er ikke alle beregninger forutsigbare. Et forsøk på å bruke RNN LSTM til en tidsserie er vist i figur 4.
Figur 4. Eksempel på et tilbakevendende nevralt nettverk med LSTM-minneceller
Som det fremgår av figur 4 var RNN LSTM i stand til å takle søket etter anomalier i denne tidsperioden. Der resultatet har en høy prediksjonsfeil (middelfeil), har det faktisk oppstått en anomali i indikatorene. Å bruke en enkelt RNN LSTM vil helt klart ikke være nok, siden den kan brukes på et lite antall beregninger. Kan brukes som en hjelpemetode for å søke etter anomalier.
Autoenkoder for feilprediksjon
– egentlig et kunstig nevralt nettverk. Inndatalaget er koder, utgangslaget er dekoder. Ulempen med alle nevrale nettverk av denne typen er at de ikke lokaliserer anomalier godt. En synkron autoencoder-arkitektur ble valgt.
Figur 5. Eksempel på autoencoder-operasjon
Autoenkodere trenes på vanlige data og finner deretter noe unormalt i dataene som mates til modellen. Akkurat det du trenger for denne oppgaven. Alt som gjenstår er å velge hvilken autoencoder som passer for denne oppgaven. Den arkitektonisk enkleste formen for en autoenkoder er et fremover, ikke-returnerende nevralt nettverk, som ligner veldig på (flerlagsperceptron, MLP), med et inngangslag, et utgangslag og ett eller flere skjulte lag som forbinder dem.
Forskjellene mellom autokodere og MLP-er er imidlertid at i en autokoder har utgangslaget samme antall noder som inngangslaget, og at i stedet for å bli trent til å forutsi en målverdi Y gitt av en inngang X, trenes autokoderen å rekonstruere sine egne Xs. Derfor er autoenkodere læringsmodeller uten tilsyn.
Autoenkoderens oppgave er å finne tidsindeksene r0 ... rn som tilsvarer de anomale elementene i inngangsvektoren X. Denne effekten oppnås ved å søke etter kvadratfeilen.
Figur 6. Synkron autokoder
For autoencoder ble valgt . Dens fordeler: muligheten til å bruke strømmebehandlingsmodus og et relativt mindre antall nevrale nettverksparametere sammenlignet med andre arkitekturer.
Mekanisme for å minimere falske positiver
På grunn av det faktum at ulike unormale situasjoner oppstår, samt en mulig situasjon med utilstrekkelig trening av det nevrale nettverket, for anomalideteksjonsmodellen som ble utviklet, ble det bestemt at det var nødvendig å utvikle en mekanisme for å minimere falske positiver. Denne mekanismen er basert på en malbase som er klassifisert av administratoren.
(DTW-algoritme, fra engelsk dynamic time warping) lar deg finne den optimale korrespondansen mellom tidssekvenser. Først brukt i talegjenkjenning: brukes til å bestemme hvordan to talesignaler representerer den samme originale talte frasen. Deretter ble det funnet søknad om det på andre områder.
Hovedprinsippet for å minimere falske positiver er å samle en database med standarder ved hjelp av en operatør som klassifiserer mistenkelige tilfeller oppdaget ved hjelp av nevrale nettverk. Deretter sammenlignes den klassifiserte standarden med tilfellet som systemet oppdaget, og det konkluderes om saken er falsk eller fører til feil. DTW-algoritmen brukes nøyaktig for å sammenligne to tidsserier. Det viktigste minimeringsverktøyet er fortsatt klassifisering. Det forventes at etter å ha samlet inn et stort antall referansetilfeller, vil systemet begynne å spørre operatøren mindre på grunn av likheten i de fleste tilfeller og forekomsten av lignende.
Som et resultat, basert på de nevrale nettverksmetodene beskrevet ovenfor, ble et eksperimentelt program bygget for å forutsi feil i "Web-Consolidation"-systemet. Målet med dette programmet var, ved å bruke det eksisterende arkivet med overvåkingsdata og informasjon om tidligere feil, å evaluere kompetansen til denne tilnærmingen for våre programvaresystemer. Opplegget for programmet er presentert nedenfor i figur 7.
Figur 7. Feilprediksjonsskjema basert på metrisk romanalyse
I diagrammet kan to hovedblokker skilles: søket etter unormale tidsperioder i overvåkingsdatastrømmen (metrikker) og mekanismen for å minimere falske positiver. Merk: For eksperimentelle formål innhentes dataene via en JDBC-tilkobling fra databasen som grafitt vil lagre dem i.
Følgende er grensesnittet til overvåkingssystemet oppnådd som et resultat av utviklingen (Figur 8).
Figur 8. Grensesnitt til det eksperimentelle overvåkingssystemet
Grensesnittet viser prosentandelen av uregelmessigheter basert på de mottatte beregningene. I vårt tilfelle er kvitteringen simulert. Vi har allerede alle dataene i flere uker og laster dem gradvis for å sjekke tilfellet med en anomali som fører til feil. Den nedre statuslinjen viser den totale prosentandelen av dataavvik på et gitt tidspunkt, som bestemmes ved hjelp av en autoenkoder. Dessuten vises en egen prosentandel for de anslåtte beregningene, som beregnes av RNN LSTM.
Et eksempel på avviksdeteksjon basert på CPU-ytelse ved bruk av RNN LSTM nevrale nettverk (Figur 9).
Figur 9. RNN LSTM-funn
Et ganske enkelt tilfelle, i hovedsak en vanlig uteligger, men som førte til systemfeil, ble vellykket beregnet ved hjelp av RNN LSTM. Anomaliindikatoren i denne tidsperioden er 85–95 %; alt over 80 % (terskelverdien ble bestemt eksperimentelt) regnes som en anomali.
Et eksempel på en anomalideteksjon når systemet ikke var i stand til å starte opp etter en oppdatering. Denne situasjonen oppdages av autoenkoderen (Figur 10).
Figur 10. Eksempel på autoencoder-deteksjon
Som du kan se av figuren, sitter PermGen fast på ett nivå. Autoenkoderen fant dette merkelig fordi den aldri hadde sett noe lignende før. Her forblir uregelmessigheten 100 % til systemet går tilbake til en fungerende tilstand. En anomali vises for alle beregninger. Som nevnt tidligere, kan ikke autokoderen lokalisere anomalier. Operatøren blir bedt om å utføre denne funksjonen i disse situasjonene.
Konklusjon
PC «Web-Consolidation» har vært under utvikling i flere år. Systemet er i en ganske stabil tilstand, og antall registrerte hendelser er lite. Det var imidlertid mulig å finne anomalier som førte til feil 5 - 10 minutter før feilen oppstod. I noen tilfeller vil varsling av feil på forhånd bidra til å spare den planlagte tiden som er tildelt for å utføre "reparasjons"-arbeid.
Basert på forsøkene som ble utført, er det for tidlig å trekke endelige konklusjoner. Så langt er resultatene motstridende. På den ene siden er det klart at algoritmer basert på nevrale nettverk er i stand til å finne "nyttige" anomalier. På den annen side er det fortsatt en stor prosentandel av falske positive, og ikke alle anomalier oppdaget av en kvalifisert spesialist i et nevralt nettverk kan oppdages. Ulempene inkluderer det faktum at nå krever det nevrale nettverket opplæring med lærer for normal drift.
For å videreutvikle feilprediksjonssystemet og bringe det til en tilfredsstillende tilstand, kan det tenkes flere måter. Dette er en mer detaljert analyse av tilfeller med uregelmessigheter som fører til feil, på grunn av dette tillegget til listen over viktige beregninger som i stor grad påvirker systemets tilstand, og forkasting av unødvendige som ikke påvirker det. Dessuten, hvis vi beveger oss i denne retningen, kan vi gjøre forsøk på å spesialisere algoritmer spesielt for våre tilfeller med anomalier som fører til feil. Det er en annen måte. Dette er en forbedring av nevrale nettverksarkitekturer og øker derved deteksjonsnøyaktigheten med en reduksjon i treningstid.
Jeg uttrykker min takknemlighet til mine kolleger som hjalp meg med å skrive og opprettholde relevansen til denne artikkelen: og Sergei Finogenov.
Kilde: www.habr.com