
Laten we herinneren dat de Elastic Stack is gebaseerd op de niet-relationele Elasticsearch-database, de webinterface Kibana en dataverwerkers (de meest bekende zijn Logstash, verschillende Beats, APM en anderen). Een van de leuke aanvullingen van deze productstack is het analyseren van gegevens met behulp van algoritmen voor machine learning. In dit artikel onderzoeken we wat deze algoritmen zijn. We nodigen u uit om verder te lezen.
Machine learning is een betaalde functie van de voorwaardelijk gratis Elastic Stack en maakt deel uit van het X-Pack-pakket. Om het te gebruiken, hoeft u alleen maar na installatie een 30-dagen proefperiode te activeren. Na afloop van de proefperiode kunt u ondersteuning aanvragen voor verlenging of een abonnement kopen. De prijs van het abonnement is niet afhankelijk van de volume van de gegevens, maar van het aantal gebruikte knooppunten. Ja, de hoeveelheid gegevens beĆÆnvloedt natuurlijk het aantal benodigde knooppunten, maar deze benadering van licentieverlening is humaner voor het budget van het bedrijf. Als er geen behoefte is aan hoge prestaties, kunt u ook besparen.
ML in de Elastic Stack is geschreven in C++ en werkt buiten de JVM, waarin Elasticsearch draait. Het proces (dat trouwens autodetect wordt genoemd) verbruikt alles wat de JVM niet kan verwerken. Dit is niet zo kritiek op een demo-stand, maar in een productieomgeving is het belangrijk om aparte knooppunten voor ML-taken te reserveren.
Algoritmen voor machine learning worden in twee categorieĆ«n verdeeld ā en . In de Elastic Stack valt het algoritme onder de categorie 'zonder toezicht'. Via is het mogelijk om de wiskundige fundamenten van de algoritmen voor machine learning te bekijken.
Voor het uitvoeren van de analyse gebruikt het algoritme voor machine learning gegevens die zijn opgeslagen in de Elasticsearch-indexen. Taken voor analyse kunnen zowel vanuit de Kibana-interface als via de API worden aangemaakt. Als dit via Kibana wordt gedaan, is het niet noodzakelijk om enkele dingen te weten. Bijvoorbeeld, aanvullende indexen die het algoritme gedurende het werk gebruikt.
Aanvullende indexen die tijdens de analyse worden gebruikt.ml-state ā informatie over statistische modellen (instellingen voor analyse);
.ml-anomalies-* ā resultaten van de ML-algoritmen;
.ml-notifications ā instellingen voor meldingen op basis van de analysekrachten.

De datastructuur in de Elasticsearch-database bestaat uit indices en de documenten die daarin zijn opgeslagen. In vergelijking met een relationele database kan een index worden vergeleken met een databasemodel, terwijl een document kan worden vergeleken met een record in een tabel. Deze vergelijking is voorwaardelijk en dient ter vereenvoudiging van het begrip van het verdere materiaal voor degenen die slechts over Elasticsearch hebben gehoord.
Via de API is dezelfde functionaliteit beschikbaar als via de webinterface, daarom zullen we ter illustratie en begrip van de concepten laten zien hoe je het via Kibana kunt instellen. In het menu aan de linkerkant is er een sectie Machine Learning, waar je een nieuwe taak (Job) kunt creƫren. In de Kibana-interface ziet dit eruit als op de afbeelding hieronder. Nu zullen we elk type taak bespreken en de soorten analyses laten zien die hier kunnen worden samengesteld.

Single Metric ā analyse van ƩƩn metriek, Multi Metric ā analyse van twee of meer metrische waarden. In beide gevallen wordt elke metriek geanalyseerd in een geĆÆsoleerde omgeving, dat wil zeggen dat het algoritme geen rekening houdt met het gedrag van parallel geanalyseerde metrische waarden zoals je misschien zou kunnen denken bij Multi Metric. Om berekeningen uit te voeren met inachtneming van de correlatie van verschillende metrische waarden kan je een Population-analyse toepassen. Advanced is een fijne afstemming van de algoritmen met extra opties voor specifieke taken.
Single Metric
De analyse van veranderingen in een enkele metriek ā dat is het eenvoudigste wat je hier kunt doen. Na het klikken op Create Job zal het algoritme naar anomalieĆ«n zoeken.

