Хабрахабр

Разбираемся с Machine Learning в Elastic Stack (он же Elasticsearch, он же ELK)

Одно из приятных дополнений всего перечисленного стека продуктов — анализ данных при помощи алгоритмов машинного обучения. Напомним, что в основе Elastic Stack лежат нереляционная база данных Elasticsearch, веб-интерфейс Kibana и сборщики-обработчики данных (самый известный Logstash, различные Beats, APM и другие). Просим под кат.
Машинное обучение — платная функция условно-бесплатного Elastic Stack и входит в пакет X-Pack. В статье мы разбираемся что из себя представляют эти алгоритмы. После истечения пробного периода можно запросить поддержку о его продлении или купить подписку. Чтобы начать им пользоваться достаточно после установки активировать 30-дневный триальник. Нет, объём данных влияет, конечно, на количество необходимых нод, но всё же такой подход к лицензированию более гуманный по отношению к бюджету компании. Стоимость подписки рассчитывается не от объёма данных, а от количества используемых нод. Если нет нужды в высокой производительности — можно и сэкономить.

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

В Elastic Stack алгоритм из категории «без учителя». Алгоритмы машинного обучения делятся на две категории — с учителем и без учителя. По этой ссылке можно посмотреть математический аппарат алгоритмов машинного обучения.

Создавать задания для анализа можно как из интерфейса Kibana так и через API. Для проведения анализа алгоритм машинного обучения использует данные, хранящиеся в индексах Elasticsearch. Например, дополнительные индексы, которые использует алгоритм в процессе работы. Если делать это через Kibana, то некоторые вещи знать необязательно.

Дополнительные индексы, используемые в процессе анализа

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

Структура данных в базе Elasticsearch состоит из индексов и хранящихся в них документах. Если сравнивать с реляционной базой данных, то индекс можно сравнить со схемой базы данных, а документ с записью в таблице. Это сравнение условно и приведено для упрощения понимания дальнейшего материала для тех, кто только слышал про Elasticsearch.

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

В обоих случаях каждая метрика анализируется в изолированной среде, т.е. Single Metric — анализ одной метрики, Multi Metric — анализ двух и более метрик. Чтобы провести расчёт с учётом корреляции различных метрик можно применить Population-анализ. алгоритм не учитывает поведение параллельно анализируемых метрик как это могло показаться в случае Multi Metric. А Advanced — это тонкая настройка алгоритмов дополнительными опциями для определённых задач.

Single Metric

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

Например, при Min аномальными будут считаться значения ниже типичных. В поле Aggregation можно выбрать подход к поиску аномалий. Описание всех функций можно посмотреть по ссылке. Есть Max, Hign Mean, Low, Mean, Distinct и другие.

В поле Field указывается числовое поле в документе, по которому будем проводить анализ.

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

При анализе алгоритм определяет повторяющиеся промежутки, рассчитывает доверительный интервал (базовые линии) и выявляет аномалии — нетипичные отклонения от обычного поведения метрики. Длительность собранных данных — ключевая вещь, которая влияет на эффективность анализа. Просто для примера:

Базовые линии при небольшом отрезке данных:

Когда алгоритму есть на чём поучиться — базовые линии выглядит так:

После запуска задания, алгоритм определяет аномальные отклонения от нормы и ранжирует их по вероятности аномалии (в скобках указан цвет соответствующей метки):

Warning (голубой): менее 25
Minor (yellow): 25-50
Major (orange): 50-75
Critical (red): 75-100

На графике ниже пример с найденными аномалиями.

Понятно, что раз значение близкое к 100, значит перед нами аномалия. Тут видно цифру 94, которая обозначает вероятность аномалии. 000063634% появления там значения метрики. В столбце под графиком указана уничижительно малая вероятность 0.

Делается это элементарно и из того же самого представления с аномалиями — кнопка Forecast в верхнем правом углу. Кроме поиска аномалий в Kibana можно запустить прогнозирование.

Даже если очень хочется — больше нельзя by design. Прогноз строится максимум на 8 недель вперёд.

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

Multi Metric

Переходим к следующей возможности ML в Elastic Stack — анализу нескольких метрик одной пачкой. Но это не значит, что будет анализироваться зависимость одной метрики от другой. Это то же самое, что и Single Metric только с множеством метрик на одном экране для удобства сравнения влияния одного на другое. Про анализ зависимости одной метрики от другой расскажем в части Population.

На них остановимся подробнее. После нажатия на квадрат с Multi Metric появится окно с настройками.

Варианты агрегации тут те же, что и для Single Metric (Max, Hign Mean, Low, Mean, Distinct и другие). Для начала нужно выбрать поля для анализа и агрегацию данных по ним. В примере мы это сделали по полю OriginAirportID. Далее данные при желании разбиваются по одному из полей (поле Split Data). Обратите внимание, что график метрик справа теперь представлен в виде множества графиков.

По умолчанию тут всегда будет хотя бы одно значение, а вы можете добавить дополнительные. Поле Key Fields (Influencers) напрямую влияет на найденные аномалии. Алгоритм будет учитывать влияние этих полей при анализе и показывать самые «влиятельные» значения.

После запуска в интерфейсе Kibana появится примерно такая картина.

тепловая карта аномалий по каждому значению поля OriginAirportID, которое мы указали в Split Data. Это т.н. Похожий анализ удобно делать, например, по рабочим станциям для отслеживания тех, где подозрительно много авторизаций и т.д. Как и в случае с Single Metric, цвет обозначает уровень аномального отклонения. Мы уже писали о подозрительных событиях в EventLog Windows, которые также можно сюда собирать и анализировать.

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

Population

Чтобы искать аномалии среди корреляций между разными метриками в Elastic Stack есть специализированный Population-анализ. Именно с помощью него можно поискать аномальные значения в производительности какого-либо сервера по сравнению с остальными при, например, увеличении количества запросов к целевой системе.

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

Это сделано в Kibana by design для улучшенного восприятия распределения значений анализируемых данных. Обратите внимание, что график анализируемых данных отличается от случаев с Single Metric и Multi Metric.

Из графика видно, что аномально вёл себя процесс stress (к слову сказать, порождённый специальной утилитой) на сервере poipu, который повлиял (или оказался инфлюэнсером) на возникновение этой аномалии.

Advanced

Аналитика с тонкой настройкой. При Advanced анализе в Kibana появляются дополнительные настройки. После нажатия в меню создания на плитку Advanced появляется вот такое окно с вкладками. Вкладку Job Details пропустили намеренно, там базовые настройки не относящиеся непосредственно к настройке анализа.

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

Конкретные кейсы использования (особенно по безопасности) мы планируем разобрать в следующих статьях. Здесь дополнительный блок настроек для настройки детектора аномалий под определённую задачу. Он связан с поиском редко появляющихся значений и реализуется функцией rare. Для примера, посмотрите один из разобранных кейсов.

Кроме rare, есть ещё пара интересных функций — time_of_day и time_of_week. В поле function можно выбрать определённую функцию для поиска аномалий. Остальные функции анализа есть в документации. Они вывляют аномалии в поведении метрик на протяжении дня или недели соответственно.

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

Расскажите в комментариях какие кейсы удалось решить при помощи Elastic Stack и для каких задач вы его используете. В статье мы попытались максимально сжато дать представление о возможностях машинного обучения в Elastic Stack, за кадром осталось ещё немало подробностей. Для связи с нами можно использовать личные сообщения на Хабре или форму обратной связи на сайте.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть