Låt oss komma ihåg att Elastic Stack är baserad på den icke-relationella Elasticsearch-databasen, Kibanas webbgränssnitt och datainsamlare och processorer (den mest kända Logstash, olika Beats, APM och andra). Ett av de trevliga tilläggen till hela den listade produktstacken är dataanalys med hjälp av maskininlärningsalgoritmer. I artikeln förstår vi vad dessa algoritmer är. Vänligen under katt.
Maskininlärning är en betald funktion i shareware Elastic Stack och ingår i X-Pack. För att börja använda det, aktivera bara 30-dagars provperioden efter installationen. När provperioden löper ut kan du begära support för att förlänga den eller köpa ett abonnemang. Kostnaden för ett abonnemang beräknas inte utifrån mängden data, utan på antalet använda noder. Nej, mängden data påverkar naturligtvis antalet nödvändiga noder, men ändå är detta tillvägagångssätt för licensiering mer humant i förhållande till företagets budget. Om det inte finns något behov av hög produktivitet kan du spara pengar.
ML i Elastic Stack är skrivet i C++ och körs utanför JVM, där Elasticsearch själv körs. Det vill säga, processen (förresten, det kallas autodetect) förbrukar allt som JVM inte sväljer. På en demomonter är detta inte så kritiskt, men i en produktionsmiljö är det viktigt att allokera separata noder för ML-uppgifter.
Maskininlärningsalgoritmer delas in i två kategorier − и . I Elastic Stack är algoritmen i kategorin "oövervakad". Förbi Du kan se den matematiska apparaten för maskininlärningsalgoritmer.
För att utföra analysen använder maskininlärningsalgoritmen data som lagras i Elasticsearch-index. Du kan skapa uppgifter för analys både från Kibana-gränssnittet och via API:et. Om du gör detta genom Kibana behöver du inte veta vissa saker. Till exempel ytterligare index som algoritmen använder under sin drift.
Ytterligare index som används i analysprocessen.ml-state — information om statistiska modeller (analysinställningar);
.ml-anomalier-* — resultat av ML-algoritmer;
.ml-notifications — inställningar för meddelanden baserade på analysresultat.
Datastrukturen i Elasticsearch-databasen består av index och dokument lagrade i dem. Jämfört med en relationsdatabas kan ett index jämföras med ett databasschema och ett dokument med en post i en tabell. Denna jämförelse är villkorad och tillhandahålls för att förenkla förståelsen av ytterligare material för dem som bara har hört talas om Elasticsearch.
Samma funktionalitet är tillgänglig via API:et som genom webbgränssnittet, så för klarhet och förståelse av koncepten kommer vi att visa hur man konfigurerar det genom Kibana. I menyn till vänster finns en maskininlärningssektion där du kan skapa ett nytt jobb. I Kibana-gränssnittet ser det ut som bilden nedan. Nu ska vi analysera varje typ av uppgift och visa vilka typer av analyser som kan konstrueras här.
Single Metric - analys av ett mått, Multi Metric - analys av två eller flera mått. I båda fallen analyseras varje mått i en isolerad miljö, d.v.s. Algoritmen tar inte hänsyn till beteendet hos parallella analyserade mätvärden, som det kan tyckas i fallet med Multi Metric. För att utföra beräkningar med hänsyn till korrelationen mellan olika mått, kan du använda Befolkningsanalys. Och Advanced finjusterar algoritmerna med ytterligare alternativ för vissa uppgifter.
Enkelt mått
Att analysera förändringar i ett enda mått är det enklaste som kan göras här. Efter att ha klickat på Skapa jobb kommer algoritmen att leta efter anomalier.
Inom området aggregation du kan välja en metod för att söka efter anomalier. Till exempel när Min värden under typiska värden kommer att betraktas som avvikande. Äta Max, Hög medelvärde, låg, medelvärde, distinkt och andra. Beskrivningar av alla funktioner finns .
Inom området Fält anger det numeriska fältet i dokumentet som vi kommer att utföra analysen på.
Inom området — Granularitet av intervall på tidslinjen längs vilken analysen kommer att utföras. Du kan lita på automatiseringen eller välja manuellt. Bilden nedan är ett exempel på att granulariteten är för låg - du kan missa avvikelsen. Med den här inställningen kan du ändra algoritmens känslighet för anomalier.
Varaktigheten av de insamlade uppgifterna är en viktig sak som påverkar analysens effektivitet. Under analysen identifierar algoritmen upprepande intervall, beräknar konfidensintervall (baslinjer) och identifierar anomalier - atypiska avvikelser från det vanliga beteendet hos måtten. Bara till exempel:
Baslinjer med en liten bit data:
När algoritmen har något att lära av ser baslinjen ut så här:
Efter att ha startat uppgiften bestämmer algoritmen onormala avvikelser från normen och rangordnar dem enligt sannolikheten för en anomali (färgen på motsvarande etikett anges inom parentes):
Varning (blå): mindre än 25
Mindre (gul): 25-50
Major (orange): 50-75
Kritisk (röd): 75-100
Grafen nedan visar ett exempel på de anomalier som hittats.
Här kan du se siffran 94, som indikerar sannolikheten för en anomali. Det är klart att eftersom värdet är nära 100 så betyder det att vi har en anomali. Kolumnen under grafen visar den nedsättande liten sannolikhet på 0.000063634 % av det metriska värdet som visas där.
Förutom att söka efter anomalier kan du köra prognoser i Kibana. Detta görs enkelt och från samma vy med anomalier - knapp Prognos i det övre högra hörnet.
Prognosen görs för max 8 veckor i förväg. Även om du verkligen vill, är det inte längre möjligt genom design.
I vissa situationer kommer prognosen att vara mycket användbar, till exempel vid övervakning av användarbelastning på infrastrukturen.
Multimetrisk
Låt oss gå vidare till nästa ML-funktion i Elastic Stack - analysera flera mätvärden i en batch. Men detta betyder inte att ett måtts beroende av ett annat kommer att analyseras. Detta är samma som Single Metric, men med flera mätvärden på en skärm för enkel jämförelse av effekten av en på en annan. Vi kommer att prata om att analysera beroendet av ett mått på ett annat i avsnittet Population.
Efter att ha klickat på rutan med Multi Metric kommer ett fönster med inställningar att visas. Låt oss titta på dem mer i detalj.
Först måste du välja fälten för analys och dataaggregering på dem. Aggregeringsalternativen här är desamma som för Single Metric (Max, Hög medelvärde, låg, medelvärde, distinkt och andra). Vidare, om så önskas, delas data upp i ett av fälten (fält Split data). I exemplet gjorde vi detta per fält OriginAirportID. Observera att måttenhetsdiagrammet till höger nu presenteras som flera grafer.
Fält Nyckelfält (påverkare) påverkar direkt de upptäckta anomalierna. Som standard kommer det alltid att finnas minst ett värde här, och du kan lägga till ytterligare. Algoritmen kommer att ta hänsyn till påverkan av dessa fält vid analys och visa de mest "inflytelserika" värdena.
Efter lanseringen kommer något liknande att visas i Kibanas gränssnitt.
Detta är den så kallade värmekarta över anomalier för varje fältvärde OriginAirportID, som vi angav i Split data. Precis som med Single Metric indikerar färg nivån på onormal avvikelse. Det är bekvämt att göra en liknande analys, till exempel på arbetsstationer för att spåra de med ett misstänkt stort antal behörigheter osv. Vi har redan skrivit , som också kan samlas in och analyseras här.
Nedanför värmekartan finns en lista över anomalier, från varje kan du byta till vyn Single Metric för detaljerad analys.
Befolkning
För att leta efter anomalier mellan korrelationer mellan olika mätvärden har Elastic Stack en specialiserad befolkningsanalys. Det är med dess hjälp som du kan leta efter avvikande värden i prestanda för en server jämfört med andra när till exempel antalet förfrågningar till målsystemet ökar.
I den här illustrationen anger fältet Population det värde som de analyserade mätvärdena kommer att relatera till. I det här fallet är det namnet på processen. Som ett resultat kommer vi att se hur processorbelastningen för varje process påverkade varandra.
Observera att grafen över de analyserade data skiljer sig från fallen med Single Metric och Multi Metric. Detta gjordes i Kibana genom design för en förbättrad uppfattning om fördelningen av värden för den analyserade datan.
Grafen visar att processen uppförde sig onormalt påkänning (förresten, genererad av ett speciellt verktyg) på servern poipu, som påverkade (eller visade sig vara en influencer) förekomsten av denna anomali.
Advanced Open water
Analys med finjustering. Med avancerad analys visas ytterligare inställningar i Kibana. Efter att ha klickat på rutan Avancerat i skapandemenyn visas detta fönster med flikar. Flik jobb~~POS=TRUNC Detaljer Vi hoppade över det med flit, det finns grundläggande inställningar som inte är direkt relaterade till att sätta upp analysen.
В summary_count_field_name Alternativt kan du ange namnet på ett fält från dokument som innehåller aggregerade värden. I det här exemplet, antalet händelser per minut. I indikerar namnet och värdet på ett fält från dokumentet som innehåller något variabelvärde. Med hjälp av masken i det här fältet kan du dela upp analyserad data i delmängder. Var uppmärksam på knappen Lägg till detektor i föregående illustration. Nedan är resultatet av att klicka på den här knappen.
Här är ytterligare ett block med inställningar för att konfigurera anomalidetektorn för en specifik uppgift. Vi planerar att diskutera specifika användningsfall (särskilt säkerhetsrelaterade) i följande artiklar. Till exempel, ett av de nedmonterade fallen. Det är förknippat med sökningen efter sällan förekommande värden och implementeras .
Inom området fungera Du kan välja en specifik funktion för att söka efter anomalier. Bortsett från sällsynt, det finns ett par fler intressanta funktioner - . De identifierar anomalier i beteendet hos mätvärden under dagen respektive veckan. Övriga analysfunktioner .
В fält namn anger fältet i dokumentet där analysen kommer att utföras. By_field_name kan användas för att separera analysresultaten för varje enskilt värde i dokumentfältet som anges här. Om du fyller över_fältnamn du får den befolkningsanalys som vi diskuterade ovan. Om du anger ett värde i partitionsfältsnamn, för detta fält i dokumentet kommer separata baslinjer att beräknas för varje värde (värdet kan till exempel vara namnet på servern eller processen på servern). I exclude_frequent kan välja alla eller ingen, vilket innebär att exkludera (eller inkludera) ofta förekommande dokumentfältvärden.
I den här artikeln försökte vi ge en så kortfattad uppfattning som möjligt om möjligheterna med maskininlärning i Elastic Stack; det finns fortfarande många detaljer kvar bakom kulisserna. Berätta för oss i kommentarerna vilka fall du lyckades lösa med Elastic Stack och vilka uppgifter du använder den till. För att kontakta oss kan du använda personliga meddelanden på Habré eller .
Källa: will.com