In het veld Aggregatie je kunt de aanpak voor het zoeken naar anomalieƫn kiezen. Bijvoorbeeld, bij Min zullen waarden lager dan normaal als anomalieƫn worden beschouwd. Er zijn ook Max, High Mean, Low, Mean, Distinct en anderen. Een beschrijving van alle functies is beschikbaar .
In het veld Veld je specificeert het numerieke veld in het document waarop we de analyse zullen uitvoeren.
In het veld ā de granulariteit van de intervallen op de tijdlijn, waarop de analyse zal plaatsvinden. Je kunt de automatische instelling vertrouwen of handmatig kiezen. In de afbeelding hieronder is een voorbeeld van een veel te lage granulariteit weergegeven ā je kunt een anomalie missen. Met deze instelling kun je de gevoeligheid van het algoritme voor anomalieĆ«n aanpassen.

De duur van de verzamelde gegevens is een cruciaal aspect dat de effectiviteit van de analyse beĆÆnvloedt. Bij de analyse bepaalt het algoritme herhalende intervallen, berekent het het betrouwbaarheidsinterval (basislijnen) en identificeert het anomalieĆ«n ā atypische afwijkingen van het normale gedrag van de metriek. Gewoon ter illustratie:
Basislijnen bij een kleine dataset:

Wanneer het algoritme iets heeft om van te leren ā zien de basislijnen er als volgt uit:

Na het starten van de taak, bepaalt het algoritme de abnormale afwijkingen van de norm en rangschikt deze op waarschijnlijkheid van anomalie (de kleur van het bijbehorende label staat tussen haakjes):
Waarschuwing (blauw): minder dan 25
Klein (geel): 25-50
Groot (oranje): 50-75
Kritiek (rood): 75-100
In de onderstaande grafiek een voorbeeld met gevonden anomalieƫn.

Hier zien we het cijfer 94, dat de waarschijnlijkheid van de anomalie aanduidt. Aangezien de waarde dicht bij 100 ligt, betekent dit dat we met een anomalie te maken hebben. In de kolom onder de grafiek staat een verwaarloosbare waarschijnlijkheid van 0.000063634% voor het voorkomen van die metrieken.
Naast het zoeken naar anomalieĆ«n in Kibana kan er ook forecasting worden uitgevoerd. Dit kan eenvoudig vanaf dezelfde weergave met anomalieĆ«n ā de knop Forecast in de rechterbovenhoek.

De voorspelling kan maximaal 8 weken vooruit worden gemaakt. Zelfs als je echt zou willen ā meer kan niet op design.

In sommige situaties kan de voorspelling zeer nuttig zijn, bijvoorbeeld wanneer de gebruikersbelasting op de infrastructuur wordt gevolgd.
Multi Metric
Laten we overgaan naar de volgende mogelijkheid van ML in het Elastic Stack ā de analyse van meerdere metriek tegelijk. Maar dat betekent niet dat de afhankelijkheid van ƩƩn metriek van een andere wordt geanalyseerd. Dit is hetzelfde als Single Metric, maar met meerdere metriek op ƩƩn scherm voor het gemak van vergelijking van onderlinge invloeden. We zullen het hebben over de afhankelijkheid van ƩƩn metriek van een andere in het gedeelte Populatie.
Na het klikken op het vierkant met Multi Metric verschijnt er een venster met instellingen. We zullen daar dieper op ingaan.

Eerst moeten we de velden voor analyse en de aggregatie van gegevens kiezen. De aggregatie-opties zijn hetzelfde als die voor Single Metric (Max, High Mean, Low, Mean, Distinct en anderen). Vervolgens kunnen de gegevens eventueel worden opgesplitst op een van de velden (veld Split Data). In het voorbeeld hebben we dat gedaan op het veld OriginAirportID. Houd er rekening mee dat de grafiek van de metriek rechts nu is weergegeven als meerdere grafieken.

Veld Key Fields (Influencers) heeft direct invloed op de gevonden anomalieƫn. Standaard is er altijd minstens ƩƩn waarde, en je kunt extra waarden toevoegen. Het algoritme houdt rekening met de invloed van deze velden bij de analyse en toont de meest 'invloedrijke' waarden.
Na het starten zal de interface van Kibana er ongeveer als volgt uitzien.

