De industriële ontwikkeling van softwaresystemen vereist veel aandacht voor de fouttolerantie van het eindproduct, evenals een snelle reactie op storingen en storingen als deze zich voordoen. Monitoring helpt uiteraard om efficiënter en sneller op storingen en mislukkingen te reageren, maar niet genoeg. Ten eerste is het erg moeilijk om een groot aantal servers bij te houden - er zijn een groot aantal mensen nodig. Ten tweede moet u goed begrijpen hoe de applicatie werkt om de staat ervan te kunnen voorspellen. Daarom hebben we veel mensen nodig die een goed begrip hebben van de systemen die we ontwikkelen, hun prestaties en functies. Laten we ervan uitgaan dat zelfs als je genoeg mensen vindt die bereid zijn dit te doen, het nog steeds veel tijd kost om ze op te leiden.
Wat moeten we doen? Dit is waar kunstmatige intelligentie ons te hulp komt. Het artikel zal erover praten (voorspellend onderhoud). Deze aanpak wint actief aan populariteit. Er is een groot aantal artikelen geschreven, onder meer over Habré. Grote bedrijven maken volledig gebruik van deze aanpak om de prestaties van hun servers op peil te houden. Nadat we een groot aantal artikelen hadden bestudeerd, besloten we deze aanpak te proberen. Wat is er van gekomen?
Introductie
Het ontwikkelde softwaresysteem wordt vroeg of laat in gebruik genomen. Voor de gebruiker is het belangrijk dat het systeem storingsvrij werkt. Als zich toch een noodsituatie voordoet, moet deze met minimale vertraging worden opgelost.
Om de technische ondersteuning van een softwaresysteem te vereenvoudigen, vooral als er veel servers zijn, worden meestal monitoringprogramma's gebruikt die gegevens van een draaiend softwaresysteem verzamelen, het mogelijk maken de toestand ervan te diagnosticeren en te helpen bepalen wat precies de fout heeft veroorzaakt. Dit proces wordt softwaresysteemmonitoring genoemd.
Figuur 1. Grafana-monitoringinterface
Metrieken zijn verschillende indicatoren van een softwaresysteem, de uitvoeringsomgeving ervan, of de fysieke computer waarop het systeem draait, met een tijdstempel van het moment waarop de metrieken werden ontvangen. In statische analyse worden deze statistieken tijdreeksen genoemd. Om de status van het softwaresysteem te controleren, worden statistieken weergegeven in de vorm van grafieken: de tijd staat op de X-as en waarden staan langs de Y-as (Figuur 1). Van een draaiend softwaresysteem (van elk knooppunt) kunnen enkele duizenden meetgegevens worden gehaald. Ze vormen een ruimte van metrieken (multidimensionale tijdreeksen).
Omdat voor complexe softwaresystemen een groot aantal meetgegevens wordt verzameld, wordt handmatige monitoring een moeilijke taak. Om de hoeveelheid gegevens die door de beheerder wordt geanalyseerd te verminderen, bevatten monitoringtools tools om mogelijke problemen automatisch te identificeren. U kunt bijvoorbeeld een trigger configureren om te activeren wanneer de vrije schijfruimte onder een bepaalde drempel daalt. U kunt ook automatisch een diagnose stellen van een serveruitschakeling of een kritieke vertraging van de servicesnelheid. In de praktijk kunnen monitoringinstrumenten goed fouten opsporen die al hebben plaatsgevonden of eenvoudige symptomen van toekomstige mislukkingen identificeren, maar over het algemeen blijft het voorspellen van een mogelijke mislukking voor hen een moeilijke noot om te kraken. Voorspelling door middel van handmatige analyse van statistieken vereist de betrokkenheid van gekwalificeerde specialisten. Het is een lage productiviteit. De meeste potentiële mislukkingen kunnen onopgemerkt blijven.
De laatste tijd is het zogenaamde voorspellende onderhoud van softwaresystemen steeds populairder geworden onder grote IT-softwareontwikkelingsbedrijven. De essentie van deze aanpak is het vinden van problemen die leiden tot systeemdegradatie in een vroeg stadium, voordat het faalt, met behulp van kunstmatige intelligentie. Deze aanpak sluit handmatige monitoring van het systeem niet volledig uit. Het is een hulpmiddel voor het monitoringproces als geheel.
Het belangrijkste instrument voor het implementeren van voorspellend onderhoud is het zoeken naar afwijkingen in tijdreeksen wanneer er een anomalie optreedt in de gegevens is de kans groot dat dit na enige tijd zal gebeuren er zal een mislukking of mislukking zijn. Een anomalie is een bepaalde afwijking in de prestaties van een softwaresysteem, zoals het vaststellen van een achteruitgang in de uitvoeringssnelheid van één type verzoek of een afname van het gemiddelde aantal afgehandelde verzoeken bij een constant niveau van clientsessies.
De taak van het zoeken naar afwijkingen voor softwaresystemen heeft zijn eigen specifieke kenmerken. In theorie is het voor elk softwaresysteem noodzakelijk om bestaande methoden te ontwikkelen of te verfijnen, omdat het zoeken naar afwijkingen sterk afhankelijk is van de gegevens waarin het wordt uitgevoerd, en de gegevens van softwaresystemen sterk variëren, afhankelijk van de tools voor het implementeren van het systeem. , tot op welke computer het draait.
Methoden voor het zoeken naar afwijkingen bij het voorspellen van fouten in softwaresystemen
Allereerst is het de moeite waard om te zeggen dat het idee van het voorspellen van mislukkingen door het artikel is geïnspireerd . Om de effectiviteit van de aanpak met automatisch zoeken naar afwijkingen te testen, werd gekozen voor het softwaresysteem Web-Consolidation, een van de projecten van het bedrijf NPO Krista. Voorheen werd hiervoor handmatige monitoring uitgevoerd op basis van de ontvangen statistieken. Omdat het systeem behoorlijk complex is, wordt er een groot aantal metrieken voor gebruikt: JVM-indicatoren (garbage collector load), indicatoren van het besturingssysteem waaronder de code wordt uitgevoerd (virtueel geheugen, % CPU-belasting van het besturingssysteem), netwerkindicatoren (netwerkbelasting ), de server zelf (CPU-belasting, geheugen), wilde statistieken en de eigen statistieken van de applicatie voor alle kritieke subsystemen.
Alle statistieken worden met behulp van grafiet uit het systeem gehaald. Aanvankelijk werd de Wfluisterdatabase gebruikt als standaardoplossing voor grafana, maar naarmate het klantenbestand groeide, kon grafiet het niet langer aan, omdat de capaciteit van het DC-schijfsubsysteem was uitgeput. Hierna werd besloten een effectievere oplossing te vinden. De keuze viel in het voordeel , waardoor het mogelijk werd om de belasting van het schijfsubsysteem met een orde van grootte te verminderen en de bezette schijfruimte vijf tot zes keer te verminderen. Hieronder ziet u een diagram van het mechanisme voor het verzamelen van statistieken met behulp van grafiet+clickhouse (Afbeelding 2).
Figuur 2. Schema voor het verzamelen van statistieken
Het diagram is afkomstig uit de interne documentatie. Het toont de communicatie tussen grafana (de monitoring-UI die we gebruiken) en grafiet. Het verwijderen van statistieken uit een applicatie wordt uitgevoerd door aparte software - . Hij stopt ze in grafiet.
Het Web Consolidation-systeem heeft een aantal functies die problemen veroorzaken bij het voorspellen van fouten:
- De trend verandert vaak. Van dit softwaresysteem zijn verschillende versies beschikbaar. Elk van hen brengt wijzigingen aan in het softwaregedeelte van het systeem. Op deze manier beïnvloeden ontwikkelaars dus rechtstreeks de statistieken van een bepaald systeem en kunnen ze een trendverandering veroorzaken;
- de implementatiefunctie, evenals de doeleinden waarvoor klanten dit systeem gebruiken, veroorzaken vaak afwijkingen zonder eerdere verslechtering;
- het percentage afwijkingen ten opzichte van de gehele dataset is klein (< 5%);
- Er kunnen hiaten ontstaan in de ontvangst van indicatoren uit het systeem. In sommige korte perioden slaagt het monitoringsysteem er niet in om meetgegevens te verkrijgen. Bijvoorbeeld als de server overbelast is. Dit is van cruciaal belang voor het trainen van een neuraal netwerk. Het is nodig om de gaten synthetisch op te vullen;
- Gevallen met afwijkingen zijn vaak alleen relevant voor een specifieke datum/maand/tijd (seizoensgebondenheid). Dit systeem kent duidelijke regels voor het gebruik ervan door gebruikers. Dienovereenkomstig zijn de statistieken alleen relevant voor een specifieke tijd. Het systeem kan niet constant worden gebruikt, maar slechts in enkele maanden: selectief afhankelijk van het jaar. Er doen zich situaties voor waarin hetzelfde gedrag van metrieken in het ene geval kan leiden tot een storing van het softwaresysteem, maar in een ander geval niet.
Om te beginnen werden methoden voor het detecteren van afwijkingen in de monitoringgegevens van softwaresystemen geanalyseerd. In artikelen over dit onderwerp wordt, wanneer het percentage afwijkingen klein is in verhouding tot de rest van de dataset, meestal voorgesteld om neurale netwerken te gebruiken.
De basislogica voor het zoeken naar afwijkingen met behulp van neurale netwerkgegevens wordt weergegeven in figuur 3:
Figuur 3. Zoeken naar afwijkingen met behulp van een neuraal netwerk
Op basis van het resultaat van de voorspelling of het herstel van het venster van de huidige stroom metrieken, wordt de afwijking berekend van die ontvangen van het draaiende softwaresysteem. Als er een groot verschil is tussen de metrieken verkregen uit het softwaresysteem en het neurale netwerk, kunnen we concluderen dat het huidige datasegment abnormaal is. Bij het gebruik van neurale netwerken doen zich de volgende reeks problemen voor:
- om correct te werken in de streamingmodus, moeten de gegevens voor het trainen van neurale netwerkmodellen alleen ‘normale’ gegevens bevatten;
- Voor een correcte detectie is het noodzakelijk om over een actueel model te beschikken. Veranderende trends en seizoensinvloeden in de statistieken kunnen een groot aantal valse positieven in het model veroorzaken. Om het bij te werken, is het noodzakelijk om duidelijk het tijdstip te bepalen waarop het model verouderd is. Als u het model later of eerder bijwerkt, zal er hoogstwaarschijnlijk een groot aantal valse positieven volgen.
We mogen ook het zoeken naar en voorkomen van het veelvuldig optreden van valse positieven niet vergeten. Aangenomen wordt dat deze zich het vaakst zullen voordoen in noodsituaties. Ze kunnen echter ook een gevolg zijn van een neurale netwerkfout als gevolg van onvoldoende training. Het is noodzakelijk om het aantal valse positieven van het model te minimaliseren. Anders zullen valse voorspellingen veel tijd van de beheerder verspillen die bedoeld is om het systeem te controleren. Vroeg of laat zal de beheerder gewoon niet meer reageren op het “paranoïde” monitoringsysteem.
Terugkerend neuraal netwerk
Om afwijkingen in tijdreeksen te detecteren, kunt u gebruiken met LSTM-geheugen. Het enige probleem is dat het alleen kan worden gebruikt voor voorspelde tijdreeksen. In ons geval zijn niet alle statistieken voorspelbaar. Een poging om RNN LSTM toe te passen op een tijdreeks wordt getoond in Figuur 4.
Figuur 4. Voorbeeld van een terugkerend neuraal netwerk met LSTM-geheugencellen
Zoals uit figuur 4 blijkt, kon RNN LSTM in deze periode de zoektocht naar afwijkingen aan. Wanneer het resultaat een hoge voorspellingsfout heeft (gemiddelde fout), is er feitelijk sprake van een anomalie in de indicatoren. Het gebruik van één enkele RNN LSTM zal duidelijk niet voldoende zijn, omdat deze toepasbaar is op een klein aantal statistieken. Kan worden gebruikt als hulpmethode bij het zoeken naar afwijkingen.
Autoencoder voor het voorspellen van storingen
– in wezen een kunstmatig neuraal netwerk. De invoerlaag is de encoder, de uitvoerlaag is de decoder. Het nadeel van alle neurale netwerken van dit type is dat ze afwijkingen niet goed lokaliseren. Er werd gekozen voor een synchrone autoencoder-architectuur.
Figuur 5. Voorbeeld van werking van de autoencoder
Autoencoders worden getraind op normale gegevens en ontdekken vervolgens iets afwijkends in de gegevens die aan het model worden toegevoerd. Precies wat u nodig heeft voor deze taak. Het enige dat overblijft is om te kiezen welke autoencoder geschikt is voor deze taak. De architectonisch eenvoudigste vorm van een autoencoder is een voorwaarts, niet-terugkerend neuraal netwerk, dat sterk lijkt op (multilayer perceptron, MLP), met een invoerlaag, een uitvoerlaag en een of meer verborgen lagen die deze verbinden.
De verschillen tussen autoencoders en MLP's zijn echter dat in een autoencoder de uitvoerlaag hetzelfde aantal knooppunten heeft als de invoerlaag, en dat in plaats van te worden getraind om een doelwaarde Y te voorspellen die wordt gegeven door een invoer X, de autoencoder wordt getraind. om zijn eigen X'en te reconstrueren. Daarom zijn Autoencoders leermodellen zonder toezicht.
De taak van de autoencoder is het vinden van de tijdindexen r0 ... rn die overeenkomen met de afwijkende elementen in de invoervector X. Dit effect wordt bereikt door te zoeken naar de kwadratische fout.
Figuur 6. Synchrone autoencoder
Er werd gekozen voor de autoencoder . De voordelen: de mogelijkheid om de streamingverwerkingsmodus te gebruiken en een relatief kleiner aantal neurale netwerkparameters vergeleken met andere architecturen.
Mechanisme voor het minimaliseren van valse positieven
Vanwege het feit dat er verschillende abnormale situaties ontstaan, evenals een mogelijke situatie van onvoldoende training van het neurale netwerk, voor het anomaliedetectiemodel dat wordt ontwikkeld, werd besloten dat het noodzakelijk was een mechanisme te ontwikkelen om valse positieven te minimaliseren. Dit mechanisme is gebaseerd op een sjabloonbasis die door de beheerder wordt geclassificeerd.
(DTW-algoritme, van het Engelse dynamische time warping) stelt u in staat de optimale overeenkomst tussen tijdreeksen te vinden. Voor het eerst gebruikt bij spraakherkenning: gebruikt om te bepalen hoe twee spraaksignalen dezelfde originele gesproken zin vertegenwoordigen. Vervolgens werd er toepassing voor gevonden op andere gebieden.
Het belangrijkste principe voor het minimaliseren van valse positieven is het verzamelen van een database met standaarden met behulp van een operator die verdachte gevallen classificeert die zijn gedetecteerd met behulp van neurale netwerken. Vervolgens wordt de geclassificeerde standaard vergeleken met het geval dat het systeem heeft gedetecteerd, en wordt er een conclusie getrokken over de vraag of het geval vals is of tot een storing leidt. Juist om twee tijdreeksen met elkaar te vergelijken wordt het DTW-algoritme gebruikt. Het belangrijkste minimaliseringsinstrument is nog steeds classificatie. De verwachting is dat het systeem, na het verzamelen van een groot aantal referentiegevallen, de operator minder zal gaan vragen vanwege de gelijkenis van de meeste gevallen en het voorkomen van soortgelijke gevallen.
Als gevolg hiervan werd, op basis van de hierboven beschreven neurale netwerkmethoden, een experimenteel programma gebouwd om storingen van het “Web-Consolidation” -systeem te voorspellen. Het doel van dit programma was om, met behulp van het bestaande archief met monitoringgegevens en informatie over eerdere storingen, de competentie van deze aanpak voor onze softwaresystemen te evalueren. Het schema van het programma wordt hieronder weergegeven in Figuur 7.
Figuur 7. Schema voor het voorspellen van storingen op basis van metrische ruimteanalyse
In het diagram kunnen twee hoofdblokken worden onderscheiden: het zoeken naar afwijkende tijdsperioden in de monitoringgegevensstroom (metrieken) en het mechanisme voor het minimaliseren van valse positieven. Opmerking: voor experimentele doeleinden worden de gegevens verkregen via een JDBC-verbinding uit de database waarin grafiet deze opslaat.
Het volgende is de interface van het monitoringsysteem dat is verkregen als resultaat van de ontwikkeling (Figuur 8).
Figuur 8. Interface van het experimentele monitoringsysteem
De interface geeft het percentage afwijkingen weer op basis van de ontvangen statistieken. In ons geval wordt de bon gesimuleerd. We beschikken al over alle gegevens voor een aantal weken en laden deze geleidelijk aan om te controleren of er sprake is van een afwijking die tot een storing heeft geleid. De onderste statusbalk geeft het totale percentage gegevensafwijkingen op een bepaald moment weer, dat wordt bepaald met behulp van een autoencoder. Ook wordt er een apart percentage weergegeven voor de voorspelde statistieken, die worden berekend door de RNN LSTM.
Een voorbeeld van anomaliedetectie op basis van CPU-prestaties met behulp van het RNN LSTM neurale netwerk (Afbeelding 9).
Figuur 9. RNN LSTM-ontdekking
Een vrij eenvoudig geval, in wezen een gewone uitschieter, maar leidend tot systeemfalen, werd met succes berekend met behulp van RNN LSTM. De anomalie-indicator in deze periode is 85-95%; alles boven de 80% (de drempel werd experimenteel bepaald) wordt als een anomalie beschouwd.
Een voorbeeld van een anomaliedetectie waarbij het systeem na een update niet kon opstarten. Deze situatie wordt gedetecteerd door de autoencoder (Figuur 10).
Figuur 10. Voorbeeld van autoencoderdetectie
Zoals je in de figuur kunt zien, zit PermGen op één niveau vast. De autoencoder vond dit vreemd omdat hij nog nooit zoiets had gezien. Hier blijft de anomalie 100% totdat het systeem terugkeert naar een werkende staat. Voor alle statistieken wordt een afwijking weergegeven. Zoals eerder vermeld, kan de autoencoder geen afwijkingen lokaliseren. In deze situaties wordt een beroep gedaan op de operator om deze functie uit te voeren.
Conclusie
PC "Web-Consolidation" is al enkele jaren in ontwikkeling. Het systeem verkeert in een redelijk stabiele staat en het aantal geregistreerde incidenten is klein. Het was echter mogelijk om 5 tot 10 minuten voordat de storing optrad afwijkingen te ontdekken die tot een storing leidden. In sommige gevallen kan het vooraf melden van een storing helpen de geplande tijd te besparen die is uitgetrokken voor het uitvoeren van “reparatiewerkzaamheden”.
Op basis van de uitgevoerde experimenten is het nog te vroeg om definitieve conclusies te trekken. Tot nu toe zijn de resultaten tegenstrijdig. Aan de ene kant is het duidelijk dat algoritmen gebaseerd op neurale netwerken in staat zijn ‘nuttige’ afwijkingen te vinden. Aan de andere kant blijft er een groot percentage valse positieven bestaan, en niet alle afwijkingen die door een gekwalificeerde specialist in een neuraal netwerk worden gedetecteerd, kunnen worden gedetecteerd. De nadelen zijn onder meer het feit dat het neurale netwerk nu training van een leraar vereist voor normale werking.
Om het systeem voor het voorspellen van storingen verder te ontwikkelen en in een bevredigende staat te brengen, kunnen verschillende manieren worden overwogen. Dit is een meer gedetailleerde analyse van gevallen met afwijkingen die tot mislukking leiden, dankzij deze toevoeging aan de lijst met belangrijke statistieken die de toestand van het systeem sterk beïnvloeden, en het weggooien van onnodige statistieken die er geen invloed op hebben. Als we deze kant op gaan, kunnen we ook pogingen ondernemen om algoritmen specifiek voor onze gevallen te specialiseren, met afwijkingen die tot mislukkingen leiden. Er is een andere manier. Dit is een verbetering van de neurale netwerkarchitecturen en verhoogt daardoor de detectienauwkeurigheid met een vermindering van de trainingstijd.
Ik spreek mijn dank uit aan mijn collega’s die mij hebben geholpen bij het schrijven en behouden van de relevantie van dit artikel: en Sergej Finogenov.
Bron: www.habr.com