Amintim că Elastic Stack se bazează pe o bază de date nerelatională Elasticsearch, un interfață web Kibana și colectoare-prelucrătoare de date (cel mai cunoscut fiind Logstash, diverse Beats, APM și altele). Una dintre caracteristicile plăcute ale acestui set de produse este analiza datelor utilizând algoritmi de învățare automată. În acest articol, explorăm ce reprezintă acești algoritmi. Vă rugăm să continuați.
Învățarea automată este o funcție plătită a Elastic Stack, care face parte din pachetul X-Pack. Pentru a începe utilizarea acesteia, este suficient să activați un trial de 30 de zile după instalare. După expirarea perioadei de probă, puteți solicita suport pentru prelungire sau achiziționa un abonament. Costul abonamentului este calculat nu în funcție de volumul de date, ci de numărul de noduri utilizate. Desigur, volumul de date influențează numărul de noduri necesare, dar totuși, o astfel de abordare a licențierii este mai umană față de bugetul companiei. Dacă nu este necesară o performanță ridicată, este posibil să economisiți.
ML în Elastic Stack este scris în C++ și funcționează în afara JVM, în care rulează Elasticsearch. Asta înseamnă că procesul (care se numește autodetect) consumă tot ce nu poate fi preluat de JVM. Într-un demo, acest lucru nu este atât de critic, dar în medii productive este important să se aloce noduri separate pentru sarcinile de ML.
Algoritmii de învățare automată se împart în două categorii — și . În Elastic Stack, algoritmul face parte din categoria „fără învățător”. Pe baza se pot vizualiza aparatele matematice ale algoritmilor de învățare automată.
Pentru a efectua analiza, algoritmul de învățare automată utilizează datele stocate în indexurile Elasticsearch. Sarcinile de analiză pot fi create atât din interfața Kibana, cât și prin intermediul API-ului. Dacă faceți acest lucru prin intermediul Kibana, nu trebuie să cunoașteți unele lucruri. De exemplu, indexurile suplimentare pe care le folosește algoritmul în timpul funcționării.
Indexuri suplimentare utilizate în procesul de analiză.ml-state — informații despre modelele statistice (setările analizei);
.ml-anomalies-* — rezultatele activității algoritmilor ML;
.ml-notifications — setările de notificare în legătură cu rezultatele analizei.
Structura datelor în baza de date Elasticsearch constă în indici și documentele stocate în aceștia. Comparativ cu o bază de date relațională, un index poate fi comparat cu schema unei baze de date, iar un document cu un înregistrare într-un tabel. Această comparație este condiționată și a fost realizată pentru a simplifica înțelegerea materialului ulterior pentru cei care au auzit doar despre Elasticsearch.
Prin API este disponibilă aceeași funcționalitate ca și prin interfața web, așa că pentru o mai bună ilustrare și înțelegere a conceptelor, vom arăta cum se configurază prin Kibana. În meniul din stânga există o secțiune de Machine Learning, unde se poate crea o nouă sarcină (Job). În interfața Kibana, aceasta arată ca în imaginea de mai jos. Acum vom analiza fiecare tip de sarcină și vom arăta tipurile de analize care pot fi configurate aici.
Single Metric — analiza unei singure măsuri, Multi Metric — analiza a două sau mai multe măsuri. În ambele cazuri, fiecare măsură este analizată într-un mediu izolat, adică algoritmul nu ia în considerare comportamentul măsurilor analizate în paralel, așa cum ar putea părea în cazul Multi Metric. Pentru a efectua un calcul ținând cont de corelația diferitelor măsuri, se poate aplica analiza Population. Iar Advanced — reprezintă ajustări fine ale algoritmilor cu opțiuni suplimentare pentru sarcini specifice.
Single Metric
Analiza modificărilor unei singure măsuri este cel mai simplu lucru pe care îl putem face aici. După apăsarea butonului Create Job, algoritmul va căuta anomalii.
În câmpul Aggregation se poate alege abordarea pentru căutarea anomaliilor. De exemplu, la Min vor fi considerate anomalii valorile sub cele tipice. Există Max, High Mean, Low, Mean, Distinct și altele. Descrierea tuturor funcțiilor poate fi consultată .
În câmpul Field se specifică câmpul numeric din document, pe care îl vom analiza.
În câmpul — granularitatea intervalelor pe linia de timp, pe care va fi efectuată analiza. Se poate lăsa la automat sau selecta manual. În imaginea de mai jos este dat un exemplu de granularitate prea mică — este posibil să ratați o anomalie. Cu această setare, se poate schimba sensibilitatea algoritmului la anomalii.
Durata datelor colectate este un aspect cheie care influențează eficiența analizei. La analiză, algoritmul determină intervalele repetate, calculează intervalul de încredere (baze de referință) și identifică anomalii — abateri netipice de la comportamentul normal al măsurii. Doar pentru exemplu:
Liniile de bază pentru un segment mic de date:
Atunci când algoritmul are de unde să învețe, liniile de bază arată așa:
După ce sarcina a fost lansată, algoritmul determină deviațiile anormale de la normă și le clasifică după probabilitatea anomaliilor (culoarea etichetei corespunzătoare este indicată între paranteze):
Avertisment (albastru): mai puțin de 25
Minor (galben): 25-50
Major (portocaliu): 50-75
Critic (roșu): 75-100
În graficul de mai jos, un exemplu cu anomalii găsite.
Aici vedem cifra 94, care reprezintă probabilitatea anomaliilor. Este clar că, având în vedere că valoarea se apropie de 100, avem o anomalie. În coloana sub grafic este indicată o probabilitate extrem de mică de 0.000063634% pentru apariția acelor valori de metrice.
Pe lângă căutarea anomaliilor în Kibana, se poate lansa o prognoză. Acest lucru este realizat simplu din aceeași vizualizare cu anomalii — butonul Prognoză în colțul din dreapta sus.
Prognoza se construiește pentru maximum 8 săptămâni în avans. Chiar dacă se dorește, mai mult nu se poate din motive de design.
În anumite situații, prognoza va fi foarte utilă, de exemplu, atunci când se urmărește încărcarea utilizatorilor pe infrastructură.
Multi Metric
Trecem la următoarea capacitate ML din Elastic Stack — analiza mai multor metrice simultan. Dar nu înseamnă că va fi analizată dependența unei metrice de alta. Este identic cu Single Metric, doar că acum sunt mai multe metrice pe un singur ecran pentru compararea ușoară a influenței unuia asupra altuia. Analiza dependenței unei metrice de alta va fi discutată în partea Population.
După ce a fost apăsat dreptunghiul cu Multi Metric, va apărea o fereastră cu setările. Vom detalia acestea.
Pentru început, trebuie să selectați câmpurile pentru analiză și agregarea datelor pe acestea. Opțiunile de agregare sunt aceleași ca pentru Single Metric (Max, High Mean, Low, Mean, Distinct și altele). Apoi, datele pot fi împărțite opțional pe unul dintre câmpuri (câmpul Split Data). În exemplu, am făcut acest lucru pe câmpul OriginAirportID. Observați că graficul metricei din dreapta este acum prezentat sub formă de mai multe grafice.
Câmp Câmpuri cheie (Influencers) influentează direct anomaliile găsite. În mod implicit, aici va exista întotdeauna cel puțin o valoare, dar puteți adăuga altele suplimentare. Algoritmul va lua în considerare influența acestor câmpuri în analiza sa și va arăta cele mai „influente” valori.
După lansare, în interfața Kibana va apărea aproximativ această imagine.
Aceasta este așa-numita hartă termică a anomaliilor pentru fiecare valoare a câmpului OriginAirportID, pe care l-am indicat în Split Data. Așa cum se întâmplă cu Single Metric, culoarea indică nivelul deviației anormale. O analiză similară poate fi realizată, de exemplu, pentru stațiile de lucru pentru a urmări cele care au un număr suspect de mari de autentificări etc. Am mai scris , care de asemenea pot fi adunate și analizate aici.
Sub harta de căldură există o listă de anomalii, de unde fiecare poate fi accesat pentru a vizualiza Single Metric pentru analiza detaliată.
Population
Pentru a căuta anomalii între corelațiile dintre diferite metrici în Elastic Stack există o analiză specializată numită Population. Cu ajutorul acesteia se pot căuta valori anormale în performanța unui server în comparație cu altele, de exemplu, în cazul creșterii numărului de cereri către sistemul țintă.
În această ilustrație, câmpul Population indică valoarea la care se vor raporta metricile analizate. În acest caz, este numele procesului. Ca rezultat, vom vedea cum utilizarea procesorului de către fiecare dintre procese a influențat unii pe alții.
Observați că graficul datelor analizate diferă de cazurile cu Single Metric și Multi Metric. Acest lucru este realizat în Kibana pentru a îmbunătăți percepția distribuției valorilor datelor analizate.
Din grafic se observă că procesul s-a comportat anormal stress (de altfel, generat de o unealtă specială) pe serverul poipu, care a influențat (sau a fost un influencer) asupra apariției acestei anomalii.
Avansat
Analiza cu reglaj fin. La analiza Advanced în Kibana apar setări suplimentare. După apăsarea în meniul de creare pe placa Advanced, apare această fereastră cu tab-uri. Tab-ul Job Details a fost omis intenționat, acolo sunt setările de bază care nu se referă direct la setarea analizei.
În summary_count_field_name se poate specifica opțional numele câmpului din documente care conține valori agregate. În acest exemplu - numărul de evenimente pe minut. În se specifică numele câmpului din document care conține o valoare variabilă. Pe baza acestui câmp se pot împărți datele analizate în submulțimi. Observați butonul Add detector în ilustrația anterioară. Mai jos este rezultatul apăsării acestui buton.
Aici este un bloc suplimentar de setări pentru configurarea detectorului de anomalii pentru o anumită sarcină. Cazurile de utilizare specifice (în special legate de securitate) le vom analiza în articolele următoare. De exemplu, unul dintre cazurile discutate. Acesta este legat de identificarea valorilor rare și este realizat .
În câmpul function puteți alege o funcție specifică pentru căutarea anomaliilor. Pe lângă rare, există și câteva funcții interesante - . Acestea identifică anomalii în comportamentul metricilor pe parcursul zilei sau săptămânii, respectiv. Alte funcții de analiză .
În field_name se specifică câmpul documentului pe care se va face analiza. By_field_name poate fi folosit pentru a separa rezultatele analizei în funcție de fiecare valoare specificată a câmpului documentului. Dacă completați over_field_name se va efectua o analiză a populației, pe care am discutat-o anterior. Dacă se specifică o valoare în partition_field_name, atunci pe acest câmp al documentului vor fi calculate linii de bază separate pentru fiecare valoare (exemplu de valoare poate fi numele serverului sau al procesului pe server). În exclude_frequent puteți alege all sau none, ceea ce va însemna excluderea (sau includerea) valorilor frecvente ale câmpurilor documentelor.
În articol, am încercat să oferim o prezentare cât mai concisă a capacităților învățării automate în Elastic Stack, rămânând nenegociat încă multe detalii. Vă rugăm să ne spuneți în comentarii ce cazuri ați reușit să rezolvați cu ajutorul Elastic Stack și pentru ce sarcini îl utilizați. Pentru a lua legătura cu noi, puteți folosi mesaje personale pe Habr sau .
Sursa: habr.com
