Разбиране на машинното обучение в Elastic Stack (известен още като Elasticsearch, ELK)

Напомняме, че основата на Elastic Stack се състои от нерелационната база данни Elasticsearch, уеб интерфейса Kibana и агрегаторите за обработка на данни (най-известният от които е Logstash, различни Beats, APM и др.). Едно от приятните допълнения на целия този стек от продукти е анализът на данни с помощта на алгоритми за машинно обучение. В статията разглеждаме какви са тези алгоритми. Моля, под кат.

Машинното обучение е платена функция в условно безплатния Elastic Stack и е част от пакета X-Pack. За да започнете да го използвате, достатъчно е след инсталацията да активирате 30-дневен пробен период. След изтичането на пробния период можете да поискате поддръжка за неговото удължаване или да закупите абонамент. Цената на абонамента не се определя от обема на данните, а от броя на използваните възли. Да, обемът на данните разбира се влияе на броя на необходимите възли, но все пак този подход към лицензирането е по-човечен по отношение на бюджета на компанията. Ако няма нужда от висока производителност — можете и да спестите.

ML в Elastic Stack е написан на C++ и работи извън JVM, в който работи самият Elasticsearch. Тоест, процесът (който между другото се нарича autodetect) консумира всичко, което не може да погълне JVM. На демо стенда това не е толкова критично, но в продуктивна среда е важно да се отделят специални възли за задачите на ML.

Алгоритмите за машинно обучение се делят на две категории — с учител и без учител. В Elastic Stack алгоритмите принадлежат към категорията „без учител“. По тази връзка можете да видите математическите основи на алгоритмите за машинно обучение.

За провеждане на анализ алгоритъмът за машинно обучение използва данни, съхранявани в индексите на Elasticsearch. Задачи за анализ могат да се създават както от интерфейса на Kibana, така и чрез API. Ако го правите чрез Kibana, не е необходимо да знаете някои неща. Например, допълнителните индекси, които алгоритъмът използва по време на работа.

Допълнителни индекси, използвани в процеса на анализ..ml-state — информация за статистическите модели (настройките на анализа);
.ml-anomalies-* — резултати от работата на алгоритмите на ML;
.ml-notifications — настройки на уведомленията за резултатите от анализа.

Структурата на данните в Elasticsearch се състои от индекси и документите, съхранявани в тях. Ако сравним с релационна база данни, индексът може да бъде сравнено с схемата на базата данни, а документът с запис в таблица. Това сравнение е условно и е дадено за опростяване на разбирането на последващия материал за тези, които само са чували за Elasticsearch.

Чрез API е достъпен същият функционал, какъвто е и през уеб-интерфейса, затова за илюстрация и разбиране на концепциите ще покажем как да настроим чрез Kibana. В менюто вляво има раздел Machine Learning, в който може да бъде създадена нова задача (Job). В интерфейса на Kibana това изглежда като на изображението по-долу. Сега ще разгледаме всеки тип задача и ще покажем видовете анализи, които могат да бъдат конструирани тук.

Single Metric — анализ на една метрика, Multi Metric — анализ на две или повече метрики. В единия и в другия случай всяка метрика се анализира в изолирана среда, т.е. алгоритъмът не взема предвид поведението на паралелно анализираните метрики, както би могло да изглежда в случая на Multi Metric. За да се проведе изчисление с оглед на корелацията между различни метрики, може да се приложи Population-анализ. А Advanced — това е фина настройка на алгоритмите с допълнителни опции за конкретни задачи.

Single Metric

Анализ на измененията на една единствена метрика — най-простото, което може да се направи тук. След натискане на Create Job, алгоритъмът ще търси аномалии.

В полето Aggregation може да бъде избран подход за търсене на аномалии. Например, при Min аномални ще се считат стойности под типичните. Има Max, High Mean, Low, Mean, Distinct и други. Описание на всички функции може да се види от връзката.

В полето Field се указва числово поле в документа, по което ще провеждаме анализ.

В полето Bucket span — грануларност на интервалите на времевата линия, по които ще се води анализ. Можете да се доверите на автоматиката или да изберете ръчно. На изображението по-долу е показан пример за твърде ниска грануларност — можете да пропуснете аномалия. С помощта на тази настройка можете да промените чувствителността на алгоритъма към аномалиите.

Продължителността на събраните данни — ключова вещ, която влияе на ефективността на анализа. При анализа алгоритъмът определя повтарящи се интервали, изчислява доверителни интервали (базови линии) и открива аномалии — нетипични отклонения от нормалното поведение на метриката. Просто за пример:

Основни линии при малък набор данни:

Когато алгоритъмът има с какво да се научи, основните линии изглеждат така:

След стартиране на задачата, алгоритъмът определя аномални отклонения от нормата и ги категоризира по вероятност на аномалията (в скобите е указани цветът на съответната етикет):

Warning (син): по-малко от 25
Minor (жълт): 25-50
Major (оранжев): 50-75
Critical (червен): 75-100

На графиката по-долу е представен пример с намерени аномалии.

Тук е видимо числото 94, което обозначава вероятността за аномалия. Ясно е, че тъй като стойността е близка до 100, това представлява аномалия. В колоната под графиката е указана пренебрежимо малка вероятност 0.000063634% за появата на стойност на метриката.

