Машинное обучение в Elastic Stack [Рич Кольер] (pdf) читать онлайн

Рич Кольер, Камилла Монтонен, Бахаалдин Азарми

Машинное обучение
в Elastic Stack

Machine Learning
with the Elastic Stack
Gain valuable insights from your data
with Elastic Stack's machine
learning features

Rich Collier
Camilla Montonen
Bahaaldine Azarmi

BIRMINGHAM — MUMBAI

Машинное обучение
в Elastic Stack
Получите максимальную отдачу от ваших
данных благодаря уникальному сочетанию
передовых технологий

Рич Кольер
Камилла Монтонен
Бахаалдин Азарми

Москва, 2022

УДК 004.4
ББК 32.972
К62

К62

Кольер Р., Монтонен К., Азарми Б.
Машинное обучение в Elastic Stack / пер. с англ. В. С. Яценкова. – М.: ДМК
Пресс, 2021. – 380 с.: ил.
ISBN 978-5-93700-107-8
В книге подробно рассматривается работа с Elastic Stack – обширной экосистемой компонентов, которые служат для сбора, поиска и обработки данных. Вы
ознакомитесь с общими принципами машинного обучения, узнаете о методах
автоматического обнаружения аномалий, проверке целостности и анализа данных
из разрозненных источников, научитесь истолковывать результаты обнаружения
и прогнозирования аномалий и использовать их в своих целях, а также выполнять
анализ временных рядов для различных типов данных.
Издание адресовано специалистам, которые работают с данными и хотят интегрировать машинное обучение с эффективными приложениями для мониторинга,
обеспечения безопасности и аналитики в области данных.

УДК 004.4
ББК 32.972

First published in the English language under the title ‘Machine Learning with the Elastic
Stack. Second Edition (978-1-80107-003-4). The Russian-Language 1st edition Copyright © 2021
by DMK Press Publishing under license by No Starch Press Inc. All rights reserved.
Все права защищены. Любая часть этой книги не может быть воспроизведена в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения
владельцев авторских прав.

ISBN 978-1-80107-003-4 (англ.)
ISBN 978-5-93700-107-8 (рус.)

© Packt Publishing, 2021
© Перевод, оформление, издание,
ДМК Пресс, 2021

Содержание
https://t.me/it_boooks

От издательства....................................................................................................12
Об авторах ..............................................................................................................13
О рецензентах .......................................................................................................14
Предисловие ..........................................................................................................15
Часть I. ЗНАКОМСТВО С МАШИННЫМ ОБУЧЕНИЕМ
И ELASTIC STACK ............................................................................................18
Глава 1. Машинное обучение в информационных
технологиях............................................................................................................19
Преодоление исторических вызовов в IT...............................................................19
Что нам делать с потоком данных? .........................................................................20
Причины появления автоматического обнаружения аномалий ........................21
Машинное обучение без учителя и с учителем .....................................................23
Использование машинного обучения без учителя для обнаружения
аномалий .....................................................................................................................24
Что такое необычность?........................................................................................24
Изучение того, что является нормой ..................................................................26
Вероятностные модели .........................................................................................26
Обучение моделей .................................................................................................27
Выявление и устранение тенденций ..................................................................30
Оценка степени необычности .............................................................................31
Роль времени ..........................................................................................................32
Применение машинного обучения с учителем в аналитике фреймов
данных .........................................................................................................................33
Процесс обучения с учителем ..............................................................................33
Заключение .................................................................................................................35

Глава 2. Подготовка и использование Elastic ML ................................36
Технические требования ...........................................................................................36
Включение функций Elastic ML................................................................................36
Включение машинного обучения в собственном кластере ............................37
Включение машинного обучения в облаке – Elasticsearch Service .................39
Обзор операционализации Elastic ML ....................................................................46
Узлы ML ...................................................................................................................46
Задания....................................................................................................................47
Сегментирование данных в анализе временных рядов ..................................48

6  Содержание
Загрузка данных в Elastic ML ...............................................................................49
Служебные хранилища .........................................................................................51
.ml-config .............................................................................................................51
.ml-state-* ...........................................................................................................51
.ml-notifications-* ..............................................................................................52
.ml-annotations-* ...............................................................................................52
.ml-stats-* ............................................................................................................52
.ml-anomalies-*...................................................................................................52
Оркестровка обнаружения аномалий .................................................................52
Снимки модели обнаружения аномалий ...........................................................53
Заключение .................................................................................................................54

Часть II. АНАЛИЗ ВРЕМЕННЫХ РЯДОВ –
ОБНАРУЖЕНИЕ И ПРОГНОЗИРОВАНИЕ АНОМАЛИЙ ..........55
Глава 3. Обнаружение аномалий .................................................................56
Технические требования ...........................................................................................56
Типы заданий Elastic ML ...........................................................................................56
Устройство детектора ................................................................................................58
Функция ..................................................................................................................59
Поле..........................................................................................................................59
Поле partition .........................................................................................................59
Поле by .....................................................................................................................60
Поле over ..................................................................................................................60
Формула детектора ................................................................................................60
Обнаружение изменений частотности событий ...................................................61
Подробнее о функциях count ................................................................................61
Другие функции подсчета ....................................................................................73
Ненулевой подсчет ............................................................................................73
Раздельный подсчет ..........................................................................................74
Обнаружение изменений значений показателей .................................................75
Метрические функции ..........................................................................................76
min, max, mean, median и metric ......................................................................76
varp.......................................................................................................................76
sum и non-null sum ............................................................................................76
Обзор расширенных функций детектора ...............................................................77
Функция rare ...........................................................................................................78
Функция freq_rare ..................................................................................................79
Функция info_content .............................................................................................79
Функции геолокации .............................................................................................79
Функции времени ..................................................................................................80
Разделение анализа по категориальным признакам ...........................................80
Настройка поля разделения .................................................................................80
Разница между разделением с использованием partition и by_field ............82
Является ли двойное разделение пределом возможного?..........................83
Обзор временного и популяционного анализов...................................................84

Содержание  7

Категоризация в анализе неструктурированных сообщений .............................86
Типы сообщений, подходящие для категоризации..........................................88
Предварительная категоризация ........................................................................88
Анализ категорий ..................................................................................................89
Пример задания по категоризации ....................................................................90
Когда не следует использовать категоризацию ................................................94
Управление Elastic ML через API .............................................................................95
Заключение .................................................................................................................97

Глава 4. Прогнозирование...............................................................................98
Технические требования ...........................................................................................98
Ключевое различие между предсказаниями и пророчествами..........................98
Для чего применяется прогнозирование? ...........................................................100
Как работает прогнозирование? ............................................................................100
Прогнозирование одиночного временного ряда ................................................103
Просмотр результатов прогнозирования.............................................................114
Прогнозирование нескольких временных рядов ...............................................119
Заключение ...............................................................................................................122

Глава 5. Интерпретация результатов.......................................................123
Технические требования .........................................................................................123
Просмотр хранилища результатов Elastic ML......................................................123
Оценка аномалий .....................................................................................................128
Оценка на уровне сегмента ................................................................................129
Нормализация ......................................................................................................131
Оценка на уровне фактора влияния .................................................................131
Факторы влияния.................................................................................................133
Оценка на уровне записи ...................................................................................135
Описание схемы хранилища результатов ............................................................136
Результаты на уровне сегмента .........................................................................137
Результаты на уровне записи.............................................................................140
Результаты на уровне факторов влияния ........................................................143
Аномалии в нескольких сегментах .......................................................................145
Пример аномалии в нескольких сегментах .....................................................145
Оценка аномалии в нескольких сегментах......................................................146
Результаты прогноза ...............................................................................................148
Запрос результатов прогноза .............................................................................149
API результатов Elastic ML ......................................................................................151
Конечные точки API результатов ......................................................................152
API обобщения сегментов ..................................................................................152
API категорий .......................................................................................................153
Пользовательские панели мониторинга и рабочие панели Canvas .................155
Панель инструментов встраивания ..................................................................155
Аномалии как аннотации в TSVB ......................................................................156
Настройка рабочих панелей Canvas ..................................................................159
Заключение ...............................................................................................................162

8  Содержание

Глава 6. Создание и использование оповещений.............................163
Технические требования .........................................................................................163
Определение и принцип работы оповещений ....................................................164
Аномалии не обязательно нуждаются в оповещениях ..................................164
Точное время имеет значение ...........................................................................165
Создание оповещений из интерфейса машинного обучения ..........................168
Определение заданий по обнаружению аномалий ........................................168
Создание оповещений для пробных заданий .................................................174
Моделирование аномального поведения в реальном времени ...................179
Получение и просмотр оповещений.................................................................180
Создание оповещений с помощью Watcher .........................................................183
Использование устаревшего варианта watch ...................................................183
trigger .................................................................................................................184
input ...................................................................................................................184
condition ............................................................................................................187
action .................................................................................................................188
Пользовательские шаблоны watch с уникальной функциональностью ......189
Связанный ввод и сценарий условий ...........................................................189
Передача информации между связанными входами ................................190
Заключение ...............................................................................................................191

Глава 7. Выявление истинных причин аномалий ..............................192
Технические требования .........................................................................................192
Настоящее значение термина AIOps.....................................................................192
Значимость и ограничения KPI .............................................................................194
Выходя за рамки KPI ................................................................................................197
Организация данных для анализа .........................................................................198
Настраиваемые запросы для каналов данных ................................................199
Дополнение получаемых данных......................................................................202
Использование контекстной информации ..........................................................203
Аналитическое разделение ................................................................................203
Статистические факторы влияния ....................................................................204
Анализ первопричин аномалии ............................................................................205
История проблемы ..............................................................................................205
Корреляция и общие факторы влияния ...........................................................207
Заключение ...............................................................................................................212

Глава 8. Другие приложения Elastic Stack для обнаружения
аномалий ...............................................................................................................213
Технические требования .........................................................................................213
Обнаружение аномалий в Elastic APM ..................................................................213
Включение обнаружения аномалий для APM .................................................214
Просмотр результатов задания по обнаружению аномалий ........................219
Создание заданий машинного обучения с помощью распознавателя
данных ...................................................................................................................222
Обнаружение аномалий в приложении Logs .......................................................224

Содержание  9

Категории журналов ............................................................................................224
Журнал аномалий ................................................................................................225
Обнаружение аномалий в приложении Metrics ..............................................227
Обнаружение аномалий в приложении Uptime ..................................................230
Обнаружение аномалий в приложении Elastic Security .....................................233
Готовые задания по обнаружению аномалий .................................................233
Оповещения на основе заданий обнаружения аномалий .............................235
Заключение ...............................................................................................................237

Часть III. АНАЛИЗ ФРЕЙМОВ ДАННЫХ ...........................................238
Глава 9. Введение в анализ фреймов данных....................................239
Технические требования .........................................................................................240
Основы преобразования данных ...........................................................................240
Чем полезны преобразования?..........................................................................240
Анатомия преобразований ................................................................................241
Использование преобразований для анализа заказов
интернет-магазина..............................................................................................242
Более сложные конфигурации сводной таблицы и агрегирования .............246
Различие между пакетными и непрерывными преобразованиями............248
Анализ данных социальных сетей с помощью непрерывных
преобразований ...................................................................................................250
Использование Painless для расширенных конфигураций
преобразования........................................................................................................253
Знакомство с Painless ..........................................................................................254
Переменные, операторы и управление выполнением ..............................255
Функции ............................................................................................................260
Совместное использование Python и Elasticsearch .............................................263
Краткий обзор клиентов Python Elasticsearch .................................................264
Зачем нам нужен Eland? .................................................................................266
Знакомство с Eland ..........................................................................................267
Заключение ...............................................................................................................269
Дополнительная литература ..................................................................................270

Глава 10. Обнаружение выбросов ............................................................272
Технические требования .........................................................................................273
Принцип работы механизма обнаружения выбросов ........................................273
Обзор четырех методов обнаружения выбросов ............................................274
Методы, основанные на расстоянии ............................................................274
Методы, основанные на плотности ..............................................................275
Оценка влияния характеристики ......................................................................276
Как рассчитывается оценка влияния характеристик для каждой
точки? ................................................................................................................277
Чем обнаружение выбросов отличается от обнаружения аномалий? .........278
Сравнение вероятностных моделей и экземпляров ..................................278
Подсчет оценок ................................................................................................279

10  Содержание
Характеристики данных .................................................................................279
Потоковая и пакетная обработка ..................................................................279
Применение обнаружения выбросов на практике .............................................280
Оценка качества обнаружения выбросов с помощью API Evaluate .................285
Настройка гиперпараметров для обнаружения выбросов ................................290
Заключение ...............................................................................................................293

Глава 11. Классификационный анализ ...................................................294
Технические требования .........................................................................................295
Классификация: от данных к обученной модели................................................295
Классифицирующие модели учатся на данных ..............................................296
Конструирование признаков .............................................................................298
Оценка модели .....................................................................................................299
Простой пример классификации...........................................................................300
Деревья решений с градиентным усилением......................................................307
Введение в деревья решений .............................................................................308
Градиентное усиление ........................................................................................309
Гиперпараметры ......................................................................................................309
Интерпретация результатов ...................................................................................313
Вероятность класса..........................................................................................314
Оценка класса ..................................................................................................314
Важность признака..........................................................................................314
Заключение ...............................................................................................................316
Дополнительная литература ..................................................................................317

Глава 12. Регрессия ...........................................................................................318
Технические требования .........................................................................................318
Использование регрессионного анализа для прогнозирования цен
на жилье.....................................................................................................................319
Использование деревьев решений в регрессионном анализе ..........................326
Заключение ...............................................................................................................329
Дополнительная литература ..................................................................................329

Глава 13. Логический вывод моделей ....................................................330
Технические требования .........................................................................................330
Поиск, импорт и экспорт обученных моделей с помощью API ........................331
Обзор API обученных моделей ..........................................................................331
Экспорт и импорт обученных моделей с помощью API и Python ................333
Обработчики логического вывода и конвейеры данных ...................................336
Обработка отсутствующих или поврежденных данных в конвейерах........345
Получение развернутой информации о прогнозах........................................347
Импорт внешних моделей с помощью eland ........................................................348
Кратко о поддержке внешних моделей в eland................................................349
Обучение DecisionTreeClassifier и импорт в Elasticsearch с помощью
eland ........................................................................................................................349
Заключение ...............................................................................................................353

Содержание  11

Приложение. Советы по обнаружению аномалий ...........................354
Технические требования .........................................................................................354
Роль факторов влияния в разделенных и неразделенных заданиях ...............354
Использование односторонних функций ............................................................361
Исключение определенных интервалов времени ..............................................363
Исключение наступающего (известного) интервала времени .....................364
Создание события календаря ........................................................................364
Остановка и запуск потока данных в нужное время .................................365
Исключение интервала времени постфактум.................................................366
Клонирование задания и повторный запуск исторических данных.......366
Возврат задания к предыдущему снимку модели ......................................366
Использование настраиваемых правил и фильтров ..........................................368
Создание собственных правил ..........................................................................369
Использование настраиваемых правил для оповещения «сверху вниз» ....370
Соображения относительно пропускной способности заданий.......................371
О вреде излишней сложности сценариев .............................................................372
Обнаружение аномалий в вычисляемых полях ..................................................373
Заключение ...............................................................................................................376

Предметный указатель ...................................................................................377

От издательства
Отзывы и пожелания
Мы всегда рады отзывам наших читателей. Расскажите нам, что вы думаете
об этой книге – что понравилось или, может быть, не понравилось. Отзывы
важны для нас, чтобы выпускать книги, которые будут для вас максимально
полезны.
Вы можете написать отзыв на нашем сайте www.dmkpress.com, зайдя на
страницу книги и оставив комментарий в разделе «Отзывы и рецензии».
Также можно послать письмо главному редактору по адресу dmkpress@gmail.
com; при этом укажите название книги в теме письма.
Если вы являетесь экспертом в какой-либо области и заинтересованы в написании новой книги, заполните форму на нашем сайте по адресу http://
dmkpress.com/authors/publish_book/ или напишите в издательство по адресу
dmkpress@gmail.com.

Список опечаток
Хотя мы приняли все возможные меры для того, чтобы обеспечить высокое качество наших текстов, ошибки все равно случаются. Если вы найдете
ошибку в одной из наших книг, мы будем очень благодарны, если вы сообщите о ней главному редактору по адресу dmkpress@gmail.com. Сделав это,
вы избавите других читателей от недопонимания и поможете нам улучшить
последующие издания этой книги.

Нарушение авторских прав
Пиратство в интернете по-прежнему остается насущной проблемой. Издательства «ДМК Пресс» и Packt очень серьезно относятся к вопросам защиты авторских прав и лицензирования. Если вы столкнетесь в интернете с незаконной
публикацией какой-либо из наших книг, пожалуйста, пришлите нам ссылку на
интернет-ресурс, чтобы мы могли применить санкции.
Ссылку на подозрительные материалы можно прислать по адресу электронной почты dmkpress@gmail.com.
Мы высоко ценим любую помощь по защите наших авторов, благодаря
которой мы можем предоставлять вам качественные материалы.

Об авторах
Рич Кольер (Rich Collier) – архитектор решений в Elastic. Он присоединился
к команде Elastic после приобретения Prelert. Рич имеет более чем 20-летний
опыт работы в качестве архитектора решений и системного инженера предпродажной подготовки программного обеспечения, оборудования и сервисных решений. Профессиональные интересы Рича включают аналитику
больших данных, машинное обучение, обнаружение аномалий, обнаружение
угроз, обеспечение безопасности, управление производительностью приложений, веб-приложения и технологии контакт-центров. Рич проживает
в Бостоне, штат Массачусетс.
Камилла Монтонен (Camilla Montonen) – старший инженер по машинному
обучению в Elastic.
Бахаалдин Азарми (Bahaaldine Azarmi), или коротко Баха, – архитектор
решений в Elastic. До этого Баха был соучредителем ReachFive, платформы
маркетинговых данных, ориентированной на поведение пользователей и социальную аналитику. Баха также сотрудничал с различными поставщиками программного обеспечения, такими как Talend и Oracle, где он занимал
должности архитектора решений и системного архитектора. Баха является
автором нескольких книг, в том числе Learning Kibana 5.0, Scalable Big Data
Architecture и Talend for Big Data. Живет в Париже и имеет степень магистра
компьютерных наук Парижского технологического института.

О рецензентах
Апурва Джоши (Apoorva Joshi) в настоящее время работает специалистом по
безопасности данных в Elastic (ранее Elasticsearch), где она занимается применением машинного обучения для обнаружения вредоносных программ
в конечных точках системы. До Elastic работала научным сотрудником в FireEye, где исследовала применение машинного обучения в задачах безопасности электронной почты. У нее разностороннее инженерное образование:
бакалавр электротехники и магистр информационных технологий (с акцентом на машинное обучение).
Лицзюань Чжун (Lijuan Zhong) – опытный инженер в области технологий
Elastic и облачных вычислений. У нее степень магистра информационных
технологий и почти 20-летний опыт работы в сфере информационных технологий и телекоммуникаций. Сейчас сотрудничает с Netnordic – основным
партнером Elastic в Швеции. Она начала свой путь в Elastic в 2019 году и стала сертифицированным инженером Elastic, также прошла курс машинного
обучения Стэнфордского университета. Возглавляет множество образовательных программ и проектов, связанных с Elastic и машинным обучением,
и клиенты всегда очень довольны результатом. Она была соорганизатором
конференции Elastic Stockholm в 2020 г., приняла участие в конференции
сообщества Elastic в 2021 г. и выступила с докладом о машинном обучении
с помощью Elastic Stack. В 2021 году была удостоена бронзовой медали за
вклад в развитие Elastic.

Предисловие
Elastic Stack, ранее известный как ELK Stack, представляет собой комплексное решение для анализа журналов, которое помогает пользователям эффективно получать, обрабатывать и анализировать данные поиска. Благодаря
применению машинного обучения – ключевой особенности решения – Elastic Stack делает этот процесс еще более эффективным. Эта книга содержит
всесторонний обзор функций машинного обучения Elastic Stack как для анализа данных временных рядов, так и для классификации, регрессии и обнаружения выбросов.
Знакомство с экосистемой Elastic Stack начинается с интуитивно понятного объяснения концепций машинного обучения. Затем под руководством
авторов вы выполните анализ временных рядов для различных типов данных, таких как файлы журналов, сетевые потоки, показатели приложений
и финансовые данные. По мере прочтения глав вы научитесь использовать
машинное обучение в Elastic Stack для ведения журнала, обеспечения безопасности и отслеживания показателей. Наконец, вы узнаете, как анализ
фреймов открывает доступ к совершенно новым сценариям использования
данных, в которых вам поможет машинное обучение.
После прочтения этой книги вы приобретете практический опыт совместного использования технологии машинного обучения и Elastic Stack, а также
знания, необходимые для включения машинного обучения в вашу платформу распределенного поиска и анализа данных.

Для кого эта книга
Если вы профессионал в области данных и хотите получить представление
о технологиях Elasticsearch, не прибегая к помощи специалиста по машинному обучению и не разрабатывая собственные решения, то эта книга про
совместное применение машинного обучения и Elastic Stack для вас. Вы
также найдете эту книгу полезной, если хотите интегрировать машинное
обучение с вашими приложениями для мониторинга, обеспечения безопасности и аналитики. Чтобы извлечь из данной книги максимальную пользу,
необходимо знать и уметь применять на практике Elastic Stack.

какие темы охватывает эта книга
Глава 1 служит введением в тему и справочным пособием по историческим
проблемам ручного анализа данных в IT и технологиях безопасности. В этой
главе также представлен всесторонний обзор базовых принципов работы

16  Предисловие
машинного обучения Elastic (Elastic ML), чтобы читатель получил полное
представление о том, что происходит «за кулисами».
В главе 2 объясняется, каким образом применяются возможности машинного обучения в Elastic Stack, а также подробно описывается теория работы
алгоритмов Elastic ML. Кроме того, в этой главе дается подробное объяснение
логистики операций машинного обучения применительно к Elastic.
В главе 3 подробно рассматриваются методы автоматического обнаружения аномалий с обучением без учителя, которые лежат в основе анализа
временных рядов.
В главе 4 показано, что сложные модели временных рядов Elastic ML можно
использовать не только для обнаружения аномалий. Возможности прогнозирования позволяют пользователям экстраполировать тенденции и поведение в будущее, чтобы помочь в решении таких задач, как планирование
мощности.
В главе 5 рассказано, как детально истолковать результаты обнаружения
и прогнозирования аномалий и использовать их в своих целях в визуализации данных, информационных панелях и инфографике.
В главе 6 рассмотрены различные методы интеграции возможностей
упреждающего уведомления Elastic и данных, полученных с помощью машинного обучения, чтобы сделать обнаружение аномалий еще более эффективным.
В главе 7 показано, как использование Elastic ML для проверки целостности и анализа данных из разрозненных источников в коррелированных
представлениях дает аналитику преимущество с точки зрения наследования
подходов.
В главе 8 объясняется, как обнаружение аномалий используется другими
приложениями в Elastic Stack для повышения эффективности анализа данных.
В главе 9 рассмотрен анализ фрейма данных, его отличие от обнаружения аномалий временных рядов и рассказано, какие инструменты доступны
пользователю для загрузки, подготовки, преобразования и анализа данных
с помощью Elastic ML.
В главе 10 описано применение анализа фреймов в сочетании с Elastic ML
в аналитике данных.
В главе 11 говорится о возможности классификационного анализа фреймов данных в сочетании с Elastic ML.
В главе 12 рассмотрено использование регрессионного анализа фреймов
данных в сочетании с Elastic ML.
Глава 13 описывает использование обученных моделей машинного обучения для логического вывода – прогнозирования выходных значений во время реальной работы системы.
Приложение включает в себя множество практических советов, которые
отчасти выходят за рамки других глав. Эти полезные советы помогут вам
максимально эффективно использовать Elastic ML.

Условные обозначения и соглашения, принятые в книге  17

как получить максимальную отДачу
от этой книги
Чтобы получить максимальную отдачу от этой книги, вам понадобится
компьютер с хорошим подключением к интернету и учетной записью Elastic.

скачивание исхоДного коДа примеров
Вы можете скачать файлы примеров кода для этой книги с GitHub по адресу
https://github.com/PacktPublishing/Machine-Learning-with-Elastic-Stack-SecondEdition. Если выйдет обновление кода, оно появится в репозитории GitHub.

условные обозначения и соглашения,
принятые в книге
В книге используются следующие типографские соглашения.
Курсив – используется для смыслового выделения важных положений, новых терминов, имен команд и утилит, а также слов и предложений на естественном языке.
Моноширинный шрифт – применяется для листингов программ, а также в обычном тексте для обозначения имен переменных, функций, типов, объектов,
баз данных, переменных среды, операторов, ключевых слов и других программных конструкций и элементов исходного кода.
Моноширинный полужирный шрифт – используется для обозначения команд или
фрагментов текста, которые пользователь должен ввести дословно без изменений, а также в листингах программ, если необходимо обратить особое
внимание на фрагмент кода.
Моноширинный курсив – применяется для обозначения в исходном коде или
в командах шаблонных меток-заполнителей, которые должны быть заменены соответствующими контексту реальными значениями.
Советы оформлены так.
Примечания оформлены так.
Важные примечания оформлены так.

Часть

I
ЗНАКОМСТВО
С МАШИННЫМ
ОБУ ЧЕНИЕМ
И EL ASTIC STACK

В этой части представлено обобщенное описание Elastic ML – не только с точки зрения алгоритмов, но и с точки зрения организации работы программного обеспечения в Elastic Stack.
Эта часть книги состоит из следующих глав:
 главы 1 «Машинное обучение в информационных технологиях»;
 главы 2 «Подготовка и использование Elastic ML».

Глава

1
Машинное обучение
в информационных
технологиях

https://t.me/it_boooks
Десять лет назад идея использования технологий машинного обучения (ML)
в IT-структурах или IT-безопасности казалась чем-то вроде научной фантастики. Однако сегодня это одно из самых популярных модных словечек,
используемых поставщиками программного обеспечения. Очевидно, что за
минувшее десятилетие произошел серьезный сдвиг как в осознании потребности в технологии ML, так и в возможностях, которые она предоставляет.
Эта эволюция важна для понимания того, как появился инструмент Elastic
ML и для решения каких проблем он был разработан.
Эта глава посвящена обзору истории и концепций, лежащих в основе работы Elastic ML. В ней также представлены различные виды анализа, которые
можно провести, и задачи, которые можно решить с помощью Elastic ML.
В частности, мы рассмотрим следующие темы:
преодоление исторических вызовов в IT;
что нам делать с потоком данных;
причины появления автоматического обнаружения аномалий;
машинное обучение без учителя и с учителем;
использование машинного обучения без учителя для обнаружения
аномалий;
 применение машинного обучения с учителем в аналитике фреймов
данных.







преоДоление исторических вызовов в IT
К специалистам по поддержке IT-структур и архитекторам решений предъявляют высокие требования. Их роль не ограничивается внедрением новых передовых проектов и технологий для бизнеса; они также должны поддерживать безопасную и бесперебойную работу развернутых в настоящее
время приложений. Сегодняшние приложения значительно сложнее, чем

Powered by TCPDF (www.tcpdf.org)

20  Машинное обучение в информационных технологиях
когда-либо прежде, – они разбиты на множество компонентов, распределены и, возможно, виртуализированы/контейнеризированы. Они могут быть
разработаны с использованием Agile-методики или аутсорсинговой командой. Вдобавок они, скорее всего, постоянно меняются. Некоторые команды
DevOps заявляют, что обычно они вносят более 100 изменений в день в действующую производственную систему. Пытаться понять состояние и поведение современного приложения уровня предприятия – все равно что механику
пытаться отремонтировать автомобиль, пока он едет по шоссе.
Аналитики по безопасности в области IT тоже с трудом справляются с повседневной работой, но, очевидно, у них другой фокус внимания – обеспечение безопасности предприятия и устранение возникающих угроз. Хакеры,
вредоносные программы и инсайдеры-мошенники стали настолько распространенными и изощренными, что по мнению большинства специалистов по
безопасности сегодня вопрос заключается не в том, будет ли взломана организация, а в том, насколько быстро она узнает об этом (если вообще узнает).
Очевидно, что узнать о взломе как можно раньше (до того, как будет нанесен
слишком большой ущерб) предпочтительнее, чем услышать об этом впервые
от правоохранительных органов или из вечерних новостей.
Но что же нам делать? Возможно, проблема в том, что экспертам по приложениям и аналитикам службы безопасности не хватает данных, которые
помогли бы им эффективно выполнять свою работу? На самом деле в большинстве случаев ситуация противоположная. Многие IT-специалисты и организации тонут в данных.

что нам Делать с потоком Данных?
IT-отделы десятилетиями вкладывали силы и средства в инструменты мониторинга, и нередко в их распоряжении есть дюжина или более инструментов,
активно собирающих и архивирующих данные, объем которых измеряется
в терабайтах или даже петабайтах в день. Источники этих данных чрезвычайно вариативны – от элементарной статистики на уровне инфраструктуры
и сети до результатов глубокой диагностики и/или файлов журналов системы
и приложений.
Ключевые показатели эффективности (key performance indicators, KPI)
на уровне бизнеса также можно отслеживать, иногда включая данные об
опыте конечного пользователя. Глубина и широта охвата доступных данных
сегодня больше, чем когда-либо. Для обнаружения возникающих проблем
или угроз, скрытых в этих данных, традиционно использовалось несколько
основных подходов к преобразованию «сырых» данных в информационные
объекты:
 фильтрация/поиск: некоторые инструменты предоставляют пользователю возможность фильтрации или поиска, чтобы сократить данные
до более удобоваримого ограниченного набора. Хотя эта возможность
чрезвычайно полезна, она чаще всего используется бессистемно, в основном когда возникает подозрение в наличии проблемы. Даже в этом

Причины появления автоматического обнаружения аномалий  21

случае успех обычно зависит от способности пользователя понять, что
он ищет, и от его уровня опыта – как от знания предыдущих ситуаций,
так и от навыков использования самой технологии поиска;
 визуализация: панели мониторинга, диаграммы и виджеты также
чрезвычайно полезны для понимания того, что происходит с данными, и выявления тенденций. Однако визуализации пассивны по своей сути и требуют постоянного наблюдения на предмет обнаружения
значимых отклонений. Когда количество собираемых и отображаемых
на экране показателей превышает возможности человеческого восприятия (или даже площадь экрана для их отображения), полезность
визуализации резко снижается;
 пороговые значения/правила: чтобы обойти физические ограничения визуализации и внести в наблюдение за данными активный
компонент (т. е. реакцию на изменение данных), многие инструменты
позволяют пользователю определять правила или действия, которые
запускаются при соблюдении определенных условий или возникновении определенных зависимостей между элементами данных. Однако
маловероятно, что вы сможете реалистично определить все подходящие рабочие диапазоны или смоделировать все возможные зависимости в современных сложных и распределенных приложениях. Кроме
того, количество и скорость изменений в приложении или среде могут
быстро сделать любой статический набор правил бесполезным.
Аналитики обнаружили, что погрязли в ложных срабатываниях предупреждающих систем – широко известная проблема мальчика, который кричал о несуществующих волках, – что приводит к возмущению пользователей
по поводу инструментов, генерирующих предупреждения, и скептицизму по
поводу ценности, которой обладает такое предупреждение.
В конечном счете стало ясно, что нужен другой подход – такой, который не
обязательно был бы полным отказом от прошлых методов, но мог бы обеспечить уровень автоматизации и значимого увеличения эмпирической ценности данных. Посмотрим правде в глаза: люди несовершенны – у нас есть
скрытые предубеждения и ограничения способности запоминать информацию, и мы легко отвлекаемся и утомляемся. Алгоритмы машинного обучения
при правильном использовании могут легко восполнить эти недостатки.

причины появления автоматического
обнаружения аномалий
Машинное обучение, будучи очень обширной темой, охватывающей многие
области, от беспилотных автомобилей до компьютерных программ, приносящих выигрыш в играх, стало естественным кандидатом на роль эффективного решения. Если вы понимаете, что большинство задач мониторинга
приложений или поиска угроз безопасности представляяют собой всего лишь
вариации на тему поиска отличий от обычного хода событий, тогда дисципли-

22  Машинное обучение в информационных технологиях
на обнаружения аномалий становится естественным местом для применения методов машинного обучения IT-специалистами.
Однако в науке об обнаружении аномалий, безусловно, нет ничего нового.
Многие очень умные люди в течение долгих лет исследовали и применяли
различные алгоритмы и методы. Но на практике обнаружение аномалий
в IT-данных сопровождается некоторыми специфическими ограничениями,
которые делают интересные с академической точки зрения алгоритмы непригодными для работы. Речь о следующих ограничениях:
 своевременность. Уведомление об отключении, нарушении или другой существенной аномальной ситуации должно стать известно как
можно быстрее, чтобы смягчить последствия. Стоимость простоя или
риск продолжения нарушения безопасности сводятся к минимуму,
если быстро устранить проблему. Алгоритмы, которые не успевают
отслеживать сегодняшние IT-данные в реальном времени, имеют ограниченную ценность;
 масштабируемость. Как упоминалось ранее, в современных IT-средах
объем, скорость и вариативность IT-данных продолжают стремительно расти. Алгоритмы, которые занимаются мониторингом и анализом
огромных данных, должны иметь возможность линейного масштабирования сообразно с данными, иначе спустя какое-то время они утратят применимость;
 эффективность. Бюджеты IT-подразделений часто подвергают тщательной проверке на предмет нерациональных расходов, и многие организации постоянно пытаются их урезать. Закупка дополнительного
парка суперкомпьютеров для запуска неэффективных алгоритмов вряд
ли будет утверждена руководством компании. Скорее, в качестве частичного решения придется использовать скромное стандартное оборудование с типичными характеристиками;
 обобщаемость. Хотя узкоспециализированная наука о данных часто является лучшим способом решения конкретной информационной проблемы, разнообразие данных в IT сформировало потребность
в подходе, который применим в большинстве случаев. Повторное использование одних и тех же методов намного более рентабельно в долгосрочной перспективе;
 адаптивность. Постоянно меняющаяся IT-среда быстро сделает жесткий алгоритмбесполезным. Обучение и переподготовка модели ML
превращаются в бесконечное занятие и фактически в пустую трату
времени, чего мы не можем себе позволить;
 точность. Мы уже говорили, что усталость от ложных предупреждений
из-за устаревших пороговых и основанных на правилах систем является реальной проблемой. Замена одного генератора ложных тревог на
другой никого не впечатлит;
 простота использования. Даже если все ранее упомянутые ограничения могут быть удовлетворены, любое решение, для реализации которого потребуется армия специалистов по данным, окажется слишком
дорогостоящим и будет немедленно отвергнуто.

Машинное обучение без учителя и с учителем  23

Итак, мы подошли к сути задачи – созданию быстрого, масштабируемого, точного и недорогого решения для обнаружения аномалий, которое
все будут охотно использовать, потому что оно работает безупречно. Без
проблем!
Как бы пугающе это ни звучало на самом деле, основатель и технический
директор Prelert Стив Додсон принял этот вызов еще в 2010 году. Хотя Додсон,
несомненно, заложил в фундамент компании свои академические знания,
технология, которая в конечном итоге превратилась в Elastic ML, зародилась
в муках попыток устранения реальных сбоев приложений уровня предприятия. Первая из них – досадный периодический сбой в работе торговой платформы в крупной лондонской финансовой компании. Додсон и несколько
инженеров, присоединившихся к этому предприятию, помогли команде банка использовать технологию обнаружения аномалий для автоматического
поиска «иголки в стоге сена», что позволило аналитикам сосредоточиться
на небольшом наборе соответствующих показателей и записей в журналах
событий, которые вызывали подозрения. Выявление первопричины (отказ
службы, восстановление которой вызывало каскадный сбой других служб
и причиняло ущерб) в конечном итоге обеспечило стабильную работу приложения и избавило банк от необходимости тратить много денег на другое
решение – дорогостоящее обновление сетевой инфраструктуры.
Однако со временем стало ясно, что даже этот показательный успех был
только началом. Спустя несколько лет и несколько тысяч примеров использования в реальном мире возник союз Prelert и Elastic – сочетание платформы,
делающей большие данные легкодоступными, и технологий, которые помогли преодолеть ограничения традиционных методов анализа.
Перенесемся в 2021 год, спустя полные 5 лет после объединения усилий,
когда Elastic ML прошел долгий путь в развитии и расширении возможностей платформы ML. Это второе издание книги включает в себя обновления,
внесенные в Elastic ML за прошедшие годы, в том числе интеграцию с некоторыми решениями Elastic, касающимися наблюдаемости и безопасности.
Во второе издание мы добавили введение в аналитику фреймов данных,
которая подробно обсуждается в третьей части книги. Чтобы получить обоснованное и глубокое понимание того, как работает Elastic ML, нам сначала
нужно рассмотреть терминологию и идеи, а потом двигаться дальше.

машинное обучение без учителя и с учителем
Хотя существует множество подтипов машинного обучения, два самых известных (и относящихся к Elastic ML) – это обучение без учителя и обучение
с учителем.
В машинном обучении без учителя нет внешнего руководства или указаний со стороны людей. Другими словами, алгоритмы должны изучать (и моделировать) шаблоны данных исключительно самостоятельно. В целом самая
большая проблема здесь состоит в том, чтобы алгоритмы точно выявляли
отклонения от нормальных шаблонов входных данных, дабы обеспечить

24  Машинное обучение в информационных технологиях
вывод модели, значимый для пользователя. Если алгоритм не может этого
сделать, то он бесполезен и непригоден для использования. Следовательно,
алгоритмы должны быть достаточно надежными и способны учитывать все
тонкости поведения входных данных.
В машинном обучении с учителем для моделирования желаемого результата используются размеченные входные данные (часто многомерные). Ключевое отличие от машинного обучения без учителя состоит в том, что человек априори решает, какие переменные использовать в качестве входных
данных, а также предоставляет «достоверные» примеры ожидаемой целевой
переменной – обучающие данные. Затем алгоритмы машинного обучения
изучают, как входные переменные взаимодействуют и влияют на известную выходную цель. Чтобы точно получить желаемый результат (например,
прогноз), алгоритм должен иметь набор «правильных данных», которые не
только отражают зависимость выхода от входа, но и достаточно разнообразны, чтобы модель смогла изучить максимально широкий спектр сочетаний
переменных на входе.
Таким образом, в обоих случаях требуются качественные входные данные,
хорошие алгоритмические подходы и хороший механизм, позволяющий ML
как изучать поведение данных, так и применять это обучение для оценки последующих наблюдений за этими данными. Давайте посмотрим, как Elastic
ML использует машинное обучение без учителя и с учителем.

использование машинного обучения
без учителя Для обнаружения аномалий
Чтобы сформировать у вас более полное представление о том, как работает
обнаружение аномалий Elastic ML с использованием машинного обучения
без учителя, мы рассмотрим следующие темы:
 строгое определение необычности в контексте технологии;
 наглядный пример обучения без учителя;
 описание того, как технология ML моделирует, устраняет тенденции
и оценивает данные.

Что такое необычность?
Обнаружение аномалий – это то, чем мы регулярно занимаемся в повседневной жизни, поэтому имеем интуитивное представление о сути процесса.
Люди довольно хорошо работают с визуальной информацией, поэтому неудивительно, что если бы я спросил у 100 человек на улице, что необычного
в графике на рис. 1.1, подавляющее большинство (включая далеких от техники людей) указало бы на всплеск линии.
Аналогично мы можем спросить у людей, что необычного на следующей
фотографии (рис. 1.2).

Использование машинного обучения без учителя для обнаружения аномалий  25

Рис. 1.1  Этот график содержит визуально заметную аномалию

Рис. 1.2  На этой фотографии запечатлен тюлень среди пингвинов

Большинство опрошенных наверняка ответят, что тюлень в окружении
пингвинов – явление весьма необычное. Но людям бывает сложно сформулировать в явных терминах эвристику, которая лежит в основе таких выводов.
Есть две разные эвристики, которые мы могли бы использовать для определения различных видов аномалий, показанных на этих изображениях:
 сущность необычна, если ее поведение значительно отклоняется от
установленного шаблона или диапазона, основанного на исторических
данных;

26  Машинное обучение в информационных технологиях
 сущность необычна, если некоторые характеристики этой сущности
значительно отличаются от тех же характеристик других членов группы или популяции.
Эти ключевые определения будут иметь прямое отношение к обнаружению аномалий Elastic ML, поскольку они образуют два основных фундаментальных режима работы алгоритмов обнаружения аномалий (временной
и популяционный анализ, о которых пойдет речь в главе 3). Как вы увидите,
пользователь будет решать, какой режим работы использовать для определенной задачи.

Изучение того, что является нормой
Как мы уже говорили, механизм обнаружения аномалий в Elastic ML основан на обучении без учителя, так как обучение происходит без привлечения
специальных обучающих данных. Человек не помогает модели обучаться;
она делает это самостоятельно, путем изучения представленных данных. Это
немного похоже на изучение иностранного языка путем погружения, вместо
того чтобы сидеть за словарями и учебниками грамматики.
Чтобы перейти от совершенно наивного состояния, когда о ситуации ничего неизвестно, к состоянию, в котором можно делать уверенные прогнозы, необходимо построить модель ситуации. Способ создания этой модели
чрезвычайно важен, поскольку эффективность всех последующих действий,
предпринятых на основе этой модели, будет сильно зависеть от точности
модели. Модель должна быть гибкой и постоянно обновляться на основе
новой информации, и это главное, что она должна делать в соответствии
с парадигмой обучения без учителя.

Вероятностные модели
Вышеупомянутой цели вполне могут служить распределения вероятностей. Существует много фундаментальных типов распределений (в Elastic
ML используются различные типы распределений, такие как пуассоновское,
гауссово, логнормальное или даже сочетание моделей), но распределение
Пуассона лучше всего подходит для обсуждения в первую очередь, потому
что оно уместно в ситуациях, когда есть дискретные события («отсчеты»)
относительно времени (рис. 1.3).
Здесь показаны три различных варианта распределения, каждый с различным средним (λ) и максимальным ожидаемым значением k. Мы можем
провести аналогию, которая гласит, что эти распределения моделируют ожидаемое количество почтовых отправлений, которые ежедневно приносят
человеку домой, представленное знаком k на оси x:
 при λ = 1 вероятность того, что ежедневно будут доставлять ноль или
одно почтовое отправление, составляет около 37 %. Возможно, это
справедливо для студента колледжа, который не получает много писем;

Использование машинного обучения без учителя для обнаружения аномалий  27

 при λ = 4 вероятность получения трех или четырех писем составляет
около 20 %. Это может быть хорошей моделью для молодого специалиста;
 при λ = 10 вероятность того, что в день будут доставлять 10 писем, составляет около 13 %, что может соответствовать молодой семье или
домашнему хозяйству, которое каким-то образом оказалось во многих
списках рассылки.

Рис. 1.3  График, демонстрирующий распределения Пуассона
(источник: https://en.wikipedia.org/wiki/Poisson_distribution#/media/File:Poisson_pmf.svg)

Дискретные точки на каждой кривой также дают вероятность других значений k. Поэтому модель может быть информативной и отвечать на такие
вопросы, как «Вероятно ли получение 15 писем?». Как видите, это маловероятно для студента (λ = 1) или молодого специалиста (λ = 4), но более
вероятно для большой семьи (λ = 10). В данном случае мы просто заявили,
что представленные модели подходят для определенных категорий людей, –
но совершенно очевидно, что в реальной жизни мы должны опираться на
механизм обучения модели конкретным ситуациям, а не ограничиваться
голословными утверждениями. Процесс обучения интуитивно понятен.

Обучение моделей
Если продолжить аналогию с доставкой писем, то становится ясно, что наилучшую модель для конкретного получателя можно определить путем ежедневного дежурства у почтового ящика и записи данных о том, сколько писем почтальон бросил в ящик. Также достаточно очевидно, что чем больше
наблюдений сделано, тем выше будет ваша уверенность в точности модели.
Другими словами, если провести у почтового ящика всего 3 дня, это даст
менее полную информацию и уверенность, чем 30 дней или даже 300.

28  Машинное обучение в информационных технологиях
Фактически мы можем разработать алгоритм выбора соответствующей
модели на основе наблюдений. Частью этого процесса самоотбора должна
быть тщательная проверка выбора алгоритмом как самого типа модели (то
есть распределение Пуассона, Гаусса, логнормальное и т. д.), так и конкретных коэффициентов этого типа модели (как в предыдущем примере λ). Для
этого проводится постоянная оценка соответствия модели. Для оценки вероятных значений параметров модели по набору данных в целом также используются байесовские методы, но с учетом того, сколько информации было
просмотрено до определенного момента времени. Алгоритмы машинного
обучения делают это автоматически.
Для тех, кто хочет более глубоко погрузиться в некоторые типичные математические
процессы, происходящие за кулисами, рекомендуем научную статью по адресу http://
www.ijmlc.org/papers/398-LC018.pdf.

Самое главное, что процесс уточнения модели является непрерывным,
так что новая информация рассматривается вместе со старой, с экспоненциальным взвешиванием более свежей информации. Такая модель после
60 наблюдений могла бы напоминать график, представленный на рис. 1.4.
Модель после 60 наблюдений
Наша модель

Рис. 1.4  Пример модели после 60 наблюдений

Использование машинного обучения без учителя для обнаружения аномалий  29

После 400 наблюдений модель будет выглядеть совсем иначе, поскольку
данные представляют собой множество новых наблюдений со значениями
от 5 до 10.
Модель после 400 наблюдений
Наша модель
Истинное распределение

Рис. 1.5  Пример модели после 400 наблюдений

Также обратите внимание, что модель может иметь несколько модов, или
областей/кластеров, с более высокой вероятностью. Сложность и точность
совпадения изученной модели (показана синей кривой) с теоретической
идеальной моделью (выделена черным цветом) имеет большое значение.
Чем точнее модель, тем лучше представление состояния нормы для этого
набора данных и, таким образом, в конечном итоге тем точнее прогноз того,
как будущие значения совпадают с этой моделью.
Непрерывный характер моделирования также требует, чтобы эту модель
можно было сериализовать и поместить в долгосрочное хранилище, а затем
восстановить и возобновить обучение или использование позже. Как мы увидим, реализация этого процесса создания, хранения и использования модели
представляет собой сложную оркестровку, которая, к счастью, автоматически
выполняется средствами Elastic ML.

30  Машинное обучение в информационных технологиях

Выявление и устранение тенденций
Еще одним важным аспектом точного моделирования реальных данных является учет явных тенденций и скрытых закономерностей, которые возникают естественным образом. Например, наблюдаются ли у вас приливы
и спады объема данных ежечасно и/или ежедневно при большей активности
в рабочие часы или в рабочие дни? Если да, то это необходимо учитывать.
Elastic ML автоматически выявляет основные тенденции в данных (линейный рост, периодические гармоники и т. д.) и учитывает их. Рассмотрим
следующий график (рис. 1.6).

Рис. 1.6  Пример обнаружения периодичности

На этом графике показано, как мы изучаем, а затем выводим суточный
цикл. Границы прогноза модели (представленные в виде голубой оболочки
вокруг темно-синего сигнала) резко изменяются после автоматического обнаружения трех последовательных итераций этого цикла.
Таким образом, по мере того как с течением времени набирается больше
данных, модели становятся более точными как с точки зрения более зрелой
функции распределения вероятностей, так и за счет автоматического распознавания и устранения тенденций других стандартных шаблонов (например, рабочих дней, выходных и т. д.), которые могут не появляться в течение
нескольких дней или недель. В следующем примере со временем обнаруживаются несколько тенденций, включая ежедневный и еженедельный цикл
и общий линейный наклон (рис. 1.7).
Эти изменения модели записываются в виде системных аннотаций. Аннотации как общая концепция будут рассмотрены в следующих главах.

Использование машинного обучения без учителя для обнаружения аномалий  31

Рис. 1.7  Обнаружение нескольких тенденций

Оценка степени необычности
После построения модели вероятность любого будущего наблюдаемого значения может быть найдена в имеющемся распределении вероятностей. Ранее мы задавали вопрос: «Вероятно ли получение 15 писем?» На этот вопрос
теперь можно дать эмпирический ответ в зависимости от модели, с числом от
0 (невозможно) до 1 (абсолютно достоверно). Elastic ML будет использовать
модель для вычисления этого дробного значения с точностью примерно до
300 значащих цифр (что может быть полезно при работе с очень низкими
вероятностями). Рассмотрим график, представленный на рис. 1.8.
В этом примере вероятность наблюдения значения 921 вычислена как
1,444e – 9 (или, как чаще записывают, всего лишь 0,0000001444 %). Это очень
маленькое значение, которое люди с трудом воспринимают и оценивают. ML
будет использовать вычисленное значение вероятности и с помощью процесса квантильной нормализации отображать его на шкалу значимости от 0
до 100, где 100 – это наивысший уровень необычности, возможный для этого
конкретного набора данных. В данном случае результат расчета вероятности
1,444e – 9 нормализован до оценки 94. Эта нормализованная оценка пригодится позже в качестве средства для оценки серьезности аномалии в целях
предупреждения и/или сортировки.

32  Машинное обучение в информационных технологиях

Рис. 1.8  Оценка аномалий

Роль времени
В Elastic ML все действия по обнаружению аномалий, которые мы будем обсуждать в оставшейся части книги, будут учитывать фактор времени, связанный с данными и анализом. Другими словами, при поиске аномалий Elastic
ML полагает, что входные данные являются данными временных рядов, и они
будут проанализированы с приращениями времени. Это ключевой момент,
который помогает различать обнаружение аномалий и аналитику фреймов
данных в дополнение к парадигме «обучение с учителем/без учителя».
Вы увидите, что есть небольшое, но важное различие между анализом совокупности (глава 3) и обнаружением выбросов (глава 10). Хотя оба они эффек-

Применение машинного обучения с учителем в аналитике фреймов данных  33

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

применение машинного обучения с учителем
в аналитике фреймов Данных
За исключением обнаружения выбросов (описанного в главе 10), которое основано на обучении без учителя, остальная часть аналитики фреймов данных
использует обучение с учителем. В частности, есть два основных типа задач,
которые позволяет решить аналитика фреймов данных Elastic ML:
 регрессия. Используется для прогнозирования непрерывного числового значения (цены, продолжительности, температуры и т. д.);
 классификация. Используется для прогнозирования того, относится
ли что-то к определенному классу (например, является ли транзакция
мошеннической и т. д.).
В обоих случаях модели строятся с использованием обучающих данных
для сопоставления входных переменных (которые могут быть числовыми
или категориальными) с выходными прогнозами посредством обучающих
деревьев решений. Конкретная реализация, используемая Elastic ML, представляет собой особый вариант XGBoost, фреймворка дерева решений с градиентным усилением с открытым исходным кодом, который недавно приобрел определенную известность среди специалистов по данным благодаря
своей способности выигрывать соревнования Kaggle.

Процесс обучения с учителем
Процесс машинного обучения с учителем значительно отличается от такового без учителя. При обучении с учителем вы четко отделяете этап обучения
от этапа прогнозирования. Очень упрощенная версия процесса выглядит,
как показано на рис. 1.9.
Здесь мы видим, что на этапе обучения признаки извлекаются из необработанных обучающих данных для создания матрицы признаков (также
называемой фреймом данных) для передачи в алгоритм машинного обучения
и создания модели. Модель может быть проверена на части данных (валидация модели), чтобы увидеть, насколько хорошо она работает, и могут быть
предприняты последующие уточняющие шаги, чтобы скорректировать извлечение признаков или уточнить параметры алгоритма машинного обучения, используемого для повышения точности прогнозов модели.
Как только пользователь решает, что модель достаточно эффективна, эта
модель «перемещается» в рабочий процесс прогнозирования, где она при-

34  Машинное обучение в информационных технологиях
меняется к новым данным. На основе модели поочередно выводится один
новый вектор признаков, чтобы сформировать прогноз.
Оценка

Обучение

Обучающие
данные

Извлечение
признаков

Прогноз

Матрица признаков

Новые
данные

Извлечение
признаков

Алгоритм ML

Модель

Вектор признаков

Модель

Прогноз

Рис. 1.9  Машинное обучение с учителем

Чтобы получить интуитивное представление о том, как это работает, представьте сценарий, в котором вы хотите продать свой дом, но не знаете, по
какой цене его выставить. Вы изучаете предыдущие продажи в вашем районе и отмечаете для себя разницу в стоимости домов в зависимости от различных факторов (количество спален, количество ванных комнат, площадь
в квадратных метрах, близость к школам/магазинам, возраст дома и т. д.).
Эти факторы являются «признаками», которые учитываются вместе (а не по
отдельности) для каждой предыдущей продажи.
Этот корпус исторических данных продаж составляет ваш набор обучающих
данных. Он полезен, потому что вы точно знаете, сколько стоит каждый дом
(и это параметр, значение которого вы в конечном итоге хотите спрогнозировать для своего дома). Если вы достаточно хорошо изучите этот набор, то
можете интуитивно понять, что цены на дома сильно зависят от некоторых
признаков (например, количества спален) и что другие признаки (возможно,
возраст дома) не так сильно влияют на ценообразование. Это понятие, так называемую важность признака (feature importance), мы еще раз обсудим в следующей главе.
Обладая достаточным количеством обучающих данных, вы можете иметь
хорошее представление о том, какова должна быть стоимость вашего дома,
учитывая, что это дом 30-летней давности с тремя спальнями, двумя ванными комнатами и площадью 1700 квадратных футов. Другими словами,
вы построили в уме модель на основе исследования сопоставимых домов,
проданных за последний год или около того. Если прошлые продажи – это
обучающие данные, то признаки вашего дома (спальни, ванные комнаты
и т. д.) – это векторы признаков (feature vector), которые будут определять
ожидаемую цену с учетом модели, которую вы «обучили» у себя в голове.
Ваша простая ментальная модель, очевидно, не настолько строгая, как та,

Заключение  35

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

заключение
В этой главе мы рассмотрели историю применения машинного обучения
в прикладных задачах IT в связи с необходимостью автоматизировать анализ
огромного и постоянно растущего объема данных в корпоративных средах. Вы получили более глубокое понимание различных типов машинного
обучения, задействованных в Elastic ML, включая как обнаружение аномалий
(обучение без учителя), так и анализ фреймов данных (обучение с учителем).
По мере продвижения по оставшимся главам мы будем часто сопоставлять
варианты прикладных задач, которые пытаемся решить, с различными режимами работы Elastic ML.
Если ваши данные представлены временными рядами, т. е. они появляются регулярно с течением времени (данные показателей/производительности,
файлы журналов, транзакции и т. д.), вполне возможно, что вы сможете обойтись только механизмом обнаружения аномалий Elastic ML. Как вы увидите
дальше, он невероятно гибкий и простой в использовании и позволяет выполнять множество сценариев использования с широким спектром данных.
Это что-то вроде швейцарского армейского ножа! Большая часть этой книги
(главы с 3 по 8) будет посвящена тому, как использовать обнаружение аномалий и дополнительные возможности прогнозирования, чтобы получить максимальную отдачу от данных временных рядов, обработанных в Elastic Stack.
Если вас больше интересует поиск необычных объектов в популяции/
когорте (необычное поведение пользователей/объектов), у вас может возникнуть непростой выбор между использованием анализа популяции для
обнаружения аномалий или обнаружением выбросов в аналитике фрейма
данных. Решение в первую очередь зависит от того, нужно ли вам делать
это почти в реальном времени, – если да, то вы наверняка выберете анализ
популяции. Если работа в реальном времени не требуется и/или если вам
требуется одновременно рассматривать несколько признаков, вы должны
предпочесть обнаружение выбросов. В главе 10 более подробно говорится
о сравнении и преимуществах каждого подхода.
Остается много других вариантов использования, требующих многопланового подхода к моделированию. Кроме вышеупомянутого примера ценообразования на недвижимость, к ним относятся такие задачи, как распознавание языка, анализ оттока клиентов, обнаружения вредоносных программ
и т. д. Все они относятся к области машинного обучения с учителем и аналитике фреймов данных и будут рассмотрены в главах с 11 по 13.
В следующей главе вы узнаете, как настроить Elastic ML и применять его
на практике. Садитесь поудобнее и приготовьтесь наслаждаться новыми знаниями!

Глава

2

Подготовка
и использование Elastic ML
В предыдущей главе вы узнали в общих чертах, каким образом Elastic ML использует машинное обучение без учителя для автоматического обнаружения
аномалий и машинное обучение с учителем для анализа фреймов данных.
Дальше мы подробно расскажем о том, как Elastic ML работает в составе
Elastic Stack (Elasticsearch и Kibana)1.
В этой главе основное внимание будет уделено как установке (на самом
деле включению) функций Elastic ML, так и подробному обсуждению порядка
действий, особенно в отношении обнаружения аномалий. В частности, мы
рассмотрим следующие темы:
 включение функций Elastic ML;
 обзор процессов.

технические требования
В этой главе мы будем использовать Elastic Stack в том виде, в котором он
представлен в версии 7.10, и рабочий процесс Elasticsearch Service для Elastic
Cloud по состоянию на ноябрь 2020 года.

включение функций ElasTIc Ml
Процесс включения функций Elastic ML внутри Elastic Stack в собственном
кластере немного отличается от использования Elasticsearch Service (ESS)
для Elastic Cloud. Если коротко, в собственном кластере функции машинного
обучения активируются с помощью лицензионного ключа (коммерческого
или пробного). В варианте ESS для использования Elastic ML необходимо
1

Если точнее, то Elastic Stack – обширная экосистема компонентов, которые служат
для поиска и обработки данных. Основные компоненты Elastic Stack – это Elasticsearch, Kibana, Logstash и Beats. Неразбериха с постоянно меняющимися названиями и торговыми марками Elastic, особенно в последние 5 лет, способна запутать
кого угодно. – Прим. перев.

Включение функций Elastic ML  37

подготовить в облачном кластере выделенный узел машинного обучения.
Далее мы подробно объясним, как это сделать в обоих случаях.

Включение машинного обучения в собственном
кластере
Если у вас есть собственный (управляемый вами) кластер, созданный в результате загрузки дистрибутивов Elasticsearch и Kibana по умолчанию (доступно на https://www.elastic.co/downloads/), включить функции Elastic ML
с помощью лицензионного ключа очень просто. Убедитесь, что вы не используете лицензионные дистрибутивы Apache 2.0 с открытым исходным
кодом, которые не содержат кодовую базу X-Pack.
Elastic ML, в отличие от большинства функций Elastic Stack, не является бесплатным – для него требуется коммерческая лицензия (в частности, уровня
Platinum). Однако это открытый исходный код, поскольку он находится в открытом доступе на GitHub (https://github.com/elastic/ml-cpp), и пользователи могут просматривать код, комментировать его или даже скачивать. Но использование Elastic ML регулируется коммерческим соглашением с компанией Elastic.
Когда Elastic ML был впервые выпущен (еще во времена версий v5.x), он
был частью пакета с закрытым исходным кодом, известного как X-Pack, требующего отдельной процедуры установки. Однако начиная с версии 6.3 код
X-Pack стал открытым (https://www.elastic.co/what-is/open-x-pack) и помещен
в стандартный дистрибутив Elasticsearch и Kibana. Следовательно, отдельный
этап установки X-Pack больше не нужен, достаточно лишь «включить» нужную функцию через коммерческую или пробную лицензию.
Процедура установки Elasticsearch и Kibana выходит за рамки этой книги,
но ее легко выполнить, следуя онлайн-документации на веб-сайте Elastic
(доступном по адресу https://www.elastic.co/guide/).
После запуска Elasticsearch и Kibana перейдите к параметру Stack (Стек)
в меню навигации слева и выберите License Management (Управление лицензиями). Вы увидите экран как на рис. 2.1.
Обратите внимание, что по умолчанию применяется бесплатный уровень
лицензии Base (Базовый). Он позволяет использовать некоторые расширенные функции, отсутствующие в лицензированном дистрибутиве Apache 2.0
с открытым исходным кодом или в сторонних сервисах (например, Amazon
Elasticsearch Service). Удобное руководство по сравнению функций, доступных на разных уровнях лицензии, можно найти на веб-сайте Elastic по адресу
https://www.elastic.co/subscriptions.
Как было сказано ранее, для Elastic ML требуется лицензия уровня Platinum. Если вы приобрели лицензию Platinum в Elastic, вы можете применить
эту лицензию, нажав кнопку Update license (Обновить лицензию), как показано на рис. 2.1. Если у вас нет лицензии Platinum, вы можете запустить
бесплатную 30-дневную пробную версию, нажав кнопку Start my trial (Начать использовать пробную версию), чтобы включить Elastic ML и другие
функции Platinum (при условии что вы согласны с условиями лицензии), как
показано на рис. 2.2.

38  Подготовка и использование Elastic ML

Рис. 2.1  Экран управления лицензиями в Kibana

Рис. 2.2  Запуск бесплатной 30-дневной пробной версии

Включение функций Elastic ML  39

Как только завершится активация пробной версии, на экране лицензирования появится сообщение, что вы сейчас находитесь в активной пробной
версии Platinum функций Elastic Stack (рис. 2.3).

Рис. 2.3  Пробная лицензия активирована

Сразу же после активации пробной версии вы можете начать использовать
Elastic ML. Чтобы воспользоваться возможностями других функций Platinum,
необходимы дополнительные шаги по настройке, но эти шаги выходят за
рамки данной книги. Обратитесь к документации Elastic для получения рекомендаций по настройке этих функций.

Включение машинного обучения в облаке –
Elasticsearch Service
Если загрузка, установка и создание собственного кластера Elastic Stack вас
привлекают меньше, чем использование платформы Elastic Stack в качестве
услуги, перейдите в Elastic Cloud (https://www.elastic.co/cloud/) и подпишитесь
на бесплатную пробную версию, используя только вашу электронную почту
(рис. 2.4).
Затем вы можете выполнить следующие шаги.
1. Оказавшись в интерфейсе Elastic Cloud после входа в систему, вы
сможете запустить бесплатную пробную версию, нажав кнопку Start

Powered by TCPDF (www.tcpdf.org)

40  Подготовка и использование Elastic ML
your free trial (Начать бесплатную пробную версию), как показано на
рис. 2.5.

Рис. 2.4  Экран приветствия Elastic Cloud

Рис. 2.5  Главный экран Elastic Cloud

Включение функций Elastic ML  41

После нажатия кнопки вы увидите, что ваша 14-дневная бесплатная
пробная версия ESS активирована (рис. 2.6).

Рис. 2.6  Пробная версия службы Elasticsearch включена

2. Конечно, чтобы опробовать Elastic ML, вам сначала понадобится подготовленный кластер Elastic Stack. Существует несколько вариантов
создания того, что ESS называет deployments (развертывания), причем
некоторые из них предназначены для конкретных случаев использования. В этом примере мы воспользуемся шаблоном Elastic Stack слева
на рис. 2.6 и выберем профиль оборудования I/O Optimized (Оптимизированный для ввода-вывода), но не бойтесь во время ознакомления
экспериментировать с другими параметрами (рис. 2.7).
3. Вы также можете выбрать, у какого облачного провайдера и в каком
регионе запускать кластер, но, что наиболее важно, если вы хотите использовать функции машинного обучения, то должны включить узел
машинного обучения, сначала нажав кнопку Customize (Настроить)
в правом нижнем углу.
4. После нажатия кнопки Customize вы увидите новый экран, позволяющий добавить узел машинного обучения (рис. 2.8).
5. Внизу рис. 2.8 есть ссылка Add Machine Learning nodes (Добавить
узлы машинного обучения). При нажатии на нее откроется интерфейс
конфигурации узла ML (рис. 2.9).
В течение 14-дневного бесплатного пробного периода ESS вы можете добавить только один узел ML объемом 1 ГБ (в одной или двух доступных зонах). Если вы перейдете
от бесплатной пробной версии к платной подписке, то, разумеется, сможете создать
больше узлов машинного обучения и занять больший объем.

42  Подготовка и использование Elastic ML

Рис. 2.7  Создание развертывания ESS

Включение функций Elastic ML  43

Рис. 2.8  Настройка развертывания для добавления узла машинного обучения

44  Подготовка и использование Elastic ML

Рис. 2.9  Добавление узлов ML

6. После добавления узла машинного обучения в конфигурацию нажмите
кнопку Create Deployment (Создать развертывание), чтобы запустить
процесс создания кластера для ESS, который займет несколько минут.
Тем временем вам будут показаны учетные данные по умолчанию,
которые вы будете использовать для доступа к кластеру (рис. 2.10).

Рис. 2.10  Учетные данные, назначенные по умолчанию

Вы можете загрузить эти учетные данные для использования позже. Не
волнуйтесь, если вы забыли их загрузить, – вы всегда можете сбросить
пароль позже, если потребуется.
7. После того как кластер будет создан и запущен, как показано на рис. 2.11
(обычно спустя несколько минут), вы увидите следующее представле-

Включение функций Elastic ML  45

ние вашего развертывания с кнопкой Open Kibana (Открыть Kibana),
которая позволит вам запустить ваше развертывание (рис. 2.11).

Рис. 2.11  Развертывание успешно создано

После нажатия кнопки Open Kibana вы автоматически авторизуетесь
в Kibana, где сразу будете готовы к использованию ML – никаких дополнительных действий по настройке не требуется.
На данный момент, с точки зрения пользователя, который хочет использовать Elastic ML, разница между конфигурацией собственного кластера,
показанной ранее, и конфигурацией, созданной в ESS, невелика. Однако
одним из основных отличий является то, что в конфигурации ESS Elastic
ML всегда изолирован в выделенный узел ML. В конфигурации собственного
кластера узлы машинного обучения могут быть выделены или иметь общую
роль (например, такие как data, ingest и ml на одном узле). Мы обсудим эту
концепцию позже в данной главе.
Теперь, когда у нас есть работающий Elastic Stack с включенным машинным обучением, мы приблизились к возможности начать анализ данных,

46  Подготовка и использование Elastic ML
о котором пойдет речь в главе 3. Но сначала давайте разберемся с операцио­
нализацией (внутренней структурой, взаимосвязями и принципом работы
составных частей) Elastic ML.

обзор операционализации ElasTIc Ml
Во время подготовки к использованию Elastic ML вам будет полезно понять
ряд ключевых концепций, касающихся того, как Elastic ML работает в Elastic
Stack. Сюда входит понимание того, как аналитика выполняется на узлах
кластера и как данные, которые должны быть проанализированы с помощью
машинного обучения, извлекаются и обрабатываются.
Некоторые концепции, представленные в этом разделе, могут казаться вам непонятными до тех пор, пока вы не начнете использовать Elastic ML на реальных примерах.
Это нормально, если вы чувствуете, что вам удобнее бегло пролистать (или даже пропустить) этот раздел сейчас и вернуться к нему позже, приобретя некоторый реальный опыт использования Elastic ML.

Узлы ML
Прежде всего, поскольку Elasticsearch по своей природе является распределенным решением со многими узлами, вполне естественно, что функция
машинного обучения Elastic Stack работает как встроенный плагин, который подчиняется многим из тех же операционных концепций. Как описано
в документации (https://www.elastic.co/guide/en/elasticsearch/reference/current/
ml-settings.html), ML можно включить на любом или всех узлах, но в производственной системе рекомендуется иметь выделенные узлы ML. Вы видели,
что этот (безусловно, правильный) подход фактически навязан пользователю
в Elastic Cloud ESS – если пользователь хочет использовать машинное обучение, ему придется создать выделенные узлы.
Наличие выделенных узлов машинного обучения также помогает оптимизировать типы ресурсов, необходимых только для машинного обучения.
В отличие от узлов данных, которые подвергают значительной нагрузке дисковый ввод-вывод из-за индексации и поиска, узлы ML более требовательны к вычислениям и памяти. Обладая этими знаниями, вы можете выбрать
оборудование, которое лучше подходит для выделенных узлов машинного
обучения.
Следует отметить один ключевой момент: алгоритмы машинного обучения
не работают в виртуальной машине Java (JVM). Это исполняемые файлы на
C++, которые будут использовать оперативную память, оставшуюся от всего,
что выделено для кучи JVM. При выполнении заданий машинного обучения
процесс, вызывающий анализ (он называется autodetect для обнаружения
аномалии и data_frame_analyzer для анализа фреймов данных), можно увидеть в списке процессов (например, выполнив команду ps в Linux). Каждому
активно выполняемому заданию машинного обучения соответствует один

Обзор операционализации Elastic ML  47

процесс. В многоузловых системах диспетчер ML распределяет задания по
каждому из узлов с поддержкой ML, чтобы сбалансировать рабочую нагрузку.
Elastic ML руководствуется параметром xpack.ml.max_machine_memory_percent, который определяет, сколько системной памяти может быть отведено
заданиям ML. Значение этого параметра по умолчанию – 30 %. Это значение относится к полной памяти машины, а не к свободной на данный момент части. Не забывайте, что JVM Elasticsearch может занимать около 50 %
машинной памяти системы, поэтому оставить 30 % для ML, а оставшиеся
20 % для операционной системы и других вспомогательных процессов – это
разумно, хотя и консервативно. Задания не будут назначены узлу, если это
приведет к тому, что расчетное использование памяти заданиями ML превысит предел, определенный этим параметром.
Хотя не существует эмпирической формулы для определения размера
и количества выделенных узлов машинного обучения, есть несколько хороших практических правил:
 иметь один выделенный узел машинного обучения (два для систем
с повышенной доступностью/отказоустойчивостью, если один узел
вдруг станет недоступным) на каждый кластер размером до 10 узлов
данных;
 иметь как минимум по два узла ML на каждый кластер размером около
20 узлов;
 добавлять дополнительный узел машинного обучения при развертывании дополнительных 10 узлов данных.
Этот общий подход, заключающийся в том, чтобы зарезервировать около
10–20 % емкости вашего кластера для выделенных узлов машинного обучения, безусловно, является разумным ориентиром, но он не избавляет вас от
необходимости проводить собственный выбор размера, тестирование характеристик и мониторинг ресурсов. Как мы увидим в нескольких последующих
главах, потребности в ресурсах для ваших задач машинного обучения будут
во многом зависеть от того, какие виды анализа выполняются, а также от
плотности и объема анализируемых данных.

Задания
В Elastic ML задание (job) – это единица работы. Существуют как задания по
обнаружению аномалий, так и задания по анализу фреймов данных. Те и другие
принимают какие-либо данные на входе и производят новую информацию
на выходе. Задания можно создавать с помощью пользовательского интерфейса ML в Kibana или программно через API. Им также требуются узлы
с поддержкой ML.
Задания по обнаружению аномалий можно запускать как однократный
пакетный анализ (по ряду исторических данных) или как непрерывный процесс в реальном времени на данных временных рядов – данных, которые
постоянно индексируются вашим Elastic Stack (или на самом деле одновременно происходит и то, и другое).

48  Подготовка и использование Elastic ML
Возможен вариант, когда задания анализа фреймов данных не являются
непрерывными, а представляют собой однократные прогоны, которые производят выходные результаты и/или выходную модель для последующего
вывода. Мы рассмотрим этот вариант более подробно в главах с 9 по 13.
Следовательно, с точки зрения ввода в эксплуатацию, задания по обнаружению аномалий немного сложнее, поскольку несколько таких заданий могут выполняться одновременно, выполняя независимые действия и анализируя данные из разных хранилищ. Другими словами, в типичном кластере,
вероятно, постоянно будут выполняться задания по обнаружению аномалий.
Конфигурация задания по обнаружению аномалий состоит из следующих
элементов, которые мы позже рассмотрим более детально:
 название/идентификатор задания;
 окно сегментации анализа (период сегмента);
 определение и настройки запроса на получение необработанных данных для анализа (поток данных);
 объект применения конфигурации обнаружения аномалий (детектор).
Далее мы сосредоточимся на сегментировании данных временных рядов,
которое является важным понятием в анализе данных реального времени.

Сегментирование данных в анализе временных
рядов
Сегментирование входных данных – важная концепция механизма обнаружения аномалий Elastic ML. Сегментирование задается с помощью ключевого
параметра bucket_span на уровне задания, в соответствии с которым входные
данные из потока данных собираются в мини-пакеты для обработки. Период
сегмента (bucket span) можно рассматривать как интервал агрегации перед
анализом – временное окно, в течение которого часть данных агрегируется
для целей анализа. Чем меньше значение bucket_span, тем более детализирован анализ, но также выше вероятность появления шумовых артефактов
в данных.
Для иллюстрации этого соображения на следующем графике показан один
и тот же набор данных, агрегированный за три разных интервала (рис. 2.12).
Обратите внимание на то, что выраженный аномальный выброс, наблюдаемый в версии, агрегированной с 5-минутным интервалом, становится
почти полностью потерянным, если данные агрегированы с 60-минутным
интервалом из-за малой продолжительности всплеска (< 2 минут). Фактически на этом 60-минутном интервале выброс даже не выглядит таким уж
аномальным.
В этом и заключается практическая целесообразность при выборе bucket_
span. С одной стороны, более короткий период агрегации полезен, потому
что он увеличит частоту анализа (и, таким образом, сократит интервал оповещения, если обнаружено что-то аномальное), но с другой – еслисделать
его слишком коротким, это может выделить в данных аномалии, которые не
имеют для вас значения.

Обзор операционализации Elastic ML  49

Рис. 2.12  Агрегирование одних и тех же данных на разных промежутках времени

Если кратковременный всплеск, показанный в предыдущих данных, является значимой аномалией для вас, то 5-минутного просмотра данных будет
достаточно. Если, однако, кратковременные аномалии данных кажутся вам
ненужной суетой, избегайте низкого значения bucket_span.
Некоторые дополнительные практические соображения можно найти в блоге Elastic:
https://www.elastic.co/blog/explaining-the-bucket-span-in-machine-learning-for-elasticsearch.

Загрузка данных в Elastic ML
Очевидно, что задания по обнаружению аномалий нуждаются в данных для
анализа (а также для построения и совершенствования статистических моделей). Эти данные поступают из ваших хранилищ временных рядов в Elasticsearch. Поток данных (datafeed) – это механизм, с помощью которого эти данные извлекаются (ищутся) на регулярной основе и поставляются алгоритмам
машинного обучения. Его конфигурация в основном скрыта от пользователя,
за исключением случая создания расширенного задания в пользовательском
интерфейсе (или с помощью API обнаружения аномалий). Тем не менее важно понимать, как работает поток данных.
Поток данных регулярно запрашивает данные по имени хранилища, которое содержит данные для анализа. Как часто поток данных запрашивает
данные (и сколько данных получает за раз), зависит от ряда факторов:
 query: фактический запрос (выраженный в Elasticsearch DSL), который
будет использоваться для извлечения данных из исходного хранилища
для анализа. Пользователь может запросить все документы, разме-

50  Подготовка и использование Elastic ML









щенные в исходном хранилище, или выборочно фильтровать и/или
агрегировать данные;
bucket_span: вы уже знаете, что bucket_span управляет шириной
временнóго окна текущего анализа. Следовательно, задача потока
данных – убедиться, что сегменты заполнены хронологически упорядоченными данными. Поэтому вы можете видеть, что поток данных
запрашивает диапазон дат в Elasticsearch;
frequency: параметр, который определяет, как часто запрашиваются необработанные данные с физической точки зрения. Если это интервал
от 2 до 20 мин, частота запросов будет равна bucket_span (например,
каждые 5 мин запрашивать данные за последние 5 минут). Если bucket_span больше, frequency по умолчанию будет меньшим числом (более
частые запросы), поэтому подразумевается, что длинный интервал
будет запрашиваться по частям. Это полезно, если набор данных довольно объемный. Другими словами, интервал длинного bucket_span
будет разделен на более мелкие интервалы просто для целей запросов;
query_delay: этот параметр определяет количество времени «после текущего момента», по истечении которого поток данных должен запрашивать данные для заданного диапазона bucket_span. По умолчанию
это 60 с, если задание настраивается через API, или случайное значение
от 60 до 120 с, если задание настраивается через пользовательский
интерфейс. Например, если установлено значение bucket_span, равное
5 мин, и значение query_delay, равное 60 с, в момент 12:01 поток данных
запросит данные, поступившие в диапазоне c 11:55 до 12:00. Эта дополнительная небольшая задержка сглаживает задержки в конвейере
приема, чтобы гарантировать, что никакие данные не будут исключены из анализа, если их прием задерживается по какой-либо внешней
причине. Если система обнаруживает, что в задании по обнаружению
аномалий отсутствуют данные из-за возможных задержек приема, будет создана сгенерированная системой аннотация (пометка-уведомление), чтобы предупредить пользователя о том, что происходит пропуск
данных и что, возможно, потребуется увеличить значение query_delay
для исправления этого;
scroll_size: в большинстве случаев тип поиска, который поток данных
выполняет для Elasticsearch, использует API прокрутки (scroll) (https://
www.elastic.co/guide/en/elasticsearch/reference/current/scroll-api.html).
Размер прокрутки определяет, сколько данных запрашивает поток
у Elasticsearch за раз. Например, если настроен запрос данных журнала
каждые 5 мин, но в типичном 5-минутном окне умещается 1 мл событий, прокрутка этих данных означает, что не весь 1 млн событий будет
получен с помощью одного гигантского запроса. Напротив, это будет
сделано при помощи нескольких запросов с приращением scroll_size.
По умолчанию размер прокрутки настроен на скромное значение 1000.
В этом случае, чтобы получить 1 млн записей, возвращенных в ML, поток данных будет запрашивать у Elasticsearch по 1000 строк 1000 раз.
Увеличение scroll_size до 10 000 уменьшит количество прокруток до
100. Смысл этой настройки в том, что более мощные кластеры должны

Обзор операционализации Elastic ML  51

иметь возможность обрабатывать больший scroll_size и, таким образом, быть более эффективными в общем процессе.
Однако есть исключение в случае задания с одной метрикой. Задание с одной метрикой (более подробно описанное в главе 3) – это простое задание
машинного обучения, которое позволяет анализировать только показатели
однократного ряда. В этом случае API прокрутки не используется для получения необработанных данных – поток данных автоматически создает
агрегацию запросов (используя агрегацию date_histogram). Этот метод агрегирования также можно использовать для любого задания по обнаружению
аномалий, но в настоящее время он требует прямого редактирования конфигурации JSON задания и рассчитан на опытных пользователей.
С точки зрения подачи данных в Elastic ML для заданий анализа фреймов, эта
парадигма отличается от обнаружения аномалий, поскольку данные не поступают на анализ непрерывно, в реальном времени. Подробное описание передачи данных в задание анализа фрейма данных будет рассмотрено в главах 9–13.
Теперь, когда у вас есть более глубокое понимание того, как данные поступают в Elastic ML для анализа, давайте рассмотрим некоторые служебные
хранилища, которые используются для организации работы Elastic ML.

Служебные хранилища
В работе Elastic ML применяется несколько служебных хранилищ:







.ml-config;
.ml-state-*;
.ml-notifications-*;
.ml-annotations-*;
.ml-stats-*;
.ml-anomalies-*.

Все эти хранилища являются системными (и большинство из них являются
скрытыми), что означает, что они не предназначены для записи или иных
манипуляций со стороны конечного пользователя. Однако часто бывает полезно понять их функцию/роль, поэтому давайте рассмотрим каждую из них
по очереди.

.ml-config
Хранилище .ml-config содержит информацию о конфигурации всех заданий
машинного обучения, которые в настоящее время определены в системе.
Информация, содержащаяся в этом хранилище, доступна для чтения и интерпретации среднестатистическому пользователю.

.ml-state-*
Хранилище .ml-state – это место, где Elastic ML хранит внутреннюю информацию о ходе выполнения заданий аналитики фреймов данных и ста-

52  Подготовка и использование Elastic ML
тистических моделях обнаружения аномалий, которые были изучены для
определенного набора данных, а также дополнительную логистическую
информацию. Это хранилище не предназначено для пользователей – его
используют внутренние алгоритмы машинного обучения, которые будут читать и записывать в него информацию.

.ml-notifications-*
В этом хранилище Elastic ML хранит сообщения аудита, которые появляются
в разделе Job Messages (Сообщения заданий) на странице Job Management
(Управление заданиями) пользовательского интерфейса обнаружения аномалий. Эти сообщения содержат основную информацию о создании и деятельности заданий. Кроме того, здесь можно найти основные ошибки выполнения. Однако более подробную информацию о выполнении заданий
машинного обучения можно найти в файле elasticsearch.log.

.ml-annotations-*
В этом хранилище хранятся записи аннотаций, связанных с заданиями по обнаружению аномалий. Сюда входят аннотации, созданные пользователями, которые можно определить с помощью пользовательского интерфейса обнаружения
аномалий, а также аннотации, созданные системой, такие как предупреждения
о задержке получения данных и уведомления о снимках модели.

.ml-stats-*
Это хранилище содержит информацию о ходе и производительности заданий
анализа фреймов данных.

.ml-anomalies-*
Хранилища .ml-anomalies-* содержат подробные результаты заданий машинного обучения. Они играют важную роль в использовании результатов
алгоритмов машинного обучения. Вся информация, отображаемая в пользовательском интерфейсе машинного обучения, будет основываться на этих
данных результатов. Кроме того, упреждающее оповещение об аномалиях
будет осуществляться за счет настройки запросов по этим хранилищам. Более подробная информация об этом будет представлена в главе 6.
Теперь, когда мы знаем названия и назначение системных хранилищ, принадлежащих Elastic ML и управляемых им, давайте более детально рассмотрим хранилища .ml-state и .ml-anomalies и их вклад в оркестровку во время
выполнения заданий по обнаружению аномалий.

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

Обзор операционализации Elastic ML  53

требуется довольно сложная оркестровка. Упрощенная схема этого процесса
показана на рис. 2.13.

исходные
данные
2. Получение новых данных

.ml-anomalies

1. Чтение модели

5. Сохранение
результатов

4. Обновление модели

.ml-state

3. Анализ/модель

Рис. 2.13  Упрощенная схема оркестровки задания по обнаружению аномалий

Процесс autodetect, который является физическим воплощением задания
по обнаружению аномалий, – это то, что представлено этапом «анализ/модель» на рис. 2.13. Хранилище .ml-state иногда считывается и записывается
процессом autodetect, как описано в следующем разделе. Выходные данные
процесса autodetect (результаты анализа) хранятся в хранилищах .ml-anomalies-*.
Как правило, вышеупомянутые процедуры выполняются один раз для каждого bucket_span (за исключением фактического чтения/записи .ml-state).
Ключевой вывод заключается в том, что такая оркестровка позволяет задаче обнаружения аномалий работать в оперативном режиме (то есть не
в автономном/пакетном режиме) и постоянно учиться на вновь полученных
данных. Этот процесс также автоматически обрабатывается Elastic ML, поэтому пользователю не нужно беспокоиться о сложной последовательности
выполнения операций.

Снимки модели обнаружения аномалий
Как упоминалось в предыдущем разделе, состояние модели обнаружения
аномалий хранится в.ml-state. Однако на самом деле оно не читается и не
записывается в каждом периоде bucket_span. Вместо этого состояние модели
в основном сохраняется в памяти процесса autodetect и только периодически сериализуется в .ml-state. Если задание по обнаружению аномалий
вызвано для обработки большого количества исторических данных или выполняется в режиме реального времени, то модель сериализуется следующими способами:
 периодически, по расписанию примерно каждые 3–4 ч (или с интервалом, определяемым background_persist_interval, если он явно задан);
 когда задание на обнаружение аномалий переводится в состояние
closed (закрыто).

54  Подготовка и использование Elastic ML
Из-за этой периодической сериализации модели старые снимки автоматически удаляются при выполнении ежесуточного ночного задания по обслуживанию системы. По умолчанию, если в хранилище .ml-state есть снимки
более чем на 1 день старше самого нового снимка, они удаляются, за исключением первого снимка каждый день. Кроме того, удаляются все снимки,
которые старше самого нового снимка более чем на 10 дней. Если вы хотите
исключить конкретный снимок из списка на удаление и сохранить его на неопределенный срок, используйте пользовательский интерфейс в Kibana или
API обновленных снимков модели, чтобы установить для параметра retain
(сохранение) значение true.
Сохранение моментальных снимков модели позволяет пользователю отменить задание, чтобы использовать один из ранее сделанных снимков модели в случае, если что-то пойдет не так в работе или возникнет непредвиденная ситуация. В приложении мы рассмотрим пример, демонстрирующий,
как возвращать исходное состояние до запуска задания при помощи снимка
модели.

заключение
В этой главе мы разобрали процедуры включения функций Elastic ML как
в собственном локальном кластере Elastic Stack, так и в Elasticsearch Service
для Elastic Cloud. Кроме того, мы заглянули за кулисы системы и увидели там
точки глубокой интеграции с остальной частью Elastic Stack и то, как Elastic
ML работает с функциональной точки зрения.
В следующих главах фокус нашего внимания смещается с базовой теории
в область практического использования. Начиная со следующей главы мы
перейдем к обширным возможностям обнаружения аномалий Elastic ML,
и вы узнаете, как настраивать задания для решения некоторых практических
задач анализа журналов, показателей и поведения пользователей.

Часть

II

АНАЛИЗ
ВРЕМЕННЫХ РЯДОВ –
ОБНАРУЖЕНИЕ
И ПРОГНОЗИРОВАНИЕ
АНОМАЛИЙ
В этой части мы обсудим методику анализа временных рядов, полученную
после приобретения компании Prelert, и ее последующую интеграцию в Elastic Stack.
Эта часть книги состоит из следующих глав:







главы 3 «Обнаружение аномалий»;
главы 4 «Прогнозирование»;
главы 5 «Интерпретация результатов»;
главы 6 «Создание и использование оповещений»;
главы 7 «Выявление истинных причин аномалий»;
главы 8 «Другие приложения Elastic Stack для обнаружения аномалий».

Глава

3

Обнаружение аномалий
https://t.me/it_boooks
Обнаружение аномалий было изначально заложено в набор функций Elastic
ML и является наиболее зрелой технологией, уходящей своими корнями во
времена Prelert (до приобретения Elastic в 2016 году). Эта технология зарекомендовала себя как надежная, простая в использовании, мощная и применимая во всех видах сценариев использования данных временных рядов.
В этой объемной и насыщенной новыми знаниями главе мы уделим основное внимание использованию Elastic ML для обнаружения аномалий
в частоте появления документов/событий, редких событий и числовых значений, выходящих за рамки ожидаемой нормальной работы. Мы разберем
несколько простых, но впечатляющих примеров, которые иллюстрируют как
эффективность Elastic ML, так и простоту его использования.
В частности, рассмотрим следующие темы:










типы заданий Elastic ML;
устройство детектора;
обнаружение изменений частотности событий;
обнаружение изменений значений показателей;
обзор расширенных функций детектора;
разделение анализа по категориальным признакам;
обзор временнóго и популяционного анализа;
категоризация в анализе неструктурированных сообщений;
управление Elastic ML через API.

технические требования
Информация в этой главе основана на Elastic Stack, существующем в версии 7.10. Как и во всех главах, весь пример кода можно найти на GitHub: https://
github.com/PacktPublishing/Machine-Learning-with-Elastic-Stack-Second-Edition.

типы заДаний ElasTIc Ml
На экране пользовательского интерфейса Elastic ML для настройки заданий
по обнаружению аномалий отображаются пять разных мастеров настройки
заданий (рис. 3.1).

Типы заданий Elastic ML  57

Рис. 3.1  Экран пользовательского интерфейса настройки заданий,
предлагающий различные мастера настройки

Наличие разных мастеров настройки наводит на мысль, что существуют
разные «типы» заданий. На самом деле существует только один тип задания,
но задание по обнаружению аномалий имеет множество опций, и различные
мастера упрощают определенные аспекты настройки конфигурации. С помощью мастера Advanced (или API) вы можете настроить любую опцию,
какую пожелаете. Фактически, когда Elastic ML впервые выпустили в виде
бета-версии в версии 5.4, это был единственный способ настройки. С тех пор
в Elastic ML добавили другие мастера для простоты и удобства настройки под
определенные сценарии использования.
Задание по обнаружению аномалий имеет множество параметров конфигурации, но двумя наиболее важными из них являются конфигурация
анализа и поток данных.
Конфигурация анализа – это описание того, какие аномалии обнаружит
задание. Она, в свою очередь, содержит конфигурацию обнаружения (называемую детектором), а также несколько других настроек, таких как диапазон сегмента. Поток данных – это конфигурация запроса, который будет
выполнять Elasticsearch для извлечения данных, подлежащих последующему
анализу детектором.
Особенности и назначение различных мастеров заданий можно определить так:
 задания, созданные мастером Single metric, имеют только один детектор. Их потоки данных содержат запросы и агрегации, поэтому они
отправляют в алгоритмы ML только обобщенные данные. Агрегации
создаются автоматически на основе параметров конфигурации в мастере. В задании также используется флаг summary_count_field_name (установленный со значением doc_count), чтобы сигнализировать о том, что
следует ожидать агрегированные данные (а не исходные данные из
хранилища-источника);
 задания, созданные мастером Multi­metric, могут иметь один или несколько детекторов. Анализ также можно разделить по категори-

58  Обнаружение аномалий
альным полям, установив partition_field_name (о нем сказано далее
в этой главе). Их потоки данных не содержат агрегаций (поскольку
код машинного обучения должен видеть все документы для каждого
возможного экземпляра значения поля и агрегировать его самостоятельно), поэтому алгоритмам ML передаются полные документы Elasticsearch;
 задания, созданные мастером Population, могут иметь один или несколько детекторов. Мастер также устанавливает флаг over_field_name (описанный далее в этой главе), сигнализирующий о том, что необходимо
использовать анализ популяции. Анализ еще можно разделить по категориальным полям, установив by_field_name (о нем сказано далее в этой
главе). Их потоки данных не содержат агрегаций, поэтому алгоритмам
ML передаются полные документы Elasticsearch;
 задания, созданные мастером Categorization, имеют только один детектор. Мастер также устанавливает флаг categorization_field_name (описанный далее в этой главе), который сигнализирует о том, что следует
использовать анализ категоризации. Анализ категоризации присваивает by_field_name (описан далее в этой главе) значение mlcategory. Анализ еще можно разделить по категориальным полям, установив partition_field_name (о нем сказано далее в этой главе). Их потоки данных
не содержат агрегаций, поэтому алгоритмам ML передаются полные
документы Elasticsearch;
 задания, созданные мастером Advanced, могут использовать все доступные параметры. Обязанность пользователя – знать, что он делает,
и правильно настроить работу. Однако пользовательский интерфейс
не позволяет пользователю совершать большинство ошибок. Опытный пользователь может обойтись использованием только мастера
Advanced для создания любого задания по обнаружению аномалий.
Количество вариантов создания заданий может показаться устрашающим,
особенно если учесть, что про них написано выше. Но не волнуйтесь – как
только мы познакомимся с терминологией и рассмотрим несколько примеров, вы обнаружите, что конфигурации заданий очень разумны; по мере
накопления опыта вы начнете конфигурировать задания, не задумываясь.
Давайте сделаем следующий шаг и изучим устройство детектора.

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

функция (function);
поле (field);
поле раздела (partition field);
поле by (by field);
поле over (over field).

Устройство детектора  59

Мы рассмотрим каждый из них по очереди. Обратите внимание, что в следующих нескольких разделах мы часто будем ссылаться на фактические имена
настроек в конфигурации задания, как если бы использовали расширенный
редактор заданий или API. Хотя полезно понимать систему наименований, по
мере чтения этой главы вы также заметите, что многие детали конфигурации
задания абстрагируются от пользователя или имеют более удобные для пользовательского интерфейса метки, чем настоящие имена настроек.

Функция
Функция детектора описывает, как данные будут агрегированы или измерены в пределах интервала анализа (промежуток времени). Функций много,
но их можно разделить на следующие категории, представленные в табл. 3.1.
Таблица 3.1. Категории функций детектора
Функции подсчета
count*
non_zero_count*
distinct_count*

Функции метрик
min
max
metric
mean*
median*
sum*
non_nuli_sum*
varp*

Прочие функции
info_content*
rare
freq_rare
lat_long
time_of_day
time_of_week

Функции, отмеченные звездочкой (*), также имеют односторонние варианты с высоким или низким значением (например, low_independent_count),
которые позволяют обнаруживать аномалии только в одном направлении.

Поле
Некоторые функции детектора для своей работы требуют наличия поля
в данных. Вот несколько примеров функций с полями:
 max(bytes);
 mean(products.price);
 high_distinct_count(destination.port).
Имя поля, с которым функция напрямую работает, называется просто
field_name.

Поле partition
Часто бывают случаи, когда анализ обнаружения необходимо разделить по
категориальному полю, чтобы анализ можно было провести отдельно для

Powered by TCPDF (www.tcpdf.org)

60  Обнаружение аномалий
всех уникальных экземпляров этого поля. В этом случае поле раздела (параметр называется partition_field_name) определяет поле для разделения по
категориям. Например, в электронной коммерции вам может потребоваться
увидеть средний доход по категории (мужская одежда, женские аксессуары
и т. д.). В этом случае поле category будет полем partition. Мы рассмотрим
разделение анализа позже в этой главе.

Поле by
Подобно полю раздела, поле by (параметр называется by_field_name) – это еще
один механизм разделения анализа, но он ведет себя по-разному в отношении того, как моделируются и оцениваются результаты. Кроме того, поле
by является обязательным, если используются функции rare или freq_rare.
Различия в использовании поля by для разделения по сравнению с полем
partition мы подробнее обсудим позже в этой главе.

Поле over
Поле over (параметр называется over_field_name) сигнализирует алгоритмам
обнаружения аномалий, что желателен популяционный анализ, где объекты
сравниваются со своими сверстниками (а не с их собственным прошлым состоянием). Популяционный анализ подробно обсуждается далее в этой главе.

Формула детектора
Если бы мы задокументировали все возможные варианты конфигурации для
детектора, а затем создали бы карту в виде блок-схемы, она выглядела бы
как на рис. 3.2.
[non-zero] count

ОБНАРУЖЕНИЕ
НЕОБЫЧНОГО…

[high]
[low]

distinct_count
mean
median
[non-null] sum
varp
info_content
min
max
metric

РОВЕСНИКИ
ПО ПОПУЛЯЦИИ
over
ПО


СРАВНЕНИЕ С…

СОБСТВЕННАЯ
ИСТОРИЯ

ДЛЯ КАЖДОГО
by

конец
РАЗБИЕНИЕ/
РАЗДЕЛЕНИЕ ПО
partition

lat_long
rare
freq_rare
time_of_day
time_of_week

Рис. 3.2  Формула построения детектора с нуля

В диаграмме, показанной на рис. 3.2, применяются следующие обозначения:

Обнаружение изменений частотности событий  61

 текст с прописной буквы – это объяснение, а курсивный текст – это
настройки конфигурации детектора (by_field_name, partition_field_name
и over_field_name сокращены до partition и over);
 пункты в квадратных скобках являются необязательными (high, low,
non-zero, non-null);
 выберите только одну выходную ветвь (обратите внимание, что из
rare/freq_rare выходит только одна ветвь, потому что параметр by является обязательным).
Сравнение какого-либо объекта с его собственной историей достигается
просто за счет отказа от поля over.
Рассмотрев в деталях устройство детектора, мы переходим к практическим примерам различных сценариев использования детекторов. Мы начнем с применения функций подсчета count, которые позволяют нам обнаруживать изменения частотности событий с течением времени.

обнаружение изменений частотности событий
Есть много важных вариантов использования, которые основаны на идее
обнаружения изменения частотности событий. К ним относятся, например,
следующие сценарии:
 обнаружение потока сообщений об ошибках, внезапно появляющихся
в файле журнала;
 обнаружение внезапного падения количества заказов, обрабатываемых онлайн-системой;
 определение внезапного чрезмерного количества попыток доступа
(например, внезапного увеличения количества попыток входа в систему для определенного идентификатора пользователя).
Чтобы найти аномалию, мы сначала должны иметь механизм, позволяющий понять нормальную частоту событий. Но полагаться на наше ошибочное
человеческое наблюдение и интуицию – не всегда самый простой (и не самый
надежный) подход.

Подробнее о функциях count
Как упоминалось в главе 2, у заданий Elastic ML есть «рецепт» обнаружения
аномалий, известный как детектор. Детектор – это ключ к определению
того, какие аномалии пользователь хочет обнаружить. Внутри детектора
есть функция, которая выбирает характерный признак того, что должно быть
обнаружено. В случае функций count признаком является частота появления чего-либо с течением времени. Мы рассмотрим три основные варианта
функции подсчета частотности:
 count: подсчитывает количество документов в сегменте, полученных
в результате запроса к хранилищу необработанных данных raw_data;

62  Обнаружение аномалий
 high_count: то же самое, что и count, но помечает аномалию только в том
случае, если число больше ожидаемого;
 low_count: то же самое, что и count, но помечает аномалию только в том
случае, если число меньше ожидаемого.
Позже вы увидите, что в Elastic ML есть множество односторонних функций
(только для обнаружения аномалий в определенном направлении). Кроме
того, важно знать, что функции подсчета не подсчитывают значение поля
или даже наличие полей в документе; они просто подсчитывают количество
документов в хранилище с течением времени.
Чтобы получить более полное представление о том, что делают функции
подсчета, давайте перейдем к простому примеру, использующему образцы
данных в Kibana.
1. Чтобы добавить образцы данных из любого источника, на главном
экране Kibana нажмите кнопку Add data (Добавить данные), как показано на рис. 3.3:

Рис. 3.3  Главный экран Kibana с опциями добавления данных

2. После нажатия кнопки Add data выберите Sample data (Образец данных), чтобы отобразить три набора данных (рис. 3.4).

Обнаружение изменений частотности событий  63

Рис. 3.4  Добавление образцов данных

3. Нажмите каждую из трех кнопок Add data в каждом разделе, чтобы
загрузить этот образец набора данных в свой Elastic Stack. После завершения загрузки мы перейдем непосредственно к машинному обучению, выбрав значок меню с тремя горизонтальными линиями ( )
в верхнем левом углу Kibana, чтобы открыть список приложений, а затем выберите Machine Learning (Машинное обучение), как показано
на рис. 3.5.

Рис. 3.5  Выбор машинного обучения в меню приложений Kibana

64  Обнаружение аномалий
4. После перехода по ссылке мы окажемся на странице обзора машинного
обучения, где сразу можем создать наше первое задание по обнаружению аномалий. Нажмите кнопку Create job (Создать задание), как
показано на рис. 3.6.

Рис. 3.6  Экран приветствия Elastic Cloud

5. Наша следующая задача – выбрать шаблон хранилища (отмечен значком с изображением осколков) или сохраненный поиск (отмечен значком увеличительного стекла), содержащий данные, которые мы хотели
бы проанализировать. Если выбран сохраненный поиск, то основой вашей работы по машинному обучению будет отфильтрованный запрос,
который был ранее создан и сохранен в приложении Kibana Discover.
Однако в этом примере мы выберем хранилище kibana_sample_data_logs
(рис. 3.7), так как хотим передать каждый документ в этом хранилище
через Elastic ML.

Обнаружение изменений частотности событий  65

Рис. 3.7  Выбор хранилища kibana_sample_data_logs для анализа

6. На следующем экране (рис. 3.8) мы выберем мастер задания одиночной
метрики Single metric, потому что на данном этапе мы заинтересованы в анализе только одного аспекта данных: их подсчета с течением
времени.

Рис. 3.8  Выбор задания с одной метрикой Single metric

66  Обнаружение аномалий
7. На следующем экране, в соответствии с нашим примером, вы должны
(это важно!) выбрать кнопку Use full kibana_sample_logs_data (Использовать полное хранилище kibana_sample_logs_data), чтобы включить аномальную выборку в этот набор данных (рис. 3.9).

Рис. 3.9  Использование всех данных в хранилище
Эти демонстрационные данные, когда они установлены, фактически помещают около
половины данных в «прошлое» и половину в «будущее» (путем динамического изменения меток времени при захвате). Это сделано для того, чтобы статические данные могли выглядеть как «в реальном времени», например при просмотре панелей
мониторинга данных за «последний час». В результате мы попросим Elastic ML проанализировать данные из прошлого и будущего, хотя в реальной жизни невозможно
получить данные из будущего. Ради простоты примера пока не обращайте на это внимания, поскольку аномалия, которую мы хотели бы продемонстрировать, находится
во второй половине набора данных (т. е. в «будущем»).

Теперь нажмите кнопку Next (Далее), чтобы перейти к следующему
шагу мастера настройки.
8. После нажатия кнопки Next нам нужно будет выбрать то, что мы хотим проанализировать, в раскрывающемся списке Pick fields (Выбрать
поля). Мы выберем опцию Count (Event rate) (Подсчет/частотность
события), чтобы сосредоточиться на нашей исходной цели, которая
заключается в обнаружении изменений в частоте событий в этом хранилище с течением времени (рис. 3.10).

Обнаружение изменений частотности событий  67

Рис. 3.10  Выбор количества событий с течением времени
в качестве объекта обнаружения

Обратите внимание, что в выпадающем списке можно выбрать и другие варианты анализа в зависимости от типа данных поля. Мы рассмотрим некоторые из этих вариантов позже, в следующих примерах.
Нажмите кнопку Next, чтобы продолжить, оставив на данный момент
другие параметры по умолчанию.
9. Теперь нам нужно дать имя нашей задаче по обнаружению аномалий.
В поле Job ID (Идентификатор задания) введите интуитивно понятное
имя. В этом примере мы используем имя web_logs_rate (рис. 3.11).
Снова оставьте другие параметры по умолчанию и нажмите кнопку
Next.
10. Далее следует шаг проверки задания, чтобы убедиться, что все настроено правильно и задание работоспособно (рис. 3.12).
Нажмите кнопку Next, чтобы продолжить.

68  Обнаружение аномалий

Рис. 3.11  Присвоение имени заданию по обнаружению аномалий

Рис. 3.12  Шаг проверки задания

Обнаружение изменений частотности событий  69

11. На этом этапе задание готово к созданию. Обратите внимание на
рис. 3.13 – для вас были выбраны некоторые разумные параметры по
умолчанию, такие как Model memory limit (Ограничение памяти модели) и Enable model plot (Включить построение графика модели).

Рис. 3.13  Задание на обнаружение аномалий готово к созданию

12. После нажатия кнопки Create job (Создать задание) вы увидите анимированный предварительный просмотр результатов, наложенных поверх данных, как показано на рис. 3.14.
Теперь нажмите кнопку View results (Просмотр результатов), чтобы
подробно изучить, что было обнаружено заданием по обнаружению
аномалий в данных.

70  Обнаружение аномалий

Рис. 3.14  Предварительный просмотр результатов выполнения задания

13. Используя ползунок под основным графиком, отрегулируйте положение и ширину области просмотра, чтобы увеличить большой пик
(рис. 3.15).
При увеличении, уменьшении и изменении масштаба просто помните об интервале
агрегирования графика по сравнению с диапазоном периода задания (обведено на
рис. 3.15). Если вы увеличили масштаб до более широкого представления, интервал
агрегирования графика может оказаться больше, чем диапазон сегмента задания, что
сделает положение аномалии на графике менее точным.

На рис. 3.15 мы можем видеть, что очень большой всплеск событий был
отмечен как две отдельные аномалии, потому что фактическое количество
веб-запросов, замеченных в журналах, было примерно в 11 раз выше ожидаемого (с учетом изученной модели данных до момента аномалии). График
показывает две аномалии рядом друг с другом, потому что очевидно, что
событие-всплеск охватило более одного 15-минутного временного интервала. Вы также можете заметить, что по умолчанию в таблице под графиком
отображается только одна аномалия. Это связано с тем, что для параметра

Обнаружение изменений частотности событий  71

Interval (Интервал) по умолчанию установлено значение Auto (Авто), а аномалии, смежные по времени, суммируются вместе, и отображается только
наивысший балл. Если для параметра Interval установлено значение Show
all (Показать все), в таблице будут перечислены обе записи об аномалиях
(рис. 3.16).

Рис. 3.15  Результаты свидетельствуют о наличии критической аномалии

Рис. 3.16  Настройка интервала для отображения всех аномалий

72  Обнаружение аномалий
В этом примере есть еще одна вещь, на которую следует обратить внимание, а именно другие, менее выраженные аномалии, встреченные ранее
в наборе данных (рис. 3.17).

Рис. 3.17  Аномалии нескольких сегментов

В отношении этих менее очевидных аномалий следует признать несколько
ключевых моментов:
 их оценка ниже, чем у массивного всплеска, который мы только что
исследовали, поэтому они, условно говоря, не такие уж аномальные,
но весьма интересны и заслуживают внимания;
 аномалия здесь – «отсутствие» ожидаемых значений. Другими словами, функция count интерпретирует отсутствие данных (событий) как
0, и это может быть аномалией, если ожидается, что события должны
были произойти;
 эти аномалии не являются аномалиями одного сегмента, а, напротив, представляют собой аномалии в нескольких сегментах (multi-bucket

Обнаружение изменений частотности событий  73

anomalies). Такие аномалии обозначаются другим символом в пользовательском интерфейсе (крестик вместо точки). Они обозначают
случаи, в которых фактическое сингулярное значение не обязательно может быть аномальным, но есть тенденция, которая возникает
в скользящем окне из 12 последовательных сегментов. Здесь вы можете
увидеть заметный спад, охватывающий несколько соседних сегментов.
Дополнительные пояснения об интерпретации аномалий, представленных в нескольких сегментах, вы можете найти в подробной статье по адресу https://www.elastic.
co/blog/interpreting-multi-bucket-impact-anomalies-using-elastic-machine-learningfeatures.

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

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

Ненулевой подсчет
Функции ненулевого подсчета (non_zero_count, low_non_zero_count и high_non_
zero_count) позволяют обрабатывать анализ на основе подсчета, а также поддерживают точное моделирование в тех случаях, когда данные могут быть
разреженными и вы хотели бы обработать отсутствие данных не как ноль,
а как null – другими словами, набор данных временного ряда, который выглядит следующим образом:
4,3,0,0,2,0,5,3,2,0,2,0,0,1,0,4

функцией non_zero_count будет интерпретирован так:
4,3,2,5,3,2,2,1,4

Обработка нулей как null может быть полезна в случаях, когда ожидается
отсутствие регулярных измерений через равные промежутки времени. Вот
некоторые практические примеры таких данных:
 количество авиабилетов, приобретенных в месяц физическим лицом;
 количество перезагрузок сервера за сутки;
 количество попыток входа в систему в час.
Чтобы выбрать ненулевую версию функций подсчета в мастерах заданий,
просто включите опцию Sparse data (Разреженные данные) во время настройки (рис. 3.18).

74  Обнаружение аномалий

Рис. 3.18  Добавление опции Sparse data для выбора ненулевой функции подсчета

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

Раздельный подсчет
Функции раздельного подсчета (unique_count, low_distinct_count и high_independent_count) измеряют уникальность (мощность, cardinality) значений
для конкретного поля. Есть много возможных применений этой функции,
особенно когда она используется в контексте анализа популяции (см. далее
в этой главе) для обнаружения объектов, которые содержат чрезмерно разнообразный набор значений полей. Хороший классический пример – поиск IP-адресов, которые выполняют сканирование портов, получают доступ
к необычно большому количеству различных номеров портов назначения
на удаленных машинах или отправляют множество разных URL-адресов на
веб-сервер – другими словами, действуют как автоматизированный бот, а не
типичный пользователь-человек. Например, если бы в качестве конфигурации детектора в последнем примере по хранилищу kibana_sample_data_logs

Обнаружение изменений значений показателей  75

мы выбрали distinct_count(url.keyword), мы бы выявили тот же аномальный
фрейм, но по другой причине – не только аномально высокий общий объем
запросов, как показано на рис. 3.15, но и аномально большое разнообразие
запрашиваемых URL (рис. 3.19).

Рис. 3.19  Пример детектора раздельного подсчета

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

обнаружение изменений значений показателей
Очевидно, что не все данные, передаваемые из систем, будут текстовыми
или категориальными по своей природе – большая часть их будет числовой.
Обнаружение изменений значений показателей с течением времени идеально подходит для обнаружения аномалий, потому что, как упоминалось
в главе 1, историческая парадигма предупреждения об аномальных числовых

76  Обнаружение аномалий
показателях с помощью статических пороговых значений десятилетиями
создавала проблемы. Давайте посмотрим, что Elastic ML может предложить
в отношении функций, помогающих обнаруживать аномальные изменения
в числовых полях ваших данных.

Метрические функции
Метрические функции (metric functions) работают с числовыми полями и возвращают числовые значения. Это, пожалуй, самые простые для понимания
функции детектора.

min, max, mean, median и metric
Эти функции работают именно так, как можно ожидать из их названия: они
возвращают минимум, максимум, среднее и медианное значение всех числовых наблюдений для интересующего поля в заданном промежутке времени.
Функция metric немного уникальна тем, что на самом деле это просто
сокращенный способ указать, что минимальное, максимальное и среднее
значение должны использоваться вместе.
Следует отметить, что если частота данных (например, данных, поступающих из источника выборки, такого как Metricbeat) в точности совпадает
с диапазоном сегмента, то существует только одна выборка на диапазон сегмента. Это означает, что минимум, максимум, среднее значение и медиана
интересующей области – это одно и то же значение (значение отдельного
наблюдения как такового). Поэтому, если возможно, обычно лучше иметь несколько числовых выборок на интервал сегмента, если вы хотите реализовать
дискриминацию с помощью этих функций.
Еще один факт, который следует отметить, заключается в том, что эти
метрические функции обрабатывают отсутствие данных как null. Другими
словами, если ваши данные немногочисленны и есть интервалы сегментов,
в которых отсутствуют наблюдения, эти отсутствующие данные не будут
«притягивать к нулю» статистику интересующей области. Вот почему эти
метрические функции не имеют «ненулевых» (или «не-null») аналогов.

varp
Функция varp измеряет общую дисперсию показателя во времени – его волатильность. Использование этой функции может быть применимо для поиска
случаев, когда числовое значение поля обычно является довольно равномерным, но вы хотели бы определить, было ли изменение.

sum и non-null sum
Функция sum вернет сумму всех числовых наблюдений для интересующего
поля в интервале времени сегмента. Используйте версию non-null sum, если
у вас есть разреженные данные и вы не хотите, чтобы их отсутствие считалось нулем, что неизбежно «притянет к нулю» значение суммы.

Обзор расширенных функций детектора  77

Если бы мы выбрали sum(bytes) в качестве конфигурации детектора в последнем примере по хранилищу kibana_sample_data_logs, мы бы обнаружили ту
же аномалию, но по другой причине – мы видим, что сделанные запросы также
привели к увеличению количества байтов, переданных с веб-сервера (рис. 3.20).

Рис. 3.20  Пример детектора sum

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

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

78  Обнаружение аномалий
ны только в том случае, если задание машинного обучения настроено с помощью мастера расширенных заданий или через API.

Функция rare
В контексте потока временной информации (например, файла журнала)
представление о чем-то статистически редком (происходящем с низкой
частотой) парадоксальным образом является одновременно очевидным
и трудным для понимания. Если бы меня попросили, например, пролистать
файл журнала и найти редкое сообщение, у меня мог возникнуть соблазн пометить первое новое сообщение, которое я увидел, как редкое. Но что, если
практически каждое сообщение было новым? Все они являются редкими?
Или наоборот, в этом случае нет редких сообщений?
Чтобы определить редкость как полезное понятие в контексте потока событий во времени, мы должны согласиться с тем, что объявление чего-либо
редким должно учитывать контекст, в котором оно существует. Если есть
много других рутинных объектов и мало уникальных, то мы можем считать
уникальные объекты редкими. Если есть много уникальных объектов, то мы
будем считать, что ни один из них не является редким.
При применении функции rare в заданиимашинного обучения необходимо объявить, на каком поле эта функция фокусируется. Это поле затем определяется как by_field_name. Конфигурация функции rare не имеет собственного мастера в пользовательском интерфейсе Elastic ML, поэтому вам нужно
будет определить ее с помощью мастера расширенных заданий. Например,
чтобы найти записи журнала, в которых упоминается редкое название страны, структурируйте свой детектор, как показано на рис. 3.21.

Рис. 3.21  Пример детектора rare

Обзор расширенных функций детектора  79

Это может быть удобно для поиска доступа из неожиданного географического региона (например, «Наши администраторы обычно почти ежедневно
входят в систему из офисов в Нью-Йорке и Лондоне, но никогда из Москвы!»).

Функция freq_rare
Функция freq_rare – это специализированная версия функции rare, поскольку она ищет членов популяции, которые вызывают частое появление редких
значений by_field_name. Например, вы можете найти конкретный IP-адрес,
с которого идут запросы на доступ ко многим редким URL-адресам, которые
обычно не характерны для всей совокупности клиентских IP-адресов. Можно
предположить, что с этого IP-адреса кто-то пытается незаконно получить
доступ к скрытым разделам веб-сайта или предпринимает попытки атак,
таких как SQL-инъекция.

Функция info_content
Функция info_content – пожалуй, самая специализированная функция детектора в арсенале Elastic ML. Первоначально она была разработана как средство
измерения количества энтропии в текстовых строках (как много в ней символов, и насколько они разнообразны). Это связано с тем, что во вредоносных
программах используются хорошо известные методы шифрования инструкций и/или данных полезной нагрузки для передачи управления и контроля
(command and control, C2) и действий по краже данных. Обнаружение подобной активности по этой функции данных более надежно, чем просмотр
других функций (таких как количество отправленных байтов или подсчет
отдельных объектов).
Используемый алгоритм по существу выполняет следующие шаги:
1) сортирует уникальные строки в алфавитном порядке;
2) объединяет эти уникальные строки в одну длинную строку;
3) применяет алгоритм gzip для сжатия этой длинной строки. Информационное содержание – это длина сжатых данных.
Некоторые из заданий машинного обучения в Elastic SIEM используют
функцию info_content – мы расскажем о ней в главе 8.

Функции геолокации
Если вы ищете географическое положение, которое необычно для изученного ранее региона местоположения на Земле, вам пригодится функция
lat_long, в которой аргумент field_name представляет собой пару чисел, разделенных запятыми, в диапазоне от –180 до 180 (например, 40.75, –73.99 –
это координаты Таймс-сквер в Нью-Йорке). Функция lat_long также может
работать с полем geo_point, полем geo_shape, содержащим значения точек, или
агрегацией geo_centroid. Примером использования функции может быть от-

Powered by TCPDF (www.tcpdf.org)

80  Обнаружение аномалий
метка ненормального (и потенциально мошеннического или вредоносного)
местоположения для конкретного пользователя, транзакции и т. д.

Функции времени
Не все события происходят случайно во времени, особенно когда речь идет
о человеческом поведении. Мы можем принимать пищу, ездить на работу
или входить в определенные системы в предсказуемое время дня или недели. Используя функции time_of_day и time_of_week, вы можете обнаруживать
изменения поведения в рамках изученной временной процедуры. Если поведение предсказуемо на 24-часовом отрезке времени, то больше подходит
time_of_day. Если обычное поведение зависит от дня недели, то более логичным выбором будет time_of_week.
Не путайте использование этих функций времени с обучением детекторов на естественных последовательностях в заданиях по обнаружению аномалий. Как было сказано в главе 1, для устранения тенденций модель изучает время, в которое что-то
происходит. Эти функции просто моделируют временную метку события в течение
дня или недели. Например, если что-то обычно случается каждые сутки в 2 часа ночи,
функция научится тому, что обычно это происходит на 7200-й секунде дня.

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

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

Настройка поля разделения
При использовании некоторых мастеров заданий (например, мастеров Multimetric и Population) вы увидите возможность разделить анализ (рис. 3.22).
Здесь, на рис. 3.22, демонстрирующем использование мастера Multi-metric
для создания задания по хранилищу kibana_sample_data_ecommerce, мы видим,
что функция high_sum в поле taxful_total_price разделяется на экземпляры в поле с именем category.keyword (плюс включен параметр Sparse data).

Разделение анализа по категориальным признакам  81

Другими словами, анализ будет проводиться для каждой категории товаров
в этом магазине электронной коммерции (мужская одежда, женские аксессуары и т. д.). Если анализ выполняется и результаты проверяются с помощью
пользовательского интерфейса Anomaly Explorer, результат может выглядеть
приблизительно так, как показано на рис. 3.23.

Рис. 3.22  Разделение по категориальному полю

Обратите внимание на рис. 3.23: представление Anomaly Explorer отличается от того, что мы видели до сих пор в Single Metric Viewer. Anomaly Explorer
показывает 10 самых аномальных категорий (поле, по которому выполняется разделение) временного ряда. Заметим, что показаны не все категории,
а только те, которые имеют аномалии, – и очевидно, что категория «Мужская
одежда» была самой необычной с выручкой 9 ноября в размере 2250 долларов
США (в этой версии набора данных). Вы узнаете больше об интерпретации
результатов заданий с несколькими критериями (multi-metric) и научитесь
широко использовать Anomaly Explorer в главе 5.

82  Обнаружение аномалий

Рис. 3.23  Результаты раздельного анализа по категориям

Разница между разделением с использованием
partition и by_field
Как было сказано ранее, когда задействованы мастер Multi-metric и разделение, параметру partition_field_name присваивается значение поля, выбранного в пользовательском интерфейсе.
Однако когда выбрано разделение в мастере Population, для разделения
анализа выбирается by_field_name. Если используется мастер Advanced, то
можно определить partition_field_name и/или by_field_name (если оба, то это
фактически двойное разделение). Поэтому было бы полезно знать, чем эти
две настройки, которые эффективно разделяют анализ, отличаются друг от
друга.
Если вы хотите реализовать «жесткое» разделение анализа, используйте
partition_field_name:

Разделение анализа по категориальным признакам  83

 выбранное поле, как правило, должно иметь < 10 000 различных значений на задание, поскольку для разделения требуется больше памяти;
 каждый экземпляр поля подобен независимой переменной.
Оценка аномалий в одном разделе более независима от других разделов.
Если вы хотите реализовать «мягкое» разделение, используйте by_field_
name:
 выбранное поле, как правило, должно иметь < 100 000 различных значений на задание;
 больше подходит для атрибутов объекта (зависимые переменные);
 при подсчете результата учитывается история других полей by.
Давайте углубимся в этот последний из перечисленных пунктов, относящийся к «истории» других полей by. Что именно это означает?
В общем случае в заданиях анализа по обнаружению аномалий существует
концепция, связанная с моментом первого появления объекта; мы назовем
этот момент началом времени (down of time). Когда что-то происходит в начале времени (то есть когда задание впервые видит данные для host:X или
error_code:Y), может возникнуть одна из двух ситуаций:
 этот новый объект рассматривается как «новинка» и сам по себе примечателен и потенциально заслуживает того, чтобы быть отмеченным
как аномалия. Для этого вам нужно, чтобы «начало времени» наступило одновременно с запуском задания;
 этот новый объект – всего лишь часть обычного «расширения» данных – возможно, в сеть был добавлен новый сервер или в каталог товаров был добавлен новый product_id. В этом случае просто начните
моделировать этот новый объект и не беспокойтесь о его появлении.
Для этого вам нужно, чтобы «начало времени» наступило, когда этот
объект впервые появится.
При разделении с использованием by_field_name «начало времени» – это
когда было запущено задание ML, а при разделении с использованием partition_field_name «начало времени» – это когда упомянутый раздел впервые
появился в данных. Таким образом, в ситуации, когда появляется что-то
«новое», вы получите разные результаты в зависимости от разделения.

Является ли двойное разделение пределом возможного?
Как уже упоминалось, используя в мастере заданий Advanced как partition_
field_name, так и by_field_name, вы можете получить двойное разделение. Но
если вам нужно выполнить больше разделений, вам придется полагаться на
другие методы. А именно вам нужно будет создать скриптовое поле, которое
представляет собой конкатенацию двух (или более) полей. Использование
скриптовых полей рассматривается в одном из примеров в приложении.
Теперь, когда вы узнали о концепции разделения анализа, давайте сосредоточимся на различиях между временным и популяционным анализами
при обнаружении аномалий.

84  Обнаружение аномалий

обзор временного и популяционного анализов
Еще в главе 1 вы узнали, что есть два подхода к определению аномальности
объекта:
 произошло ли кардинальное изменение поведения объекта по сравнению с его собственным поведением в пределах известного временного
ряда;
 наблюдается ли кардинальное отличие объекта от других членов однородной популяции.
По умолчанию используется первый режим (который мы будем просто называть временным анализом), если только в конфигурации детектора явным
образом не указана опция over_field_name.
Популяционный анализ может быть очень полезен при обнаружении аномалий во множестве важных прикладных сценариев. Например, мы хотим
найти машины, которые регистрируют больше (или меньше) событий, чем
машины с аналогичной конфигурацией, в силу следующих причин:
 неправильные изменения конфигурации, которые привели к внезапному появлению большего количества ошибок в файле журнала системы или приложения;
 системе, которая может быть скомпрометирована вредоносным ПО,
дано указание подавлять ведение журнала в определенных ситуациях,
что резко уменьшает объем журнала;
 система потеряла соединение или вышла из строя, что привело к уменьшению объема журнала;
 в остальном безобидное изменение настройки уровня ведения журнала (отладка вместо обычного журналирования), теперь заставляющее
ваши журналы занимать раздражающе много места на диске.
Другой способ, которым часто используется популяционный анализ, – это
анализ поведения пользователей/сущностей (user/entity behavioral analysis,
EUBA), когда сравнение действий объекта или человека в сопоставлении с их
аналогами может выявить следующее:
 автоматизированные пользователи: вместо типичного человеческого поведения или модели использования автоматизированный
сценарий может демонстрировать поведенческие модели, которые
выглядят совершенно иначе с точки зрения скорости, продолжительности и разнообразия создаваемых ими событий. Автоматическая
идентификация автоматизированных пользователей может оказаться
полезной, будь то поиск веб-сканера, пытающегося собрать информацию о товарах и ценах из онлайн-каталога, или обнаружение бота,
который может быть вовлечен в распространение дезинформации
в социальных сетях;

Обзор временного и популяционного анализов  85

 пользователи-разведчики: будь то настоящий человек, определяющий границы того, что ему сойдет с рук, или интеллектуальная
вредоносная программа, ведущая разведку сетевой структуры, такой
пользователь-разведчик может выполнять самые разные действия, надеясь найти нужную информацию или уязвимость (например, путем
сканирования портов). Часто использование функции independent_count
помогает найти разведчика;
 злоумышленники и агрессивные пользователи: после фазы разведки злоумышленник или вредоносное ПО переходит к активным действиям, таким как отказ в обслуживании, перебор паролей или кража
ценной информации. Опять же, злонамеренные и агрессивные пользователи резко выделяются на общем фоне своим поведением в отношении объема, разнообразия и интенсивности активности в единицу
времени.
Практическим примером может быть поиск клиента, который тратит намного больше денег, чем его соседи по популяции. Независимо от того, делаете ли вы это в контексте упреждающего расследования потенциального
мошенничества или заинтересованы в расширении услуг для своих самых
состоятельных клиентов, вам все равно необходимо найти эти выбросы.
Если бы мы использовали хранилище kibana_sample_data_ecommerce, которое
добавили ранее в примере задания в этой главе, то могли бы создать задание по анализу популяции, выбрав мастер Population, а затем выбрав поле
customer_full_name.keyword для Population field (чтобы сравнивать каждого
пользователя со всеми остальными). Для детектора мы выберем поле taxful_total_price, которое представляет собой общий доход от каждого заказа,
размещенного физическим лицом (рис. 3.24).
После выполнения этого задания вы должны увидеть результаты, показанные на рис. 3.25.
Здесь, на рис. 3.25, мы видим, что в списке самых необычных пользователей (в данном случае – крупнейших покупателей за период времени)
доминирует пользователь по имени Вагди Шоу (Wagdi Show), который,
очевидно, разместил заказ на общую сумму 2250 долл. Проницательные
читатели узнают эту аномалию из более раннего примера – за исключением того, что на этот раз наш анализ нацелен на пользователя, а не на
категорию товара.
Как видите, популяционный анализ может быть очень мощным и широко
используется в тех случаях, когда нужно выявить отдельные объекты. Поэтому он очень полезен в случаях использования аналитики в целях безопасности. Теперь давайте обратимся к одной дополнительной, но мощной возможности обнаружения аномалий Elastic ML – способности эффективно
анализировать неструктурированные сообщения журнала с помощью процесса, называемого категоризацией.

86  Обнаружение аномалий

Рис. 3.24  Популяционный анализ доходов по пользователям

категоризация в анализе неструктурированных
сообщений
Представьте, что вы устраняете проблему, просматривая определенный файл
журнала. Вы видите в журнале строку, которая сообщает, что не обновлена
главная таблица базы данных:
18/05/2020 15:16:00 DB Not Updated [Master] Table

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

Категоризация в анализе неструктурированных сообщений  87

Рис. 3.25  Результаты анализа популяции крупнейших покупателей

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

88  Обнаружение аномалий
На помощь приходит Elastic ML с возможностями, которые позволяют эмпирически оценить как уникальность содержания сообщений, так и относительную частоту появления.

Типы сообщений, подходящие для категоризации
Нам следует быть достаточно строгими и избирательными при выборе типов
строк журнала на основе сообщений, которые подходят для такого рода анализа. Что мы не рассматриваем, так это строки журнала/события/документы,
которые являются полностью произвольными и, вероятно, выступают результатом человеческого творчества (электронные письма, твиты, комментарии и т. д.). Подобные сообщения слишком произвольны и разнообразны
по своему построению и содержанию.
Вместо этого мы сосредоточимся на сгенерированных компьютером сообщениях, которые, очевидно, возникают, когда приложение сталкивается
с различными ситуациями или исключениями, тем самым ограничивая их
структуру и содержимое относительно дискретным набором возможностей
(понимая, что все равно могут присутствовать некоторые переменные аспекты сообщения). Например, давайте посмотрим на следующие несколько
строк журнала приложения:
18/05/2016 15:16:00 S ACME6 DB Not Updated [Master] Table
18/05/2016 15:16:00 S ACME6 REC Not INSERTED [DB TRAN] Table
18/05/2016 15:16:07 S ACME6 Using: 10.16.1.63!svc_
prod#uid=demo;pwd=demo
18/05/2016 15:16:07 S ACME6 Opening Database = DRIVER={SQL
Server};SERVER=10.16.1.63;network=dbmssocn;
address=10.16.1.63,1433;DATABASE=svc_
prod;uid=demo;pwd=demo;AnsiNPW=No
18/05/2016 15:16:29 S ACME6 DBMS ERROR : db=10.16.1.63!svc_
prod#uid=demo;pwd=demo Err=-11 [Microsoft][ODBC SQL Server
Driver][TCP/IP Sockets]General network error. Check your
network documentation.

Здесь мы видим, что существует множество сообщений с разным текстом,
но все равно просматривается некоторая общая структура. После отметки даты/времени и имени сервера, с которого было отправлено сообщение
(здесь ACME6), идет содержание сообщения, где приложение информирует
внешний мир о происходящем в данный момент – все работает как надо или
возникают ошибки.

Предварительная категоризация
Чтобы навести порядок в беспорядочном потоке сообщений в файле журнала, Elastic ML будет использовать метод группировки похожих сообщений
вместе с использованием алгоритма кластеризации схожих строк. Упрощенная логика действий этого алгоритма такова:

Категоризация в анализе неструктурированных сообщений  89

 неизменяемым словарным (английским) словам уделяется больше
внимания, чем изменяемым (то есть network и address являются словарными словами, но dbmssocn, скорее всего, является изменяемой/
переменной строкой);
 неизменяемые словарные слова пропускают через алгоритм подобия
строк (аналогичный расстоянию Левенштейна1), чтобы определить, насколько похожа текущая строка журнала на предыдущие строки;
 если разница между текущей строкой журнала и существующей категорией небольшая, ее добавляют в эту категорию. В противном случае
создают новую категорию для текущей строки журнала.
В качестве простого примера рассмотрим эти три сообщения:
Error writing file "foo" on host "acme6"
Error writing file "bar" on host "acme5"
Opening database on host "acme7"

Алгоритм объединяет первые два сообщения в одну категорию, так как
они относятся к ошибке записи файла (Error writing file), тогда как третьему
сообщению будет присвоена собственная (новая) категория.
Система имен этих категорий очень проста: ML будет называть их просто
mlcategory N, где N – увеличивающееся целое число. Следовательно, в этом
примере первые две строки будут связаны с mlcategory 1, а третья строка
будет связана с mlcategory 2. В реалистичном машинном журнале могут быть
тысячи (или даже десятки тысяч) категорий, которые возникают из-за разнообразия сообщений журнала, но все равно набор возможных категорий должен быть конечным. Однако если количество категорий начнет исчисляться
сотнями тысяч, его трудно считать ограниченным набором возможных типов
сообщений, и такой набор данных уже не будет подходящим кандидатом для
анализа путем категоризации.

Анализ категорий
Теперь, когда сообщения классифицированы с помощью алгоритма, описанного ранее, следующий шаг – провести анализ (с использованием функций
count или rare). В этом случае мы не будем считать строки журнала (и, следовательно, документы хранилища Elasticsearch) сами по себе; вместо этого
мы собираемся подсчитать частоту появления различных категорий, которые являются выходными данными алгоритма. Строки журнала из примера выше, если они возникли в пределах одного сегмента, дадут следующий
результат алгоритма категоризации:
mlcategory 1: 2
mlcategory 2: 1
1

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

90  Обнаружение аномалий
Другими словами, было два появления ошибки типа Error writing file
и одно появление ошибки типа Opening database on host в последнем интервале
сегмента. Именно эта информация будет в конечном итоге обработана моделью машинного обучения, чтобы определить, является ли она необычной.

Пример задания по категоризации
Благодаря мастеру заданий категоризации в пользовательском интерфейсе
процесс настройки этого типа заданий чрезвычайно прост. Давайте сначала
предположим, что у нас есть загруженный неструктурированный файл журнала (например, файл secure.log в папке example_data на GitHub):
Дополнительные сведения о том, как принимать данные с помощью визуализатора файлов, представлены в подробной статье по адресу https://www.elastic.co/blog/
importing-csv-and-log-data-into-elasticsearch-with-file-data-visualizer.

1. Выбрав интересующее вас хранилище и мастер Categorization, а затем указав соответствующий временной диапазон для анализа, вы
перейдете к выбору детектора категоризации (детектор Count или
детектор Rare), а также нужного поля категоризации (Categorization
field). В данном случае наши данные содержат только два поля (@timestamp и message). Следовательно, мы будем классифицировать в Elastic
ML поле message. В этом примере мы также выберем детектор Count
(рис. 3.26).
Обратите внимание, что вы можете просмотреть поле выбранной категории, чтобы убедиться, что оно дает разумные результаты. Также
заметим, что в разделе Examples (Примеры) представлено визуальное
подтверждение того, что Elastic ML сфокусирован на неизменяемом
тексте сообщений журнала.
2. После подтверждения конфигурации и запуска задания вы увидите
в окне мастера предварительный просмотр результатов по мере их
обнаружения и анализа (рис. 3.27).

Категоризация в анализе неструктурированных сообщений  91

Рис. 3.26  Настройка задания категоризации

92  Обнаружение аномалий

Рис. 3.27  Предварительный просмотр результатов задания категоризации

В этом простом примере в данных было обнаружено 23 категории.
Когда результаты просматриваются в Anomaly Explorer, мы видим, что
главная аномалия здесь – это категория номер 7.
3. Если нажать мышкой на столбец примеров категорий, представление
расширяется, демонстрируя примеры строк журнала, которые попали
в эту категорию (рис. 3.28).

Категоризация в анализе неструктурированных сообщений  93

Рис. 3.28  Результаты задания по категоризации

Здесь мы видим, что количество полученных сообщений Received disconnect резко возросло.
4. Нажав на значок шестеренки, как показано на рис. 3.28 справа вверху, мы можем выбрать View examples (Просмотр примеров), чтобы
перейти в пользовательский интерфейс Kibana Discover, но с отфильтрованным соответствующим сообщением и растянутым временным
интервалом (рис. 3.29).
Панель запроса Discover была автоматически заполнена соответствующим запросом KQL, чтобы ограничить наше представление типом
сообщений, который признан аномальным.
5. Если мы удалим этот фильтр запроса, то получим все сообщения в файле журнала во время этой аномалии и увидим более обширную картину
происходящего, которая заключается в том, что кто-то предпринимал
много попыток аутентификации (рис. 3.30).
Судя по всему, наблюдается шквал попыток аутентификации с использованием хорошо известных имен пользователей (user, test и т. д.). Похоже,
мы обнаружили попытку взлома системы методом грубой силы (брутфорс,
brute-force), просто используя категоризацию!

94  Обнаружение аномалий

Рис. 3.29  Проверка необработанных строк журнала
из результатов задания категоризации

Когда не следует использовать категоризацию
Несмотря на то что категоризация весьма полезна, ей присущи свои ограничения. В частности, можно назвать такие варианты данных, когда попытка
использовать категоризацию, скорее всего, даст плохие результаты:
 поля текста произвольной формы, вероятно, созданные людьми, – твиты, комментарии, электронные письма и заметки;
 строки журнала, которые действительно содержат правильные пары
имя/значение, такие как журнал доступа к сети;
 документы, содержащие много многострочного текста, такого как
трассировка стека, XML и т. д.

Управление Elastic ML через API  95

Риc. 3.30  Просмотр всех линий журнала в период аномалии

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

управление ElasTIc Ml через aPI
Как и практически все компоненты Elastic Stack, модуль ML также можно
полностью автоматизировать с помощью вызовов API, включая настройку
заданий, выполнение и сбор результатов. Фактически все ваши взаимодействия в пользовательском интерфейсе Kibana за кулисами используют API
Elastic ML. Вы можете, например, полностью разработать свой собственный
пользовательский интерфейс, если вам нужны определенные рабочие процессы или визуализации.

96  Обнаружение аномалий
Более подробную информацию об API обнаружения аномалий вы найдете на сайте
https://www.elastic.co/guide/en/machine-learning/current/ml-api-quickref.html. Часть
аналитики фреймов данных в Elastic ML имеет совершенно отдельный API, который
будет обсуждаться в главах с 9 по 13.

Мы не будем вдаваться в подробности каждого вызова API, но хотели бы
выделить некоторые компоненты, на которые стоит обратить внимание.
Первым очевидным API, который следует упомянуть, является интерфейс
создания заданий, который позволяет создавать конфигурацию заданий
Elastic ML. Например, если вы хотите создать заново задание анализа популяции, показанное на рис. 3.24, следующий вызов создаст такое задание
с названием revenue_over_users_api:
PUT _ml/anomaly_detectors/revenue_over_users_api
{
"job_id": "revenue_over_users_api",
"analysis_config": {
"bucket_span": "15m",
"detectors": [
{
"detector_description": "high_sum(taxful_total_price)
over customer_full_name.keyword",
"function": "high_sum",
"field_name": "taxful_total_price",
"over_field_name": "customer_full_name.keyword"
}
],
"influencers": [
"customer_full_name.keyword"
]
},
"data_description":{
"time_field":"order_date",
"time_format":"epoch_ms"
}
}

Обратите внимание, что поле job_id должно быть уникальным при создании задания.
Чтобы создать конфигурацию сопутствующего потока данных для этого
задания, мы должны выполнить следующий отдельный вызов API:
PUT _ml/datafeeds/datafeed-revenue_over_users_api
{
"datafeed_id": "datafeed-revenue_over_users_api",
"job_id": "revenue_over_users_api",
"query_delay": "60s",
"indices": [
"kibana_sample_data_ecommerce"
],
"query": {

Заключение  97
"bool": {
"must": [
{
"match_all": {}
}
]
}
},
"scroll_size": 1000,
"chunking_config": {
"mode": "auto"
}
}

Обратите внимание, что запрос по умолчанию к хранилищу – match_all,
что означает отсутствие фильтрации. Конечно, мы могли бы вставить любой
допустимый Elasticsearch DSL в блок запроса для выполнения настраиваемых
фильтров или агрегаций. Этот подход мы рассмотрим позже.
Существуют и другие API, которые можно использовать для извлечения результатов или изменения других аспектов выполнения задания машинного
обучения. Обратитесь к онлайн-документации для получения дополнительной информации.

заключение
Вы видели, что Elastic ML может выделять различия в объеме, разнообразии
и уникальности метрик и сообщений журнала, в том числе тех, которые сначала нуждаются в некоторой категоризации. Кроме того, мы показали, что
популяционный анализ может быть чрезвычайно интересной альтернативой
обнаружению временных аномалий, когда основное внимание уделяется
поиску самых необычных сущностей. Эти методы помогают решить проблему ограниченных возможностей человека, который во многих случаях не
способен определить, что действительно необычно и заслуживает внимания
и исследования.
Навыки, приобретенные в данной главе, пригодятся в последующих главах, где вы увидите, как ML помогает в поиске первопричин сложных ITпроблем, выявлении снижения производительности приложений или обнаружении деятельности вредоносных программ и злонамеренной внешней
активности.
В следующей главе вы увидите, как модели временных рядов, построенные
с помощью заданий по обнаружению аномалий, могут быть использованы
для прогнозирования тенденций ваших данных в будущем.

Глава

4
Прогнозирование

Прогнозирование – это естественное продолжение моделирования временных рядов в Elastic ML. Поскольку показательные модели описывают историческое поведение данных и строятся на их основе, можно спроецировать
эту информацию вперед во времени и предсказать, как что-то должно вести
себя в будущем.
На этом этапе мы потратим некоторое время на изучение концепций прогнозирования, а также на рассмотрение некоторых практических примеров.
В частности, в этой главе будут рассмотрены следующие темы:







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

технические требования
Информация и примеры, представленные в этой главе, актуальны для версии 7.11 Elastic Stack.

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

Ключевое различие между предсказаниями и пророчествами  99

иметь положительные результаты в следующие восемь кварталов и что их капитализация будет продолжать расти? Вероятность свидетельствует в пользу
этого факта, но это еще не все. И прежде чем впасть в опасное заблуждение,
будто способность Elastic ML к прогнозированию поможет нам заработать
состояние на фондовом рынке, мы должны четко осознать ключевое ограничение – всегда есть неконтролируемые факторы.
Причина, по которой финансовые компании используют вышеупомянутый
отказ от ответственности, заключается в том, что часто возникают неизвестные, неконтролируемые факторы, которые могут значительно повлиять на траекторию любого процесса. Например, правительство может внести в нормативные акты или торговую политику изменения, которые помогут или помешают
компании работать и приносить прибыль, или же внезапно может вскрыться
мошенничество в бухгалтерском учете и выяснится, что руководители сговорились фальсифицировать корпоративную отчетность, которая не отражает
реальное положение дел, и в конечном итоге компания обанкротится.
Эти факторы считаются неизвестными и внешними по следующим причинам:
 они находятся вне контроля самой организации (как в примере, когда
правительство определяет экономическую политику независимо от
деятельности компании);
 они не входят в доступную информацию о системе (внешний инвестор
в режиме реального времени имеет доступ только к общедоступным
отчетам, а не к сведениям о мошеннических действиях по фабрикации
этих отчетов).
Следовательно, ваши экономические прогнозы хороши ровно настолько,
насколько хороши имеющаяся у вас информация и ваша способность устранять или смягчать влияние внешних неизвестных факторов, которые повлияют на ваш прогноз. Это справедливо и в мире информационных технологий. Не всегда можно предсказать тенденцию или сбой, если существенное
влияние оказывает неизвестный внешний фактор (некорректное изменение
конфигурации, отказ оборудования и т. д.). Однако мы можем использовать
вероятностный анализ, чтобы составить наилучшее возможное представление о будущем, максимально абстрагируясь от непредсказуемых внешних
факторов. Наличие этого представления позволяет нам реализовать некоторые сценарии использования прогнозирования, не зацикливаясь на пророчествах1. Давайте теперь поговорим о том, как мы можем использовать
прогнозирование на практике.
1

Powered by TCPDF (www.tcpdf.org)

Здесь авторы оставили между строк мысль о том, что формализованное использование доступной информации временных рядов – это прогнозирование, а разговоры о потенциально неизвестных и непредсказуемых факторах – это пророчество.
Мошенничество руководителей инвестиционного фонда невозможно спрогнозировать, но можно напророчить, а потом сидеть в ожидании, пока пророчество
сбудется (я же говорил!) или не сбудется. Но доходность инвестиционного фонда
можно спрогнозировать на основании исторической информации о динамике доходности и стоимости акций предприятий, в которые фонд инвестирует средства. –
Прим. перев.

100  Прогнозирование

Для чего применяется прогнозирование?
В контексте Elastic ML на самом деле есть только два в некотором роде похожих сценария, в которых можно использовать прогнозирование:
 приоритет значения: вы экстраполируете временной ряд в будущее,
чтобы спрогнозировать вероятную будущую ценность. Это, например,
ответы на вопросы типа: «Сколько виджетов я буду продавать в день
через 2 месяца?»;
 приоритет времени: в этом сценарии вы оцениваете вероятное время, в течение которого будет достигнуто ожидаемое значение. Это ответы на вопросы типа: «Достигнет ли нагрузка на сервер значения 80 %
в течение следующей недели?»
Различия между этими двумя вариантами использования могут заключаться не только в том, как поставлен вопрос (как выполняется поиск данных), но и в том, как вы интерпретируете вывод. Однако, прежде чем мы
углубимся в несколько примеров использования функции прогнозирования,
давайте уделим немного времени обсуждению того, как она работает с логистической точки зрения.

как работает прогнозирование?
Первое, что нужно понять, – получение прогноза на основе имеющихся данных является расширением известного задания по обнаружению аномалий.
Другими словами, вам необходимо настроить задание обнаружения аномалий, и это задание должно проанализировать исторические данные, прежде
чем вы сможете делать прогнозы на основе этих данных. Это связано с тем,
что в процессе прогнозирования используются модели, созданные заданием
«Обнаружение аномалий». Чтобы спрогнозировать данные, вам необходимо
выполнить те же шаги, которые использовались для создания задания на
обнаружение аномалий, как описано в предыдущих главах. Если при выполнении этого задания обнаружены аномалии, вы можете не обращать на них
внимания, если ваша единственная цель – выполнить прогноз. После того
как задание изучило некоторые исторические данные, модель или модели
(если задание настроено для анализа данных из более чем одного временного ряда), связанные с этим заданием, становятся текущими и актуальными,
как показано на рис. 4.1.
Мы будем рассматривать период времени, предшествующий текущему моменту, как историческое обучение (historical learning) – период, в течение которого модели учились на реальных данных. Когда в определенный момент
пользователь желает получить прогноз, создается копия модели (моделей),
и запускается отдельный процесс, который берет эти модели и экстраполирует их в «будущее». Этот процесс выполняется параллельно, чтобы не мешать
исходным моделям и их развитию, как показано на рис. 4.2.

Как работает прогнозирование  101
Текущая(ие)
модель(и)

Обучение на исторических данных
Время
Текущий момент

Рис. 4.1  Условное представление процесса создания моделей
на исторических данных

Текущая(ие)
модель(и)

Скопированная(ые)
модель(и)

Обучение на исторических данных

«Будущее»
Время

Запрос прогноза

Рис. 4.2  Символьное представление моделей,
скопированных для прогнозирования будущего

Значения прогноза записываются в то же хранилище результатов, что
и обнаружение аномалий, но как результат особого типа (подробнее об этом
позже), и они доступны для просмотра в пользовательском интерфейсе или
через API.
Важно отметить, что нормальное выполнение задания машинного обучения, анализирующего реальные данные, будет продолжаться (если оно выполняется в реальном времени), и, следовательно, по прошествии некоторого
времени может возникнуть разница между спрогнозированным значением
(сделанным во время выполнения задания прогноза) и фактическим значением на тот момент, когда наступит время прогноза (рис. 4.3).
Наличие ошибки прогноза следовало ожидать, но мы всегда надеемся, что
она будет минимальной. Разница между прогнозом и реальностью в выбранный момент в настоящее время не используется в Elastic ML, но, возможно,
в будущем она поможет модели формировать более точные последующие
прогнозы. Конечно, также возможно, что причиной ошибки прогноза послужит неизвестный внешний фактор (как мы говорили ранее).
Другой (возможно, более простой) способ понять неопределенность прогнозов – это представить предсказание результата подбрасывания монеты.

102  Прогнозирование
Вы можете наблюдать последовательность предыдущих подбрасываний монеты, но если вы не принимаете во внимание физику подбрасывания монеты
(скорость, высоту, вращение и т. д.) и полагаетесь только на результаты прошлых наблюдений, то вы не добьетесь лучшей точности прогноза, чем 50/50.
Кроме того, вполне возможно, что в течение периода обучения модели Elastic
ML не обнаружит данных, согласованных с чьим-либо поведением. Поэтому
шум в данных также вносит в прогноз некоторое количество вариаций или
неопределенности.
Ошибка прогноза

Время
Запрос
прогноза

Текущий
момент

Рис. 4.3  Ошибка прогноза

Пользователь может делать несколько прогнозов в разное время. Они будут храниться отдельно, как показано на рис. 4.4.

№1
№2

Время
Запрос
прогноза № 1

Запрос
прогноза № 2

Рис. 4.4  Прогнозы, сделанные в разное время

Прогнозы № 1 и № 2 различаются внутренним уникальным идентификатором экземпляра прогноза. Это станет видно позже, когда мы посмотрим,
как результаты прогнозов размещаются в хранилище.
Теперь, когда у вас есть базовое представление о процессе прогнозирования, давайте рассмотрим пример использования Elastic ML для прогнозирования одиночного временного ряда.

Прогнозирование одиночного временного ряда  103

прогнозирование оДиночного временного ряДа
Чтобы проиллюстрировать процедуру прогнозирования, мы начнем с набора
данных, который представляет собой одиночный временной ряд. Хотя этот
набор данных является общим для разных примеров, вы можете представить,
что он отражает метрику производительности системы, количество транзакций, обработанных системой, или даже данные о доходах от продаж. Важной
особенностью этого набора данных является то, что он содержит несколько
различных трендов, зависящих от времени: дневной тренд, недельный тренд
и общий возрастающий тренд. Elastic ML обнаружит все эти тренды и будет
эффективно предсказывать их в будущем. Стоит отметить, что набор данных также содержит некоторые аномалии, но будущие аномалии невозможно
предсказать, поскольку они являются непредсказуемыми событиями по определению. Так как здесь мы говорим исключительно о прогнозировании, при
построении моделей для прогнозирования мы будем игнорировать наличие
любых аномалий, обнаруженных в нашем наборе данных.
С учетом сказанного, давайте перейдем к примеру, используя набор данных forecast_example из репозитория GitHub. После загрузки данные можно
легко импортировать в Kibana с помощью визуализатора данных Elastic ML.
Последовательно выполните следующие действия.
1. Чтобы загрузить образцы данных, на главном экране Kibana нажмите
кнопку Upload a file (Загрузить файл), как показано на рис. 4.5.

Рис. 4.5  Загрузка файла в Kibana

104  Прогнозирование
2. Выберите файл forecast_example.json на локальном компьютере. Визуализатор данных отобразит первые 1000 строк файла, чтобы вы могли
предварительно увидеть его содержимое, а также разбить различные
поля (рис. 4.6).

Рис. 4.6  Предварительный просмотр содержимого файла для загрузки

Прогнозирование одиночного временного ряда  105

3. Нажмите кнопку Import (Импорт), затем присвойте имя конечному
хранилищу для данных, которые будут загружены, как показано на
рис. 4.7.

Рис. 4.7  Присвоение имени целевому хранилищу для загрузки

4. Введите имя для целевого хранилища, убедитесь, что опция Create index pattern (Создать шаблон хранилища) отмечена, если вы загружаете
эти данные впервые, и снова нажмите кнопку Import, чтобы завершить
загрузку. Вы должны увидеть успешное завершение загрузки, как показано на рис. 4.8.
5. После загрузки данных перейдите в раздел Machine Learning (Машинное обучение) и создайте задание Anomaly Detection (Обнаружение
аномалий), выбравшаблон хранилища с названием, которое ввели на
предыдущем шаге (рис. 4.9).
6. Этот конкретный набор данных представляет собой только одну метрику временного ряда (поле с названием amount), поэтому мы просто
воспользуемся мастером Single metric (Единственная метрика) для
создания задания, как показано на рис. 4.10.
7. На следующем снимке экрана (рис. 4.11) показано, что мы будем анализировать данные только до 1 марта 2017 г. @ 00:00:00.000, чтобы
оставить возможность сравнения нашего прогноза с реальными последующими данными. Для этого сначала нажмите кнопку Use full
forecast_example data (Использовать полные данные forecast_example),
а затем вручную измените дату окончания, чтобы она соответствовала
тому, что показано на рис. 4.11.

106  Прогнозирование

Рис. 4.8  Загрузка завершена

Рис. 4.9  Сначала нужно создать задание на обнаружение аномалий

Прогнозирование одиночного временного ряда  107

Рис. 4.10  Выбор мастера Single metric для текущих данных

Рис. 4.11  Использование данных только до определенной даты

108  Прогнозирование
В этом примере представлены данные за период с 31 января 2017 года по 1 марта
2017 года. Несмотря на то что сейчас они все оказались в прошлом, мы можем сделать
вид, что находимся в этом временном интервале, и заявить, что сегодняшняя дата –
1 марта 2017 г. Поэтому нам нужно, чтобы задание машинного обучения анализировало данные между 31 января и «сегодня», а затем использовало машинное обучение
для прогнозирования этой метрики на 10 дней вперед. Позже мы увидим, насколько
точен наш прогноз относительно остальных данных. Если ваш часовой пояс Kibana
настроен на ваше местное время, даты в этой главе могут выглядеть немного иначе,
поскольку снимки экрана были сделаны с версией Kibana, настроенной на восточный
часовой пояс США (US).

Теперь нажмите кнопку Next (Далее), чтобы перейти к следующему
шагу мастера настройки.
8. После нажатия кнопки Next нам нужно будет выбрать предмет анализа в раскрывающемся списке Pick fields (Выбрать поля). Мы выберем
поле Sum (amount), потому что поле суммы представляет собой просто
числовое значение, меняющееся с течением времени (рис. 4.12).

Рис. 4.12  Выбор поля Sum (amount) в качестве предмета анализа

Прогнозирование одиночного временного ряда  109

Нажмите кнопку Next, чтобы продолжить, оставив на данный момент
другие параметры без изменения (значения по умолчанию).
9. Теперь нам нужно дать название нашему заданию по обнаружению
аномалий – в поле Job ID (Идентификатор задания) введите интуитивно понятное имя. На следующем снимке экрана было использовано
имя forecast_example (рис. 4.13).

Рис. 4.13  Назначение имени заданию по обнаружению аномалий

Вновь оставьте другие параметры по умолчанию и нажмите кнопку
Next.
10. Далее следует этап проверки, чтобы убедиться, что все правильно настроено для задания анализа, как показано на рис. 4.14.
Нажмите кнопку Next, чтобы продолжить.
11. На этом этапе работа готова к созданию, как показано на следующем
снимке экрана:

110  Прогнозирование

Рис. 4.14  Этап проверки задания

Рис. 4.15  Задание на обнаружение аномалий готово к созданию

Прогнозирование одиночного временного ряда  111

12. После нажатия кнопки Create job (Создать задание) вы увидите анимированный предварительный просмотр результатов, наложенных поверх данных, как показано на следующем снимке экрана (рис. 4.16).

Рис. 4.16  Предварительный просмотр результатов выполнения задания

Чтобы получить доступ к функции прогнозирования, нам нужно нажать кнопку View Results (Просмотр результатов), которая приведет
нас к средству просмотра единственной метрики Single Metric Viewer.
Здесь мы можем увидеть весь набор данных и оценить форму и сложность поведения этих данных; есть как дневные, так и еженедельные
периодические компоненты, а также постоянный положительный наклон (тренд), который вызывает дрейф данных с течением времени,
как изображено на рис. 4.17.

112  Прогнозирование

Рис. 4.17  Результаты с добавленными отображениями аннотаций

Если мы раскроем и изучим аннотации, то увидим, где Elastic ML обнаружил различные тенденции в данных. Несмотря на то что сейчас нас
интересует только прогнозирование на основе этих данных, задание
все равно будет указывать на аномалии в истории данных. Мы можем
просто игнорировать их, если захотим.

Прогнозирование одиночного временного ряда  113

13. Чтобы вызвать прогноз по этим данным, нажмите кнопку Forecast
(Прогноз) и в диалоговом окне введите продолжительность 10 дней
(10d), как показано на следующем снимке экрана (рис. 4.18).

Рис. 4.18  Создание нового 10-дневного прогноза
Не стоит запрашивать продолжительность прогноза, превышающую продолжительность данных, проанализированных заданием машинного обучения. Другими словами, не запрашивайте двухнедельный прогноз, если для машинного обучения применялись данные только за одну неделю. У вас должна быть как минимум равная
продолжительность обучающего и прогнозируемого периодов (в идеале период
исторических данных должен быть больше, чем период прогноза). Наконец, предоставьте модели достаточно большую последовательных данных, чтобы из нее можно
было выявить закономерности. Например, для получения качественных прогнозов
нужны минимум три цикла периодического шаблона.

После нажатия кнопки Run (Выполнить), показанной на рис. 4.18, прогноз
будет запущен в фоновом режиме. Мы можем увидеть результаты нашего
прогноза практически сразу, как показано на рис. 4.19.

114  Прогнозирование

Рис. 4.19  Результаты прогноза

Заштрихованная область вокруг прогнозируемой зоны – это 95-й процентиль доверительного интервала. Другими словами, Elastic ML рассчитал,
что существует 95%-ная вероятность того, что будущие значения попадут
в этот диапазон (и, аналогично, только 2,5%-ная вероятность того, что будущие значения будут либо выше, либо ниже доверительного интервала).
95-й процентильный диапазон в настоящее время является фиксированным
значением и не может быть установлен пользователем.
Теперь, когда у нас есть возможность создавать простые прогнозы из пользовательского интерфейса, давайте рассмотрим результаты прогноза подробнее, а затем перейдем к более сложному примеру.

просмотр результатов прогнозирования
Теперь, когда мы составили прогноз, мы можем более подробно изучить
результаты, полученные в процессе прогнозирования. Мы можем в любое
время просмотреть результаты ранее созданного прогноза в пользовательском интерфейсе одним из двух способов. Первый способ – нажать кнопку
Forecast в Single Metric Viewer, чтобы отобразить список предыдущих прогнозов (рис. 4.20).

Просмотр результатов прогнозирования  115

Рис. 4.20  Просмотр ранее созданных прогнозов в Single Metric Viewer

Кроме того, вы можете просмотреть их на странице Job Management
(Управление заданиями) на вкладке Forecasts для этого задания, как показано на следующем снимке экрана (рис. 4.21).

Рис. 4.21  Просмотр ранее созданных прогнозов на странице управления заданиями
Срок хранения прогнозов, построенных в Kibana, по умолчанию составляет 14 дней.
После этого результаты прогноза удаляются безвозвратно. Если требуется другой
срок хранения, прогноз необходимо будет вызвать через конечную точку API _forecast, что мы обсудим позже; документацию по этому вопросу можно найти по адресу
https://www.elastic.co/guide/en/elasticsearch/reference/current/ml-forecast.html.

116  Прогнозирование
При просмотре результатов прогноза в Single Metric Viewer обратите
внимание на то, что при наведении указателя мыши на точки данных прогноза во всплывающем окне будут перечислены три ключевых элемента информации о точке данных – значение прогноза, значение верхней границы
и значение нижней границы, как показано на рис. 4.22.

Рис. 4.22  Информация, отображаемая во всплывающем окне прогноза

Напомним, что верхняя и нижняя границы определяют диапазон доверительной вероятности 95-го процентиля. Значение прогноза – это значение
с наибольшим правдоподобием (вероятностью). Эти три ключевых значения
хранятся в хранилищах результатов .ml-anomalies-* со следующими именами:
 forecast_prediction;
 forecast_upper;
 forecast_lower.

Просмотр результатов прогнозирования  117

В главе 5 вы узнаете, как обратиться к хранилищам .ml-anomalies-*, чтобы
найти информацию, относящуюся к прогнозам, и как использовать эту информацию для других целей, например для информационных панелей или
предупреждений.
Если вы хотите увидеть, насколько хорошо прогноз Elastic ML совпадает
с фактическими данными на следующие 10 дней (модели задания ML еще
не видели те дни), вы можете вернуться на страницу управления заданиями,
загрузить задание, чтобы продолжить его, и проанализировать оставшиеся
данные. Для этого щелкните ссылку Start datafeed (Запустить поток данных)
в меню с правой стороны, как показано на рис. 4.23.

Рис. 4.23  Запуск потока данных со страницы управления заданиями

После появления диалогового окна установите в поле Search start time
(Время начала поиска) значение Continue from 2017-03-01 00:00:00 (Продолжить с 01.03.2017 00:00:00, или со времени, соответствующего вашему
местному часовому поясу) и укажите в поле Search end time (Время окончания поиска) 11 марта 2017 в 12:00, как показано на рис. 4.24.
После этого вернитесь в Single Metric Viewer для задания, убедитесь, что
вы просматриваете правильный диапазон времени с помощью средства выбора времени Kibana, и нажмите кнопку Forecast, чтобы просмотреть ранее
созданный прогноз, как описано выше в этой главе. Теперь вы сможете увидеть значения прогноза, наложенные на фактические значения данных, как
показано на рис. 4.25.

118  Прогнозирование

Рис. 4.24  Продолжение анализа потока данных с места остановки

Рис. 4.25  Сравнение прогноза с фактическими данными

Прогнозирование нескольких временных рядов  119

Как мы и говорили в начале этой главы, наблюдается небольшое расхождение между прогнозом Elastic ML и фактическими значениями данных.
Это связано с тем, что прогнозы являются вероятностными, а вероятность
влечет за собой определенный уровень неопределенности. Однако это не
умаляет полезности прогнозов. Благодаря возможности упреждающего уведомления (глава 6) мы могли бы быть предупреждены об опасности взлома.
Упреждающее уведомление особенно полезно, когда пользователи не могут
отслеживать сотни или тысячи объектов по отдельности. В следующем разделе вы увидите, как прогнозирование нескольких метрик позволяет нам
автоматически отслеживать эти объекты.

прогнозирование нескольких временных ряДов
Чтобы выполнить прогнозирование для нескольких временных рядов, вам
просто понадобится задание машинного обучения, которое моделирует несколько временных рядов. Предположим, что у нас есть задание машинного
обучения, которое проанализировало веб-запросы по странам. Используя
встроенные учебные образцы веб-журналов (kibana_sample_data_logs), которые мы применяли в главе 3, вы можете легко создать задание с несколькими
метриками, которое подсчитывает события, разделенные по коду страны, из
которой поступил запрос (поле называется geo.src), как показано на рис. 4.26.
В этом наборе данных 183 уникальные страны. После создания и выполнения задания по обнаружению аномалий, которое построит базовые модели
для всех 183 стран, вы можете вызвать прогноз. Если мы применим к вызову
прогноза тот же подход, что и раньше (через Single Metric Viewer), мы можем
ошибочно подумать, что прогноз будет выполнен только для отображаемого
ряда, как показано на следующем снимке экрана (рис. 4.27).
На предыдущем снимке экрана (рис. 4.26) мы видим, что код страны, выбранный для geo.src, – это CN (Китай). Но, как указано в предупреждающем
сообщении всплывающего окна Forecasting (Прогнозирование), нажатие
кнопки Run запустит прогноз, который будет выполняться для всех разделов, присутствующих в задании (в данном случае мы знаем, что существует
более 100 разделов).

Powered by TCPDF (www.tcpdf.org)

120  Прогнозирование

Рис. 4.26  Создание задания с несколькими метриками для прогнозирования

Рис. 4.27  Вызов многомерного прогноза из Single Metric Viewer

Прогнозирование нескольких временных рядов  121

В качестве альтернативы для вызова прогноза мы можем использовать
конечную точку API _forecast. Для этого в консоли Dev Tools (Инструменты
разработчика) можно отправить следующий запрос:
POST _ml/anomaly_detectors/web_traffic_per_country/_forecast
{
"duration": "1d"
}
Задание обнаружения состояний должно быть в «открытом» состоянии, прежде чем
вы сможете вызывать прогноз через API.

Ответ на вызов API выглядит следующим образом:
{
"acknowledged" : true,
"forecast_id" : " sm7AF3cBpc7Wt6MbTWYg"
}

Результаты запрошенного нами прогноза будут доступны для просмотра
либо в Single Metric Viewer, либо программно путем запроса к хранилищу
результатов, как это описано в главе 5. С помощью Single Metric Viewer мы
можем увидеть прогноз для любой страны, нажав кнопку Forecast, выбрав наш
предыдущий прогноз, а затем выбрав код страны, как показано на рис. 4.28.

Рис. 4.28  Просмотр прогноза для отдельного раздела
в составе общего прогноза по нескольким временным рядам

122  Прогнозирование
Просмотр результатов многомерного прогноза в Single Metric Viewer не вполне
совершенен, если речь идет о версии 7.10. Это связано с тем, что в представлении
отображаются только те разделы, для которых записаны аномалии. Эта функция была
добавлена в версии 7.11.

Прогнозирование по нескольким временным рядам может быть чрезвычайно полезным в сценариях планирования мощности, когда необходимо
проанализировать сотни или, возможно, тысячи объектов и составить прогноз, чтобы увидеть, возможны ли какие-либо проблемы в ближайшем будущем.

заключение
Помимо обнаружения аномалий, у Elastic ML есть дополнительная функция:
способность экстраполировать модели временных рядов в будущее для целей
прогнозирования. Если применить эту функцию в сценариях, подразумевающих расширенное обнаружение вторжений и планирование нагрузочной
емкости, она снимает с нас бремя ручного построения графиков, отслеживания и прогнозирования будущих событий в зависимости от того, как объекты
наблюдения вели себя в прошлом.
В следующей главе вы более детально изучите толкование результатов,
полученных в результате обнаружения аномалий и прогнозирования, а также научитесь использовать эти результаты для информационных панелей
и упреждающих предупреждений.

Глава

5
Интерпретация
результатов

Как вы видели в предыдущих главах, Elastic ML способен выполнять чрезвычайно полезный анализ как для обнаружения аномалий, так и для прогнозирования. Но тем не менее до этого момента мы лишь относительно
поверхностно рассматривали результаты, полученные с помощью Elastic ML.
В этой главе вы более детально исследуете получаемые результаты, узнаете,
как они хранятся и как их можно использовать для получения дополнительной информации.
В частности, в этой главе будут рассмотрены следующие темы:








просмотр хранилища результатов Elastic ML;
оценка аномалий;
подробнее о схеме хранилища результатов;
аномалии в нескольких сегментах;
результаты прогноза;
API результатов Elastic ML;
пользовательские панели мониторинга и рабочие панели Canvas.

технические требования
Информация в этой главе основана на использовании Elastic Stack версии 7.10.

просмотр хранилища результатов ElasTIc Ml
Поскольку значительную часть этой главы мы посвятим тому, как пользователи должны интерпретировать результаты заданий обнаружения аномалий
Elastic ML, будет полезно изучить связь между передаваемой информацией
и ее представлением для хранения во внутреннем хранилище результатов
Elastic ML. Чтобы быстро получить представление об этом хранилище, вы
можете либо обратиться к нему по шаблону напрямую, используя API _search
в Elasticsearch, либо, что более интуитивно понятно, добавить шаблон хра-

124  Интерпретация результатов
нилища в Kibana и просмотреть его с помощью собственных инструментов
Kibana. Но сначала вы должны выполнить небольшую процедуру, чтобы предоставить Kibana доступ к внутреннему хранилищу результатов Elastic ML.
1. В Kibana щелкните боковое меню и выберите в списке Stack Management (Управление стеком), как на рис. 5.1.

Рис. 5.1  Выбор опции Управление стеком

2. Выберите Index Patterns (Шаблоны хранилища) (рис. 5.2).

Рис. 5.2  Выбор опции Шаблоны хранилища

Просмотр хранилища результатов Elastic ML  125

3. Выберите Create index pattern (Создать шаблон хранилища) (рис. 5.3).

Рис. 5.3  Выбор кнопки Создать шаблон хранилища

4. Введите .ml-anomalies-* в поле Index pattern name (Имя шаблона хранилища), а потом включите переключатель Include system and hidden
indices (Включая системные и скрытые хранилища). Затем нажмите
кнопку Next step (Следующий шаг) (рис. 5.4).

Рис. 5.4  Присвоение имени шаблону хранилища

5. Выберите опцию timestamp в поле Time field (Поле времени) и нажмите
кнопку Create index pattern (Создать шаблон хранилища) (рис. 5.5).

126  Интерпретация результатов

Рис. 5.5  Определение поля времени

6. Убедитесь, что шаблон хранилища определен (рис. 5.6).

Рис. 5.6  Подтверждение того, что шаблон хранилища определен

Просмотр хранилища результатов Elastic ML  127

Теперь, когда шаблон хранилища.ml-anomalies-* определен, вы можете
использовать Kibana Discover для изучения содержимого хранилища результатов (выберите Discover в главном меню Kibana, как показано на рис. 5.7).

Рис. 5.7  Просмотр хранилища результатов в Kibana Discover

Получив доступ к просмотру хранилища результатов в Kibana Discover,
вы можете использовать возможности поиска и фильтрации Discover, чтобы
исследовать результаты. Например, вы можете запросить все аномалии на
уровне записи для определенного имени задания по обнаружению аномалий,
где оценка аномалии записи превышает определенное значение (рис. 5.8).
Синтаксис этого запроса на языке KQL (Kibana Query Language) выглядит
следующим образом:
job_id:"web_traffic_per_country" and result_type:"record" and record_score>90

Здесь мы видим два конкретных вхождения, соответствующих нашему запросу. В хранилище результатов содержится множество информации, и вы
будете последовательно учиться расшифровывать большую часть этой информации на протяжении всей главы.
Хотя просматривать и запрашивать результаты в шаблоне хранилища .ml-anomalies-*
безопасно, вы должны помнить, что хранилища, соответствующие этому шаблону, являются системными хранилищами, и не следует пытаться вручную изменить или удалить содержимое этих хранилищ.

128  Интерпретация результатов

Рис. 5.8  Использование Kibana Discover для поиска и фильтрации аномалий

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

оценка аномалий
Интерпретация результатов заданий по обнаружению аномалий в Elastic ML
в первую очередь требует от вас понимания того факта, что существует несколько уровней оценок степени необычности, выраженных в результатах.
Вот они:
 уровень сегмента (result_type:bucket): на этом уровне суммируются
результаты всего задания по обнаружению аномалий за определенный
сегмент времени. По сути, это информация о том, насколько необычен
этот сегмент времени с учетом конфигурации вашего задания;
 уровень фактора влияния (result_type:influencer): используется для
лучшего понимания природы наиболее необычных объектов (факторов
влияния) в течение определенного промежутка времени;
 уровень записи (result_type:record): это наиболее подробная информация о каждом аномальном происшествии или аномальном объекте
в сегменте времени. В зависимости от конфигурации задания (несколько детекторов, разбиения и т. д.) за сегмент времени может накопиться
много документов уровня записи.

Оценка аномалий  129

Кроме того, чтобы разобраться, как выполняется оценка, вам также необходимо хорошо усвоить следующие понятия:
 нормализация – приведение оценки аномальности к фиксированной
шкале от 0 до 100;
 факторы влияния – сущности, которые вызывают образование аномалий своим весомым вкладом в набор данных в момент возникновения аномалии.
Далее мы более подробно рассмотрим каждую из пяти вышеупомянутых
концепций.

Оценка на уровне сегмента
Оценка аномалии на уровне сегмента сродни ответу на вопрос: «Насколько
необычным был этот интервал времени по сравнению со всеми другими
интервалами времени для этого задания?», где этот интервал определяется
параметром bucket_span задания обнаружения аномалий. Если в вашем задании есть несколько детекторов или разбиений, результатом которых может быть несколько объектов одновременно, то каждый результат на уровне
сегмента является агрегированным представлением всех этих вещей. Оценку
аномалий на уровне сегмента можно просмотреть несколькими способами,
первым из которых является обзорная полоса (Overall) вверху пользовательского интерфейса Anomaly Explorer (рис. 5.9).

Рис. 5.9  Обзорная полоса Overall в Anomaly Explorer

130  Интерпретация результатов
На рисунке видно, что полоса Overall раскрашена в различные цвета –
оценки значимости, причем конкретная выделенная плитка показывает
максимальный балл аномалии (Max anomaly score), равный 88. Здесь важно отметить, что временной диапазон, показанный в этом представлении,
включает данные с 6 января по 5 февраля; поэтому на обзорной полосе по
горизонтали расположено около 30 «плиток», каждая из которых представляет один день. Задание по обнаружению аномалий было настроено на 15 минут, поэтому на каждой плитке отображается максимальная оценка за весь
день. Если вы увеличите масштаб отображения до одного дня, используя
средство выбора времени Kibana (элемент управления диапазоном даты/
времени в правом верхнем углу экрана), то увидите больше деталей, в частности аномалии на уровне сегмента времени, которые наблюдались между
02:00 и 02:30 (рис. 5.10).

Рис. 5.10  Обзорная полоса в Anomaly Explorer
после увеличения детализации

Здесь также важно отметить, как общая обзорная полоса связана (или не
связана) с сеткой полос под ней. Эта сетка полос показывает оценку на уровне фактора влияния (обсуждается в следующем разделе) и поэтому не имеет
прямого отношения к оценке на уровне сегмента. Многие люди заблуждаются, когда думают, что общая обзорная полоса – это некая комбинация
(например, максимальная оценка) элементов из сетки под ней. На рис. 5.10
вы можете видеть, что это явно не так, поскольку группа оценок на уровне
фактора влияния во второй строке сетки (около 07:00) не имеет соответствующей оценки на общем уровне (сегменте). Почему так? Если коротко, дело
в том, что общая полоса представляет собой сравнение сегментов времени
друг с другом. Следовательно, самые необычные периоды времени получают
самые высокие оценки, а периоды времени, которые намного менее необычны (из-за количества и серьезности отдельных аномалий в пределах этого
периода времени), получают меньшие оценки или даже не получают оценок
вообще. Процесс определения этой относительной оценки называется нор-

Оценка аномалий  131

мализацией. Это важная часть оценки на всех уровнях, и она заслуживает
отдельного объяснения.

Нормализация
Как впервые было сказано в главе 1, необработанные значения вероятности
для конкретных аномалий нормализуются по шкале от 0 до 100. Этот процесс позволяет проводить относительное ранжирование аномалий, а также
сводить значения к фиксированному интервалу значений, что удобно при
оценке значимости в целях сортировки и/или оповещения.
Ключевым аспектом здесь является понятие относительного ранжирования. Другими словами, нормализованные значения учитывают ненормальности, которые уже были замечены заданием по обнаружению аномалий,
и соответственно ранжируют их. Это также означает, что ранее присвоенные
нормализованные оценки могут изменяться со временем по мере обнаружения новых аномалий. Поэтому вы можете заметить, что оценки в хранилище
результатов имеют как «начальное», так и текущее значение, например:
 initial_anomaly_score: начальная оценка аномалии на уровне сегмента,
которая была записана во время регистрации аномалии;
 anomaly_score: текущая нормализованная оценка аномалии на уровне
сегмента.
Эти два значения могут быть одинаковыми, но могут и начать различаться
со временем. Начальная оценка – это фиксированное значение, но текущая
оценка может быть скорректирована по мере того, как со временем будут
встречаться более выраженные аномалии. Процесс нормализации происходит каждые несколько часов во время работы в реальном времени или
спонтанно, если аналитика обнаруживает резкие изменения в таблице нормализации. Это также происходит, если задание по обнаружению аномалий
закрыто (переводится в закрытое состояние). Нормализация может заново
оценить аномалии в прошлом, независимо от того, как настроен параметр
renormalization_window_days (30 дней, или 100 сегментов времени, – это значение по умолчанию, и это значение можно изменить только в том случае, если
задание создается с помощью API или мастера расширенных заданий путем
прямого изменения файла JSON, содержащего конфигурацию задания).

Оценка на уровне фактора влияния
Оценка аномалии на уровне фактора влияния сродни ответу на вопрос «Какие сущности самые необычные в этот момент времени?», где мы теперь
сравниваем эти сущности друг с другом. Оценки на уровне факторов влияния
можно просмотреть двумя способами: первый – это основная сетка обзорных
полос в центре пользовательского интерфейса Anomaly Explorer, а второй –
это список Top influencers (Наиболее влиятельные факторы) в левой части
(рис. 5.11).

132  Интерпретация результатов

Рис. 5.11  Представление факторов влияния в Anomaly Explorer

Здесь мы видим, что в основной сетке обзорных полос коды стран поля
geo.src перечислены в порядке уменьшения общего балла фактора влияния.
Обратите внимание, что, несмотря на то что сетка настроена на отображение 10 строк на странице, в списке указаны только шесть кодов стран (за
этот период больше не нашлось стран, для которых есть значимые оценки
факторов влияния). Кроме того, наиболее значимые факторы влияния перечислены в левой части, показывая для каждой сущности как максимальную
оценку фактора влияния (99 для geo.src:IN), так и сумму всех оценок факторов влияния для этого временного диапазона (223 для geo.src:IN). В данном
случае, поскольку для этого задания определен только один фактор влияния,
эта информация может показаться избыточной. Однако для многих заданий
определено более одного фактора влияния, поэтому в этом случае представление становится более разумным. Например, если мы посмотрим на
задание анализа популяции по хранилищу kibana_sample_data_logs, в котором
мы выбираем distinct_count("url.keyword") over clientip в качестве детектора
и выбираем как clientip, так и response.keyword в качестве факторов влияния,
представление Anomaly Explorer может выглядеть как на рис. 5.12.
Обратите внимание, что в поле View by (Просмотр по…) выбрано значение
clientip, но в списке Top influencers слева показаны оба списка.
Anomaly Explorer является интерактивным, поэтому, если мы выберем
плитку критической аномалии на общей обзорной строке на день 19 февраля,
сетка и списки факторов влияния изменятся в связи с неявным применением
фильтра для этого периода (рис. 5.13).
Теперь мы видим только соответствующие точки для выбранного дня.
Получив некоторое представление о том, что такое факторы влияния, вы
можете спросить: какие поля являются хорошими кандидатами на роль факторов влияния, если они могут быть представлены таким образом? Давайте
сделаем небольшое отступление и рассмотрим понятие фактора влияния
более подробно.

Оценка аномалий  133

Рис. 5.12  Несколько факторов влияния в Anomaly Explorer

Рис. 5.13  Anomaly Explorer с фильтром за определенный день

Факторы влияния
В конфигурации задания обнаружения аномалий есть возможность объявить
определенные поля факторами влияния. По сути, фактор влияния – это поле,
описывающее некую сущность, относительно которой вы хотели бы знать,
виновата ли она в существовании аномалии или, по крайней мере, внесла ли
она значительный вклад. Обратите внимание, что любое поле, выбранное
в качестве кандидата на роль фактора влияния, не обязательно должно быть
частью логики детектора, хотя имеет смысл в качестве факторов влияния
выбирать поля, которые используются как разбиения или популяции.

134  Интерпретация результатов
Если мы вернемся к примеру, показанному на рис. 5.13, то увидим, что
поля clientip и response.keyword были объявлены как факторы влияния для
задания (где clientip был частью конфигурации детектора, а response.keyword – нет). IP-адрес клиента 30.156.16.164 определен как главный фактор
влияния. Это определение кажется несколько излишним, потому что данный IP-адрес и так является аномалией, но это ожидаемая ситуация, когда
факторы влияния выбираются среди полей, которые определяют совокупность или являются полями разделения. Другой главный фактор влияния
(response.keyword) имеет значение 404. Эта конкретная информация чрезвычайно важна, поскольку дает пользователю прямую подсказку о том, что IPадрес 30.156.16.164 делал во время аномалии. Если мы исследуем поведение
IP-адреса во время аномалии, то увидим, что 100 % сделанных запросов
привели к ответу с кодом 404 (рис. 5.14).

Рис. 5.14  Значение 404 поля фактора влияния
значительно преобладает над другими результатами в период аномалии

Поэтому значение 404 имеет высокий балл в качестве фактора влияния (50,
как показано на рис. 5.13). Вы можете подумать, что, поскольку 100 % запросов
привели к ответу 404, оценка фактора влияния также должна быть равна 100,
но все не так просто. Оценки факторов влияния нормализованы относительно
оценок других факторов влияния, и оценка также выражает, насколько необычным было значение 404 в остальное время. В этом конкретном примере
набора данных встречаются еще сотни случаев ответа 404, но большинство
из них не были связаны с аномалиями. Наличие большого количества других
таких же значений ограничивает оценку фактора влияния. Возможно, найдутся веские аргументы в пользу разделения концепций – одна оценка выражает необычность объекта на интервале времени, а другая оценка отражает

Оценка аномалий  135

степень влияния значения поля на конкретную аномалию, – но на данный
момент эти понятия формируют совместный рейтинг факторов влияния.
Также важно понимать, что процесс поиска потенциальных факторов
влияния происходит уже после того, как Elastic ML обнаруживает аномалию.
Другими словами, это не влияет на вычисления вероятности, выполняемые
в рамках обнаружения. После определения аномалии ML будет систематически просматривать все экземпляры каждого поля, претендующего на роль
фактора влияния, и удалять вклад этого экземпляра в данные в этом временном сегменте. Если после удаления оставшиеся данные больше не являются
аномальными, то, исходя из контрфактических рассуждений, вклад этого
экземпляра должен быть влиятельным и оценивается соответствующим образом (с помощью influencer_score в результатах).
Факторы влияния могут стать очень мощным инструментом, который
можно использовать при просмотре результатов не только одного задания
машинного обучения, но, возможно, нескольких связанных заданий. В главе 7 вы увидите, как эффективно использовать факторы влияния в анализе
первопричин.

Оценка на уровне записи
Оценка аномалии на уровне записи – это самый низкий уровень абстракции
результатов, содержащий наибольшее количество деталей. В пользовательском интерфейсе Anomaly Explorer результаты на уровне записи показаны
в таблице внизу (рис. 5.15).

Рис. 5.15  Таблица аномалий, показывающая результаты на уровне записи

136  Интерпретация результатов
Обратите внимание, что если переключатель Interval (Интервал) установлен в положение Auto (Авто), то любые аномалии, которые следуют подряд,
будут свернуты, и будет отображаться только аномалия с наивысшим баллом.
Если в поле Interval установить значение Show all (Показать все), то при
желании можно будет выявить каждую отдельную аномалию.
Распространенное заблуждение состоит в том, что оценка аномалии на
уровне записи напрямую связана с отклонением, указанным в столбце description (описание) пользовательского интерфейса (здесь в 41 раз выше).
Оценка определяется исключительно расчетом вероятности с использованием того же процесса нормализации, который был описан ранее. Поле description и даже значение typical – это упрощенные фрагменты контекстной
информации, облегчающие понимание аномалии. Фактически, как вы увидите позже, поле description не сохраняется в хранилище результатов – оно
вычисляется только на лету в Kibana.
Глядя на эти записи аномалий разного уровня в хранилище .ml-anomalies-*,
мы видим, что многие поля предназначены для нашего использования. Некоторые могут быть очевидными, а некоторые нет. В следующем разделе мы
тщательно рассмотрим схему хранилища результатов и опишем значение
важных полей.

описание схемы хранилища результатов
Как мы уже отмечали, внутри хранилища результатов есть множество различных документов, каждый из которых имеет свою полезность с точки зрения понимания результатов заданий по обнаружению аномалий. Здесь мы
обсудим те из них, которые непосредственно относятся к трем уровням абстракции, представленным ранее в этой главе. Они вполне логично названы
следующим образом:
 result_type:bucket – для получения результатов на уровне сегмента;
 result_type:record – для получения результатов на уровне записи;
 result_type:influencer – для получения результатов на уровне фактора
влияния.
Распределение документов по типам будет зависеть от конфигурации задания машинного обучения и характеристик анализируемого набора данных.
Принципы формирования документов по типам выглядят следующим образом:
 result_type:bucket – на каждый сегмент времени записывается один
документ. Другими словами, если период сегментации составляет
15 минут, то один документ этого типа будет записываться каждые
15 минут. Его метка времени будет равна переднему краю сегмента.
Например, для периода времени, охватывающего диапазон от 11:30
до 11:45, в итоговом документе этого типа будет метка времени 11:30;
 result_type:record – один документ записывается для каждого случая
аномалии в пределах сегмента времени. Следовательно, если мы имеем
дело с большим набором данных, охватывающим множество объектов
(IP-адреса, имена хостов и т. д.), то во время крупного аномального со-

Описание схемы хранилища результатов  137

бытия или широко распространившегося сбоя в некоторых сегментах
времени могут быть сгенерированы сотни или даже тысячи записей об
аномалиях. Этот документ также будет иметь метку времени, равную
переднему краю сегмента;
 result_type:influencer – один документ для каждого фактора влияния,
найденного для каждой записи об аномалии. Поскольку для каждой
записи об аномалии потенциально может быть найдено несколько факторов влияния разных типов, эта разновидность документа может быть
даже более объемной, чем результаты уровня записи. Этот документ
также будет иметь метку времени, равную переднему краю сегмента.
Иметь представление о полях в этих документах будет особенно важно,
когда мы перейдем к главе 6, рассказывающей об оповещениях, потому что
неизбежно придется искать компромисс между детализацией оповещений
(обычно чем больше, тем лучше) и количеством отдельных оповещений
в единицу времени (обычно чем меньше, тем лучше). Мы вернемся к этому
вопросу, когда начнем разрабатывать настоящие оповещения.

Результаты на уровне сегмента
На самом высоком уровне абстракции находятся результаты на уровне сегмента. Помните, что это агрегированные результаты для всего задания как
функции времени, и, по сути, они отвечают на вопрос: «Насколько необычным был этот сегмент времени?»
Рассмотрим пример документа в хранилище .ml-anomalies-*, используя
Kibana Discover и выполнив следующий запрос на языке KQL:
result_type :"bucket" and anomaly_score >98

Ответ на запрос представлен на рис. 5.16.

Рис. 5.16  Документ с результатами на уровне сегмента,
показанный в Kibana Discover

138  Интерпретация результатов
Нажав на значок > рядом с меткой времени документа (рис. 5.16), вы развернете документ для просмотра во всех подробностях (рис. 5.17).

Рис. 5.17  Детали документа на уровне сегмента в Kibana Discover

Вы можете видеть, что из нашего запроса на рис. 5.16 был возвращен только
один документ уровня сегмента, соответствующий единственному аномальному периоду времени (с меткой времени 1613824200000 или в моем часовом
поясе, 20 февраля 2021 года, 07:30:00 AM GMT–05:00), у которого anomaly_score
превышает 98. Другими словами, не было других сегментов времени с такими
большими аномалиями. Рассмотрим подробнее ключевые поля:
 timestamp – метка времени начала сегмента. В Kibana это поле будет по
умолчанию отображаться в вашем местном часовом поясе (хотя оно
сохраняется в хранилище в формате эпох с часовым поясом UTC);

Описание схемы хранилища результатов  139

 anomaly_score – текущая нормализованная оценка сегмента, основанная на диапазоне вероятностей, наблюдаемых для всего задания. Значение этой оценки может меняться со временем, поскольку новые
данные обрабатываются заданием и могут быть обнаружены новые
аномалии;
 initial_anomaly_score – начальная нормализованная оценка сегмента,
то есть присвоенная, когда этот сегмент был впервые проанализирован. Эта оценка, в отличие от anomaly_score, не изменится по мере анализа большего количества данных;
 event_count – количество необработанных документов Elasticsearch,
просмотренных алгоритмами машинного обучения в течение сегмента времени;
 is_interim – флаг, который показывает, завершен ли сегмент или он все
еще ожидает получения всех данных в диапазоне сегмента. Это поле
актуально для текущих заданий, выполняемых в режиме реального
времени. Для некоторых типов анализа могут быть доступны промежуточные результаты, даже если не все данные сегмента были просмотрены;
 job_id – имя задания по обнаружению аномалий, создавшего этот результат;
 processing_time_ms – внутренний показатель производительности, показывающий, сколько времени (в миллисекундах) потребовалось для
обработки данных этого сегмента;
 bucket_influencers – массив факторов влияния (и подробная информация о них), которые были найдены для этого текущего сегмента.
Даже если факторы влияния не были выбраны как часть конфигурации задания или они не были выбраны как часть анализа, всегда будет
существовать фактор влияния по умолчанию типа influencer_field_
name:bucket_time, который в основном является внутренним устройством хранения записей, позволяющим упорядочивать аномалии на
уровне сегмента в случаях, когда явные факторы влияния не могут
быть определены.
Если у задания есть именованные и идентифицированные факторы влияния, то массив bucket_influencers может выглядеть так, как показано на
рис. 5.17.
Обратите внимание, что в дополнение к записи по умолчанию для типа
influencer_field_name: bucket_time в этом случае есть запись для имени поля
geo.src, определенного анализом как фактор влияния. Это свидетельствует
о том, что geo.src был релевантным фактором влияния, обнаруженным во
время этой аномалии. Поскольку в конфигурации задания может быть выбрано несколько кандидатов на звание фактора влияния, следует отметить,
что в данном случае geo.src является единственным полем фактора влияния,
и никакие другие поля не были признаны влиятельными. Также следует отметить, что на этом уровне детализации конкретный экземпляр geo.src не
раскрывается; эта информация будет раскрыта при запросах на более низких
уровнях абстракции, которые мы обсудим далее.

Powered by TCPDF (www.tcpdf.org)

140  Интерпретация результатов

Результаты на уровне записи
На более низком уровне абстракции располагаются результаты на уровне
записи. Предоставляя как можно больше деталей, результаты на уровне записи показывают конкретные случаи аномалий и, по сути, отвечают на вопрос:
«Какая сущность была необычной и насколько?»
Рассмотрим пример документа в хранилище .ml-anomalies-*, используя
Kibana Discover и выполнив следующий запрос KQL:
result_type :"record" and record_score >98

Результат будет выглядеть приблизительно так, как показано на рис. 5.18.

Рис. 5.18  Документ с результатами на уровне записи,
показанный в Kibana Discover

Нажав на значок > рядом с меткой времени документа (рис. 5.18), вы развернете документ для просмотра во всех подробностях (рис. 5.19).
Вы можете видеть на рис. 5.18, что нашим запросом были возвращены несколько документов уровня записи. Рассмотрим подробнее ключевые поля:
 timestamp – метка времени начала сегмента, внутри которого произошла эта аномалия;
 job_id – имя задания по обнаружению аномалий, создавшего этот результат;
 record_score – текущая нормализованная оценка записи об аномалии,
основанная на диапазоне вероятностей, наблюдаемых для всего задания. Значение этой оценки может меняться со временем, поскольку
новые данные обрабатываются заданием и могут быть обнаружены
новые аномалии;

Описание схемы хранилища результатов  141

Рис. 5.19  Детали документа на уровне записи в Kibana Discover

 initial_record_score – начальная нормализованная оценка записи об
аномалии, то есть когда этот сегмент был впервые проанализирован.
Эта оценка, в отличие от record_score, не изменится по мере анализа
большего количества данных;
 detector_index – внутренний счетчик для отслеживания конфигурации
детектора, к которой принадлежит эта аномалия. Очевидно, что для
задания с одним детектором это значение будет равно нулю, но оно
может быть ненулевым в заданиях с несколькими детекторами;
 function – ссылка для отслеживания того, какая функция детектора использовалась для создания этой аномалии;
 is_interim – флаг, который показывает, завершен ли сегмент или он все
еще ожидает получения всех данных в пределах диапазона сегмента.
Это поле актуально для текущих заданий, выполняемых в режиме реального времени. Для некоторых типов анализа могут быть доступны
промежуточные результаты, даже если не все данные сегмента были
просмотрены;

142  Интерпретация результатов
 actual – фактическое наблюдаемое значение проанализированных
данных в этом сегменте. Например, если функцией является count, то
она представляет количество документов, которые встречаются (и подсчитываются) в этом сегменте;
 typical – представление ожидаемого или прогнозируемогозначения на
основе модели машинного обучения для этого набора данных;
 multi_bucket_impact – значение по шкале от –5 до +5, которое определяет,
насколько эта конкретная аномалия зависела от влияния вторичного
анализа нескольких сегментов (поясняется позже в этой главе), от отсутствия влияния (–5) до полного влияния (+5);
 influencers – массив факторов влияния (и значения этих факторов),
имеющих отношение к данной записи об аномалии.
Если в задании определены разделения (с именем by_field_name и/или partition_field_name) и найдены факторы влияния, то в документах результатов уровня записи будет больше информации, например как показано на
рис. 5.19:
 partition_field_name – признак того, что было определено поле раздела
и что для одного из значений поля раздела была обнаружена аномалия;
 partition_field_value – значение поля раздела, для которого возникла
эта аномалия. Другими словами, имя сущности, для которой была обнаружена эта аномалия.
В дополнение к упомянутым здесь полям (которые имели бы вид by_field_
name и by_field_value, если бы задание было настроено на использование поля
by) мы также видим явный экземпляр поля geo.src. Это просто ярлык – каждый раздел by или over_field_value в результатах также будет иметь прямое
имя поля.
Если ваше задание представляет собой популяционный анализ (с использованием over_field_name), то документ с результатами на уровне записи
будет организован несколько иначе, так как отчет формируется с ориентацией на необычных членов совокупности. Например, если мы посмотрим
на задание популяционного анализа по хранилищу kibana_sample_data_logs,
в котором мы выбираем distinct_count("url.keyword") over clientip в качестве
детектора, то пример документа с результатами на уровне записи также будет содержать массив причин (рис. 5.20).
Массив причин создан для компактного выражения всех аномальных действий, которые конкретный IP совершил в этом сегменте. Опять же, многие
данные кажутся избыточными, но в первую очередь потому, что могут существовать разные способы агрегирования информации для представления
результатов на информационных панелях или в оповещениях.
Кроме того, в случае этого популяционного анализа мы видим, что массив
факторов влияния содержит как поле clientip, так и поле response.keyword
(рис. 5.21).
Завершим наш обзор схемы хранилища результатов рассмотрением результатов на уровне факторов влияния.

Описание схемы хранилища результатов  143

Рис. 5.20  Документ на уровне записи,
представляющий массив причин для задания популяционного анализа

Рис. 5.21  Документ на уровне записи,
представляющий массив факторов влияния для задания популяционного анализа

Результаты на уровне факторов влияния
Еще один объектив, через который можно взглянуть на результаты, – это факторы влияния. Просмотр результатов с этой точки зрения позволяет ответить
на вопрос: «Какие сущности были самыми необычными в моем задании машинного обучения, и когда они были необычными?» Чтобы познакомиться
со структурой и содержанием результатов на уровне факторов влияния, рассмотрим пример документа в хранилище .ml-anomalies-*, используя Kibana
Discover и выполнив следующий запрос KQL:
result_type :"influencer" and response.keyword:404

Обратите внимание, что в этом случае мы запросили не оценку (influencer_score), а ожидаемое имя и значение объекта. Последний документ в списке (со значением influencer_score, равным 50,174) соответствует тому, что мы
видели на рис. 5.13.

144  Интерпретация результатов

Рис. 5.22  Документ с результатами на уровне факторов влияния,
показанный в Kibana Discover

Рассмотрим ключевые поля:
 timestamp – метка времени начала сегмента, внутри которого произошла аномальная активность, связанная с этим фактором влияния;
 job_id – имя задания по обнаружению аномалий, создавшего этот результат;
 influencer_field_name – имя поля, которое было объявлено как фактор
влияния в конфигурации задания;
 influencer_field_value – значение поля фактора влияния, для которого
актуален этот результат;
 influencer_score – текущая нормализованная оценка того, насколько
необычным и значащим был фактор влияния для аномалии на данном
этапе;
 initial_influencer_score – начальная нормализованная оценка фактора
влияния, когда этот сегмент был впервые проанализирован. Эта оценка, в отличие от оценки influencer_score, не изменится по мере анализа
большего количества данных;
 is_interim – флаг, который показывает, завершен ли сегмент или он все
еще ожидает получения всех данных в диапазоне сегмента. Это поле

Аномалии в нескольких сегментах  145

актуально для текущих заданий, выполняемых в режиме реального
времени. Для некоторых типов анализа могут быть доступны промежуточные результаты, даже если не все данные сегмента были просмотрены.
Теперь, когда в деталях рассмотрели соответствующие поля, доступные
пользователю, мы можем сохранить эту информацию в архиве для создания
пользовательских панелей мониторинга, визуализаций и сложных оповещений, чем мы и займемся в следующих главах. Но прежде чем мы закончим эту
главу, вам еще предстоит изучить несколько важных концепций. Далее следует обсуждение особого вида аномалии – аномалии в нескольких сегментах.

аномалии в нескольких сегментах
Почти все известные вам на данный момент аномалии, генерируемые заданиями по обнаружению аномалий Elastic ML, возникали в определенное
время, квантованное с интервалом bucket_span. Тем не менее у вас, безусловно, могут возникнуть ситуации, в которых конкретное наблюдение в пределах одного сегмента может быть не таким уж необычным, но расширенное
временное окно, охватывающее несколько сегментов, может оказаться значительно более необычным, чем любое отдельное наблюдение. Рассмотрим
следующий пример.

Пример аномалии в нескольких сегментах
Мы впервые показали следующий график (рис. 5.23) под номером 3.17 в главе 3, а сейчас специально повторяем его, чтобы показать, как аномалии в нескольких сегментах отображаются в пользовательском интерфейсе Elastic ML.
Как мы обсуждали в главе 3, аномалии в нескольких сегментах обозначаются в пользовательском интерфейсе другим символом (крестиком вместо
точки). Они соответствуют случаям, когда фактическое сингулярное значение не обязательно является аномальным, но есть тенденция, которая возникает в скользящем окне из 12 последовательных сегментов. Здесь вы можете
увидеть заметный спад, охватывающий несколько соседних сегментов.
Обратите внимание, однако, что некоторые из маркеров аномалии в нескольких сегментах помещаются в точки времени, следующие после того, как
данные «восстановлены». Это может несколько сбить с толку пользователей,
пока вы не поймете, что, поскольку определение таких аномалий является
вторичным анализом (в дополнение к посегментному анализу) и поскольку
этот анализ представляет собой скользящее окно, наблюдающее аномалию
в своей «хвостовой» части, передний край этого окна на момент обнаружения
аномалии может оказаться в точке времени, когда ситуация уже восстановилась.

146  Интерпретация результатов

Рис. 5.23  Аномалии в нескольких сегментах, впервые показанные в главе 3

Оценка аномалии в нескольких сегментах
Как уже упоминалось выше, анализ нескольких сегментов – вторичный анализ. Поэтому для каждого диапазона сегментов вычисляются две вероятности – вероятность наблюдения, присутствующего в текущем сегменте,
и вероятность наблюдения в нескольких сегментах – своего рода средневзвешенное значение текущего сегмента и 11 предыдущих. Если эти две
вероятности представляют собой величины примерно одного порядка, тогда
multi_bucket_impact будет низким (в отрицательной части шкалы от –5 до 5).
Если, с другой стороны, вероятность наличия события в нескольких сегментах значительно ниже (а значит, событие более необычно), тогда multi_bucket_impact будет высоким.
В примере, показанном на рис. 5.24, пользовательский интерфейс покажет
пользователю, что значение multi_bucket_impact велико (помечено словом
high – высокий), но без указания фактических результатов.

Аномалии в нескольких сегментах  147

Рис. 5.24  Аномалии в нескольких сегментах с указанием оценки влияния

Однако если вы посмотрите на необработанный результат на уровне записи, то увидите, что multi_bucket_impact было присвоено значение 5 (рис. 5.25).

Рис. 5.25  Запись, соответствующая аномалии в нескольких сегментах,
и оценка влияния в баллах по шкале от –5 до 5

148  Интерпретация результатов
Аномалии, наблюдаемые через окно в нескольких сегментах, дают вам
другой взгляд на поведение ваших данных. Вам нужно помнить о том, как
они обозначаются и оцениваются с помощью поля multi_bucket_impact, чтобы
вы могли включать или исключать их, при необходимости, из вашей логики
отчетов или оповещений.
Давайте теперь посмотрим на то, как результаты прогнозов представлены
в хранилище результатов.

результаты прогноза
Как подробно объясняется в главе 4, мы можем заставить Elastic ML экстраполировать в будущее тенденции анализируемых данных. Давайте заново
рассмотрим рис. 5.26 с результатами прогноза, впервые показанный в главе 4
(рис. 4.21).

Рис. 5.26  Результаты прогноза, впервые показанные в главе 4

Напомним, что значение прогноза – это значение с наибольшим правдоподобием (вероятностью), а заштрихованная область – это диапазон 95-го процентиля достоверности. Эти три ключевых значения хранятся в хранилищах
результатов .ml-anomalies-* со следующими именами:

Результаты прогноза  149

 forecast_prediction;
 forecast_upper;
 forecast_lower.

Запрос результатов прогноза
При запросе результатов прогноза в хранилищах результатов .ml-anomalies-*
важно помнить, что результаты прогнозов являются временными – они
имеют срок действия по умолчанию 14 дней после создания, особенно если
они созданы из пользовательского интерфейса в Kibana. Если нужна другая продолжительность срока действия, тогда прогноз необходимо будет
вызвать через конечную точку API _forecast и явно указать длительность
expires_in.
Также следует помнить, что для одного и того же набора данных могут
быть вызваны несколько прогнозов в разные моменты времени. Как было
показано на рис. 4.4 и повторяется здесь (рис. 5.27), несколько вызовов дают
несколько результатов прогнозов.

№1
№2

Время
Запрос
прогноза № 1

Запрос
прогноза № 2

Рис. 5.27  Условная иллюстрация вызова нескольких прогнозов в разное время

Следовательно, нам нужен способ различать результаты. В пользовательском интерфейсе Kibana их можно различить, просто взглянув на дату создания (рис. 5.28).
Глядя на хранилище результатов, вы могли заметить, что каждый вызванный прогноз имеет уникальный forecast_id (идентификатор прогноза)
(рис. 5.29).
Значение forecast_id видно только при вызове прогноза с использованием
API _forecast, потому что это значение возвращается как часть полезной нагрузки вызова API.
Следовательно, если бы было создано несколько прогнозов, охватывающих общий период времени, было бы несколько результатов с разными
идентификаторами.

150  Интерпретация результатов

Рис. 5.28  Просмотр нескольких ранее выполненных прогнозов

Рис. 5.29  Просмотр результатов прогноза в Kibana Discover

При запросе результатов прогноза вы можете использовать одну из двух
основных стратегий:
 приоритет значения – запрос предоставляет дату и время, и в результате возвращается конкретное значение для этого времени. Хорошим
примером является вопрос: «Какой будет загруженность моего сервера
через 5 дней?»;

API результатов Elastic ML  151

 приоритет времени – запрос предоставляет значение, а результатом
является время, в которое это значение реализуется. Хорошим примером является вопрос: «Когда загруженность моего сервера достигнет
80 %?»
Очевидно, что мы можем составить запросы того и другого типа. Например, чтобы реализовать запрос, ориентированный на время, нам нужно немного переформулировать запрос и попросить его вернуть дату (или даты),
когда предсказанные значения соответствуют определенным критериям.
Пользователь может запросить результаты прогноза, используя другие традиционные методы запроса (KQL, Elasticsearch DSL), но, чтобы продемонстрировать разнообразие методов, мы отправим запрос с помощью Elastic
SQL в консоли Kibana Dev Tools:
POST _sql?format=txt
{
"query": "SELECT forecast_prediction,timestamp FROM \".mlanomalies-*\"
WHERE job_id='forecast_example' AND forecast_
id='Fm5EiHcBpc7Wt6MbaGcw' AND result_type='model_forecast' AND
forecast_prediction>'16890' ORDER BY forecast_prediction DESC"
}

В этом запросе мы спрашиваем, есть ли моменты, в течение которых прогнозируемое значение превышает наше предельное значение 16 890. Ответ
выглядит так:
forecast_prediction|
timestamp
-------------------+-----------------------16893.498325784924 | 2017-03-17T09:45:00.000Z

Другими словами, есть большая вероятность, что мы преодолеем порог
17 марта в 9:45 утра по GMT (хотя, как вы помните из главы 4, использованные образцы данных взяты из прошлого, и поэтому прогнозы тоже остались
в прошлом). Теперь, когда у нас есть хорошее представление о том, как запрашивать результаты прогнозов, мы можем включать их в информационные
панели и визуализации, о которых расскажем позже в этой главе, или даже
в оповещения, как будет показано в главе 6.
Но прежде чем мы рассмотрим включение результатов в настраиваемые
информационные панели и визуализации, давайте рассмотрим последнюю
краткую тему – API результатов Elastic ML.

aPI результатов ElasTIc Ml
Если в дополнение к непосредственному запросу хранилищ результатов вам
нужен доступ к результатам из своей программы, вы можете запросить API
результатов Elastic ML. Некоторые части API повторяют то, что мы уже исследовали, а некоторые части уникальны. Далее мы рассмотрим API результатов
более подробно.

152  Интерпретация результатов

Конечные точки API результатов
Вам доступны пять различных конечных точек API результатов:






получение сегментов;
получение факторов влияния;
получение записей;
получение обобщения сегментов;
получение категорий.

Первые три конечные точки API дают результаты, которые являются избыточными в свете того, что мы уже рассмотрели в этой главе, путем прямого
запроса хранилища результатов (через Kibana или с помощью API Elasticsearch _search), и доступ через API лишь обеспечивает большую гибкость,
поэтому мы не будем их здесь обсуждать. Однако последние две конечные
точки API являются новыми, и каждая заслуживает объяснения.

API обобщения сегментов
Вызов API обобщения сегментов – это средство, с помощью которого программным способом возвращаются сводные результаты множества заданий
по обнаружению аномалий. Мы не станем исследовать каждый аргумент тела
запроса и описывать каждое поле в теле ответа, поскольку вы всегда можете
воспользоваться документацией. Но мы обсудим здесь важную функцию
этого вызова API, который должен запросить результаты произвольного количества заданий и получить обобщенную оценку результата (называемую
overall_score), включающую среднее значение top_n максимальной оценки
anomaly_score сегмента для каждого запрошенного задания. В документации
приводится пример вызова, который запрашивает два верхних задания (в
наборе заданий, которые начинаются с имени job-), чья оценка аномалии
сегмента при усреднении превышает 50,0, начиная с определенной временной метки:
GET _ml/anomaly_detectors/job-*/results/overall_buckets
{
"top_n": 2,
"overall_score": 50.0,
"start": "1403532000000"
}
Ответ на этот запрос выглядит так:
{
"count": 1,
"overall_buckets": [
{
"timestamp" : 1403532000000,
"bucket_span" : 3600,
"overall_score" : 55.0,
"jobs" : [
{

API результатов Elastic ML  153
"job_id" : "job-1",
"max_anomaly_score" : 30.0
},
{
"job_id" : "job-2",
"max_anomaly_score" : 10.0
},
{
"job_id" : "job-3",
"max_anomaly_score" : 80.0
}
],
"is_interim" : false,
"result_type" : "overall_bucket"
}
]
}

Обратите внимание, что в этом случае overall_score является средним из
двух наивысших оценок (результат overall_score 55,0 является средним значением для задания job-3, равного 80,0, и для задания job-1, равного 30,0),
даже несмотря на то, что три задания по обнаружению аномалий соответствуют шаблону запроса job-*. Хотя это, безусловно, интересно, например
для создания составного оповещения, вы должны осознавать ограничения
такого отчета, особенно если вы можете получить доступ только к оценке
аномалии на уровне сегмента, но не на уровне записи или фактора влияния.
В главе 6 мы рассмотрим некоторые варианты составных оповещений.

API категорий
Вызов API категорий актуален только для заданий, использующих категоризацию, как подробно описано в главе 3. API категорий возвращает некоторые интересные внутренние определения категорий, обнаруженные в ходе
текстового анализа документов. Если мы запустим API для задания категоризации, которое создали еще в главе 3 (сокращенное, чтобы для краткости
возвращать только одну запись), результат будет следующим:
GET _ml/anomaly_detectors/secure_log/results/categories
{
"page":{
"size": 1
}
}

Мы увидим такой ответ:
{
"count" : 23,
"categories" : [
{

154  Интерпретация результатов
"job_id" : "secure_log",
"category_id" : 1,
"terms" : "localhost sshd Received disconnect from port",
"regex" :
".*?localhost.+?sshd.+?Received.+?disconnect.+?from.+?port.*",
"max_matching_length" : 122,
"examples" : [
"Oct 22 15:02:19 localhost sshd[8860]: Received
disconnect from 58.218.92.41 port 26062:11: [preauth]",
"Oct 22 22:27:20 localhost sshd[9563]: Received
disconnect from 178.33.169.154 port 53713:11: Bye [preauth]",
"Oct 22 22:27:22 localhost sshd[9565]: Received
disconnect from 178.33.169.154 port 54877:11: Bye [preauth]",
"Oct 22 22:27:24 localhost sshd[9567]: Received
disconnect from 178.33.169.154 port 55723:11: Bye [preauth]"
],
"grok_pattern" : ".*? %{SYSLOGTIMESTAMP:timestamp}.+
?localhost.+?sshd.+? %{NUMBER:field}.+?Received.+?
disconnect.+?from.+? %{IP:ipaddress}.+?port.+? %{NUMBER:field2}.+
? %{NUMBER:field3}.*",
"num_matches" : 595
}
]
}

Ответ состоит из нескольких элементов:
 category_id – это номер категории сообщения (начинается с 1). Он соответствует значению поля mlcategory в хранилище результатов;
 terms – это список статических, неизменяемых слов, извлеченных из
сообщения;
 examples – массив полных неизмененных строк журнала выборки, которые попадают в эту категорию. Они используются, чтобы показать
пользователям, как выглядят некоторые из реальных строк журнала;
 grok_pattern – шаблон соответствия в стиле регулярного выражения,
которое можно использовать для Logstash или входного конвейера,
который можно использовать для сопоставления этой категории сообщений;
 num_matches – количество раз, когда эта категория сообщений была замечена в журналах на протяжении всего задания по обнаружению аномалий, выполняемого для этого набора данных.
Возможно, наиболее интересным использованием этого API является не
обнаружение аномалий, а простое исследование уникального количества
типов категорий и распределения этих типов в ваших неструктурированных
журналах, чтобы ответить на такие вопросы, как «Какие типы сообщений находятся в моих журналах и сколько записей каждого типа?». Некоторые из
этих возможностей пригодятся в будущем для создания процесса «подготовки данных», чтобы упростить пользователям загрузку неструктурированных
журналов в Elasticsearch.

Пользовательские панели мониторинга и рабочие панели Canvas  155

Давайте теперь исследуем, как результаты, полученные из заданий по обнаружению аномалий и прогнозированию в Elastic ML, могут быть использованы в настраиваемых панелях мониторинга, визуализациях и рабочих
панелях Canvas.

пользовательские панели мониторинга
и рабочие панели canvas
Очевидно, что теперь, когда вы знаете все тонкости устройства хранилища
результатов, в котором хранятся все полезные вещи, полученные при обнаружении аномалий и прогнозной аналитике Elastic ML, ваши возможности
ограничены только вашим воображением, и вы можете представить эти результаты в соответствии со своими целями. В этом разделе кратко представлены некоторые концепции и идеи, которые вы можете использовать, чтобы
вывести результаты Elastic ML на большой экран.

Панель инструментов встраивания
Одним из недавних дополнений к возможностям Elastic ML является возможность встраивать временную шкалу Anomaly Explorer (обзорная полоса)
в существующие настраиваемые информационные панели. Для этого просто нажмите на символ меню «три точки» в правом верхнем углу Anomaly
timeline (Шкала времени аномалии) и выберите параметр Add to dashboard
(Добавить на панель управления) (рис. 5.30).

Рис. 5.30  Добавление шкалы времени аномалии на другую панель мониторинга

156  Интерпретация результатов
На этом этапе выберите, какую часть видов обзорных полос вы хотите
включить и на какие панели мониторинга вы хотите их добавить (рис. 5.31).

Рис. 5.31  Добавление шкалы времени аномалии на конкретную панель управления

Нажатие кнопки Add and edit dashboard (Добавить и редактировать панель мониторинга) перенесет вас на целевую панель мониторинга, где вы
сможете перемещать и изменять размер встроенных панелей. Например,
можно расположить аномалии рядом с другими визуализациями, как показано на рис. 5.32.

Аномалии как аннотации в TSVB
Компонент Time Series Visual Builder (TSVB, визуальный построитель временных рядов) в Kibana – это чрезвычайно гибкий конструктор визуализаций, который позволяет пользователям не только отображать данные своих
временных рядов, но и аннотировать эти данные с помощью информации из
других хранилищ. Это идеальный рецепт для отображения необработанных
данных, а затем наложения аномалий из задания по обнаружению аномалий
поверх этих данных. Например, вы можете создать TSVB для kibana_sample_
data_logs, как показано на рис. 5.33.

Пользовательские панели мониторинга и рабочие панели Canvas  157

Рис. 5.32  Новая панель управления,
теперь содержащая визуализации аномалий в обзорных полосах

Рис. 5.33  Создание новой визуализации TSVB – параметры Panel

158  Интерпретация результатов
Кроме того, существует конфигурация на вкладке Data (Данные) для агрегирования терминов для пяти ведущих стран происхождения (geo.src).

Рис. 5.34  Создание новой визуализации TSVB – параметры Data

Далее в нашем распоряжении конфигурация на вкладке Annotations (Аннотации), позволяющая наложить результаты ранее созданного задания по
обнаружению аномалий с именем web_traffic_per_country и выбрать аномалии с рекордным количеством баллов более 90.

Рис. 5.35  Создание новой визуализации TSVB – параметры Annotations

Обратите внимание, что поле Query string (Строка запроса) выглядит довольно знакомым, учитывая то, о чем мы говорили в этой главе. TSVB также
требует список разделенных запятыми полей для аннотаций (здесь мы вво-

Пользовательские панели мониторинга и рабочие панели Canvas  159

дим record_score и partition_field_value) и Row template (Шаблон строки),
который определяет форматирование аннотации (здесь мы вводим Anomaly:
{{record_score}} for {{partition_field_value}}). Как только это будет сделано,
вы получите окончательный результат (рис. 5.36).

Рис. 5.36  Создание новой визуализации TSVB с аннотациями аномалий

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

Настройка рабочих панелей Canvas
Kibana Canvas – это идеальный инструмент для создания идеально точной
инфографики на основе данных из Elasticsearch. Вы можете создавать индивидуализированные отчеты с набором настраиваемых элементов. Работа с Canvas сильно отличается от стандартных информационных панелей
Kibana. Canvas представляет собой рабочую область – так называемую рабочую панель (workpad), в которой вы можете создавать наборы слайдов, как
в Microsoft PowerPoint.
Чтобы использовать обнаружение аномалий и/или результаты прогнозирования на рабочем столе Canvas, не нужно делать ничего особенного – вы
уже изучили все, что нужно. Это связано с тем, что в Canvas очень легко использовать команду essql для запроса шаблона хранилища .ml-anomalies-*
и извлечения важной информации.
Когда вы устанавливаете образцы данных Kibana, вместе с ними вы также
получаете несколько образцов рабочих панелей Canvas (рис. 5.37).
Щелкнув по образцу рабочей панели [Logs] Web Traffic ([Журналы] Вебтрафик), вы откроете его для редактирования (рис. 5.38).
Если выбрать один из элементов на странице (допустим, счетчик TOTAL
VISITORS (ВСЕГО ПОСЕТИТЕЛЕЙ) внизу, который в настоящее время показывает значение 324), а затем выбрать Expression editor (Редактор выражений), то в правой части экрана Canvas покажет детали элемента (рис. 5.39).

Powered by TCPDF (www.tcpdf.org)

160  Интерпретация результатов

Рис. 5.37  Образцы рабочих панелей Canvas

Рис. 5.38  Пример рабочей панели веб-трафика

Настоящая «магия» получения данных в реальном времени заложена
в команде essql, а остальная часть выражения – это просто форматирование.
В качестве простого примера мы можем записать SQL следующим образом:
SELECT COUNT(timestamp) as critical_anomalies FROM \".mlanomalies-*\"
WHERE job_id='web_logs_rate' AND result_
type='record' AND record_score>'75'

Пользовательские панели мониторинга и рабочие панели Canvas  161

Рис. 5.39  Редактирование элемента Canvas в редакторе выражений

Следует отметить, что, поскольку имя шаблона хранилища .ml-anomalies-*
начинается с неалфавитного символа, имя должно быть заключено в двойные кавычки, а эти двойные кавычки необходимо экранировать с помощью
символа обратной косой черты.
Этот запрос вернет общее количество критических аномалий (тех, у которых record_score больше 75) для конкретного задания по обнаружению
аномалий в этом наборе данных (рис. 5.40).

Рис. 5.40  Отображение количества критических аномалий

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

162  Интерпретация результатов

заключение
Механизмы обнаружения аномалий и прогнозирования Elastic ML создают
впечатляющие и полезные результаты, которые можно исследовать с помощью богатого пользовательского интерфейса, предоставляемого в Kibana,
или программно с помощью прямого обращения к хранилищам результатов
через API. Понимание результатов ваших заданий по обнаружению и прогнозированию аномалий и возможность надлежащим образом использовать
эту информацию для дальнейших настраиваемых визуализаций или оповещений делает эти настраиваемые ресурсы еще более мощными.
В следующей главе мы воспользуемся результатами для создания сложных
и полезных упреждающих оповещений, чтобы еще больше повысить прикладную ценность Elastic ML.

Глава

6
Создание
и использование
оповещений

В предыдущей главе говорилось о том, как результаты обнаружения и прогнозирования аномалий сохраняются в хранилищах Elasticsearch. В этой главе
мы расскажем о создании информативных и прогнозных оповещений на
основе полученных ранее результатов анализа.
На момент написания данной книги Elastic Stack находился на переломном этапе развития. В течение нескольких лет Elastic ML полагался на Watcher (компонент Elasticsearch), поскольку это был эксклюзивный механизм
оповещения. Однако начиная с версии 7.11 введена новая платформа оповещения, работающая как часть Kibana, и в дальнейшем она будет основным
механизмом оповещения.
Есть несколько интересных функций Watcher, которые пока не реализованы в механизме оповещений Kibana. Поэтому в данной главе мы продемонстрируем создание оповещений с использованием средств Kibana и Watcher.
В зависимости от ваших потребностей вы можете решить, что из них лучше
использовать.
В частности, в этой главе будут рассмотрены следующие темы:
 определение и принцип работы оповещений;
 создание оповещений из пользовательского интерфейса ML;
 создание оповещений с помощью Watcher.

технические требования
В этой главе мы будем использовать Elastic Stack в том виде, в котором он
существует в версии 7.12.

164  Создание и использование оповещений

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

Аномалии не обязательно нуждаются
в оповещениях
Об этом нужно сказать прямо. Часто пользователи, которые научились обнаруживать аномалии, чувствуют себя обязанными предупреждать обо всем,
что удалось заметить. Это стремление может создать проблемы, если обнаружение аномалий развернуто на сотнях, тысячах или даже десятках тысяч
объектов. Инструменты обнаружения аномалий, безусловно, освобождают
пользователей от необходимости определять конкретные, управляемые правилами исключения или жестко заданные пороговые значения оповещений,
но при этом они способствуют раздуванию объема генерируемых данных при
расширении масштаба использования. Вы должны понимать, что подробное
оповещение о каждой маленькой аномалии может стать источником мешающего информационного шума, если не проявить разумную осторожность.
К счастью, в главе 5 вы познакомились с подходами, которые помогают
нам исправить ситуацию:
 обобщение: вы узнали, что аномалии не только попадают в отчет по
отдельности (на уровне записи), но также суммируются на уровне сегмента и на уровне фактора влияния. Эти итоговые оценки дают нам
возможность генерировать оповещение на более высоком уровне абстракции, если мы того пожелаем;
 нормализованная оценка: поскольку каждое задание по обнаружению аномалий имеет настраиваемую шкалу нормализации, специально
созданную для конкретной конфигурации детектора и анализируемого
набора данных, это означает, что мы можем использовать нормализованную оценку, получаемую из Elastic ML, для ограничения частоты появления типичных оповещений. Возможно, для конкретного задания,
которое вы создали, оповещение с минимальной оценкой аномалии 10
обычно дает около дюжины оповещений в день, оценка 50 дает около
одного оповещения в день, а оценка 90 дает около одного оповещения
в неделю. Другими словами, вы можете настроить оповещение в соответствии с вашими требованиями к количеству оповещений, которые
вы предпочитаете получать за единицу времени (конечно, за исключением неожиданного сбоя в масштабах всей системы, который может
создать больше оповещений, чем обычно);
 корреляция/комбинация: возможно, аномалия одной метрики (чрезмерно высокий уровень нагрузки на процессор) выглядит не столь
убедительно, как группа связанных аномалий (нагрузка растет, объем

Определение и принцип работы оповещений  165

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

Точное время имеет значение
Еще в главе 2 вы узнали, что задания по обнаружению аномалий представляют собой относительно сложную оркестровку запроса необработанных данных, анализа этих данных и представления результатов в виде непрерывного
процесса, который может выполняться почти в реальном времени. Поэтому
существуют несколько ключевых аспектов конфигурации задания, которые
определяют частоту этого процесса, а именно параметры bucket_span, frequency и query_delay. Эти параметры определяют, когда результаты «готовы»
и какую метку времени получат значения. Это чрезвычайно важно, потому
что оповещение о результатах обнаружения аномалий будет включать последующий запрос к хранилищам результатов (.ml-anomalies-*), и очевидно,
что от того, когда этот запрос выполняется и какой временной диапазон
используется, зависит, действительно ли вы обнаружите аномалии, которые
ищете. Эти соображения проиллюстрированы на рис. 6.1.
сейчас

t1

t2

ta

tb
Время

t2 – t1 = bucket_span
now – t2 = query_delay
tb – ta = frequency

Рис. 6.1  Представление ширины сегмента,
задержки запроса и частоты по отношению к текущему моменту

На риc. 6.1 мы видим, что конкретный период времени (представленный
интервалом, равным t2–t1) отстает от текущего системного времени (сейчас)
на величину, равную query_delay. Внутри сегмента могут быть шаги времени,
которые определены параметром frequency. Что касается того, как результаты
этого сегмента записываются в хранилища результатов .ml-anomalies-*, вы
должны помнить, что метка времени всех документов, написанных для этого
сегмента, будет иметь значение метки времени, равное времени в момент
t1 – передний край сегмента.

166  Создание и использование оповещений
В качестве практического примера рассмотрим следующие значения:
 bucket_span = 15 мин;
 frequency = 15 мин;
 query_delay = 2 мин.
Если сейчас 12:05, то сегмент, соответствующий интервалу 11:45–12:00,
был запрошен и обработан Elastic ML примерно в 12:02 (из-за задержки
query_delay), и вскоре после этого готовый документ был записан в .ml-anomalies-* (но записан с меткой времени, равной 11:45). Следовательно, если
в 12.05 мы заглянем в .ml-anomalies-*, чтобы увидеть результаты на 11:45, мы
можем быть уверены, что они существуют, и мы могли бы изучить содержимое. Однако если сейчас только 12:01, то готового документа для сегмента,
соответствующего интервалу 11:45–12:00, пока не существует, и он появится
только спустя еще минуту или около того. Как видите, выбор времени очень
важен.
Если в нашем примере сценария мы уменьшим значение frequency до 7,5
или 5 мин, то у нас действительно «раньше» появится доступ к результатам
сегмента, но результаты будут помечены как промежуточные (interim) и могут измениться после завершения обработки сегмента.
Промежуточные результаты создаются в пределах сегмента, если значение frequency
является кратным значению bucket_span, но не все детекторы дают промежуточные
результаты. Например, если у вас есть детектор max или high_count, то промежуточный результат, который показывает значение выше ожидаемого по сравнению с типичным значением, возможен и разумен – вам не нужно видеть содержимое всей
корзины, чтобы знать, что вы уже превзошли ожидания. Однако если вы используете
детектор mean, вам придется получить весь объем наблюдений в сегменте, прежде чем
определять среднее значение, поэтому промежуточные результаты не имеют смысла
и не выдаются.

Итак, с учетом сказанного, если мы теперь возьмем диаграмму на рис. 6.1
и немного увеличим время, но также нарисуем сегменты до и после упомянутого сегмента, новая диаграмма будет выглядеть, как показано на рис. 6.2.

сейчас

t1

t0

сегмент t0

t2

сегмент t1

сегмент t2
Время

2 * bucket_span

Рис. 6.2  Представление последовательных сегментов

Определение и принцип работы оповещений  167

На рис. 6.2 мы видим, что текущее системное время (обозначенное словом «сейчас») находится примерно в середине сегмента t2 – следовательно,
сегмент t2 еще не завершен, и если есть какие-либо результаты, записанные
для сегмента t2 заданием по обнаружению аномалий, они будут отмечены
флагом is_interim:true, как было показано в главе 5.
Если мы сделаем запрос оповещения, который отвечает на вопрос «Найдены ли какие-либо новые аномалии с тех пор, как мы проверяли результаты
в последний раз?», и время этого запроса соответствует текущему системному времени «сейчас», как показано на рис. 6.2, то можно сделать следующие
выводы:
 период «оглядки назад» должен быть примерно вдвое больше bucket_span. Это гарантирует, что мы увидим любые промежуточные результаты, которые могут быть опубликованы для текущего сегмента
(здесь сегмент t2), и любые окончательные результаты для предыдущего сегмента (здесь сегмент t1). Результаты из сегмента t0 не будут
представлены, потому что метка времени для сегмента t0 находится
за пределами запрашиваемого окна времени – это нормально, если мы
делаем запрос оповещения, который будет повторяться по правильному расписанию (как сказано в следующем пункте);
 время, выбранное для выполнения этого запроса, может попасть практически в любое место в пределах временного окна сегмента t2, и запрос все равно будет работать, как описано. Это важно, потому что
расписание, по которому запускается запрос оповещения, скорее всего,
не будет синхронизировано с расписанием, по которому выполняются
задание обнаружения аномалий и запись результатов;
 скорее всего, вы запланируете поиск оповещений так, чтобы он срабатывал не реже, чем с интервалом, равным bucket_span, но он может
выполняться и чаще, если мы заинтересованы в выявлении промежуточных аномалий в текущем, еще не завершенном сегменте;
 если вам не нужны промежуточные результаты, достаточно изменить
запрос так, чтобы он включал условие is_interim:false.
У вас могло сложиться впечатление, что для правильной и надежной работы запроса оповещения не обойтись без навыков темной магии. К счастью,
когда мы создаем оповещения с помощью Kibana из пользовательского интерфейса Elastic ML, вся необходимая работа будет сделана за вас.
Однако если вы чувствуете себя волшебником и полностью понимаете, как
все это работает, то, возможно, вас не слишком пугает перспектива создания
тонко настраиваемых условий оповещения с помощью Watcher, где у вас
будет полный контроль.
В следующих разделах мы рассмотрим несколько примеров с использованием каждого метода, чтобы вы могли сравнить их работу.

168  Создание и использование оповещений

созДание оповещений из интерфейса
машинного обучения
С выпуском v7.12 Elastic ML изменил свой обработчик оповещений по умолчанию с Watcher на оповещения Kibana. До версии 7.12 у пользователя был
выбор: принять опцию по умолчанию watch (экземпляр сценария для Watcher), если в пользовательском интерфейсе ML было выбрано оповещение,
или самостоятельно создать объект watch с нуля. Сейчас мы уделим основное
внимание новому рабочему процессу с использованием оповещений Kibana
версии 7.12, который предлагает хороший баланс гибкости и простоты использования.
В качестве наглядного примера оповещения в реальном времени мы разработаем сценарий для набора данных веб-журналов Kibana, с которым познакомились в главе 3.
Мы должны пройти через три основных шага:
1) определяем несколько заданий по обнаружению аномалий для пробных данных;
2) определяем два оповещения для двух заданий по обнаружению аномалий;
3) запускаем моделирование аномального поведения, чтобы зафиксировать это поведение в оповещении.
Давайте сначала определим задания по обнаружению аномалий.

Определение заданий по обнаружению аномалий
Очевидно, что, прежде чем мы сможем создавать оповещения, нам нужны
задания, выполняемые в режиме реального времени. Мы можем использовать примеры заданий машинного обучения, которые поставляются вместе
с набором данных веб-журналов Kibana.
Если у вас уже есть этот набор данных, загруженный в ваш кластер, вы должны удалить его и снова добавить. Это приведет к сбросу отметок времени в наборе данных,
так что примерно половина данных будет в прошлом, а остальные – в будущем. Наличие некоторых данных в будущем позволит нам представить, будто данные появляются в реальном времени, и поэтому наши задания по обнаружению аномалий
в реальном времени и наши оповещения об этих заданиях будут действовать так, как
будто они действительно работают в режиме реального времени.

Для начала давайте перезагрузим образцы данных и создадим несколько
пробных заданий.
1. На главном экране Kibana нажмите ссылку Try our sample data (Попробовать наши образцы данных) (рис. 6.3).

Создание оповещений из интерфейса машинного обучения  169

Рис. 6.3  Главный экран Kibana

2. Щелкните Index Patterns (Шаблоны хранилища) в разделе Sample web
logs (Образцы веб-журналов). Если они уже загружены, удалите и снова
добавьте их (рис. 6.4).

Рис. 6.4  Добавление примеров данных веб-журналов

3. В меню View data (Просмотр данных) выберите ML jobs (Задания
машинного обучения), чтобы создать несколько примеров заданий
(рис. 6.5).

170  Создание и использование оповещений

Рис. 6.5  Cоздание нескольких пробных заданий машинного обучения

4. Дайте трем примерам заданий префикс идентификатора задания
(здесь был выбран alert-demo-) и убедитесь, что вы сняли флажок Use
full kibana_sample_data_logs data (Использовать полные данные
kibana_sample_data_logs), затем выберите время окончания не позднее
15 минут относительно текущего системного времени в вашем часовом
поясе (рис. 6.6).

Создание оповещений из интерфейса машинного обучения  171

Рис. 6.6  Присвоение префиксов имен примерам заданий
и выбор текущего системного времени в качестве времени окончания

5. Обратите внимание на рис. 6.6, что 8 апреля 2021 г. @ 11:00:00.00
было выбрано в качестве времени окончания, а дата на 11 дней раньше
(28 марта 2021 @ 00:00:00.00) была выбрана в качестве времени начала (данные примера охватывают 11 дней с момента его установки).
Текущее местное время на момент создания этого снимка экрана было
11:10 утра 8 апреля 2021 г. Это важно в том смысле, что мы пытаемся заставить эти образцы данных выглядеть так, будто они собраны
в реальном времени. Нажмите кнопку Create Jobs (Создать задание),
чтобы начать создание задания. Как только задание будет создано, вы
увидите следующий экран (рис. 6.7).

Рис. 6.7  Завершение инициализации примеров заданий

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

172  Создание и использование оповещений
жмите ссылку Anomaly Detection (Обнаружение аномалий) в верхней
строке меню, чтобы вернуться на страницу Job Management (Управление заданиями). Здесь мы видим, что наши три задания проанализировали некоторые данные, но теперь находятся в закрытом состоянии,
а потоки данных в настоящее время остановлены (рис. 6.8).

Рис. 6.8  Примеры заданий на экране управления заданиями

7. Теперь нам нужно запустить эти три задания в реальном времени. Установите флажки рядом с каждым заданием, а затем щелкните значок
шестеренки, чтобы открыть меню и выбрать Start data feeds (Запуск
каналов данных) для всех трех заданий (рис. 6.9).

Рис. 6.9  Запуск потока данных для всех трех пробных заданий

Создание оповещений из интерфейса машинного обучения  173

8. Во всплывающем окне выберите верхнюю опцию списка для полей
Search start time (Время начала поиска) и Search end time (Время
окончания поиска), чтобы задание продолжало выполняться в реальном времени. Сейчас мы не станем выставлять флажок Create alert
after datafeed has started (Создать оповещение после начала подачи
данных), поскольку вскоре создадим свои собственные оповещения
(рис. 6.10).

Рис. 6.10  Запуск потоков данных трех пробных заданий
для запуска в реальном времени

9. После нажатия кнопки Start (Пуск) мы увидим, что три наших задания
теперьнаходятся в открытом (работающем) состоянии (рис. 6.11).

Рис. 6.11  Примеры заданий,
которые теперь выполняются в режиме реального времени

174  Создание и использование оповещений
Создав пробные задания и убедившись, что они работают, определим для
них несколько оповещений.

Создание оповещений для пробных заданий
Теперь, когда наши задания выполняются в режиме реального времени, мы
можем определить для них оповещения.
1. Для задания alert-demo-response_code_rates щелкните значок троеточия
«…», расположенный справа, и выберите опцию Create alert (Создать
оповещение) (рис. 6.12).

Рис. 6.12  Создание оповещения для пробного задания

2. Далее появится всплывающее окно Create alert, и вы можете приступить к настройке желаемой конфигурации оповещения (рис. 6.13).
3. В соответствии с полями на рис. 6.13 нужно задать имя оповещению,
а также указать, чтобы это оповещение проверяло наличие аномалий
каждые 10 минут. Для этого задания интервал bucket_span установлен
на 1 час, но параметр frequency установлен на 10 минут, поэтому промежуточные результаты будут доступны гораздо раньше, чем закончится
сегмент. По этой же причине стоит включить промежуточные результаты в вашу конфигурацию оповещений, чтобы получить уведомление
как можно скорее. В секции Result type (Тип результата) выберите
Bucket, чтобы получить обобщенное описание аномальности, как обсуждалось ранее. Наконец, установите порог значимости 51, чтобы
оповещения генерировались только для аномалий с оценкой, превышающей это значение.

Создание оповещений из интерфейса машинного обучения  175

Рис. 6.13  Создание конфигурации оповещения

4. Прежде чем продолжить, проверьте конфигурацию оповещений на
прошлых данных. Введя значение 30d в проверочное поле, вы увидите,
что за последние 30 дней было только одно оповещение, которое соответствовало заданному условию (рис. 6.14).

176  Создание и использование оповещений

Рис. 6.14  Проверка конфигурации оповещений на прошлых данных

5. Наконец, вы можете настроить действие, которое будет выполняться
при срабатывании оповещения. В данном случае наша система была
предварительно настроена на использование Slack в качестве действия
оповещения (рис. 6.15), поэтому мы на этом и остановимся, но есть
много других вариантов, доступных пользователю (перейдите по адресу https://www.elastic.co/guide/en/kibana/current/action-types.html, чтобы
изучить все доступные варианты и способы отправки сообщений с оповещениями).

Создание оповещений из интерфейса машинного обучения  177

Рис. 6.15  Настройка действия оповещения

6. Нажатие на кнопку Save (Сохранить), очевидно, сохранит оповещение, которое затем можно будет просмотреть и изменить через Stack
Management | Alerts and Actions (Управление стеком | Оповещения
и действия) в Kibana (рис. 6.16).
7. Теперь создайте еще одно оповещение для задания alert-demo-url_scanning. Пусть это будет оповещение типа Record (Запись), но с другими
параметрами конфигурации, аналогичными предыдущему примеру
(рис. 6.17).

178  Создание и использование оповещений

Рис. 6.16  Управление оповещениями

Рис. 6.17  Настройка оповещения для задания сканирования URL

Создание оповещений из интерфейса машинного обучения  179

Теперь, когда у вас настроены два оповещения, давайте перейдем к моделированию действительно аномальной ситуации в реальном времени, чтобы
вызвать срабатывание оповещений.

Моделирование аномального поведения
в реальном времени
Запуск моделирования аномального поведения в контексте этих примеров
веб-журналов выглядит немного сложнее, чем настройка конфигурации заданий. Этот процесс потребует использования API Elasticsearch и выполнения нескольких команд через консоль Dev Tools в Kibana. Консоль – это
место, где вы можете выполнять вызовы API в Elasticsearch и просматривать
выходные данные (ответ) этих вызовов API.
Если вы незнакомы с консолью, перейдите по адресу https://www.elastic.co/guide/en/
kibana/current/console-kibana.html.

Мы проведем моделирование по двум направлениям: добавим несколько
фальшивых документов в хранилище, за которым следит задание по обнаружению аномалий, а затем дождемся срабатывания оповещения. В этих
документах будет показан всплеск запросов с фиктивного IP-адреса 0.0.0.0,
ведущих к ответу с кодом 404, а также запросов случайных URL. Для запуска
моделирования выполните следующие шаги.
1. Определите свое текущее время по UTC. Вы должны знать время в формате UTC (в отличие от времени вашего местного часового пояса), потому что документы, расположенные в хранилище Elasticsearch, имеют
метку времени в формате UTC. Для этого вы можете просто воспользоваться любым онлайн-сервисом точного мирового времени (например, поиском в Google по запросу «текущее время UTC»). На момент
написания этого абзаца текущим всемирным координированным временем было 16:41 8 апреля 2021 года. После преобразования в формат,
который Elasticsearch ожидает для индекса kibana_sample_data_logs, оно
будет иметь следующий вид:
"timestamp": "2021-04-08T16:41:00.000Z"

2. Давайте теперь вставим несколько новых фиктивных документов
в хранилище kibana_sample_data_logs с меткой текущего времени (возможно, с небольшим буфером – округляя до следующей половины часа,
в данном случае до 17:00). Замените значение поля timestamp на значение своего текущего времени по UTC и вызовите следующую команду
не менее 20 раз в консоли Dev Tools для вставки документов:
POST kibana_sample_data_logs/_doc
{
"timestamp": "2021-04-08T17:00:00.000Z",
"event.dataset" : "sample_web_logs",

Powered by TCPDF (www.tcpdf.org)

180  Создание и использование оповещений
"clientip": "0.0.0.0",
"response" : "404",
"url": ""
}

3. Далее вы можете динамически изменять только те документы, которые
вы только что вставили (в частности, поле url), чтобы имитировать
уникальность всех URL, используя небольшой скрипт для рандомизации значения поля в вызове API _update_by_query:
POST kibana_sample_data_logs/_update_by_query
{
"query": {
"term": {
"clientip": {
"value": "0.0.0.0"
}
}
},
"script": {
"lang": "painless",
"source": "ctx._source.url = '/path/to/'+ UUID.
randomUUID().toString();"
}
}

4. Вы можете убедиться, что правильно создали набор уникальных случайных запросов с нашего фиктивного IP-адреса, посмотрев данные за
нужное время в Kibana Discover (рис. 6.18).
5. Обратите внимание на рис. 6.18, что нам пришлось немного заглянуть в будущее, чтобы увидеть документы, которые были вставлены
вручную (поскольку красная вертикальная линия на временной шкале около 12:45 является фактическим текущим системным временем
в местном часовом поясе). Также обратите внимание, что вставленные
нами документы имеют вполне корректно выглядящие случайные значения в поле url. Теперь, когда вы «заложили ловушку» для обнаружения аномалий и у вас есть готовые оповещения, вы можете просто
сидеть, спокойно пить кофе и ждать, пока они сработают.

Получение и просмотр оповещений
Пока добавленное вами аномальное поведение ожидает обнаружения, вы
можете подумать о том, в какой момент времени должны увидеть оповещение. Учитывая, что период времени заданий составляет 1 час, частота равна
10 мин, а задержки запросов составляют порядка 1–2 мин (при условии что
ваши оповещения действительно будут искать промежуточные результаты
и что они действительно выполняются с периодичностью 10 мин асинхронно
по отношению к заданию обнаружения аномалий), вы должны ожидать появления оповещений между 13:12 и 13:20 по местному времени.

Создание оповещений из интерфейса машинного обучения  181

Так и есть – оповещения для двух заданий поступают в Slack в 13:16 и 13:18
по местному времени (рис. 6.19).

Текущее системное время
Случайные значения URL

Наша имитация аномалии

Рис. 6.18  Фиктивный всплеск аномальных событий, показанный в Discover

Верхнее оповещение на рис. 6.19, очевидно, предназначено для задания
по обнаружению аномалий, которое подсчитывало количество событий для
каждого response.keyword (поэтому было замечено, что количество документов с ответом 404 превышает ожидания), а нижнее оповещение – для другого задания, которое замечает аномально большое количество обращений
к уникальным URL-адресам. Обратите внимание, что оба задания правильно
определяют clientip = 0.0.0.0 как фактор, влияющий на аномалии. В тексте
оповещения предусмотрена возможность перейти по ссылке для прямого
просмотра информации в Anomaly Explorer. Перейдя по ссылке во втором
оповещении, вы попадаете в знакомое место для дальнейшего исследования
аномалии (рис. 6.20).

182  Создание и использование оповещений

Рис. 6.19  Оповещения, полученные в клиенте Slack

Рис. 6.20  Окно Anomaly Explorer после перехода по ссылке из оповещения

Создание оповещений с помощью Watcher  183

С помощью этого примера вы не только увидели, как использовать оповещения с применением фреймворка оповещения Kibana для заданий по
обнаружению аномалий, но и смогли оценить тонкости работы как задания,
так и оповещения в реальном времени. Настройки в потоке данных задания
и интервале выборки оповещений действительно влияют на то, насколько
близки к реальному времени могут быть оповещения. Мы могли бы, например, уменьшить значение параметра frequency и отключить опцию Check
every в настройках оповещения, чтобы сэкономить несколько минут.
В следующем разделе мы не будем пытаться воспроизвести создание оповещений в реальном времени с помощью Watcher, но постараемся разобраться в соответствующих настройках, чтобы связать Watcher с заданием
обнаружения аномалий, а также продемонстрировать несколько интересных
примеров применения.

созДание оповещений с помощью WaTchEr
До версии 7.12 Watcher использовался как механизм оповещения об аномалиях, обнаруженных Elastic ML. Watcher – это очень гибкий собственный
плагин для Elasticsearch, который может обрабатывать ряд задач автоматизации, а оповещения, безусловно, являются одной из них. В версиях 7.11
и более ранних пользователи могли либо создать свои собственные задания
watch (экземпляр задачи автоматизации в Watcher) с нуля, чтобы оповещать
о результатах задания по обнаружению аномалий, либо выбрать шаблон
watch по умолчанию, созданный с помощью пользовательского интерфейса
Elastic ML. Сначала мы рассмотрим вариант, предлагаемый по умолчанию,
а затем обсудим некоторые идеи, касающиеся пользовательских экземпляров watch.

Использование устаревшего варианта watch
Теперь, когда оповещение о заданиях по обнаружению аномалий обрабатывается новой платформой оповещения Kibana, устаревший шаблон watch
по умолчанию (плюс несколько других примеров) размещен в репозитории GitHub по адресу https://github.com/elastic/examples/tree/master/Alerting/
Sample%20Watches/ml_examples.
Анализируя содержимое файла шаблона по умолчанию default_ml_watch.
json и сопутствующую версию, в которой есть оповещение по электронной
почте (default_ml_watch_email.json), мы видим, что они состоят из четырех
основных разделов:





trigger – определяет расписание watch;
input – определяет входные данные для оценки;
condition – оценивает, надо ли выполнять раздел actions;
actions – список действий, которые необходимо предпринять, если условие condition выполнено.

184  Создание и использование оповещений
Полное описание всех возможностей Watcher вы можете найти в документации по
Elastic по адресу https://www.elastic.co/guide/en/elasticsearch/reference/current/howwatcher-works.html.

Далее мы подробно обсудим каждый раздел.

trigger
В шаблонах Watcher для ML по умолчанию раздел trigger определяется следующим образом:
"trigger": {
"schedule": {
"interval": "82s"
}
},

Здесь мы видим, что интервал срабатывания данного экземпляра watch
в реальном времени составляет 82 секунды. Обычно это должно быть случайное значение от 60 до 120 секунд, чтобы при перезапуске узла все экземпляры watch не были синхронизированы и у каждого из них было свое время
выполнения, распределенное более-менее равномерно, чтобы снизить потенциальную пиковую нагрузку на кластер. Также важно, чтобы это значение
интервала было меньше или равно промежутку времени выполнения задания. Как было сказано ранее в этой главе, если он больше, чем длительность
сегмента, Watcher может пропустить недавно сделанные записи об аномалиях. Поскольку интервал меньше (или даже намного меньше), чем период
задания, вы также можете воспользоваться преимуществами расширенного
оповещения, которое доступно при наличии промежуточных результатов,
т. е. аномалий, которые можно определить, даже если вы не просмотрели все
данные в пределах сегмента.

input
Раздел input начинается с секции search, в которой определяется следующий
запрос по шаблону индекса .ml-anomalies-*:
"query": {
"bool": {
"filter": [
{
"term": {
"job_id": ""
}
},
{
"range": {
"timestamp": {
"gte": "now-30m"
}

Создание оповещений с помощью Watcher  185
}
},
{
"terms": {
"result_type": [
"bucket",
"record",
"influencer"
]
}
}
]
}
},

Здесь мы просим Watcher запрашивать документы bucket, record и influencer для задания (вы должны заменить фактическим job_id для интересующего задания по обнаружению аномалий) за последние 30 мин. Как
было сказано ранее в этой главе, это окно ретроспективного анализа должно
быть в два раза больше значения bucket_span задания ML (данный шаблон
предполагает, что период сегмента задания составляет 15 мин). Хотя были
запрошены все типы результатов, позже вы увидите, что только результаты
уровня сегмента (bucket) используются для оценки того, следует ли создавать
оповещение.
Далее следует серия из трех агрегаций. В свернутом состоянии они выглядят, как показано на рис. 6.21.

Рис. 6.21  Агрегации запросов на входе watch

Агрегация bucket_results сначала фильтрует сегменты, в которых оценка
аномалии больше или равна 75:
"aggs": {
"bucket_results": {
"filter": {
"range": {
"anomaly_score": {
"gte": 75
}
}
},

186  Создание и использование оповещений
Затем субагрегация запрашивает первый сегмент из списка, отсортированного по значению anomaly_score:
"aggs": {
"top_bucket_hits": {
"top_hits": {
"sort": [
{
"anomaly_score": {
"order": "desc"
}
}
],
"_source": {
"includes": [
"job_id",
"result_type",
"timestamp",
"anomaly_score",
"is_interim"
]
},
"size": 1,

Затем в субагрегации top_bucket_hits следует ряд определений script_
fields:
"script_fields": {
"start": {
"script": {
"lang": "painless",
"source": "LocalDateTime.
ofEpochSecond((doc[\"timestamp\"].value.getMillis()((doc[\"bucket_span\"].value * 1000)\n * params.padding)) /
1000, 0, ZoneOffset.UTC).toString()+\":00.000Z\"",
"params": {
"padding": 10
}
}
},
"end": {
"script": {
"lang": "painless",
"source": "LocalDateTime.
ofEpochSecond((doc[\"timestamp\"].value.
getMillis()+((doc[\"bucket_span\"].value * 1000)\n * params.
padding)) / 1000, 0, ZoneOffset.UTC).toString()+\":00.000Z\"",
"params": {
"padding": 10
}
}

Создание оповещений с помощью Watcher  187
},
"timestamp_epoch": {
"script": {
"lang": "painless",
"source": """doc["timestamp"].
value.getMillis()/1000"""
}
},
"timestamp_iso8601": {
"script": {
"lang": "painless",
"source": """doc["timestamp"].
value"""
}
},
"score": {
"script": {
"lang": "painless",
"source": """Math.
round(doc["anomaly_score"].value)"""
}
}
}

Эти вновь определенные переменные будут использоваться механизмом
Watcher для обеспечения большей функциональности в контексте задания.
Некоторые из переменных представляют собой значения в другом формате
(score – это просто округленная версия anomaly_score), в то время как start
и end сыграют свою роль позже, определяя время начала и окончания, которые вычисляются как ±10 длительностей сегмента с момента аномального
сегмента. Позже эти значения понадобятся пользовательскому интерфейсу, чтобы показать соответствующий контекстный временной диапазон
до и после аномального сегмента, чтобы пользователь увидел более ясную
картину.
Агрегации influencer_results и record_results запрашивают три верхние
оценки на уровнях фактора влияния и записи, но только результат агрегирования record_results используется в последующих частях экземпляра
watch (и только в разделе actions файла default_ml_watch_email.json, который
содержит некоторый текст электронной почты по умолчанию).

condition
Раздел condition – это место, где input проверяется на соответствие условиям,
при которых нужно выполнить действие action. В этом случае раздел условий
выглядит следующим образом:
"condition": {
"compare": {
"ctx.payload.aggregations.bucket_results.doc_count": {

188  Создание и использование оповещений
"gt": 0
}
}
},

В данном случае выполняется проверка, вернула ли агрегация bucket_results какие-либо документы (где doc_count больше 0). Другими словами, если
агрегация bucket_results вернула ненулевые результаты, это означает, что
существуют документы, в которых значение anomaly_score превышает 75. Если
это так, то будет вызвана секция action.

action
Раздел action по умолчанию в нашем случае состоит из двух частей: действие log для записи информации журнала в файл и действие send_email
для отправки электронного письма. Для краткости мы не будем приводить
здесь текст экземпляра watch (там действительно много текста). Действие log
распечатает сообщение в выходной файл, который по умолчанию является
файлом журнала Elasticsearch. Обратите внимание, что синтаксис сообщения использует язык шаблонов под названием Mustache (названный так изза частого использования фигурных скобок – mustache, англ. язык). Проще
говоря, переменные, помещенные в двойные фигурные скобки Mustache,
будут заменены их фактическими значениями. В результате для одного из
примеров заданий, которые мы создали ранее в этой главе, текст журнала,
записанный в файл, может выглядеть следующим образом:
Alert for job [alert-demo-response_code_rates] at
[2021-04-08T17:00:00.000Z] score [91]

Это оповещение выглядит весьма похожим на сообщение Slack ранее
в этой главе – ведь оно основано на той же информации. Оповещение по
электронной почте может выглядеть следующим образом:
Elastic Stack Machine Learning Alert
Job: alert-demo-response_code_rates
Time: 2021-04-08T17:00:00.000Z
Anomaly score: 91
Click here to open in Anomaly Explorer.
Top records:
count() [91]

Очевидно, что данное сообщение предназначено не для краткого пересказа информации пользователю, а для того, чтобы побудить его продолжить
исследование, щелкнув ссылку в электронном письме.
Кроме того, следует отметить, что в тексте сообщения по электронной почте указаны первые три записи. В нашем примере есть только одна запись
(детектор count с оценкой 91). Эта информация получена из агрегации record_results, которую мы описали ранее в разделе input.
Данный шаблон watch, используемый по умолчанию, является хорошим
и полезным оповещением, которое предоставляет обобщенную информа-

Создание оповещений с помощью Watcher  189

цию о необычности набора данных с течением времени, но также полезно
понимать особенности использования этого шаблона:
 основное условие для срабатывания оповещения – оценка аномалии
сегмента выше определенного значения. Следовательно, оно не будет
предупреждать об отдельных аномальных записях в сегменте в случае,
если их оценка не поднимает общую оценку сегмента выше установленного порога;
 по умолчанию в выходных данных указывается не более трех наивысших оценок в сегменте, и только в версии для электронной почты;
 выбор доступных действий в этих примерах ограничен – только запись
в журнал и отправка сообщения по электронной почте. Добавление
других действий (сообщение Slack, веб-сокет и т. д.) потребует ручного
редактирования шаблона.
В какой-то момент вам может понадобиться более полнофункциональный
и сложный шаблон для полной настройки поведения экземпляра watch. Далее
мы обсудим еще несколько примеров создания конфигураций watch с нуля.

Пользовательские шаблоны watch с уникальной
функциональностью
Энтузиастам, которые хотят глубже изучить возможности Watcher, мы предлагаем рассмотреть несколько других примеров, представленных в репозитории GitHub. К ним относятся примеры одновременного запроса результатов нескольких заданий, программного объединения оценок аномалий
и динамического сбора дополнительных указаний на первопричины других
аномалий, коррелированных во времени.

Связанный ввод и сценарий условий
Хорошим примером интересного шаблона является multiple_jobs_watch.json,
который демонстрирует возможность выполнения связанного ввода (выполнения нескольких запросов к результатам нескольких заданий), а также
обработки более сложного динамического условия с помощью сценария:
"condition" : {
"script" : {
// возвращает true, только если совокупная взвешенная оценка превышает 75
"source" : "return ((ctx.payload.job1.aggregations.max_
anomaly_score.value * 0.5) + (ctx.payload.job2.aggregations.
max_anomaly_score.value * 0.2) + (ctx.payload.job3.
aggregations.max_anomaly_score.value * 0.1)) > 75"
}
},

Фактически этот сценарий означает, что оповещение срабатывает только
в том случае, если совокупная взвешенная оценка аномалий трех разных за-

190  Создание и использование оповещений
даний превышает значение 75. Другими словами, не все задания считаются
одинаково важными, и учитывается вес каждого задания.

Передача информации между связанными входами
Еще одним уникальным аспектом связанных входных данных является то,
что информация, полученная из одного входного потока, может передаваться в другой поток. Как показано в chained_watch.json, второй и третий входные потоки используют значение метки времени, полученной из первого
запроса, как часть фильтра range:
{ "range": { "timestamp": {"gte": "{{ctx.payload.job1.hits.
hits.0._source.timestamp}}||-{{ctx.metadata.lookback_window}}",
"lte": "{{ctx.payload.job1.hits.hits.0._source.timestamp}}"}}},

Фактически это означает, что Watcher собирает вторичные аномалии в качестве свидетельств, извлеченных из временного окна, отмеренного до предположительно важной аномалии первого задания. Данный вид оповещений
хорошо согласуется с ситуацией, которую мы скоро обсудим в главе 7. Это
анализ, в котором реальная проблема приложения решается путем поиска
коррелированных аномалий в окне вокруг аномалии KPI. Пример вывода
такого шаблона Watcher может выглядеть следующим образом:
[CRITICAL] Anomaly Alert for job it_ops_kpi: score=85.4309 at
2021-02-08 15:15:00 UTC
Possibly influenced by these other anomalous metrics (within
the prior 10 minutes):
job:it_ops_network: (anomalies with at least a record score of
10):
field=In_Octets: score=11.217614808972602,
value=13610.62255859375 (typical=855553.8944717721) at 2021-0208 15:15:00 UTC
field=Out_Octets: score=17.00518, value=1.9079535783333334E8
(typical=1116062.402864764) at 2021-02-08 15:15:00 UTC
field=Out_Discards: score=72.99199, value=137.04444376627606
(typical=0.012289061361553099) at 2021-02-08 15:15:00 UTC
job:it_ops_sql: (anomalies with at least a record score of 5):
hostname=dbserver.acme.com field=SQLServer_Buffer_Manager_
Page_life_expectancy: score=6.023424, value=846.0000000000005
(typical=12.609336298838242) at 2021-02-08 15:10:00 UTC
hostname=dbserver.acme.com field=SQLServer_Buffer_Manager_
Buffer_cache_hit_ratio: score=8.337633, value=96.93249340057375
(typical=98.93088463835487) at 2021-02-08 15:10:00 UTC
hostname=dbserver.acme.com field=SQLServer_General_Statistics_
User_Connections: score=27.97728, value=168.15000000000006
(typical=196.1486370757187) at 2021-02-08 15:10:00 UTC

Здесь форматированием вывода, который сопоставляет результаты каждой из трех полезных нагрузок, управляет объемный сценарий transform,
реализованный на Java-подобном языке сценариев Painless.

Заключение  191
Дополнительную информацию о языке сценариев Painless вы можете найти в документации Elastic по адресу https://www.elastic.co/guide/en/elasticsearch/reference/
current/modules-scriptingpainless.html.

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

заключение
Задания по обнаружению аномалий, безусловно, полезны сами по себе, но
в сочетании с оповещениями в режиме, близком к реальному времени, пользователи могут использовать возможности автоматического анализа, при
этом будучи уверенными в получении только значимых оповещений.
Изучив приемы эффективной фиксации результатов заданий по обнаружению аномалий с помощью оповещений в реальном времени, мы рассмотрели подробный пример использования новой инфраструктуры оповещений
Kibana для простого определения некоторых интуитивно понятных оповещений и протестировали их с помощью реалистичного сценария. Затем рассмотрели примеры того, как опытный пользователь может использовать всю
мощь Watcher для создания расширенных оповещений, если возможности
Kibana не удовлетворяют его потребности.
В следующей главе вы увидите, как задания по обнаружению аномалий
способствуют не только оповещению о важных ключевых показателях производительности, но и автоматическому анализу широкого набора данных
при помощи Elastic ML, который в контексте конкретного приложения становится средством достижения чего-то наподобие «искусственного интеллекта», занятого отслеживанием проблемы приложения и определением ее
первопричины.

Глава

7
Выявление истинных
причин аномалий

До этого момента мы подробно объясняли ценность обнаружения аномалий
отдельно по метрикам и журналам. Это, конечно, очень важно. Однако в некоторых случаях знание того, что конкретная метрика или файл журнала
содержит аномалии, не раскрывает нам полную картину происходящего. Например, аномалия может указывать на симптом, а не на причину проблемы.
Чтобы лучше понять весь объем возникающей проблемы, часто бывает полезно изучить разные аспекты системы или взглянуть на ситуацию целиком.
Этот подход включает в себя одновременный «интеллектуальный» анализ
нескольких видов связанных наборов данных.
В этой главе рассмотрим следующие темы:







истинное значение термина AIOps;
понимание важности и ограничений KPI;
выход за рамки KPI;
организация данных для анализа;
использование контекстной информации;
переход к RCA.

технические требования
Информация и примеры, представленные в данной главе, актуальны для версии 7.11 Elastic Stack и используют образцы наборов данных из репозитория
GitHub, которые можно найти по адресу https://github.com/PacktPublishing/
Machine-Learning-with-Elastic-Stack-Second-Edition.

настоящее значение термина aIOPs
В главе 1 вы узнали, что многие компании захлебываются в постоянно растущем потоке IT-данных, при этом от них требуют «делать больше с меньшими
затратами» (меньше людей, меньше расходов и т. д.). Часть этих данных со-

Настоящее значение термина AIOps  193

бирают и/или хранят с применением специализированных инструментов
и платформ, но некоторые данные могут быть собраны на платформах данных общего назначения, таких как Elastic Stack. Остается открытым вопрос:
какому проценту этих данных уделяется достаточное внимание? Мы имеем
в виду долю собранных данных, которые активно проверяются людьми или
отслеживаются с помощью автоматизированных средств (оповещения на основе правил, пороговых значений и т. д.). Даже оптимистичные оценки этой
доли данных ограничиваются однозначными числами. Так почему же 90 %
или более собираемых данных остаются без внимания? Правильный ответ
заключается в том, что мы на самом деле не знаем всех причин.
Прежде чем упрекать IT-организации в том, что они собирают кучу данных, но не анализируют их, нам необходимо понять масштаб проблем, связанных с этими операциями. Типичное пользовательское приложение может
делать следующее:
 охватывать сотни физических серверов;
 иметь десятки (если не сотни) микросервисов, каждый из которых может иметь десятки или сотни операционных показателей или записей
журнала, описывающих его работу.
Комбинация этих показателей легко дает нам шести- или семизначное
количество уникальных точек измерения. Больше того, под управлением
IT-организации могут быть десятки или даже сотни таких приложений. Неудивительно, что количество данных, собираемых этими системами за день,
можно легко измерить в терабайтах.
Поэтому вполне естественно, что подходящее решение может заключаться в сочетании автоматизации и искусственного интеллекта, чтобы уменьшить нагрузку на аналитиков. Какой-то умный маркетолог придумал термин
AIOps1, чтобы обозначить предполагаемое решение проблемы – делать то,
что люди не могут (или не имеют времени) сделать вручную, при помощи
интеллектуальной автоматизации. То, что на самом деле делает решение
AIOps для достижения этой цели, часто остается на усмотрение взыскательного пользователя.
Итак, давайте разберемся в том, что на самом деле скрывается за сокращением AIOps, а красивые термины оставим маркетологам. Мы сформулируем
перечень функций, которые должна выполнять интеллектуальная технология, чтобы помочь нам в трудной ситуации с обработкой данных:
 автономно проверять данные и оценивать их актуальность, важность
и значимость на основе автоматически изученного набора ограничений, правил и поведения;
 отфильтровывать шум не относящегося к делу поведения, чтобы не отвлекать аналитиков от вещей, которые действительно имеют значение;
 вырабатывать нужное количество опережающих (прогнозных) оповещений о проблемах, которые назревают, но пока не привели к сбою
или отказу;
1

Arttificial Intellect for IT Operations – деятельность по обработке и использованию
данных в IT с применением искусственного интеллекта. – Прим. перев.

194  Выявление истинных причин аномалий
 автоматически собирать связанные/коррелированные свидетельства
о наличии проблемы, чтобы помочь с анализом первопричин (root cause
analysis, RCA);
 выявлять проблемы эксплуатационной эффективности для максимального повышения производительности инфраструктуры;
 предлагать действие или последовательность действий для исправления, основываясь на прошлых исправлениях и их эффективности.
Хотя этот список никоим образом не является исчерпывающим, мы можем сделать главный вывод – внедрение интеллектуальной автоматизации
и анализа способно принести большую отдачу, позволяя IT-подразделениям
значительно повысить эффективность и, таким образом, максимизировать
бизнес-результаты.
Платформа Elastic ML (Elastic Machine Learning) может играть важную роль
в реализации почти всех вышеупомянутых функций, за исключением разве
что последнего пункта в списке. Вы уже видели, как Elastic ML может автоматически обнаруживать аномальное поведение, прогнозировать тенденции,
вырабатывать прогнозные оповещения и т. д. Но мы также должны признать,
что Elastic ML является платформой машинного обучения общего назначения – это не специализированный инструмент для IT-операций/наблюдения
или аналитики безопасности. В связи с этим важно иметь исчерпывающее
представление о том, как Elastic ML используется в контексте деятельности
IT-подразделений.
Также важно отметить, что до сих пор существует большое количество
операционных IT-подразделений, которые в настоящее время не используют интеллектуальную автоматизацию и анализ. Они часто заявляют, что
хотели бы использовать подход на основе ИИ для улучшения своей работы,
но не совсем готовы сделать решительный шаг. Итак, давайте попробуем
опровергнуть расхожее представление о том, что единственный способ
извлечь выгоду из ИИ – это сделать и внедрить все, что возможно, за один
день. Давайте вместо этого создадим несколько практических приложений
Elastic ML в контексте IT-операций и посмотрим, как их можно использовать для достижения большинства целей, сформулированных в предыдущем списке.
Мы начнем с понятия ключевого показателя эффективности (key performance indicator, KPI) и пояснения, почему это наилучший и логичный выбор
для начала работы с Elastic ML.

значимость и ограничения KPI
Если вы стремитесь решить проблему масштабирования и добиться заметного прогресса в практическом применении собранных данных, то в первую очередь нужно обратить внимание на показатели, которые являются
лучшими индикаторами производительности и работоспособности. Ключевые показатели эффективности, которые IT-организация выбирает для

Значимость и ограничения KPI  195

измерения, отслеживания и оповещений, могут быть очень разнообразными, например:
 качество обслуживания клиентов – эта группа показателей отражает
качество обслуживания клиентов в числовой форме, такой как время
отклика приложений или количество ошибок;
 доступность – часто бывает важно отслеживать такие показатели, как
время безотказной работы или среднее время простоя (mean time to
repair, MTTR);
 бизнес – в эту группу могут входить показатели, которые напрямую
измеряют эффективность бизнеса, например количество заказов в минуту или количество активных пользователей.
Как правило, эти типы показателей обычно отображаются на первом плане
и в центре на большинстве операционных панелей мониторинга высокого
уровня или в отчетах для всех сотрудников, от технических специалистов до
руководителей. Поиск изображений в Google по фразе KPI dashboard (информационная панель KPI) вернет бесчисленное количество примеров диаграмм,
датчиков, циферблатов, карт и других приятных для глаз визуализаций.
Несмотря на то что визуальное представление информации, которое можно охватить одним взглядом, имеет большую ценность, ручная проверка
показателей по-прежнему сопряжена с фундаментальными проблемами:
 интерпретация – могут возникнуть трудности с пониманием разницы
между нормальной работой и ненормальной, если только человек не
знает этого заранее;
 проблемы масштабирования – несмотря на то что KPI уже представляет собой концентрированную выборку наиболее важных показателей, нередко возникает ситуация, когда показателей KPI больше, чем
можно отобразить на одной панели мониторинга. В итоге вы можете
получить перегруженную визуализацию или же длинные информационные панели, требующие прокрутки либо разбиения по страницам;
 отсутствие проактивности – многие информационные панели не
имеют возможности привязывать показатели к оповещениям (особенно к проактивным, т. е. прогнозным, работающим на опережение),
поэтому требуется постоянное наблюдение со стороны человека, если
заранее известно, что важен нестабильный ключевой показатель эффективности.
Иными словами, правильный выбор и измерение KPI – чрезвычайно важный шаг в процессе выявления и отслеживания значимых индикаторов работоспособности и поведения IT-системы. Однако должно быть очевидно, что
простое определение и отслеживание набора KPI с использованием только
прямой визуализации не лишено существенных недостатков.
Мы утверждаем, что KPI – отличный кандидат на роль показателей, которые можно отслеживать с помощью механизма обнаружения аномалий
Elastic ML. Например, предположим, что у нас есть данные, которые выглядят следующим образом (фрагмент набора данных it_ops_kpi в репозитории
GitHub):

196  Выявление истинных причин аномалий
{
''_index'' : ''it_ops_kpi'',
''_type'' : ''_doc'',
''_id'' : ''UqUsMngBFOh8A28xK-E3'',
''_score'' : 1.0,
''_source'' : {
''@timestamp'' : ''2021-01-29T05:36:09.000Z'',
''events_per_min'' : 28,
''kpi_indicator'' : ''online_purchases''
}
},

В данном случае KPI (поле с именем events_per_min) представляет собой
суммарное общее количество покупок в минуту для некоторой онлайн-системы обработки транзакций. Мы можем без труда отслеживать изменения
этого KPI с течением времени с помощью задания по обнаружению аномалий
с функцией суммирования по полю events_per_min и промежутком времени
в 15 мин. Неожиданный спад онлайн-продаж (до 921) обнаружен и помечен
как аномальный (рис. 7.1).

Рис. 7.1  Анализ KPI с помощью типичного задания по обнаружению аномалий

Здесь KPI – это всего лишь единый обобщенный показатель. Если в данных есть другое категориальное поле, которое позволяет сегментировать
показатель (например, продажи по идентификатору продукта, по категории

Выходя за рамки KPI  197

продукта, по географическому региону и т. д.), то ML может легко разделить
анализ по этому полю на параллельные ветви анализа (как было показано
в главе 3). Но давайте не будем отвлекаться от того, на чем мы сейчас сосредоточены: упреждающий анализ ключевого показателя, который кого-то,
вероятно, волнует. Количество онлайн-продаж в единицу времени напрямую
связано с поступающей выручкой и, следовательно, является очевидным KPI.
Однако, несмотря на важность понимания того, что с нашим KPI происходит что-то необычное, до сих пор нет понимания того, почему это происходит. Может быть, возникли проблемы в работе одной из серверных систем,
обслуживающих это клиентское приложение? Или в новой версии пользовательского интерфейса возникла ошибка, из-за которой пользователям было
сложнее завершить транзакцию? Или возникла проблема со сторонним поставщиком услуг обработки платежей? Ни на один из этих вопросов нельзя
ответить, просто изучив KPI.
Чтобы получить представление о реальной картине происходящего, нам
нужно будет расширить наш анализ, включив в него другие наборы релевантной и связанной информации.

выхоДя за рамки KPI
В целом процесс выбора KPI редко вызывает затруднения, поскольку обычно
очевидно, на какие показатели нужно обращать внимание в первую очередь
(если онлайн-продажи падают, приложение, скорее всего, не работает). Но
если мы хотим получить более полное представление о том, что послужило
причиной возникновения операционной проблемы, то придется расширить
наш анализ за пределы KPI и рассмотреть показатели, отражающие работу
базовых систем и технологий, поддерживающих приложение.
К счастью, существует множество способов сбора всех видов данных для
последующего централизованного анализа в Elastic Stack. Например, Elastic
Agent – это единый унифицированный агент, который можно развернуть
на узлах или контейнерах для сбора данных и отправки их в Elastic Stack. За
кулисами основного процесса Elastic Agent запускает службы доставки Beats
или Elastic Endpoint, необходимые для вашей конфигурации. Начиная с версии 7.11 Elastic Agent доступен в Kibana через пользовательский интерфейс
Fleet и может использоваться для добавления и управления интеграциями
популярных сервисов и платформ (рис. 7.2).
Используя различные интеграции, пользователь может легко собирать
данные и централизовать их в Elastic Stack. Хотя эта глава не содержит руководство по использованию Fleet и Elastic Agent, важным моментом является
то, что независимо от того, какие инструменты вы используете для сбора
базовых данных приложения и системы, несомненно одно: данных будет
много, очень много. Помните, что наша конечная цель – охватить вниманием
и подвергнуть упреждающему анализу как можно больший процент от общего набора данных. Но, чтобы подвергнуть эти данные наиболее эффективному анализу с помощью Elastic ML, их необходимо правильно организовать.

198  Выявление истинных причин аномалий

Рис. 7.2  Раздел интеграции в пользовательском интерфейсе Fleet

организация Данных Для анализа
Одна из самых приятных особенностей сбора данных через Elastic Agent
заключается в том, что по умолчанию собранные данные нормализуются
с использованием обобщенной схемы Elastic (Elastic Common Schema, ECS).
ECS – это спецификация с открытым исходным кодом, которая определяет общую таксономию и соглашения об именах для данных, хранящихся
в Elastic Stack. Благодаря этому данные становятся проще в управлении,
анализе, визуализации и выявлении корреляции между разными типами
данных, в том числе между показателями производительности и файлами
журналов.
Даже если вы не используете Elastic Agent или более старые инструменты
Elastic (такие как Beats и Logstash) и вместо этого полагаетесь на сторонние
процессы сбора или извлечения данных, все равно рекомендуется согласовывать свои данные со спецификацией ECS, потому что ваши усилия окупятся

Организация данных для анализа  199

в будущем, если пользователи будут использовать эти данные для запросов,
информационных панелей и, конечно же, для задач машинного обучения.
Более подробную информацию о ECS можно найти в справочном разделе веб-сайта
по адресу https://www.elastic.co/guide/en/ecs/current/ecs-reference.html.

Среди многих важных полей в ECS есть поле host.name, которое определяет, с какого хоста были собраны данные. По умолчанию большинство
стратегий сбора данных в Elastic Stack включают размещение данных в хранилищах, ориентированных на тип данных и, следовательно, потенциально
содержащих подборку документов с множества разных хостов. Возможно,
некоторые из хостов в нашей среде поддерживают одно приложение (например, онлайн-покупки), но другие хосты поддерживают другое приложение
(например, обработку счетов). Поскольку все хосты отправляют свои данные
в одно хранилище, если мы хотим составить отчет и провести анализ данных для какого-то одного или группы приложений, то не сможем ориентироваться только на хранилище – нам понадобится возможность различать
приложения.
Для этого у нас есть несколько вариантов:
 изменить запрос задания по обнаружению аномалий таким образом,
чтобы он фильтровал данные только для хостов, связанных с интересующим приложением;
 при сборе данных добавлять в каждый документ дополнительную контекстную информацию, которая позже будет применяться для фильтрации запроса, сделанного заданием обнаружения аномалий.
Оба способа требуют настройки запроса канала данных, который задание
обнаружения аномалий делает к необработанным данным в исходных хранилищах. Первый вариант может привести к относительно сложному запросу,
а второй вариант требует промежуточного этапа дополнения данных с использованием настраиваемых конвейеров. Кратко обсудим каждый вариант.

Настраиваемые запросы для каналов данных
Когда вы создаете новое задание в пользовательском интерфейсе обнаружения аномалий, первым делом нужно выбрать либо шаблон хранилища,
либо сохраненный поиск Kibana. Если выбрано первое, то вызывается запрос
Elasticsearch {''match_all'':{}} (возвращать каждую запись в хранилище).
Если задание создается с помощью API или мастера расширенных заданий,
пользователь может указать практически любой допустимый Elasticsearch
DSL для фильтрации данных. Создание произвольной формы Elasticsearch
DSL неопытными пользователями может привести к ошибкам. Более простым и понятным способом является использование сохраненных поисковых
запросов Kibana.
Например, предположим, что у нас есть хранилище файлов журналов,
а соответствующие хосты, связанные с приложением, которое мы хотим отслеживать и анализировать, состоят из двух серверов, esxserver1.acme.com

Powered by TCPDF (www.tcpdf.org)

200  Выявление истинных причин аномалий
и esxserver2.acme.com. На странице Discover (Обнаружение) Kibana мы можем
создать фильтрующий запрос на языке KQL, используя поле поиска в верхней
части пользовательского интерфейса (рис. 7.3).

Рис. 7.3  Построение фильтрующего запроса с использованием KQL

Текст этого KQL-запроса будет следующим:
physicalhost_name:''esxserver1.acme.com'' or physicalhost_
name:''esxserver2.acme.com''

Если вам интересно узнать о реальном Elasticsearch DSL, который вызывается Kibana для выполнения этого запроса, вы можете нажать кнопку Inspect
(Осмотр) в правом верхнем углу и выбрать вкладку Request (Запрос), чтобы
увидеть Elasticsearch DSL (рис. 7.4).
Вероятно, стоит отметить, что хотя в этом конкретном примереKQL-запрос
транслируется в Elasticsearch DSL (например, с использованием match_phrase),
это не единственный способ достичь желаемых результатов. Есть еще один
способ – фильтрация запроса с использованием terms, но оценка преимуществ того или иного способа выходит за рамки этой книги.
Независимо от Elasticsearch DSL, который работает на заднем плане, ключевой момент заключается в том, что у нас есть запрос, который фильтрует необработанные данные, выделяя только серверы, имеющие отношение
к приложению, которое мы хотели бы проанализировать с помощью Elastic ML. Чтобы сохранить этот отфильтрованный поиск, необходимо нажать
кнопку Save в правом верхнем углу и присвоить поиску имя (рис. 7.5).

Организация данных для анализа  201

Рис. 7.4  Просмотр содержания Elasticsearch DSL, выполняющего фильтр KQL

Рис. 7.5  Сохранение результатов поиска
для последующего использования в Elastic ML

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

202  Выявление истинных причин аномалий

Рис. 7.6  Использование сохраненного поиска
в задании по обнаружению аномалий

Таким образом, наша задача машинного обучения теперь будет выполняться только для хостов, представляющих интерес для этого конкретного
приложения. Мы смогли эффективно ограничить и сегментировать анализ
данных по хостам, которые, как мы определили, связаны с работой нужного
приложения.

Дополнение получаемых данных
Другой вариант – перенести принятие решения о том, какие хосты каким
приложениям принадлежат, на момент получения данных. Если частью процесса сбора данных является Logstash, вы можете использовать плагин фильтра для добавления дополнительных полей к данным при просмотре списка
активов (файл, база данных и т. д.). Обратитесь к документации Logstash по
адресу https://www.elastic.co/guide/en/logstash/current/lookup-enrichment.html,
где показано, как динамически дополнять помещаемые в хранилище документы уточняющими полями для формирования контекста. Если вы не использовали Logstash (а просто задействовали Beats/Elastic Agent и приемный
узел), возможно, более простым способом будет применение расширенной
обработки. За дополнительной информацией обратитесь к справочной документации по адресу https://www.elastic.co/guide/en/elasticsearch/reference/
current/ingest-enriching-data.html.
Например, вы можете добавить поле application_name и динамически заполнять значение этого поля соответствующим именем приложения (здесь
показан фрагмент JSON):
''host'': ''wasinv2.acme.com'',
''application_name'': ''invoice_processing'',

Или так:
''host'': ''www3.acme.com'',
''application_name'': ''online_purchases'',

Использование контекстной информации  203

После того как значение этого поля установлено и вставлено в сохраненные документы, вы должны использовать поле application_name вместе
с фильтрующим запросом для задания обнаружения аномалии (как описано
ранее), чтобы ограничить анализ данных нужным значением поля. Может
показаться, что дополнение данных требует лишних усилий, но они должны окупить себя в долгосрочной перспективе, поскольку этот метод легче
обновлять по мере изменения или расширения перечня имен активов, в то
время как первый метод требует жесткого кодирования имен активов при
отборе заданий ML.
Теперь, когда вы организовали свои данные и, возможно, даже дополнили
их, давайте посмотрим, как использовать контекстную информацию, чтобы
сделать задания по обнаружению аномалий более эффективными.

использование контекстной информации
Когда ваши данные организованы и дополнены, вы можете использовать
контекстную информацию двумя основными способами: с помощью аналитических разделений (split) и статистических факторов влияния (influencer).

Аналитическое разделение
Вы уже видели, что задание по обнаружению аномалий можно разделить по
любому категориальному полю. Таким образом, вы можете построить индивидуальную модель поведения отдельно для каждого экземпляра этого поля
(категории). Это может быть чрезвычайно ценно, особенно в случае, когда
каждому экземпляру нужна собственная модель.
Возьмем, к примеру, случай, когда у нас есть данные по разным регионам
мира (рис. 7.7).
Какими бы ни были данные (ключевые показатели эффективности продаж, показатели использования и т. д.), очевидно, что у них есть выраженные
особенности, уникальные для каждого региона. В этом случае имеет смысл
разделить по регионам любой анализ на обнаружение аномалий, чтобы извлечь пользу из этой уникальности, и тогда вы сможете обнаружить аномалии в поведении, характерные для каждого региона.
Давайте также представим, что в каждом регионе парк серверов поддерживает обработку приложений и транзакций, но они сбалансированы по
нагрузке и в равной степени влияют на производительность приложения
в целом. Следовательно, на вкладе каждого конкретного сервера нет ничего
уникального. Скорее всего, нет смысла разделять анализ по серверам.
Естественно, мы пришли к выводу, что разделение по регионам более эффективно, чем по серверам. Но что, если на конкретном сервере в регионе
возникают проблемы, напрямую влияющие на обнаруженные аномалии?
Разве вы не хотели бы, чтобы эта информация была доступна немедленно,
вместо того чтобы вручную проводить дальнейшую диагностику? Ответ можно получить, исследуя факторы влияния.

204  Выявление истинных причин аномалий

Рис. 7.7  Различное поведение данных в зависимости от региона

Статистические факторы влияния
Вы познакомились с факторами влияния в главе 5. Напомним, что фактор
влияния – это поле, описывающее сущность, о которой вы хотели бы знать,
влияет ли она на существование аномалии или, по крайней мере, вносит ли
в нее заметный вклад. Любое поле, выбранное в качестве кандидата на роль
фактора влияния, не обязательно должно быть частью логики детектора, хотя
имеет смысл в качестве факторов влияния выбирать поля, которые используются для разбиения. Также важно, чтобы факторы влияния были выбраны
при создании заданий по обнаружению аномалий, поскольку их невозможно
добавить в конфигурацию позже.
Нужно понимать, что процесс поиска потенциальных факторов влияния
происходит после того, как задание по обнаружению аномалий обнаружит
аномалию. Другими словами, это не влияет на вычисления вероятностей,
выполняемые в процессе обнаружения аномалии. После определения аномалии ML будет последовательно просматривать все экземпляры каждого поля
кандидата на фактор влияния и удалять вклад этого экземпляра в данные

Анализ первопричин аномалии  205

в определенном временном сегменте. Если после удаления оставшиеся данные больше не являются аномальными, то в соответствии с принципом исключения вклад этого экземпляра следует считать влиятельным и оценивать
соответствующим образом (со значением influencer_score в результатах).
Однако в следующем разделе вы увидите, как факторы влияния могут
быть задействованы при просмотре результатов не только одного задания
по обнаружению аномалии, но даже нескольких связанных заданий. Далее
мы рассмотрим процесс группирования и совместного просмотра заданий,
перетекающий в процесс анализа первопричин (RCA).

анализ первопричин аномалии
Сейчас настало время обсудить, как объединить полученные ранее знания
и навыки для построения комплексного процесса выявления причин аномалии. Если вы стремитесь повысить эффективность IT-операций и более
комплексно отслеживать работоспособность приложений, вам необходимо
применить на практике то, что вы узнали в предыдущих разделах, и соответствующим образом настроить задания по обнаружению аномалий. С этой
целью давайте рассмотрим реальный сценарий, в котором Elastic ML помог
найти первопричину эксплуатационного сбоя.

История проблемы
Этот сценарий в общих чертах основан на реальном сбое приложения, хотя
данные были несколько упрощены и очищены, чтобы скрыть настоящего
клиента. Проблема заключалась в приложении розничной торговли, которое обрабатывало транзакции по подарочным картам. Иногда приложение
внезапно переставало работать, и транзакции не обрабатывались. Причем
это становилось известно лишь тогда, когда отдельные магазины начинали звонить в штаб-квартиру компании, чтобы пожаловаться на неполадки.
Основная причина проблемы оставалась неизвестной, и клиент не мог ее
установить. Поскольку он так и не нашел первопричину и устранял сбой
простой перезагрузкой серверов приложений, проблема продолжала возникать в произвольные моменты времени и мучила клиента в течение нескольких месяцев.
Следующие данные были собраны и включены в анализ, чтобы понять
происхождение проблемы (они доступны в репозитории GitHub):
 обобщенный (1-минутный) подсчет объема транзакции (основной KPI);
 журналы приложений (частично структурированные текстовые сообщения) от механизма обработки транзакций;
 метрики производительности SQL сервера из базы данных, которая
обслуживает механизм обработки транзакций;
 метрики производительности использования сети, в которой работает
механизм обработки транзакций.

206  Выявление истинных причин аномалий
Таким образом, для анализа данных были настроены четыре задания машинного обучения:
 it_ops_kpi – использует функцию sum для подсчета количества транзакций, обрабатываемых за минуту;
 it_ops_logs – использует функцию count детектора mlcategory для подсчета количества сообщений журнала по типам, но применяет динамическую категоризацию на основе машинного обучения для определения различных типов сообщений;
 it_ops_sql – простой анализ среднего значения (mean) каждой метрики
SQL-сервера в хранилище;
 it_ops_network – простой анализ среднего значения (mean) каждой метрики производительности сети в хранилище.
Эти четыре задания были настроены и выполняли анализ данных, когда
в приложении возникла проблема. Были обнаружены аномалии, особенно
в KPI, отслеживающем количество обрабатываемых транзакций. Фактически
это тот же самый KPI, который вы видели в начале этой главы, где неожиданное падение количества обработанных заказов было основным индикатором
возникновения проблемы (рис. 7.8).

Рис. 7.8  KPI количества обработанных транзакций

Однако основная причина не была понятна до тех пор, пока аномалия
этого ключевого показателя эффективности не была сопоставлена с аномалиями в трех других заданиях машинного обучения, которые просматривали

Анализ первопричин аномалии  207

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

Корреляция и общие факторы влияния
Помимо аномалии в KPI обработанных транзакций (в которой происходит неожиданный провал), три других задания по обнаружению аномалий (производительность сети, журналы приложений и производительность SQL-сервера)
были наложены на тот же временной интервал в инструменте Anomaly Explorer. На следующем снимке экрана показаны результаты наложения (рис. 7.9).

Рис. 7.9  Anomaly Explorer отображает результаты нескольких заданий

В частности, обратите внимание, что в тот день, когда возникла проблема с KPI (8 февраля 2021 г., как показано на рис. 7.8), три других задания
на рис. 7.9 демонстрируют коррелированные аномалии (обведены красной
линией). При более детальном рассмотрении (нажав на красную плитку для
задания it_ops_sql) вы можете увидеть, что были проблемы с несколькими
метриками SQL-сервера, которые одновременно принимали аномальные
значения (рис. 7.10).

208  Выявление истинных причин аномалий

Рис. 7.10  Anomaly Explorer отображает аномалии SQL-сервера
Заштрихованная область диаграмм обозначает окно времени, связанное с шириной
выбранной плитки на строке просмотра. Это окно может быть больше, чем период
анализа (как в данном случае), и поэтому заштрихованная область может содержать
несколько отдельных аномалий в течение этого периода времени.

Если мы посмотрим на аномалии в задании по обнаружению аномалий
журнала приложения, то обнаружим много ошибок, и все они ссылаются на
базу данных, что дополнительно подтверждает нестабильность SQL-сервера
(рис. 7.11).
Однако интересные вещи происходили и в сети (рис. 7.12).
В частности, наблюдался большой всплеск сетевого трафика (представленный метрикой Out_Octets) и высокий всплеск количества пакетов, отбрасываемых на уровне сетевого интерфейса (представленный метрикой
Out_Discards).

Анализ первопричин аномалии  209

Рис. 7.11  Anomaly Explorer отображает аномалии в журнале приложения

На тот момент возникло явное подозрение, что этот скачок в сети может
иметь какое-то отношение к проблеме с базой данных. И хотя корреляция
не всегда является причинно-следственной связью, этого было достаточно,
чтобы побудить аналитиков вернуться к некоторым историческим данным
по предыдущим отключениям. При каждом предыдущем отключении также
наблюдался большой всплеск сетевого трафика и количества отвергнутых
пакетов.
Конечной причиной скачка трафика в сети оказалось решение по перемещению виртуальных машин VMware на новые серверы ESX. Кто-то неправильно сконфигурировал сетевой коммутатор, и VMware отправляла этот
массивный всплеск трафика через VLAN приложения вместо VLAN управления. Когда это происходило (конечно, в случайные моменты), приложение для обработки транзакций временно теряло соединение с базой данных и пыталось восстановить соединение. Однако в соответствующем коде
переподключения был критический недостаток, заключающийся в том, что
код не пытался переподключиться к базе данных по удаленному IP-адресу,
принадлежащему SQL-серверу. Вместо этого он пытался переподключиться
к localhost (IP-адрес 127.0.0.1), где, конечно же, такой базы данных не было.
Ключ к разгадке этой ошибки был замечен в одной из строк журнала, которые Elastic ML отображал в разделе Examples (Примеры), обведенном на
рис. 7.13.

210  Выявление истинных причин аномалий

Рис. 7.12  Anomaly Explorer отображает аномалии сетевых данных

Таким образом, после возникновения проблемы подключение к SQLсерверу было возможно только в том случае, если сервер приложений полностью перезагружен, файлы конфигурации запуска повторно прочитаны и IPадрес SQL-сервера правильно определен. Вот почему полная перезагрузка
всегда решала проблему.
Следует отметить, что факторы влияния в пользовательском интерфейсе
также помогают сузить круг потенциальных виновников аномалий (рис. 7.14).

Анализ первопричин аномалии  211

Рис. 7.13  Anomaly Explorer показывает основную причину
проблемы повторного подключения

Факторы влияния, набравшие наибольшее количество баллов за период
времени, выбранный на панели инструментов, перечислены в разделе Top
influencers слева. Для каждого фактора отображается максимальная оценка
(в любом сегменте) вместе с общей оценкой фактора за временной диапазон
панели мониторинга (суммируется по всем сегментам). И если несколько
заданий отображаются вместе, то те факторы влияния, которые являются
общими для разных заданий, имеют более высокие суммы, что поднимает
их рейтинг выше.
Это довольно важный момент, потому что теперь очень легко увидеть
общие черты в аномалиях разных заданий. Например, если esxserver1.acme.
com – единственный физический хост, который выступает в качестве фактора влияния при просмотре нескольких заданий, нам сразу понятно, на какой машине сосредоточиться; мы знаем, что это не очень распространенная
проблема.
В конце концов, заказчик смог устранить проблему, исправив неверную
конфигурацию сети и ошибку в коде переподключения к базе данных. Ему
удалось довольно быстро исключить рабочие версии и найти основную причину, потому что Elastic ML позволил сузить фокус расследования, тем самым
сэкономив время и предотвратив возникновение проблем в будущем.

212  Выявление истинных причин аномалий

заключение
Elastic ML, безусловно, может увеличить охват
данных, на которые IT-подразделения и организации обращают внимание, и, таким образом, существенно увеличить ценность всего объема собираемых данных. Возможность организовывать
данные, находить в них корреляции и комплексно
анализировать связанные аномалии по типам
данных имеет решающее значение для изоляции
проблем и выявления первопричин. Это сокращает время простоя приложения и уменьшает
вероятность повторения проблемы.
В следующей главе вы увидите, как другие приложения, входящие пакет в Elastic Stack (APM,
Security и Logs), используют Elastic ML, чтобы
обеспечить быстрое развертывание, адаптированное для конкретных случаев использования.

Рис. 7.14  Anomaly Explorer
показывает наиболее
значимые факторы влияния

Глава

8
Другие приложения
Elastic Stack
для обнаружения
аномалий

Когда два года назад было опубликовано первое издание этой книги, в Elastic Stack не существовало решений, использующих Elastic ML для поиска
аномалий в конкретной предметной области. Однако с тех пор Elastic ML
стал поставщиком средств обнаружения аномалий для доменных решений,
предоставляя индивидуальные конфигурации заданий, которые пользователи могут активировать одним щелчком мыши.
В этой главе мы рассмотрим, что Elastic ML привносит в различные приложения Elastic Stack:






обнаружение аномалий в Elastic APM;
обнаружение аномалий в приложении Logs;
обнаружение аномалий в приложении Metrics;
обнаружение аномалий в приложении Uptime;
обнаружение аномалий в приложении Elastic Security.

технические требования
Информация в этой главе актуальна для версии 7.12 Elastic Stack.

обнаружение аномалий в ElasTIc aPM
Elastic APM выводит мониторинг приложений и управление производительностью на совершенно новый уровень, позволяя пользователям оснащать
инструментальными средствами код своих приложений, чтобы получить

214  Другие приложения Elastic Stack для обнаружения аномалий
детальное представление о производительности отдельных микросервисов
и транзакций. В сложных средах это может привести к большому количеству
измерений и создать потенциально парадоксальную ситуацию – когда более
высокая наблюдаемость достигается за счет детализации измерений, но при
этом аналитик, которому приходится тщательно изучать полученные результаты, начинает тонуть в потоке данных.
К счастью, Elastic APM и Elastic ML – это союз, заключенный на небесах. Обнаружение аномалий не только автоматически адаптируется к уникальным
характеристикам каждого типа транзакции с помощью машинного обучения
без учителя, но также легко масштабируется для обработки больших объемов
данных, которые может генерировать APM.
Хотя пользователь всегда может создавать задания по обнаружению аномалий для любых данных временных рядов в любом хранилище, независимо от типа, есть веский аргумент в пользу того, чтобы просто использовать
готовые конфигурации заданий для данных Elastic APM, поскольку формат
данных уже известен.

Включение обнаружения аномалий для APM
Чтобы воспользоваться преимуществом обнаружения аномалий в данных
APM, вам, очевидно, необходимо иметь данные APM, собранные для определенных объявленных служб, и иметь собранные данные, размещенные
в хранилищах, доступных через шаблон хранилища apm-*.
1. Если вы еще не настроили обнаружение аномалий в своих данных APM,
вы увидите индикатор в верхней части экрана, сообщающий, что его
необходимо настроить (рис. 8.1).

Рис. 8.1  Индикатор, показывающий,
что обнаружение аномалий еще не включено в APM

2. Чтобы продемонстрировать, как будет выглядеть конфигурация обнаружения аномалий, было создано простое приложение в стиле Hello
World для Node.js, обслуживаемое Elastic APM. Это приложение (под
названием myapp) также было помечено тегом среды dev, чтобы обозначить, что оно является приложением для разработки (все это делается
в агенте APM для конфигурации Node.js) (рис. 8.2).

Обнаружение аномалий в Elastic APM  215

Рис. 8.2  Пример приложения Node.js, оснащенного Elastic APM

3. При просмотре внутри Elastic APM служба будет выглядеть, как показано на рис. 8.3.

Рис. 8.3  Пример приложения Node.js
в пользовательском интерфейсе Elastic APM

4. Чтобы включить обнаружение аномалий для этой службы, просто перейдите в Settings (Настройки), нажмите Anomaly detection (Обнаружение аномалий), а затем нажмите кнопку Create ML Job (Создать
задание машинного обучения) (рис.8.4).

216  Другие приложения Elastic Stack для обнаружения аномалий

Рис. 8.4  Создание заданий машинного обучения для данных APM

5. Затем укажите имя среды, для которой вы хотите создать задание
(рис. 8.5).

Рис. 8.5  Указание среды, для которой создается задание машинного обучения

6. Здесь мы выберем dev, так как это единственный вариант, доступный
для нашего приложения. После выбора среды и нажатия кнопки Create
Jobs (Создать задание) мы получаем подтверждение, что задание было
создано и оно указано в таблице (рис. 8.6).

Обнаружение аномалий в Elastic APM  217

Риc. 8.6  Список созданных заданий обнаружения аномалий в APM

7. Если мы перейдем в приложение Elastic ML, чтобы просмотреть сведения о задании, которое было создано для нас, то увидим экран как на
рис. 8.7.

Рис. 8.7  Список созданных заданий по обнаружению аномалий в ML

8. Продолжая изучать задание, мы можем увидеть фактическую конфигурацию детектора (рис. 8.8).

218  Другие приложения Elastic Stack для обнаружения аномалий

Рис. 8.8  Конфигурация детектора для задания APM

Обратите внимание, что при этом используется функция high_mean
поля transaction.duration.us, разделенного как по transaction.type, так
и по service.name. Также заметим, что значение длительности сегмента
bucket_span для данного задания составляет 15 минут, что может быть,
а может и не быть идеальным параметром для вашей среды.
Следует отметить, что эта конфигурация является единственно возможной при использовании подхода одним щелчком из пользовательского интерфейса APM, поскольку конфигурация жестко запрограммирована. Если вы хотите настроить или
создать свои собственные конфигурации, вы можете либо создать их с нуля, либо
клонировать это задание и установить свой собственный диапазон сегмента и/или
логику детектора.

9. Мы можем щелкнуть вкладку Datafeed, чтобы увидеть следующие настройки потока запрашиваемых данных (рис. 8.9).

Рис. 8.9  Конфигурация потока данных для задания APM

Обнаружение аномалий в Elastic APM  219

Обратите внимание, что мы запрашиваем только те документы, которые соответствуют "service.environment" : "dev", как мы указали при
настройке задания в пользовательском интерфейсе APM.
10. Мы можем нажать на вкладку Datafeed preview (Предварительный
просмотр потока данных), чтобы просмотреть образец наблюдений,
которые будут переданы в Elastic ML для этого конкретного задания,
как показано на рис. 8.10.

Рис. 8.10  Предварительный просмотр потока данных для задания APM

Теперь, когда задание APM настроено и запущено, давайте посмотрим, где
в пользовательском интерфейсе APM будут отражаться результаты задания
по обнаружению аномалий.

Просмотр результатов задания по обнаружению
аномалий
Помимо просмотра результатов задания в пользовательском интерфейсе
Elastic ML, есть три ключевых места, в которых результаты заданий по обнаружению аномалий отображаются в пользовательском интерфейсе APM:
 обзор служб – это представление в пользовательском интерфейсе APM
является индикатором работоспособности высокого уровня, который
отражает максимальную оценку аномалий в результатах поиска аномалий для этой конкретной службы (рис. 8.11);

Powered by TCPDF (www.tcpdf.org)

220  Другие приложения Elastic Stack для обнаружения аномалий

Рис. 8.11  Обзор служб в пользовательском интерфейсе APM

 карта служб – это динамическое представление показывает зависимости транзакций приложения с цветовым индикатором аномалии,
основанным на максимальной оценке аномалий в результатах обнаружения аномалий для этой конкретной службы (рис. 8.12);
 график продолжительности транзакции – эта диаграмма под основным представлением транзакций в APM показывает ожидаемые
границы и цветную аннотацию, когда оценка аномалии превышает 75
для определенного типа транзакции.

Обнаружение аномалий в Elastic APM  221

Рис. 8.12  Карта служб в пользовательском интерфейсе APM

Рис. 8.13  График продолжительности транзакции
в пользовательском интерфейсе APM

222  Другие приложения Elastic Stack для обнаружения аномалий
Эти полезные индикаторы аномальности помогают пользователю в дальнейшем исследовании и устранении проблем с использованием широких
возможностей пользовательского интерфейса APM и ML. Далее мы рассмотрим еще один способ интеграции Elastic ML с данными из APM, используя
распознаватель данных.

Создание заданий машинного обучения
с помощью распознавателя данных
Хотя «распознаватель данных» (the data recognizer) не является официальным маркетинговым названием функции в Elastic ML, на самом деле он
может быть очень полезен, потому что помогает пользователю создавать
предварительно настроенные задания для распознаваемых данных.
Предварительно настроенные задания для распознавателя данных определены
и хранятся в следующем репозитории GitHub: https://github.com/elastic/kibana/tree/
master/x-pack/plugins/ml/server/models/data_recognizer/modules.

Рабочий процесс создания нового задания с помощью распознавателя выглядит следующим образом.
Если в процессе создания задания на обнаружение аномалий входные
данные задания (шаблон хранилища или сохраненный поиск) соответствуют
шаблонам поиска, известным одному из предопределенных модулей распознавания, то вы можете предложить пользователю создать одно из таких
предопределенных заданий. В качестве иллюстрации можно взять типичный
пример Node.js, представленный ранее в этой главе. Вместо того чтобы создавать задание обнаружения аномалий из пользовательского интерфейса
APM, можно пройти через пользовательский интерфейс Elastic ML и выбрать
шаблон хранилища apm-*:
 выбрав шаблон хранилища, вы увидите два предварительно настроенных задания, предлагаемых в дополнение к обычным мастерам заданий (рис. 8.14);
 первое задание с названием APM – это задание того же типа, которое
мы уже создали ранее в этой главе из пользовательского интерфейса
APM. Второй вариант (APM: Node.js) на самом деле представляет собой
набор из трех заданий (рис. 8.15);
 третье задание – это снова тот же тип задания, который мы уже создали ранее в этой главе из пользовательского интерфейса APM, но два
других уникальны. Идея предлагать пользователям варианты готовых
заданий, если исходные данные «распознаны», не уникальна для данных APM, и вы можете увидеть эти задания в других ситуациях или
сценариях использования (например, при выборе хранилищ для образцов данных Kibana, данных из nginx и т. д.).

Обнаружение аномалий в Elastic APM  223

Рис. 8.14  Задания, предлагаемые распознавателем данных

Рис. 8.15  Задания Node.js, предлагаемые распознавателем данных

Теперь, когда вы увидели, как Elastic ML встроен в приложение APM, давайте выясним, как обнаружение аномалий используется приложением Logs.

224  Другие приложения Elastic Stack для обнаружения аномалий

обнаружение аномалий в приложении lOgs
Приложение Logs в разделе Observability интерфейса Kibana предлагает такое же представление ваших данных, как и приложение Discover. Тем не
менее пользователям, которые больше ценят возможность просмотра своих
журналов в реальном времени независимо от хранилищ, в которых они расположены, понравится приложение Logs (рис. 8.16).

Рис. 8.16  Приложение Logs – часть раздела Observability в Kibana

Обратите внимание, что на экране есть вкладки Anomalies (Аномалии)
и Categories (Категории). Давайте начнем с раздела Categories.

Категории журналов
Категоризация Elastic ML, впервые показанная еще в главе 3, применяется в качестве общего подхода к любому хранилищу неструктурированных
данных журнала. Однако в приложении Logs категоризация используется
с некоторыми более строгими ограничениями на данные. Ожидается, что
данные будут в представлены в формате обобщенной схемы данных Elastic
(Elastic Common Schema, ECS) с набором определенных полей (особенно полем event.dataset).
Набор данных журналов из главы 7 дублируется для этой главы в репозитории GitHub
для использования с приложением Logs, но с добавлением поля event.dataset. Если
вы импортируете набор через средство загрузки файлов в ML, обязательно замените
имя поля на event.dataset вместо предлагаемого по умолчанию event_dataset.

Обнаружение аномалий в приложении Logs  225

Причину этого ограничения можно понять, учитывая, что приложение
Logs пытается создать для вас задание категоризации шаблонным способом. Следовательно, необходимо быть уверенным в соблюдении соглашения
об именах полей. Очевидно, что на это нельзя рассчитывать, если задание
создано в приложении ML, где ответственность за объявление имен поля
категоризации и поля сообщения лежит на пользователе.
Если вы все же настроите приложение Logs для выполнения категоризации, то результат будет выглядеть примерно так, как на рис. 8.17, на котором
показаны все отдельные категории журналов, отсортированные по максимальной оценке аномалии.

Рис. 8.17  Приложение Logs,
отображающее результаты категоризации из Elastic ML

Затем пользователи могут нажать кнопку Analyze in ML (Анализировать
в машинном обучении), чтобы перейти к обозревателю аномалий Anomaly
Explorer в пользовательском интерфейсе машинного обучения для дальнейшей проверки.

Журнал аномалий
Раздел Anomalies приложения Logs обеспечивает представление, аналогичное обзору Anomaly Explorer (рис. 8.18).

226  Другие приложения Elastic Stack для обнаружения аномалий

Рис. 8.18  Приложение Logs отображает представление,
подобное обозревателю аномалий в ML

Этот раздел также позволяет пользователю управлять заданиями по обнаружению аномалий, если нажать кнопку Manage ML jobs (Управление
заданиями машинного обучения) (рис. 8.19).

Рис. 8.19  Приложение Logs позволяет управлять заданиями ML

Задание Log rate (Скорость наполнения журнала), отображаемое в левой
части рис. 8.18, представляет собой простой детектор count на основе поля
event.dataset.
Пользователи должны помнить, что эти задания машинного обучения
здесь можно только сбросить, но не удалить окончательно – чтобы удалить

Обнаружение аномалий в приложении Logs  227

эти задания, вы должны перейти на страницу управления заданиями по обнаружению аномалий в приложении машинного обучения.
Очевидно, что опытный пользователь может заниматься созданием
и управлением заданиями по обнаружению аномалий для своих журналов
в приложении ML. Но приятно, что приложение Logs раскрывает возможности Elastic ML таким образом, что эти функции становятся очевидными
и легко реализуемыми. Давайте продолжим эту тенденцию и посмотрим, как
Elastic ML используется в приложении Metrics.

Обнаружение аномалий в приложении Metrics
Приложение Metrics, также являющееся частью раздела Observability интерфейса Kibana, позволяет пользователям просматривать свои данные с точки
зрения ресурсов и метрик:
 в представлении Inventory (Доступные ресурсы) пользователи видят
общую карту отслеживаемых ресурсов. Такие объекты, как хосты, модули или контейнеры, могут быть организованы и отфильтрованы для
настройки представления, включая шкалу состояния с цветовой кодировкой, как показано на рис. 8.20.

Рис. 8.20  Представление Inventory в приложении Metrics

228  Другие приложения Elastic Stack для обнаружения аномалий
Обратите внимание, что на нижней панели будут отображаться обнаруженные аномалии. В настоящее время это единственное место для
просмотра аномалий в приложении Metrics;
 чтобы включить встроенные задания по обнаружению аномалий через
приложение Metrics, нажмите кнопку Anomaly detection (Обнаружение аномалий) вверху, чтобы активировать всплывающее меню конфигурации (рис. 8.21);

Рис. 8.21  Управление заданиями по обнаружению аномалий
в приложении Metrics

 если, например, мы решим включить обнаружение аномалий для хостов, нажатие соответствующей кнопки Enable (Включить) покажет
конфигурацию как на рис. 8.22;
 обратите внимание, что в случае необходимости поле раздела предлагается как часть конфигурации. Когда вы нажимаете кнопку Enable
jobs (Включить задания), от вашего имени для вас создаются три разных задания по обнаружению аномалий, которые можно просмотреть
в разделе Job Management пользовательского интерфейса Elastic ML
(рис. 8.23);
 чтобы установить минимальный балл аномалии, необходимый для
отображения аномалий в приложении Metrics, перейдите на вкладку
Settings (Настройки) и настройте параметр Anomaly Severity Threshold (Порог серьезности аномалии) (рис. 8.24).

Обнаружение аномалий в приложении Logs  229

Рис. 8.22  Конфигурация обнаружения аномалий на хостах в приложении Metrics

Рис. 8.23  Задания по обнаружению аномалий для хостов,
созданные приложением Metrics

230  Другие приложения Elastic Stack для обнаружения аномалий

Рис. 8.24  Настройка порога серьезности аномалии в приложении Metrics

Интеграция Elastic ML с приложением Metrics помогает пользователю
быстро начать использовать обнаружение аномалий в своих данных метрик.
Давайте теперь кратко рассмотрим интеграцию с приложением Uptime.

обнаружение аномалий в приложении UPTIME
Приложение Uptime позволяет отслеживать доступность и время отклика
сервисов с помощью различных сетевых протоколов, включая HTTP/S, TCP
и ICMP.
1. Приложение Uptime, которое часто относят к инструментам синтетического мониторинга, использует Heartbeat для активного зондирования конечных точек сети из одного или нескольких мест (рис. 8.25).

Рис. 8.25  Приложение Uptime в Kibana

Обнаружение аномалий в приложении Uptime  231

2. Если вы хотите включить обнаружение аномалий для конкретного монитора, просто нажмите на имя монитора, чтобы просмотреть подробные сведения о нем. Вы увидите кнопку Enable anomaly detection (Включить обнаружение аномалии) на панели Monitor duration,
отображающей результаты в ходе мониторинга (рис. 8.26).

Рис. 8.26  Включение обнаружения аномалий
для монитора времени работоспособности

3. Нажатие кнопки Enable anomaly detection создает задание в фоновом
режиме и предлагает пользователю возможность создать предупреждение об аномалиях, обнаруженных в задании (рис. 8.27).
4. Как только задание на обнаружение аномалий станет доступным, любые обнаруженные аномалии также будут отображаться на странице
сведений о мониторе на панели Monitor duration (рис. 8.28).

232  Другие приложения Elastic Stack для обнаружения аномалий

Рис. 8.27  Создание оповещения
для задания обнаружения аномалий в приложении Uptime

Рис. 8.28  Аномалии, отображаемые в приложении Uptime

Обнаружение аномалий в приложении Elastic Security  233

И снова интеграция Elastic ML с другим приложением из группы Observability в Elasctic Stack позволяет пользователям невероятно легко воспользоваться преимуществами сложного обнаружения аномалий. Но мы также
знаем, что Elastic ML может делать кое-какие интересные вещи в отношении
анализа популяций и редких событий. В следующем разделе вас ждет интеграция ML с Elastic SIEM.

обнаружение аномалий в приложении
ElasTIc sEcUrITy
Elastic Security – это настоящая квинтэссенция целевого приложения в Elastic Stack. Созданное с нуля для реализации рабочего процесса аналитика
по безопасности, всеобъемлющее приложение Elastic Security само по себе
достойно отдельной книги. Однако в основе приложения Elastic Security лежит функция обнаружения, в которой правила, созданные пользователем
и Elastic, применяются для создания оповещений при выполнении условий,
заданных в правилах. Как вы увидите чуть позже, Elastic ML играет важную
роль в функции обнаружения.

Готовые задания по обнаружению аномалий
Большинство правил обнаружения в Elastic Security статичны, но многие из
них поддерживаются предварительно созданными заданиями обнаружения
аномалий, которые работают с данными, собранными из Elastic Agent или
Beats, или эквивалентными данными, соответствующими полям ECS, применимым для каждого типа задания. Чтобы увидеть полный список заданий
по обнаружению аномалий, предоставляемых Elastic, просмотрите определение конфигурации потока данных и задания в папках security_* и siem_*
в следующем репозитории GitHub: https://github.com/elastic/kibana/tree/7.12/xpack/plugins/ml/server/models/data_recognizer/modules.
(Вы можете подставить номер последней версии выпуска на место, которое сейчас занимает 7.12.)
Проницательный читатель заметит, что многие заранее созданные задания используют либо популяционный анализ, либо обнаружение редких событий. Каждый из этих способов обнаружения аномалий хорошо согласуется
с целями аналитика по безопасности – где обнаружение нового поведения
или поведения, которое выделяет пользователей или объекты из толпы, часто является признаком компрометации системы.
Предварительно созданные задания по обнаружению аномалий доступны
для просмотра на вкладке Detections (Обнаружения) в Elastic Security и имеют тег ML (рис. 8.29).
Если нажать на ML job settings (Настройки задания ML) в правом верхнем углу экрана, откроется список настроек, в котором пользователь сможет
увидеть все задания в библиотеке – даже те, которые недоступны (отмечены
значком предупреждения) (рис. 8.30).

234  Другие приложения Elastic Stack для обнаружения аномалий

Рис. 8.29  Задания машинного обучения
в разделе правил обнаружения приложения Security

Рис. 8.30  Список заданий в разделе ML job settings приложения Security

Обнаружение аномалий в приложении Elastic Security  235

Задания помечаются как недоступные, если необходимые данные в настоящее время не размещены в хранилищах Elasticsearch. Если задание доступно, вы можете активировать его, нажав на переключатель, и задание по
обнаружению аномалий будет выполнено в фоновом режиме. Конечно, вы
всегда можете просмотреть задания, созданные в пользовательском интерфейсе управления заданиями Elastic ML (рис. 8.31).

Рис. 8.31  Задания Elastic ML, созданные Security
и представленные в пользовательском интерфейсе управления заданиями

Теперь, когда вы знаете, как включить задания по обнаружению аномалий,
пора посмотреть, как они создают оповещения об обнаружении для приложения Security.

Оповещения на основе заданий обнаружения
аномалий
Если вы вернетесь к представлению Detections, показанному на рис. 8.28,
и нажмете кнопку Create new rule (Создать новое правило), то увидите, что
можете выбрать Machine Learning в качестве типа правила (рис. 8.32).
Если вы захотите выбрать конкретное задание машинного обучения с помощью раскрывающегося списка, вам также будет предложено выбрать пороговое значение оценки аномалии, которое необходимо превысить, чтобы
вызвать оповещение об обнаружении аномалии (рис. 8.33).

236  Другие приложения Elastic Stack для обнаружения аномалий

Рис. 8.32  Создание правила обнаружения на основе машинного обучения

Риc. 8.33  Выбор задания ML
и порогового значения для правила обнаружения

Заключение  237

Разумеется, если задание в данный момент не выполняется, появится
предупреждение о том, что задание необходимо запустить. Также примечательно, что если вы создали свое собственное задание (то есть не использовали одно из предварительно созданных заданий), но назначили его Job
Group (группе заданий) c названием Security в приложении Elastic ML, это
настраиваемое задание также будет кандидатом на подачу оповещений,
и его можно будет выбрать в раскрывающемся списке. Оставшуюся часть
настройки правила обнаружения можно оставить на усмотрение читателя,
поскольку она не относится к машинному обучению.
Приложение Elastic Security в значительной степени опирается на обнаружение аномалий, чтобы дополнить традиционные статические правила
динамическим поведенческим анализом пользователя или объекта, который может выявить заметные события, часто заслуживающие пристального исследования. Будет интересно понаблюдать за тем, насколько глубоко
и широко машинное обучение будет применяться в этом новом варианте
использования спустя некоторое время!

заключение
Elastic ML глубоко интегирован со многими приложениями в Elastic Stack,
предоставляя пользователям простые в использовании функциональные
возможности. Это показывает, насколько важную роль играет Elastic ML в составе Elastic Stack и насколько его функции схожи с другими ключевыми
функциями стека, такими как агрегирование.
Поздравляем, вы дошли до конца первой половины этой книги! Мы надеемся, что теперь вы знаете все, что нужно об обнаружении аномалий при
помощи Elastic ML.
Дальше мы займемся «обратной стороной» Elastic ML – аналитикой фреймов данных, и вы узнаете, как использовать другие методы машинного
обучения (включая создание моделей, обучаемых с учителем, и логический
вывод), чтобы задействовать аналитические решения в принципиально новых вариантах использования.

Часть

III
АНАЛИЗ
ФРЕЙМОВ ДАННЫХ

В этом разделе рассмотрены основы анализа фреймов данных, его полезность и способы его реализации. В нем описаны различные типы анализа
и их отличия друг от друга. В конце раздела представлены полезные советы
и примеры, которые можно использовать для получения максимальной отдачи от Elastic ML.
Эта часть книги состоит из следующих глав:







главы 9 «Введение в анализ фреймов данных»;
главы 10 «Обнаружение выбросов»;
главы 11 «Классификационный анализ»;
главы 12 «Регрессия»;
главы 13 «Заключение»;
приложение «Полезные советы».

Глава

9
Введение в анализ
фреймов данных

В первой части этой книги мы подробно рассказали об обнаружении аномалий – основной функции машинного обучения, которая напрямую интегрирована в Elastic Stack. В этой и следующей главах вы познакомитесь
с новыми функциями машинного обучения, интегрированными в стек. К ним
относятся обнаружение выбросов, новый метод обучения без учителя для обнаружения необычных точек данных в хранилищах, не относящихся к временным рядам, а также две функции обучения с учителем: классификация
и регрессия.
Алгоритмы обучения с учителем используют размеченные наборы данных – например, набор данных, описывающий различные аспекты образцов
биологической ткани, а также информацию о том, является ли ткань злокачественной – для обучения модели. Затем эту модель можно использовать
для прогнозирования ранее не встречавшихся точек данных (или образцов
тканей, если продолжить наш пример). Когда целью прогноза является дискретная переменная или категория, например является ткань злокачественной или нет, метод обучения с учителем называется классификацией. Когда
целью является непрерывная числовая переменная, например цена продажи
квартиры или почасовая цена на электроэнергию, такой метод обучения
с учителем известен как регрессия. В совокупности эти три новые разновидностимашинного обучения (обнаружение выбросов, классификация и регрессия) известны как анализ фреймов (окон) данных. Мы обсудим каждую из
этих разновидностей более подробно в следующих главах.
Хотя они решают разные задачи и имеют разные цели, все они работают
под капотом общей технологии преобразования данных, которая позволяет
нам преобразовывать и агрегировать данные, представленные в виде последовательности транзакций или потока в формат на основе объектов. Этот
ориентированный на объект формат нужен для многих алгоритмов, которые
применяются в анализе фреймов данных, и поэтому, прежде чем углубиться
в изучение новых функций машинного обучения, мы собираемся детально
рассказать о том, как преобразовать ваши данные в формат, который больше
подходит для последующих технологий машинного обучения. Мы также собираемся представить краткий обзор Painless – встроенного в Elasticsearch
языка сценариев, который является хорошим инструментом для любых спе-

Powered by TCPDF (www.tcpdf.org)

240  Введение в анализ фреймов данных
циалистов по обработке данных или инженеров, работающих с машинным
обучением в Elastic Stack.
Богатая экосистема библиотек как для обработки данных, так и для машинного обучения существует и за пределами Elastic Stack. Основным стимулом для развития этих приложений является популярность языка Python.
Из-за его повсеместного распространения в сообществах специалистов по
науке о данных и инженерии данных во второй части этой главы мы сосредоточимся на совместном использовании Python и Elastic Stack, уделяя особое
внимание новому клиенту Elasticsearch для обработки данных – Eland. В этой
главе мы рассмотрим следующие темы:
 основы преобразования данных;
 использование Painless для сложных конфигураций преобразования;
 совместное использование Python и Elasticsearch.

технические требования
Материал в этой главе требует использования Elasticsearch версии 7.9 или
выше и Python версии 3.7 или выше. Примеры кода и фрагменты, необходимые для данной главы, размещены в репозитории GitHub книги по адресу
https://github.com/PacktPublishing/Machine-Learning-with-Elastic-Stack-SecondEdition/tree/main/Chapter09. Когда для некоторых примеров требуется конкретная новая версия Elasticsearch, об этом говорится до начала описания
примера.

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

Чем полезны преобразования?
Каковы наиболее распространенные типы данных, загружаемых в Elasticsearch? Зачастую это документы, которые содержат записи, зависящие от
времени или последовательности записей, например журналы веб-сервера,
покупки клиентов в интернет-магазине, комментарии, опубликованные на
платформе социальных сетей, и т. д.
Хотя этот вид данных полезен для понимания поведения наших систем
на отрезке времени и идеально подходит для использования с такими технологиями, как обнаружение аномалий, наборы данных на основе потоков
или событий сложно заставить работать с функциями анализа фреймов без
предварительной агрегации или преобразования. Например, рассмотрим

Основы преобразования данных  241

интернет-магазин, в котором регистрируются покупки, сделанные клиентами. За год каждый покупатель может совершить десятки или сотни транзакций. Если магазин затем захочет найти способ использовать обнаружение
выбросов для выявления необычных клиентов, ему придется преобразовать
все точки данных транзакций для каждого клиента и суммировать определенные ключевые показатели, такие как средняя сумма денег, потраченная
на покупку, или количество покупок за календарный месяц. На рис. 9.1 представлена упрощенная иллюстрация, которая изображает процесс извлечения
записей транзакций из покупок электронной коммерции, сделанных двумя
покупателями, и преобразования их в набор, ориентированный на объект
и описывающий общее количество товаров, приобретенных этими покупателями, а также среднюю стоимость их заказа.
Имя: Анна
Дата: 2020-09-10
Покупка: Туфли
Количество: 5
Имя: Анна
На сумму: 10
Дата: 2020-10-11
Покупка: Футболка
Количество: 10
На сумму: 25
Имя: Саймон
Дата: 2020-09-11
Покупка: Носки
Количество: 6
На сумму: 15

пре

обр

азо

ван

ие

Имя

Общее количество

Средняя стоимость

Анна

15

17,5

Саймон

6

15

Рис. 9.1  Схема преобразования транзакций интернет-магазина
в набор данных, ориентированный на объекты

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

Анатомия преобразований
Хотя мы собираемся начать наше путешествие по преобразованиям с простых примеров, многие реальные варианты использования намного сложнее.
При применении преобразований к вашим собственным проектам данных
полезно помнить о двух вещах, которые помогут вам справиться с задачей:
сводная таблица (pivot) и агрегирование (aggregation).

242  Введение в анализ фреймов данных
Давайте посмотрим, как эти два инструмента дополняют друг друга, помогая преобразовать потоковый документ в набор, представляющий объекты.
В нашем сценарии использования клиентской аналитики у нас есть много
различных признаков, описывающих каждого клиента: имя клиента, цена,
которую он заплатил за каждый из своих продуктов при оформлении заказа,
список приобретенных товаров, дата покупки, местоположение клиента и т. д.
Первое, что нам нужно выбрать, – это объект представления, для которого
мы собираемся построить наш объектно-ориентированный набор. Давайте начнем с очень простого примера и скажем, что наша цель – выяснить,
сколько денег в среднем каждый покупатель потратил на покупку в течение
выбранного периода времени и сколько они потратили в целом. Таким образом, объект представления, для которого мы хотим построить новый набор
данных – нашу сводную таблицу, – это имя клиента.
С большинством клиентов в нашем исходном наборе данных связано более
одной транзакции. Следовательно, если мы попытаемся сгруппировать наш
набор по имени клиента, для каждого клиента у нас будет несколько документов. Чтобы успешно составить сводную таблицу, нам нужно решить, какие агрегированные количества (например, среднюю цену за заказ клиента)
мы хотим включить в наш набор, представляющий объект. От этого, в свою
очередь, зависит, какие агрегации мы определим в нашей конфигурации
преобразования. Давайте посмотрим, как это работает, на практическом
примере.

Использование преобразований для анализа
заказов интернет-магазина
В этом разделе для иллюстрации некоторых основных принципов преобразования, изложенных раньше, мы будем использовать образец набора данных Kibana E-Commerce.
1. Импортируйте образец набора данных заказов Sample eCommerce
orders из панели данных Sample data Kibana, показанной на рис. 9.2,
нажав кнопку Add data (Добавить данные). Будет создано новое хранилище с именем kibana_sample_data_ecommerce, заполненное выбранным
набором данных.
2. Перейдите к мастеру преобразований Transforms, вызвав раскрывающееся меню панели Kibana с помощью кнопки в верхнем левом углу,
затем перейдите в раздел Stack Management (Управление стеком)
и нажмите Transforms в меню Data.
3. В окне Transforms нажмите на Create your first transform (Создать
первое преобразование), чтобы вызвать мастер преобразований. Вам
будет предложено выбрать исходное хранилище, которое преобразование будет использовать для создания вашей сводной таблицы
и агрегатов. В данном случае нас интересует хранилище kibana_sample_data_ecommerce, которое вы должны выбрать на панели, показанной
на рис. 9.3. Исходные хранилища, отображаемые в вашем интерфейсе

Основы преобразования данных  243

Kibana, могут немного отличаться в зависимости от хранилищ, доступных в настоящее время в вашем кластере Elasticsearch.

Рис. 9.2  Импорт набора данных Sample eCommerce orders
из панели данных Kibana Sample

Рис. 9.3  Для нашего примера выберите kibana_sample_data_ecommerce

4. После выбора исходного хранилища мастер преобразования откроет
диалоговое окно, в котором представлен предварительный просмотр
исходных данных (рис. 9.4), а также позволит нам выбрать сводный
объект с помощью раскрывающегося селектора в разделе Group by
(Группировать по). В данном случае нужно выбрать поле с именем customer_full_name.
5. Теперь, когда определен объект для формирования сводных данных,
мы перейдем к следующей части построения преобразования: агрегациям. В данном случае нас интересует вычисление средней суммы
денег, которую покупатель потратил в интернет-магазине на один заказ. Во время каждой транзакции, которая записывается в документе
в исходном хранилище, общая сумма, уплаченная клиентом, сохраняется в поле taxful_total_price.
Следовательно, агрегирование, которое мы определяем, будет работать
с этим полем. В меню Aggregations (Агрегаты) выберите taxful_total_price.avg. После того как вы щелкнете по этому пункту, под ним

244  Введение в анализ фреймов данных
появится поле предварительного просмотра сводного набора данных,
как показано на рис. 9.5.

Рис. 9.4  Выберите в списке Group by объект,
для которого вы хотите представить сводную информацию

Рис. 9.5  Предварительный просмотр преобразованных данных
для быстрой проверки, все ли настроено должным образом

6. Наконец, мы настроим последние два элемента: идентификатор задания преобразования и имя целевого хранилища, в которое будут помещены документы, описывающие наши сводные данные. Рекомендуется
оставить флажок Create index pattern (Создать шаблон хранилища)
установленным, как показано на рис. 9.6, чтобы можно было легко
перейти к целевому хранилищу на вкладке Discover и просмотреть
результаты.

Основы преобразования данных  245

Идентификатор преобразования будет использоваться для
определения задания преобразования и целевого хранилища.
7. Чтобы запустить задание преобразования, не забудьте нажать
Next в мастере преобразования
после выполнения инструкций,
описанных в шаге 6, а затем
Create and start (Создать и запустить), после чего будет запущено задание преобразования
и создан сводный набор данных,
представляющий объект.
8. После завершения преобразования (индикатор выполнения доРис. 9.6  Каждому преобразованию
стигнет 100 %, если все идет хонужно присвоить идентификатор
рошо) вы можете нажать кнопку
Discover в нижней части мастера преобразования и просмотреть преобразованные документы.
Как было сказано в начале этого раздела, мы видим из образца документа на рис. 9.7, что задание преобразования взяло набор данных, представляющий последовательность транзакций, описывающих каждую покупку,
сделанную клиентом в нашем интернет-магазине, и преобразовывало его
в набор, представляющий объект, который содержит результаты конкретного аналитического преобразования (расчет средней цены, уплачиваемой
клиентом), и сгруппированный по полному имени клиента.

Рис. 9.7  Результатом выполнения задания преобразования
является целевой набор данных, где каждый документ содержит агрегирование
для каждого объекта. В данном случае это средняя цена taxful_total_price,
уплачиваемая каждым покупателем за один заказ

246  Введение в анализ фреймов данных
Поздравляем – вы создали и запустили свое первое задание преобразования! Хотя оно довольно простое по своей природе, эта базовая конфигурация задания является хорошим строительным блоком для создания более
сложных преобразований, которые мы рассмотрим в следующих разделах.

Более сложные конфигурации сводной таблицы
и агрегирования
В предыдущем разделе мы рассмотрели две части преобразования: сводную
таблицу и агрегирование. В последующем примере наша цель состояла в том,
чтобы, используя преобразования в демонстрационном наборе данных интернет-магазина, узнать среднюю сумму денег, которую клиенты тратят на
один заказ. Решая эту задачу, мы выяснили, что каждый документ, содержащий транзакцию, имеет поле с именем customer.full_name, и мы использовали
это поле для составления сводной таблицы из исходных данных. Наше агрегирование представляло собой среднее значение поля, в котором записана
общая сумма денег, потраченных клиентом на заказ.
Однако не все вопросы, которые мы могли бы задать о наших данных
интернет-магазина, поддаются простой сводке или группировке в конфигурациях, подобных рассмотренной ранее. Давайте разберем некоторые более сложные конфигурации преобразований, способствующие выполнению
других исследований, которые мы, возможно, захотим провести с набором
данных интернет-магазина. Если вы хотите узнать обо всех доступных конфигурациях сводной таблицы, ознакомьтесь с документацией API по следующему адресу: https://www.elastic.co/guide/en/elasticsearch/reference/master/
put-transform.html.
Предположим, что мы хотим узнать среднюю сумму денег, потраченную на
один заказ за неделю, и сколько уникальных клиентов совершили покупки за
этот период. Чтобы ответить на эти вопросы, нам нужно будет создать новую
конфигурацию преобразования.
1. Вместо того чтобы опираться на имя клиента, мы должны построить
гистограмму дат из поля order_date, которое, как следует из названия,
хранит информацию о том, когда был размещен заказ. Мастер преобразования упрощает эту работу, поскольку date_histogram(order_date)
является одним из предварительно настроенных параметров, отображаемых в раскрывающемся списке Group by.
2. После того как вы выбрали date_histogram(order_date) в раскрывающемся списке Group by, обратите внимание на правую часть панели
на рис. 9.8. Она должна содержать условные обозначения для длины
интервала группировки, используемого в гистограмме даты (например, 1m для интервала в 1 минуту). В нашем случае мы заинтересованы
в группировке по неделям, поэтому нам нужно выбрать в списке 1w
(week, неделя).

Основы преобразования данных  247

Рис. 9.8  Выберите частоту группировки по дате из раскрывающегося списка

3. Далее для нашего агрегирования выберем уже знакомую среднюю цену
(total_taxful_price). После того как мы сделаем свой выбор, мастер преобразования отобразит предварительный просмотр, в котором будет
показана средняя цена, уплачиваемая клиентом за заказ, в группах заказов по разным неделям, для нескольких выборочных записей. Предварительный просмотр предназначен для проверки получившихся
результатов. Поскольку задания преобразования могут быть ресурсоемкими, на этом этапе рекомендуется временно остановиться и внимательно изучить предварительные результаты, чтобы убедиться, что
данные преобразованы в желаемый формат.
4. Иногда нам может потребоваться опросить наши данные способами,
которые не получается реализовать простыми одноуровневыми группировками, подобными той, которую мы исследовали на предыдущих
шагах. Как вы сейчас увидите, можно создавать вложенные группировки. Предположим, что в нашем гипотетическом примере интернетмагазина владельцам также будет интересно узнать среднюю сумму
денег, потраченную за неделю по географическим регионам.
Чтобы решить эту проблему, вернемся к мастеру преобразования и добавим второе поле для группировки. В этом случае мы будем группировать данные по geoip.region_name. Как и раньше, мастер отображает
предварительные результаты для просмотра, когда мы выбираем поле
группировки. Как и в предыдущем случае, лучше потратить время на
проверку строк, отображаемых в области предварительном просмотра,
чтобы убедиться, что данные были преобразованы правильно.

248  Введение в анализ фреймов данных
Щелкните переключатель Columns (Столбцы) над таблицей предварительного
просмотра, чтобы изменить порядок столбцов.

Помимо создания вложенной группировки, мы также можем добавить
к нашему преобразованию несколько агрегаций. Предположим, что помимо средней суммы, потраченной на одного покупателя в неделю по
регионам, нам также будет интересно узнать количество уникальных
покупателей, разместивших заказы в нашем магазине за эту неделю.
Давайте посмотрим, как мы можем добавить эту агрегацию к нашему
преобразованию.
5. В раскрывающемся меню Aggregations в мастере прокрутите список
вниз, пока не найдете опцию entity cardinality (мощность объекта)
для поля customer.full_name.keyword, и выберите ее. Соответствующая
агрегация будет добавлена в вашу конфигурацию преобразования,
и в предварительном просмотре должен появиться один дополнительный столбец.
Теперь вы можете выполнить шаги, описанные в руководстве в предыдущем разделе, чтобы назначить идентификатор и целевое хранилище
для преобразованных данных, а также создать и запустить задание. Мы
оставляем вам эти шаги в качестве упражнений.
В предыдущих двух разделах мы исследовали два ключевых компонента
преобразований: сводную таблицу и агрегирование, а также рассмотрели два
разных пошаговых примера, чтобы показать, как простые и усложненные
комбинации сводной таблицы и агрегирования могут использоваться для
исследования наших данных и получения различных сведений.
Внимательные читатели могли заметить, что на рис. 9.6 мы оставили флажок Continuous mode (Непрерывный режим) снятым. В следующем разделе
мы более подробно рассмотрим, что означает запуск преобразования в непрерывном режиме.

Различие между пакетными и непрерывными
преобразованиями
Первое преобразование, которое мы создали в предыдущем разделе, было
простым и выполнялось только один раз. Задание преобразования прочитало
исходный набор данных kibana_sample_data_ecommerce, который мы указали
в мастере преобразования, выполнило вычисления средней цены заказа каждого клиента, а затем записало полученные документы в целевое хранилище.
Поскольку наше преобразование выполняется только один раз, любые изменения в нашем исходном наборе kibana_sample_data_ecommerce, которые происходят после запуска задания преобразования, больше не будут отражаться
в данных, оказавшихся в целевом хранилище. Такое преобразование, которое выполняется только один раз, называется пакетным преобразованием.
Во многих реальных сценариях, которые создают записи транзакций (например, в нашем примере вымышленного интернет-магазина), в исходное хранилище постоянно добавляются новые документы. Это означает, что наш свод-

Основы преобразования данных  249

ный набор данных, представляющий объекты, почти сразу устареет. Одним из
решений, позволяющих поддерживать синхронизацию целевого хранилища
с исходным, является постоянное удаление целевого хранилища и повторный
запуск задания пакетного преобразования через регулярные промежутки времени. Однако это непрактично и заставляет выполнять вручную большой объем работы. Здесь вступают в игру непрерывные преобразования.
Если у нас есть исходное хранилище, которое постоянно обновляется, и мы
хотим использовать его для создания сводного хранилища, представляющего
объект, то мы должны использовать непрерывное преобразование. Давайте
рассмотрим непрерывные преобразования более подробно, чтобы понять,
чем они отличаются от пакетных преобразований и какие важные параметры
конфигурации следует учитывать при запуске непрерывного преобразования.
Прежде всего подготовим почву для проблемы, которую мы пытаемся решить. Предположим, у нас есть вымышленная платформа для микроблогов
в социальных сетях, где пользователи публикуют короткие посты, назначают
им категории и устанавливают взаимосвязи с другими пользователями, а также с заранее определенными темами. Можно поделиться постом и поставить
лайк. Также записывается статистика для каждого поста. Мы написали код
Python, чтобы помочь сгенерировать этот набор данных. Этот код и сопутствующие инструкции по его запуску доступны в репозитории GitHub по адресу
https://github.com/PacktPublishing/Machine-Learning-with-Elastic-Stack-Second-Edition/tree/main/Chapter09. После запуска генератора у вас появится хранилище
под названием social-media-feed, которое будет содержать ряд документов.
Каждый документ в наборе данных содержит пост, опубликованный пользователем в социальной сети. Для краткости мы исключили текст поста из документа. На рис. 9.9 показан образец документа в хранилище social-media-feed.

Рис. 9.9  Образец документа в хранилище ленты социальной сети
содержит имя пользователя, время отправки сообщения на платформу,
а также некоторую базовую статистику о взаимодействии поста с пользователями

250  Введение в анализ фреймов данных
В следующем разделе вы увидите, как использовать этот набор данных вымышленной платформы социальных сетей, чтобы реализовать непрерывные
преобразования.

Анализ данных социальных сетей с помощью
непрерывных преобразований
В этом разделе мы будем использовать представленный ранее набор данных
для изучения концепции непрерывных преобразований. Как было сказано
в предыдущем разделе, пакетное преобразование уместно для однократного
анализа, когда мы либо готовы проанализировать моментальный снимок набора данных в определенный момент времени, либо у нас нет набора данных,
который изменяется. В большинстве реальных приложений дело обстоит
иначе. Файлы журналов непрерывно дополняются новыми записями, многие
платформы социальных сетей работают круглосуточно, а платформы электронной коммерции обслуживают клиентов во всех часовых поясах и, таким
образом, генерируют поток данных о транзакциях. Здесь вступают в игру
непрерывные преобразования.
Давайте посмотрим, как мы можем проанализировать средний уровень
взаимодействия (количество лайков и репостов, полученных пользователем
социальной сети) с помощью непрерывных преобразований.
1. Перейдите к мастеру преобразований. На странице Stack Management
(Управление стеком) слева под разделом Data выберите Transforms.
2. Действуя, как в предыдущих разделах, начнем с создания преобразования. В качестве исходного хранилища выберите шаблон хранилища social-media-feed. Вы должны увидеть представление, подобное
изображенному на рис. 9.10.

Рис. 9.10  Мастер преобразований показывает образец записей
в хранилище ленты социальных сетей

Основы преобразования данных  251

3. В данном случае нас интересует вычисление агрегированных показателей взаимодействия каждого поста для каждого имени пользователя. Таким образом, наша конфигурация Group by будет включать имя
пользователя, в то время как наши агрегации будут вычислять общее
количество лайков и репостов для каждого пользователя, среднее количество лайков и репостов для каждого пользователя, а также общее
количество постов, опубликованных каждым пользователем. Окончательная конфигурация Group by и Aggregations должна выглядеть
примерно так, как показано на рис. 9.11.

Рис. 9.11  Конфигурация Group by и Aggregations
для нашего примера непрерывного преобразования

4. Переведите переключатель Continuous mode во включенное состояние и убедитесь, что в поле Date field выбрано значение timestamp, как
показано на рис. 9.12.

Рис. 9.12  Включите переключатель Continuous mode,
чтобы процесс преобразования периодически проверял исходное хранилище
и добавлял новые документы в целевое хранилище

252  Введение в анализ фреймов данных
5. После нажатия кнопки Create and start вы сможете вернуться на страницу Transforms и увидите, что выполняется задание непрерывного
преобразования для хранилища social-media-feed. Обратите внимание
на тег continuous (непрерывный) в описании задания.

Рис. 9.13  Непрерывные преобразования, отображаемые на странице Transforms.
Обратите внимание, что задание помечено тегом continuous

6. Давайте вставим несколько новых сообщений в хранилище socialmedia-feed и посмотрим, как изменится статистика для пользователя по
имени Carl после добавления нового документа в исходное хранилище. Чтобы вставить новый пост, откройте консоль Kibana Dev Console
и выполните следующую команду REST API:
POST social-media-feed/_doc
{
"username": "Carl",
"statistics": {
"likes": 320,
"shares": 8000
},
"timestamp": "2021-01-18T23:19:06"
}

7. Теперь, когда мы добавили новый документ в хранилище social-mediafeed, мы вправе ожидать, что этот документ будет выбран заданием непрерывного преобразования и добавлен в целевое хранилище socialmedia-feed-engagement. На рис. 9.14 показана преобразованная запись для
пользователя по имени Carl.
В предыдущем примере очень упрощенно показано, как работают непрерывные преобразования и как вы можете создать свое собственное непрерывное преобразование с помощью мастера преобразований, доступного
в Kibana. В главе 13 мы вернемся к теме непрерывных преобразований, когда
продемонстрируем, как комбинировать обученные модели ML, логический
вывод и преобразования.

Использование Painless для расширенных конфигураций преобразования  253

Рис. 9.14  Целевое хранилище непрерывного преобразования
содержит запись для нового имени пользователя Carl,
которое мы добавили вручную через Kibana Dev Console

А пока сделаем краткий экскурс в мир языка сценариев Painless. Хотя
мастера преобразований и множества предустановленных конфигураций
группировки и агрегирования, которые он предлагает, достаточно для многих наиболее распространенных сценариев использования анализа данных,
более продвинутые пользователи захотят определять свои собственные агрегации. Очевидный способ сделать это – использовать встроенный скриптовый язык Elasticsearch Painless.
В следующем разделе мы совершим небольшой тур по миру Painless, который подготовит вас к созданию собственных расширенных конфигураций
преобразования.

использование PaInlEss Для расширенных
конфигураций преобразования
Как вы видели раньше, стандартные настройки сводной таблицы и агрегирования позволяют нам анализировать и опрашивать наши данные различными способами. Однако для более нестандартных или расширенных
вариантов использования встроенные функции могут быть недостаточно
гибкими. В этих случаях нам нужно будет написать собственные конфигурации сводных данных и агрегирования. Для этого и предназначен гибкий
язык сценариев Painless, встроенный в Elasticsearch.

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

Знакомство с Painless
Painless – это язык сценариев, встроенный в Elasticsearch. Мы рассмотрим
Painless с точки зрения переменных, конструкций управления выполнением,
операций и функций. Это основные строительные блоки, которые помогут
вам разработать собственные сценарии для применения в преобразованиях
данных.
Вполне вероятно, что многие читатели этой книги имеют некоторый
опыт программирования. Возможно, вы создавали скрипты очистки данных с помощью Python, программировали Linux с по мощью сценариев bash
или разрабатывали корпоративное программное обеспечение на Java. Хотя эти
языки имеют много различий и предназначены для разных целей, все они имеют
общие строительные блоки, которые помогают людям, читающим язык, понимать
их. Хотя существует почти бесконечное
количество подходов к обучению языку
программирования, подход, который мы
выбрали, основан на усвоении следующих
основных тем о Painless: переменные, операции (такие как сложение, вычитание
и различные проверки условий), управление выполнением (конструкции if-else
и циклы for) и функции. Эти концепции
должны быть понятны пользователям,
знакомым с любым другим языком программирования. В дополнение к этому мы
рассмотрим некоторые особенности, присущие только Painless, такие как различные контексты выполнения.
При изучении нового языка программирования важно иметь рабочую площадку,
на которой можно экспериментировать
с синтаксисом. К счастью, начиная с версии Elasticsearch 7.10 приложение Dev Tools
Рис. 9.15  Ссылка на страницу
содержит новую отладочную среду Painless
Dev Tools находится в нижней части
Lab, где вы можете опробовать образцы
бокового меню Kibana.
кода, представленные в этой главе, а также
Нажмите на нее, чтобы получить
любой код, который вы разработаете самодоступ к интерактивной среде
стоятельно. Чтобы попасть в Painless Lab,
отладки Painless Lab

Использование Painless для расширенных конфигураций преобразования  255

перейдите в Dev Tools, как показано на рис. 9.15, а затем в верхнем меню
страницы Dev Tools выберите Painless Lab.
После перехода по ссылке откроется встроенный редактор кода Painless,
как показано на рис. 9.16.

Рис. 9.16  В Painless Lab есть встроенный редактор кода.
Окно Output показывает результат выполнения кода, введенного в окне редактора

Редактор кода в Painless Lab по умолчанию предлагает некоторые примеры
функций и объявления переменных в качестве иллюстрации того, как можно
нарисовать фигуру в окне вывода на рис. 9.16 при помощи Painless. Сейчас
вы можете удалить этот код, чтобы освободить место для ваших собственных
экспериментов, которые вы будете проводить при чтении оставшейся части
этой главы.
Полную спецификацию языка Painless можно найти по адресу https://www.elastic.co/
guide/en/elasticsearch/painless/master/painless-lang-spec.html. Вы можете использовать ее как справочник и ресурс для получения дополнительной информации по
темам, рассмотренным далее в этой главе.

Переменные, операторы и управление выполнением
Первое, что мы обычно делаем на новом языке программирования, – учимся
манипулировать значениями. Для этого мы присваиваем этим значениям
имена или переменные. Painless имеет типы, и прежде чем переменная может быть назначена, она должна быть объявлена вместе с ее типом. Синтаксис объявления переменной выглядит так: идентификатор_типа имя_переменной;.
Применение этого синтаксиса на практике показано в следующем блоке кода, где мы объявляем переменные a и b для хранения целочисленных
значений, переменную my_string для хранения строкового значения и переменную my_float_array для хранения массива значений с плавающей запятой:

256  Введение в анализ фреймов данных
int a;
int b;
String my_string;
float[] my_float_array;

На данный момент переменные еще не содержат ненулевых значений.
Они только что инициализированы и готовы к использованию оператора
присваивания, который присваивает каждой переменной значение соответствующего типа. Если вы попытаетесь скопировать предыдущий блок
кода в редактор Painless Lab, то увидите в окне вывода результат null, как
показано на рис. 9.17.

Рис. 9.17  Слева инициализируются переменные Painless различных типов.
Справа на панели вывода отображается значение null,
поскольку этим переменным еще не присвоено значение
Редактор кода Painless Lab отображает только результат выполнения последнего оператора.

Теперь присвоим этим переменным какие-нибудь значения, чтобы продолжить эксперименты. Присвоение значений показано в следующем блоке
кода. В первых двух строках мы присваиваем целочисленные значения нашим целочисленным переменным a и b. В третьей строке мы назначаем строковое значение "hello world" строковой переменной my_string, а в последней
строке инициализируем новый массив значениями с плавающей запятой:
a = 1;
b = 5;
my_string = "hello world";
my_double_array = new double[] {1.0, 2.0, 2.5};

Чтобы продемонстрировать работу некоторых операторов Painless, выполним с этими переменными различные действия. Полный список доступных
операторов представлен в спецификации языка Painless по адресу https://
www.elastic.co/guide/en/elasticsearch/painless/current/painless-operators.html.
Следующие блоки кода иллюстрируют основные математические операции:
сложение, вычитание, деление и умножение, а также операцию модуля или
взятие остатка:
int a;
int b;

Использование Painless для расширенных конфигураций преобразования  257
a = 1;
b = 5;
// Сложение
int addition;
addition = a+b;
// Вычитание
int subtraction;
subtraction = a-b;
// Умножение
int multiplication;
multiplication = a*b;
// Целочисленное деление
int int_division;
int_division = a/b;
// Остаток от деления
int remainder;
remainder = a%b;

Попробуйте ввести эти примеры кода в редакторе Painless Lab, и вы сможете увидеть результаты выполнения последнего оператора, как показано
в примере сложения на рис. 9.18.

Рис. 9.18  Использование редактора кода Painless Lab и консоли
для выполнения операции сложения. Результат, сохраненный в переменной
под названием addition в редакторе кода слева, отображается на вкладке Output справа

Помимо математических операций, мы также рассмотрим логические
операторы. Они жизненно важны для многих сценариев и конфигураций
Painless, а также для операторов управления выполнением кода, которые
мы рассмотрим позже.
Следующие фрагменты кода показывают, как объявить переменную для
хранения логического (истина/ложь) значения и как использовать операторы сравнения. Полный список логических операторов Painless представлен
в спецификации, доступной по адресу https://www.elastic.co/guide/en/elasticsearch/painless/current/painless-operators-boolean.html:

258  Введение в анализ фреймов данных
boolean
boolean
boolean
boolean

less_than = 45;
less_than_or_equal = 4 = 5;

В качестве упражнения скопируйте предыдущий блок кода в редактор
Painless Lab. При желании вы можете просмотреть содержимое каждой из
этих переменных, введя ее имя и точку с запятой в последней строке редактора кода, и значение, хранящееся в переменной, отобразится в окне вывода
справа, как показано на рис. 9.19.

Рис. 9.19  Введя имя переменной и точку с запятой в редакторе кода Painless Lab,
вы увидите значение переменной на вкладке Output

Хотя представленный здесь оператор boolean полезен во многих численных
вычислениях, мы, вероятно, не смогли бы написать эффективные операторы
управления выполнением кода без операторов равенства == и неравенства
!=, которые проверяют, равны ли две переменные. В следующем блоке кода
показано, как использовать эти операторы, на нескольких практических примерах:
// логический оператор проверки на равенство
boolean two_equal_strings = "hello" == "hello";
two_equal_strings;
// логический оператор проверки на неравенство
boolean not_equal = 5!=6;
not_equal;

И последнее, но не менее важное: в нашем обзоре логических операторов
Painless – это блок кода, иллюстрирующий применение оператора instanceof,
который проверяет, действительно ли данная переменная является экземпляром типа и возвращает true или false. Это полезно при создании кода,
который вы хотите использовать только с переменными указанного типа:
// логический оператор instanceof проверяет, действительно ли
// переменная является экземпляром указанного типа
// проверка переменной is_integer вернет результат true (истина)
int int_number = 5;

Использование Painless для расширенных конфигураций преобразования  259
boolean is_integer = int_number instanceof int;
is_integer;

В заключительной части этого раздела мы рассмотрим один из самых важных строительных блоков кода на языке Painless: операторы if-else и циклы
for. Синтаксис операторов if-else показан в следующем блоке кода:
int a = 5;
int sum;
if (a < 6){
sum = a+5;
}
else {
sum = a-5;
}
sum;

В этом блоке кода мы объявляем целочисленную переменную a и присваиваем ей целочисленное значение 5. Затем объявляем другую целочисленную
переменную sum. Эта переменная будет изменяться в соответствии с ветвью
выполнения, определяемой оператором if-else. Наконец, оператор if-else
сначала проверяет, меньше ли целочисленная переменная a, чем 6, и если да,
то сохраняет результат сложения a и целого числа 5 в переменной sum. В противном случае значение, присвоенное переменной sum, является результатом
вычитания 5 из a.
Если вы наберете этот код в редакторе кода Painless Lab, консоль вывода
отобразит значение суммы, равное 10 (как показано на рис. 9.20), чего мы
и ожидали, основываясь на предыдущих рассуждениях.

Рис. 9.20  Оператор if-else приводит к присвоению переменной sum значения 10

Далее рассмотрим цикл for, который полезен для различных задач анализа
и обработки данных с помощью Painless. В цикле for мы будем перебирать
строковую переменную и вычислять, сколько вхождений буквы a встречается
в строке. Это очень простой пример, но он поможет вам понять синтаксис,
чтобы вы могли применять его в своем коде:

Powered by TCPDF (www.tcpdf.org)

260  Введение в анализ фреймов данных
// инициализация строки и переменной counter
String sample_string = "a beautiful day";
int counter = 0;
for (int i=0;i