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

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

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

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

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

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

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

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

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

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

Единичен показател

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

В областта Агрегация можете да изберете подход за търсене на аномалии. Например, когато Min стойности под типичните стойности ще се считат за аномални. Яжте Макс, високо средно, ниско, средно, различно и други. Описанията на всички функции могат да бъдат намерени по ссылке.

В областта Област указва числовото поле в документа, върху който ще извършим анализа.

В областта Обхват на кофата — детайлност на интервалите от времевата линия, по която ще се извършва анализът. Можете да се доверите на автоматизацията или да изберете ръчно. Изображението по-долу е пример за твърде ниска детайлност - може да пропуснете аномалията. Използвайки тази настройка, можете да промените чувствителността на алгоритъма към аномалии.

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

Базови линии с малка част от данните:

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

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

Предупреждение (синьо): по-малко от 25
Малък (жълт): 25-50
Мажор (оранжев): 50-75
Критичен (червен): 75-100

Графиката по-долу показва пример за откритите аномалии.

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

В допълнение към търсенето на аномалии, можете да стартирате прогнозиране в Kibana. Това се прави просто и от същия изглед с аномалии - бутон Прогноза в горния десен ъгъл.

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

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

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

Нека да преминем към следващата ML функция в Elastic Stack - анализиране на няколко показателя в една партида. Но това не означава, че ще се анализира зависимостта на един показател от друг. Това е същото като единичен показател, но с множество показатели на един екран за лесно сравнение на въздействието на един върху друг. Ще говорим за анализиране на зависимостта на един показател от друг в раздела Популация.

След като щракнете върху квадратчето с Multi Metric, ще се появи прозорец с настройки. Нека ги разгледаме по-подробно.

Първо трябва да изберете полетата за анализ и агрегиране на данни в тях. Опциите за агрегиране тук са същите като за единична метрика (Макс, високо средно, ниско, средно, различно и други). Освен това, ако желаете, данните се разделят на едно от полетата (поле Разделени данни). В примера направихме това по поле OriginAirportID. Забележете, че графиката на показателите вдясно вече е представена като множество графики.

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

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

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

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

Население

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

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

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

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

Подробно

Анализ с фина настройка. С разширен анализ се появяват допълнителни настройки в Kibana. След като щракнете върху плочката Разширени в менюто за създаване, се появява този прозорец с раздели. Раздел Детайли за работа Нарочно го пропуснахме, има основни настройки, които не са пряко свързани с настройката на анализа.

В summary_count_field_name По желание можете да посочите името на поле от документи, съдържащи обобщени стойности. В този пример, броят на събитията в минута. IN име на_поле_за_категоризация показва името и стойността на поле от документа, което съдържа някаква стойност на променлива. Като използвате маската в това поле, можете да разделите анализираните данни на подгрупи. Обърнете внимание на бутона Добавете детектор в предишната илюстрация. По-долу е резултатът от щракването върху този бутон.

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

В областта функция Можете да изберете конкретна функция за търсене на аномалии. С изключение рядък, има още няколко интересни функции - време на деня и време_от_седмицата. Те идентифицират аномалии в поведението на показателите през деня или седмицата, съответно. Други функции за анализ е в документацията.

В име на полето посочва полето на документа, върху което ще се извършва анализът. По_име_на_поле може да се използва за разделяне на резултатите от анализа за всяка отделна стойност на полето на документа, посочено тук. Ако попълните над_име_на_поле получавате анализа на населението, който обсъдихме по-горе. Ако посочите стойност в дял_поле_име, тогава за това поле на документа ще бъдат изчислени отделни базови линии за всяка стойност (стойността може да бъде например името на сървъра или процеса на сървъра). IN изключва_често може да избира all или нито един, което ще означава изключване (или включване) на често срещани стойности на полетата на документа.

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

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