Освен търсенето на аномалии в Kibana, може да се стартира прогноза. Това се прави лесно и от същото представление с аномалиите — бутона Forecast в горния десен ъгъл.

Прогнозата се изгражда максимум за 8 седмици напред. Дори да се иска, повече не може по замисъл.

В някои ситуации прогнозата ще бъде много полезна, например, когато се следи натоварването на потребителите върху инфраструктурата.

Мултимиетрика

Преминаваме към следващото възможност ML в Elastic Stack — анализ на няколко метрики наведнъж. Но това не означава, че ще се анализира зависимостта на една метрика от друга. Това е същото като Single Metric, само че с множество метрики на един екран за удобно сравнение на влиянието на едната върху другата. За анализа на зависимостта на една метрика от друга ще говорим в частта Population.

След натискане на квадрата с Мултимиетрика ще се появи прозорец с настройки. Нека се спрем на тях по-подробно.

Първо е необходимо да изберете полета за анализ и агрегация на данните по тях. Вариантите за агрегация тук са същите, както за Single Metric (Max, High Mean, Low, Mean, Distinct и други). След това данните, ако желаете, се разделят по едно от полетата (поле Split Data). В примера ние го направихме по полето OriginAirportID. Обърнете внимание, че графиката на метриките вдясно сега е представена под формата на множество графики.

Поле Ключови полета (Influencers) пряко влияе на намерените аномалии. По подразбиране тук винаги ще бъде поне една стойност, а вие можете да добавите допълнителни. Алгоритъмът ще отчита влиянието на тези полета при анализа и ще показва най-„влиятелните“ стойности.

След стартиране в интерфейса на Kibana ще се появи приблизително такава картина.

Това е т.н. топлинна карта на аномалии по всяка стойност на полето. OriginAirportID, което посочихме в Split Data. Както при Single Metric, цветът обозначава нивото на аномалното отклонение. Подобен анализ е удобен, например, за работни станции, за проследяване на тези, при които има подозрително много авторизации и т.н. Вече писахме за подозрителни събития в EventLog Windows, които също могат да бъдат събирани и анализирани тук.

Под термалната карта списък с aномалии, от които може да се премине към представяне на Single Metric за детайлен анализ.

Population

За да търсите аномалии сред корелациите между различни метрики, в Elastic Stack има специализирана Population анализ. С негова помощ можете да откриете аномални стойности в производителността на определен сървър в сравнение с останалите при, например, увеличаване на броя на заявките към целевата система.

На тази иллюстрация в полето Population е указана стойността, с която ще се отнасят анализираните метрики. В този случай това е името на процеса. В резултат ще видим как натоварването на процесора от всеки от процесите е влияело помежду си.

Обърнете внимание, че графикът на анализираните данни се различава от случаите с Single Metric и Multi Metric. Това е направено в Kibana по дизайн за подобряване на възприятието на разпределението на стойностите на анализираните данни.

От графиката се вижда, че процесът stress (между другото, генериран от специализирана утилита) на сървъра poipu, който е оказал влияние (или е бил инфлуенсър) за възникването на тази аномалия.

Разширен

Анализ с фини настройки. При разширения анализ в Kibana се появяват допълнителни настройки. След натискане на менюто за създаване на плочката Advanced, се появява такова прозорче с раздели. Разделът Job Details беше пропуснат умишлено, там има основни настройки, които не се отнасят пряко за настройката на анализа.

В summary_count_field_name по желание може да укажете името на полето от документите, съдържащо агрегирани стойности. В този пример — броя на събитията в минута. В categorization_field_name се указва името на полето от документа, което съдържа променлива стойност. По маската на това поле могат да се разделят анализирани данни на подмножества. Обърнете внимание на бутона Add detector на предишната илюстрация. По-долу е резултатът от натискането на този бутон.

Тук е допълнителен блок с настройки за конфигуриране на детектора на аномалии за конкретна задача. Конкретни случаи на употреба (особено тези, свързани с безопасността) планираме да разгледаме в следващите статии. Например, вижте един от разгледаните случаи. Той е свързан с търсенето на рядко срещащи се стойности и се реализира с функцията rare.

В полето function можете да изберете конкретна функция за търсене на аномалии. Освен rare, Има и още няколко интересни функции — time_of_day и time_of_week. Те разкриват аномалии в поведението на метриките през деня или седмицата съответно. Останалите функции за анализ са налични в документацията.

В field_name посочва полето на документа, по което ще бъде извършен анализ. By_field_name може да се използва за разделяне на резултатите от анализа по всяка отделна стойност на посоченото поле на документа. Ако попълните over_field_name ще получите population-анализ, който разгледахме по-горе. Ако зададете стойност в partition_field_name, то по това поле на документа ще се изчисляват отделни основни линии за всяка стойност (в ролята на стойност могат да действат например имена на сървъри или процеси на сървъра). В exclude_frequent можете да изберете всички или none, което ще означава изключване (или включване) на често срещаните стойности на полетата на документите.

В статията се опитахме възможно най-кратко да представим възможностите на машинното обучение в Elastic Stack, зад кадър останаха много подробности. Кажете ни в коментарите кои случаи сте успели да решите с помощта на Elastic Stack и за какви задачи го използвате. За контакт с нас можете да използвате лични съобщения в Хабре или формата за обратна връзка на сайта.

Източник: habr.com