Lad os huske på, at Elastic Stack er baseret på den ikke-relationelle Elasticsearch-database, Kibana-webgrænsefladen og dataindsamlere og processorer (den mest berømte Logstash, forskellige Beats, APM og andre). En af de gode tilføjelser til hele den listede produktstak er dataanalyse ved hjælp af maskinlæringsalgoritmer. I artiklen forstår vi, hvad disse algoritmer er. Venligst under kat.
Machine learning er en betalt funktion i shareware Elastic Stack og er inkluderet i X-Pack. For at begynde at bruge det skal du blot aktivere 30-dages prøveversion efter installationen. Når prøveperioden udløber, kan du anmode om support for at forlænge den eller købe et abonnement. Prisen for et abonnement beregnes ikke ud fra mængden af data, men ud fra antallet af anvendte noder. Nej, mængden af data påvirker selvfølgelig antallet af nødvendige noder, men alligevel er denne tilgang til licensering mere human i forhold til virksomhedens budget. Hvis der ikke er behov for høj produktivitet, kan du spare penge.
ML i Elastic Stack er skrevet i C++ og kører uden for JVM, hvor Elasticsearch selv kører. Det vil sige, at processen (i øvrigt kaldes det autodetect) forbruger alt, hvad JVM'en ikke sluger. På en demostand er dette ikke så kritisk, men i et produktionsmiljø er det vigtigt at allokere separate noder til ML-opgaver.
Maskinlæringsalgoritmer falder i to kategorier − и . I den elastiske stak er algoritmen i kategorien "uovervåget". Ved Du kan se det matematiske apparat af maskinlæringsalgoritmer.
For at udføre analysen bruger maskinlæringsalgoritmen data, der er gemt i Elasticsearch-indekser. Du kan oprette opgaver til analyse både fra Kibana-grænsefladen og gennem API'et. Hvis du gør dette gennem Kibana, så behøver du ikke at vide nogle ting. For eksempel yderligere indekser, som algoritmen bruger under sin drift.
Yderligere indekser brugt i analyseprocessen.ml-state — information om statistiske modeller (analyseindstillinger);
.ml-anomalier-* — resultater af ML-algoritmer;
.ml-meddelelser — indstillinger for meddelelser baseret på analyseresultater.
Datastrukturen i Elasticsearch-databasen består af indekser og dokumenter gemt i dem. Sammenlignet med en relationsdatabase kan et indeks sammenlignes med et databaseskema og et dokument med en post i en tabel. Denne sammenligning er betinget og er tilvejebragt for at forenkle forståelsen af yderligere materiale for dem, der kun har hørt om Elasticsearch.
Den samme funktionalitet er tilgængelig gennem API'et som gennem webgrænsefladen, så for klarhed og forståelse af koncepterne vil vi vise, hvordan det konfigureres gennem Kibana. I menuen til venstre er der en Machine Learning sektion, hvor du kan oprette et nyt job. I Kibana-grænsefladen ser det ud som på billedet nedenfor. Nu vil vi analysere hver type opgave og vise de analysetyper, der kan konstrueres her.
Single Metric - analyse af en metrik, Multi Metric - analyse af to eller flere metrics. I begge tilfælde analyseres hver metrik i et isoleret miljø, dvs. Algoritmen tager ikke højde for adfærden af parallelt analyserede metrikker, som det kan se ud i tilfældet med Multi Metric. For at udføre beregninger under hensyntagen til sammenhængen mellem forskellige metrikker, kan du bruge Befolkningsanalyse. Og Advanced finjusterer algoritmerne med yderligere muligheder for visse opgaver.
Enkelt metrisk
At analysere ændringer i en enkelt metrik er den enkleste ting, der kan gøres her. Efter at have klikket på Opret job, vil algoritmen lede efter uregelmæssigheder.
I feltet Sammenlægning du kan vælge en tilgang til at søge efter anomalier. For eksempel hvornår Min værdier under typiske værdier vil blive betragtet som unormale. Spise Max, High Mean, Low, Mean, Distinct og andre. Beskrivelser af alle funktioner kan findes .
I feltet Felt angiver det numeriske felt i dokumentet, som vi vil udføre analysen på.
I feltet — granularitet af intervaller på tidslinjen, langs hvilken analysen vil blive udført. Du kan stole på automatiseringen eller vælge manuelt. Billedet nedenfor er et eksempel på, at granulariteten er for lav - du kan gå glip af anomalien. Ved at bruge denne indstilling kan du ændre algoritmens følsomhed over for anomalier.
Varigheden af de indsamlede data er en nøgleting, der påvirker analysens effektivitet. Under analysen identificerer algoritmen gentagne intervaller, beregner konfidensintervaller (baselines) og identificerer anomalier - atypiske afvigelser fra den sædvanlige opførsel af metrikken. Bare for eksempel:
Grundlinjer med et lille stykke data:
Når algoritmen har noget at lære af, ser basislinjen sådan ud:
Efter start af opgaven bestemmer algoritmen unormale afvigelser fra normen og rangerer dem i henhold til sandsynligheden for en anomali (farven på den tilsvarende etiket er angivet i parentes):
Advarsel (blå): mindre end 25
Mindre (gul): 25-50
Major (orange): 50-75
Kritisk (rød): 75-100
Grafen nedenfor viser et eksempel på de fundne anomalier.
Her kan du se tallet 94, som angiver sandsynligheden for en anomali. Det er klart, at da værdien er tæt på 100, betyder det, at vi har en anomali. Kolonnen under grafen viser den nedsættende lille sandsynlighed på 0.000063634 % af den metriske værdi, der vises der.
Ud over at søge efter uregelmæssigheder kan du køre prognoser i Kibana. Dette gøres enkelt og fra samme visning med anomalier - knap Forecast i øverste højre hjørne.
Prognosen er lavet for maksimalt 8 uger i forvejen. Selvom du virkelig vil, er det ikke længere muligt designmæssigt.
I nogle situationer vil prognosen være meget nyttig, for eksempel ved overvågning af brugerbelastning på infrastrukturen.
Multi Metrisk
Lad os gå videre til den næste ML-funktion i Elastic Stack - analysere flere metrikker i én batch. Men dette betyder ikke, at en metriks afhængighed af en anden vil blive analyseret. Dette er det samme som Single Metric, men med flere metrics på én skærm for nem sammenligning af virkningen af en på en anden. Vi vil tale om at analysere en metriks afhængighed af en anden i Befolkningssektionen.
Efter at have klikket på firkanten med Multi Metric, vises et vindue med indstillinger. Lad os se på dem mere detaljeret.
Først skal du vælge felterne til analyse og dataaggregering på dem. Aggregeringsmulighederne her er de samme som for Single Metric (Max, High Mean, Low, Mean, Distinct og andre). Yderligere, hvis det ønskes, opdeles dataene i et af felterne (felt Opdel data). I eksemplet gjorde vi dette efter felt OriginAirportID. Bemærk, at metrik-grafen til højre nu præsenteres som flere grafer.
Field Nøglefelter (influencers) påvirker direkte de opdagede anomalier. Som standard vil der altid være mindst én værdi her, og du kan tilføje yderligere. Algoritmen vil tage højde for indflydelsen af disse felter, når den analyseres og vise de mest "indflydelsesrige" værdier.
Efter lanceringen vil noget lignende dukke op i Kibana-grænsefladen.
Dette er den såkaldte varmekort over anomalier for hver feltværdi OriginAirportID, som vi angav i Opdel data. Som med Single Metric angiver farve niveauet af unormal afvigelse. Det er praktisk at lave en lignende analyse, for eksempel på arbejdsstationer for at spore dem med et mistænkeligt stort antal autorisationer osv. Vi har allerede skrevet , som også kan samles og analyseres her.
Nedenfor varmekortet er en liste over uregelmæssigheder, fra hver af dem kan du skifte til visningen Single Metric for detaljeret analyse.
Befolkning
For at se efter uregelmæssigheder mellem korrelationer mellem forskellige metrikker har Elastic Stack en specialiseret befolkningsanalyse. Det er med dens hjælp, at du kan lede efter unormale værdier i en servers ydeevne sammenlignet med andre, når for eksempel antallet af anmodninger til målsystemet stiger.
I denne illustration angiver feltet Population den værdi, som de analyserede metrics vil relatere til. I dette tilfælde er det navnet på processen. Som et resultat vil vi se, hvordan processorbelastningen af hver proces påvirkede hinanden.
Bemærk venligst, at grafen over de analyserede data adskiller sig fra tilfældene med Single Metric og Multi Metric. Dette blev gjort i Kibana ved design for en forbedret opfattelse af fordelingen af værdier af de analyserede data.
Grafen viser, at processen opførte sig unormalt stress (i øvrigt genereret af et særligt hjælpeprogram) på serveren poipu, der påvirkede (eller viste sig at være en influencer) forekomsten af denne anomali.
Avanceret
Analyse med finjustering. Med avanceret analyse vises yderligere indstillinger i Kibana. Efter at have klikket på flisen Avanceret i oprettelsesmenuen, vises dette vindue med faner. Tab Job Detaljer Vi sprang det over med vilje, der er grundlæggende indstillinger, der ikke er direkte relateret til opsætning af analysen.
В summary_count_field_name Du kan eventuelt angive navnet på et felt fra dokumenter, der indeholder aggregerede værdier. I dette eksempel er antallet af hændelser pr. minut. I angiver navnet og værdien af et felt fra dokumentet, der indeholder en variabel værdi. Ved at bruge masken i dette felt kan du opdele de analyserede data i undersæt. Vær opmærksom på knappen Tilføj detektor i den forrige illustration. Nedenfor er resultatet af at klikke på denne knap.
Her er en ekstra blok med indstillinger til konfiguration af anomalidetektoren til en specifik opgave. Vi planlægger at diskutere specifikke brugstilfælde (især sikkerhedstilfælde) i de følgende artikler. For eksempel, en af de adskilte sager. Det er forbundet med søgningen efter sjældent forekommende værdier og er implementeret .
I feltet funktion Du kan vælge en specifik funktion for at søge efter uregelmæssigheder. Undtagen sjældne, der er et par flere interessante funktioner - . De identificerer anomalier i adfærden af metrikker i løbet af henholdsvis dagen eller ugen. Andre analysefunktioner .
В feltnavn angiver det felt i dokumentet, som analysen vil blive udført på. By_field_name kan bruges til at adskille analyseresultaterne for hver enkelt værdi af det her specificerede dokumentfelt. Hvis du fylder over_field_name du får den befolkningsanalyse, som vi diskuterede ovenfor. Hvis du angiver en værdi i partitionsfeltnavn, så vil der for dette felt i dokumentet blive beregnet separate basislinjer for hver værdi (værdien kan f.eks. være navnet på serveren eller processen på serveren). I ekskluder_hyppig kan vælge alle eller ingen, hvilket vil betyde at ekskludere (eller inkludere) hyppigt forekommende dokumentfeltværdier.
I denne artikel forsøgte vi at give en så kortfattet idé som muligt om mulighederne ved maskinlæring i Elastic Stack; der er stadig mange detaljer tilbage bag kulisserne. Fortæl os i kommentarerne, hvilke sager du formåede at løse ved hjælp af Elastic Stack, og hvilke opgaver du bruger den til. For at kontakte os kan du bruge personlige beskeder på Habré eller .
Kilde: www.habr.com