La oss huske at Elastic Stack er basert på den ikke-relasjonelle Elasticsearch-databasen, Kibanas nettgrensesnitt og datainnsamlere og prosessorer (den mest kjente Logstash, forskjellige Beats, APM og andre). Et av de fine tilleggene til hele den listede produktstakken er dataanalyse ved hjelp av maskinlæringsalgoritmer. I artikkelen forstår vi hva disse algoritmene er. Vennligst under katt.
Maskinlæring er en betalt funksjon i shareware Elastic Stack og er inkludert i X-Pack. For å begynne å bruke det, bare aktiver 30-dagers prøveversjon etter installasjon. Etter at prøveperioden utløper, kan du be om støtte for å forlenge den eller kjøpe et abonnement. Kostnaden for et abonnement beregnes ikke basert på datavolumet, men på antall noder som brukes. Nei, datavolumet påvirker selvfølgelig antall nødvendige noder, men likevel er denne tilnærmingen til lisensiering mer human i forhold til selskapets budsjett. Hvis det ikke er behov for høy produktivitet, kan du spare penger.
ML i Elastic Stack er skrevet i C++ og kjører utenfor JVM, der Elasticsearch selv kjører. Det vil si at prosessen (forresten, det kalles autodetect) bruker alt som JVM ikke svelger. På en demo-stand er ikke dette så kritisk, men i et produksjonsmiljø er det viktig å tildele separate noder for ML-oppgaver.
Maskinlæringsalgoritmer faller inn i to kategorier − и . I Elastic Stack er algoritmen i kategorien "uten tilsyn". Av Du kan se det matematiske apparatet til maskinlæringsalgoritmer.
For å utføre analysen bruker maskinlæringsalgoritmen data som er lagret i Elasticsearch-indekser. Du kan lage oppgaver for analyse både fra Kibana-grensesnittet og gjennom API. Hvis du gjør dette gjennom Kibana, trenger du ikke å vite noen ting. For eksempel ekstra indekser som algoritmen bruker under driften.
Ytterligere indekser brukt i analyseprosessen.ml-state — informasjon om statistiske modeller (analyseinnstillinger);
.ml-anomalies-* — resultater av ML-algoritmer;
.ml-notifications — innstillinger for varsler basert på analyseresultater.
Datastrukturen i Elasticsearch-databasen består av indekser og dokumenter som er lagret i dem. Sammenlignet med en relasjonsdatabase, kan en indeks sammenlignes med et databaseskjema, og et dokument med en post i en tabell. Denne sammenligningen er betinget og er gitt for å forenkle forståelsen av ytterligere materiale for de som bare har hørt om Elasticsearch.
Den samme funksjonaliteten er tilgjengelig gjennom API som gjennom webgrensesnittet, så for klarhet og forståelse av konseptene vil vi vise hvordan du konfigurerer det gjennom Kibana. I menyen til venstre er det en maskinlæringsdel hvor du kan opprette en ny jobb. I Kibana-grensesnittet ser det ut som bildet nedenfor. Nå skal vi analysere hver type oppgave og vise hvilke typer analyser som kan konstrueres her.
Enkelt metrikk - analyse av én metrikk, Multimetrisk - analyse av to eller flere beregninger. I begge tilfeller analyseres hver metrikk i et isolert miljø, dvs. Algoritmen tar ikke hensyn til oppførselen til parallellanalyserte beregninger, slik det kan virke i tilfellet med Multi Metric. For å utføre beregninger som tar hensyn til korrelasjonen mellom ulike beregninger, kan du bruke Befolkningsanalyse. Og Advanced finjusterer algoritmene med tilleggsalternativer for visse oppgaver.
Enkelt metrikk
Å analysere endringer i én enkelt metrikk er den enkleste tingen som kan gjøres her. Etter å ha klikket på Opprett jobb, vil algoritmen se etter uregelmessigheter.
I felt aggregering du kan velge en tilnærming til å søke etter anomalier. For eksempel når Min verdier under typiske verdier vil bli ansett som unormale. Spise Max, High Mean, Low, Mean, Distinkt og andre. Beskrivelser av alle funksjoner finnes .
I felt Felt angir det numeriske feltet i dokumentet som vi skal utføre analysen på.
I felt — Granularitet av intervaller på tidslinjen som analysen skal utføres på. Du kan stole på automatiseringen eller velge manuelt. Bildet nedenfor er et eksempel på at granulariteten er for lav - du kan gå glipp av anomalien. Ved å bruke denne innstillingen kan du endre følsomheten til algoritmen for uregelmessigheter.
Varigheten av dataene som samles inn er en sentral ting som påvirker effektiviteten til analysen. Under analyse identifiserer algoritmen repeterende intervaller, beregner konfidensintervaller (grunnlinjer) og identifiserer anomalier – atypiske avvik fra den normale oppførselen til metrikken. Bare for eksempel:
Grunnlinjer med et lite stykke data:
Når algoritmen har noe å lære av, ser basislinjen slik ut:
Etter å ha startet oppgaven, bestemmer algoritmen unormale avvik fra normen og rangerer dem i henhold til sannsynligheten for en anomali (fargen på den tilsvarende etiketten er angitt i parentes):
Advarsel (blå): mindre enn 25
Mindre (gul): 25-50
Major (oransje): 50-75
Kritisk (rød): 75-100
Grafen nedenfor viser et eksempel på anomaliene som er funnet.
Her kan du se tallet 94, som indikerer sannsynligheten for en anomali. Det er klart at siden verdien er nær 100, betyr det at vi har en anomali. Kolonnen under grafen viser den pejorativt lille sannsynligheten på 0.000063634 % av den metriske verdien som vises der.
I tillegg til å søke etter anomalier, kan du kjøre prognoser i Kibana. Dette gjøres enkelt og fra samme visning med anomalier - knapp Varsel i øvre høyre hjørne.
Varselet er laget for maksimalt 8 uker i forveien. Selv om du virkelig vil, er det ikke lenger mulig designmessig.
I noen situasjoner vil prognosen være svært nyttig, for eksempel ved overvåking av brukerbelastning på infrastrukturen.
Multimetrisk
La oss gå videre til neste ML-funksjon i Elastic Stack - analysere flere beregninger i en batch. Men dette betyr ikke at avhengigheten til en metrikk av en annen vil bli analysert. Dette er det samme som Single Metric, men med flere beregninger på én skjerm for enkel sammenligning av virkningen av en på en annen. Vi snakker om å analysere avhengigheten av en beregning av en annen i Befolkningsdelen.
Etter å ha klikket på firkanten med Multi Metric, vises et vindu med innstillinger. La oss se på dem mer detaljert.
Først må du velge feltene for analyse og dataaggregering på dem. Aggregeringsalternativene her er de samme som for Single Metric (Max, High Mean, Low, Mean, Distinkt og andre). Videre, hvis ønskelig, deles dataene inn i ett av feltene (felt Del data). I eksemplet gjorde vi dette etter felt OriginAirportID. Legg merke til at beregningsgrafen til høyre nå presenteres som flere grafer.
Feltet Nøkkelfelt (påvirkere) påvirker direkte de oppdagede anomaliene. Som standard vil det alltid være minst én verdi her, og du kan legge til flere. Algoritmen vil ta hensyn til påvirkningen av disse feltene når den analyseres og vise de mest "innflytelsesrike" verdiene.
Etter lansering vil noe slikt dukke opp i Kibana-grensesnittet.
Dette er den såkalte varmekart over anomalier for hver feltverdi OriginAirportID, som vi indikerte i Del data. Som med Single Metric, indikerer farge nivået av unormalt avvik. Det er praktisk å gjøre en lignende analyse, for eksempel på arbeidsstasjoner for å spore de med et mistenkelig stort antall autorisasjoner osv. Vi har allerede skrevet , som også kan samles og analyseres her.
Under varmekartet er en liste over uregelmessigheter, fra hver av dem kan du bytte til Single Metric-visning for detaljert analyse.
Befolkning
For å se etter anomalier mellom korrelasjoner mellom forskjellige beregninger, har Elastic Stack en spesialisert populasjonsanalyse. Det er med dens hjelp du kan se etter unormale verdier i ytelsen til en server sammenlignet med andre når for eksempel antall forespørsler til målsystemet øker.
I denne illustrasjonen angir Populasjon-feltet verdien som de analyserte beregningene vil relatere seg til. I dette tilfellet er det navnet på prosessen. Som et resultat vil vi se hvordan prosessorbelastningen til hver prosess påvirket hverandre.
Vær oppmerksom på at grafen for de analyserte dataene er forskjellig fra tilfellene med Single Metric og Multi Metric. Dette ble gjort i Kibana ved design for en forbedret oppfatning av fordelingen av verdier til de analyserte dataene.
Grafen viser at prosessen oppførte seg unormalt stresset (forresten, generert av et spesielt verktøy) på serveren poipu, som påvirket (eller viste seg å være en påvirker) forekomsten av denne anomalien.
Avansert
Analytics med finjustering. Med avansert analyse vises tilleggsinnstillinger i Kibana. Etter å ha klikket på Avansert-flisen i opprettelsesmenyen, vises dette vinduet med faner. Tab jobbdetaljer Vi hoppet over det med vilje, det er grunnleggende innstillinger som ikke er direkte relatert til å sette opp analysen.
В summary_count_field_name Du kan eventuelt angi navnet på et felt fra dokumenter som inneholder aggregerte verdier. I dette eksemplet, antall hendelser per minutt. I angir navnet og verdien til et felt fra dokumentet som inneholder en variabelverdi. Ved å bruke masken på dette feltet kan du dele de analyserte dataene i delsett. Vær oppmerksom på knappen Legg til detektor i forrige illustrasjon. Nedenfor er resultatet av å klikke på denne knappen.
Her er en ekstra blokk med innstillinger for å konfigurere anomalidetektoren for en spesifikk oppgave. Vi planlegger å undersøke spesifikke brukstilfeller (spesielt angående sikkerhet) i de følgende artiklene. For eksempel, en av de demonterte sakene. Det er assosiert med søket etter verdier som sjelden vises og er implementert .
I felt funksjon Du kan velge en spesifikk funksjon for å søke etter uregelmessigheter. Unntatt sjelden, det er et par flere interessante funksjoner - . De identifiserer anomalier i oppførselen til beregninger gjennom dagen eller uken, henholdsvis. Andre analysefunksjoner .
В feltnavn angir feltet i dokumentet som analysen skal utføres på. By_field_name kan brukes til å skille analyseresultatene for hver enkelt verdi i dokumentfeltet som er spesifisert her. Hvis du fyller over_field_name du får befolkningsanalysen som vi diskuterte ovenfor. Hvis du angir en verdi i partisjonsfeltnavn, så vil det for dette feltet i dokumentet beregnes separate grunnlinjer for hver verdi (verdien kan for eksempel være navnet på serveren eller prosessen på serveren). I ekskluder_hyppig kan velge alle eller none, som betyr å ekskludere (eller inkludere) ofte forekommende dokumentfeltverdier.
I denne artikkelen prøvde vi å gi en så kortfattet idé som mulig om egenskapene til maskinlæring i Elastic Stack; det er fortsatt mange detaljer bak kulissene. Fortell oss i kommentarfeltet hvilke saker du klarte å løse ved å bruke Elastic Stack og hvilke oppgaver du bruker den til. For å kontakte oss kan du bruke personlige meldinger på Habré eller .
Kilde: www.habr.com