Dit is wat men een anomalie heatmap noemt voor elke waarde van het veld OriginAirportID, dat we hebben opgegeven in Split Data. Net zoals bij Single Metric, geeft de kleur het niveau van afwijking aan. Een soortgelijke analyse kan bijvoorbeeld worden uitgevoerd op werkstations om te volgen waar verdachte veel autorisaties plaatsvinden, enz. We hebben al geschreven , die we ook hier kunnen verzamelen en analyseren.
Onder de heatmap staat de lijst met anomalieƫn; van elke anomalie kun je doorklikken naar de weergave van Single Metric voor gedetailleerde analyse.
Population
Om anomalieƫn te zoeken onder de correlaties tussen verschillende metrics in de Elastic Stack is er een gespecialiseerde Population-analyse. Hiermee kun je afwijkende waarden in de prestaties van een bepaalde server zoeken in vergelijking met de andere, bijvoorbeeld bij een toename van het aantal verzoeken aan het doelsysteem.

In deze illustratie geeft het veld Population de waarde aan waaraan de geanalyseerde metrics zich zullen verhouden. In dit geval is het de naam van het proces. We zullen zien hoe de CPU-belasting van elk van de processen elkaar heeft beĆÆnvloed.
Let op dat de grafiek van de geanalyseerde gegevens verschilt van de gevallen met Single Metric en Multi Metric. Dit is in Kibana ontworpen voor een beter begrip van de verdeling van de waarden van de geanalyseerde gegevens.

Uit de grafiek blijkt dat het proces stress (ter info, gegenereerd door een speciale tool) op de server poipu, dat invloed heeft gehad (of een influencer was) op de oorsprong van deze anomalie.
Geavanceerd
Geavanceerde analyse met fijnere instellingen. Bij Advanced analyse in Kibana verschijnen er extra instellingen. Na het klikken in het creatiemenu op de tegel Advanced verschijnt er dit venster met tabbladen. Het tabblad Job Details hebben we opzettelijk overgeslagen, daar zijn de basisinstellingen niet direct gerelateerd aan de analyse-instellingen.

In summary_count_field_name kan optioneel de naam van het veld in de documenten worden opgegeven dat de geaggregeerde waarden bevat. In dit geval ā het aantal gebeurtenissen per minuut. In geef je de naam van de veldwaarde in het document aan die een bepaalde variabele waarde bevat. Op basis van dit veld kunnen de geanalyseerde gegevens in subsets worden opgesplitst. Let op de knop Add detector in de vorige illustratie. Hieronder het resultaat van het klikken op deze knop.

Hier is een extra instellingenblok voor het configureren van de anomaliedetector voor een specifieke taak. We zijn van plan om specifieke gebruikscasussen (vooral op het gebied van beveiliging) in de volgende artikelen te bespreken. Als voorbeeld, een van de besproken gevallen. Het is gerelateerd aan het zoeken naar zeldzaam voorkomende waarden en wordt geĆÆmplementeerd .
In het veld functie je kunt een specifieke functie kiezen voor het zoeken naar anomalieĆ«n. Naast rare, zijn er nog een paar interessante functies ā . Ze identificeren anomalieĆ«n in het gedrag van metrics over de dag of week respectievelijk. De overige analysemethoden .
In field_name geeft het veld van het document aan waarop de analyse zal worden uitgevoerd. By_field_name kan worden gebruikt om de analysecijfers op elk afzonderlijk waarde van het hier opgegeven documentveld te splitsen. Als je over_field_name vult, krijg je een population-analyse, die we hierboven hebben besproken. Als je een waarde opgeeft in partition_field_name, dan worden voor dit documentveld afzonderlijke basislijnen berekend voor elke waarde (waarbij de waarde bijvoorbeeld de naam van de server of het proces op de server kan zijn). In exclude_frequent kun je kiezen all of none, wat betekent dat frequente waarden van documentvelden worden uitgesloten (of inbegrepen).
In dit artikel hebben we geprobeerd een zo beknopt mogelijk overzicht te geven van de mogelijkheden van machine learning in de Elastic Stack, maar er zijn nog veel details buiten beeld gebleven. Laat ons in de opmerkingen weten welke cases je hebt kunnen oplossen met de Elastic Stack en voor welke taken je deze gebruikt. Voor contact kun je persoonlijke berichten op Habr gebruiken of .
Bron: habr.com
