Нагадаємо, що в основі Elastic Stack лежать нереляційна база даних Elasticsearch, веб-інтерфейс Kibana та збирачі-обробники даних (найвідоміший Logstash, різні Beats, APM та інші). Один із приємних доповнень всього перерахованого стеку продуктів — аналіз даних за допомогою алгоритмів машинного навчання. У статті ми розуміємо що собою представляють ці алгоритми. Просимо під кат.
Машинне навчання - платна функція умовно-безкоштовного Elastic Stack і входить до пакету X-Pack. Щоб почати користуватися ним достатньо після встановлення активувати 30-денний тріальник. Після закінчення пробного періоду можна запитати підтримку про його продовження або купити передплату. Вартість передплати розраховується немає від обсягу даних, як від кількості використовуваних нод. Ні, обсяг даних впливає, звичайно, на кількість необхідних нод, але все ж таки такий підхід до ліцензування гуманніший по відношенню до бюджету компанії. Якщо немає потреби у високій продуктивності — можна й заощадити.
ML в Elastic Stack написаний на С++ і працює поза 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 – це тонке налаштування алгоритмів додатковими опціями для певних завдань.
Єдина метрика
Аналіз змін однієї метрики — найпростіше, що можна тут зробити. Після натискання на Create Job алгоритм шукає аномалії.
В полі агрегування можна вибрати підхід до пошуку аномалій. Наприклад, при Мін аномальними будуть вважатися значення, нижчі за типові. Є Max, High Mean, Low, Mean, Distinct та інші. Опис усіх функцій можна переглянути .
В полі Поле вказується числове поле у документі, яким будемо проводити аналіз.
В полі — гранулярність проміжків на таймлайні, за якими проводитиметься аналіз. Можна довіритись автоматиці або вибрати вручну. Нижче наведено приклад надто низької гранулярності - ви можете пропустити аномалію. За допомогою цього налаштування можна змінювати чутливість алгоритму до аномалій.
Тривалість зібраних даних – ключова річ, яка впливає на ефективність аналізу. При аналізі алгоритм визначає проміжки, що повторюються, розраховує довірчий інтервал (базові лінії) і виявляє аномалії - нетипові відхилення від звичайної поведінки метрики. Просто для прикладу:
Базові лінії при невеликому відрізку даних:
Коли алгоритм є на чому повчитися — базові лінії виглядає так:
Після запуску завдання алгоритм визначає аномальні відхилення від норми і ранжує їх за ймовірністю аномалії (у дужках вказаний колір відповідної мітки):
Warning (блакитний): менше 25
Minor (yellow): 25-50
Major (orange): 50-75
Critical (red): 75-100
На графіку нижче приклад із знайденими аномаліями.
Тут видно цифру 94, що означає можливість аномалії. Зрозуміло, що якщо значення близьке до 100, значить перед нами аномалія. У стовпці під графіком вказано принизливо мала ймовірність 0.000063634% появи там значення метрики.
Окрім пошуку аномалій у Kibana можна запустити прогнозування. Робиться це елементарно і з того ж уявлення з аномаліями — кнопка Прогноз в верхньому правому кутку.
Прогноз будується максимум на 8 тижнів уперед. Навіть якщо дуже хочеться, більше не можна by design.
У деяких ситуаціях прогноз буде дуже корисним, наприклад, коли відстежується навантаження користувача на інфраструктуру.
Multi Metric
Переходимо до наступної можливості ML в Elastic Stack - аналізу кількох метриків однією пачкою. Але це не означає, що аналізуватиметься залежність однієї метрики від іншої. Це те саме, що і Single Metric тільки з безліччю метрик на одному екрані для зручності порівняння впливу одного на інше. Про аналіз залежності однієї метрики від іншої розповімо у розділі Population.
Після натискання на квадрат із Multi Metric з'явиться вікно з налаштуваннями. На них зупинимося докладніше.
Для початку потрібно вибрати поля для аналізу та агрегацію даних щодо них. Варіанти агрегації тут самі, що й у Single Metric (Max, High Mean, Low, Mean, Distinct та інші). Далі дані за бажання розбиваються по одному з полів (поле Розділити дані). У прикладі ми це зробили полем OriginAirportID. Зверніть увагу, що графік метрик справа тепер представлений у вигляді множини графіків.
Поле Key Fields (Influencers) безпосередньо впливає знайдені аномалії. За замовчуванням тут завжди буде хоч одне значення, а ви можете додати додаткові. Алгоритм враховуватиме вплив цих полів при аналізі та показуватиме «найвпливовіші» значення.
Після запуску в інтерфейсі Kibana з'явиться така картина.
Це т.зв. теплова карта аномалій за кожним значенням поля OriginAirportID, яке ми вказали в Розділити дані. Як і у випадку Single Metric, колір позначає рівень аномального відхилення. Схожий аналіз зручно робити, наприклад, робочими станціями для відстеження тих, де підозріло багато авторизацій і т.д. Ми вже писали , які також можна сюди збирати та аналізувати.
Під тепловою картою список аномалій, з кожного можна перейти на представлення Single Metric для детального аналізу.
населення
Щоб шукати аномалії серед кореляцій між різними метриками, в Elastic Stack є спеціалізований Population-аналіз. Саме за допомогою нього можна пошукати аномальні значення у продуктивності будь-якого сервера в порівнянні з іншими при, наприклад, збільшення кількості запитів до цільової системи.
На цій ілюстрації в полі Population вказано значення, до якого будуть належати аналізовані метрики. У цьому вся це ім'я процесу. В результаті ми побачимо, як завантаження процесора кожним з процесів впливало один на одного.
Зверніть увагу, що графік аналізованих даних відрізняється від випадків із Single Metric та Multi Metric. Це зроблено Kibana by design для поліпшеного сприйняття розподілу значень аналізованих даних.
З графіка видно, що аномально поводився процес стрес (до речі сказати, породжений спеціальною утилітою) на сервері поіпуякий вплинув (або виявився інфлюенсером) на виникнення цієї аномалії.
Advanced
Аналітика з тонким налаштуванням. При Advanced аналізі Kibana з'являються додаткові налаштування. Після натискання в меню створення на плитку Advanced з'являється таке вікно з вкладками. Вкладку опис роботи пропустили навмисно, там базові налаштування, що не стосуються безпосередньо налаштування аналізу.
В summary_count_field_name опціонально можна вказати назву поля з документів, що містить агреговані значення. У цьому прикладі кількість подій на хвилину. У вказується назва значення поля з документа, що містить певне змінне значення. По масці це поле можна розбивати аналізовані дані на підмножини. Зверніть увагу на кнопку Add detector на попередній ілюстрації. Нижче результат натискання на цю кнопку.
Тут є додатковий блок налаштувань для налаштування детектора аномалій під певне завдання. Конкретні кейси використання (особливо безпеки) ми плануємо розібрати в наступних статтях. Для прикладу, один із розібраних кейсів. Він пов'язаний з пошуком значень, що рідко з'являються, і реалізується .
В полі функція можна вибрати певну функцію пошуку аномалій. Крім рідкісний, є ще пара цікавих функцій . Вони виводять аномалії в поведінці метрик протягом дня або тижня відповідно. Інші функції аналізу .
В назва_поля вказується поле документа, яким буде вестися аналіз. By_field_name може використовуватися для поділу результатів аналізу за кожним окремим значенням вказаного поля документа. Якщо заповнити over_field_name вийде population-аналіз, який ми розглядали вище. Якщо вказати значення в partition_field_name, то цим полем документа будуть розраховуватися окремі базові лінії для кожного значення (в ролі значення можуть виступати, наприклад, назва сервера або процесу на сервері). У exclude_frequent можна вибрати всі або ніхто, що означатиме виняток (або включення) значень полів документів, що часто зустрічаються.
У статті ми спробували максимально стисло дати уявлення про можливості машинного навчання в Elastic Stack, за кадром залишилося чимало подробиць. Розкажіть у коментарях, які кейси вдалося вирішити за допомогою Elastic Stack і для яких завдань ви його використовуєте. Для зв'язку з нами можна використовувати особисті повідомлення на Хабре або .
Джерело: habr.com