ELK Stack
ELK Stack, What?
Юз кейсы, когда нужно внедрять ELK:
Юз кейсы, когда рекомендуется внедрять ELK:
когда девы хотят красивенько смотреть логи в браузере
когда Вы хотите красивенько смотреть логи в браузере
когда у Вас есть необходимость посмотреть что было с аппом в период с 19:45:08 до 19:45:10 и nano на сервере подвисает
Анти юз кейсы, когда не нужно внедрять ELK:
Во всех остальных случаях внедрять агрегацию логов однозначно нужно, тем более, что это решает одну самую главную проблему любого Ops/DevOps/Sysadmin:
— Здравствуйте, бородатый сисадмин! Зайдите, пожалуйста, на сервер sheet.prod.it.company, и скопируйте мне одну строку лога за неделю назад, я не знаю какую, но она была примерно 500000 секунд назад, там ещё ошибка была! Спасибо!
— Я DevOps, вот тебе инструмент: зайди на kibana.it.company ищи там что тебе нужно.
— Благодарю Вас, о великий DevOps! Больше никогда не буду отвлекать Вас по таким пустякам!
Внедряем!
Сначала определимся с терминами:
Пререквизиты
В Logstash заваливаются сами логи, он их процессит внутри согласно правилам которые Вы опишете, и индексирует в хранилку, в Elasticsearch. Соответственно ему нужен CPU для парсинга, и немного мема чтобы держать в памяти то, что уже распарсилось но еще не успело залезть в Еластик.
Через Kibana все будут взаимодействовать с хранилкой логов. Кибана любит открывать 100500 соединений в кластер Еластиксерча, рекомендую поставить эти продукты поближе.
Filebeat опа, внезапность, будет стоять на каждой виртуалке и отправлять нам логи.
Сетап
Ничего сложного, довольно тривиальный процесс.
Как оно работает
Filebeat Интерналс
В конфигах нужно указать путь к лог файлу, дать тип для этого типа логов, и настроить урлу логстеша, куда он будет отсылать. Все.
Logstash Интерналс
Конфиг логстеша делится на 3 части: инпут, фильтр, аутпут. Инпутов у него очень много разных, реально используется beats:
На этих портах будет слушать Логстеш. Закрываем его шифрованием, чтобы никто плохой ничего лишнего не прислал.
После того как лог попадёт в инпут, и это будет валидный тип (тот, который слушает логстеш на этом инпуте), он уйдет дальше в фильтр.
Инпутов очень много. Справедливости ради стоит сказать, что пацаны которые не успевают парсить логстешем логи ставят перед ним Rabbit/Redis/Kafka для того, чтобы создавать пул задач на логстеш. Это не очень хорошее решение.
> Кстати, хоть grok и mutate использовать плохо, потому что grok выносит CPU своими регекспеми, а mutate превращает Logstash в однопоточный костыльный апп, все равно почитать про них нужно.
Когда лог пройдет все фильтры, он попадет в аутпут. Как правило, с аутпутом все просто:
До этого этапа я пытался вызвать когнитивный диссонанс:
юзать только beats инпут
не делать пул тасок перед логстешами
— Кококо, у меня логи стремные, я не смогу их так красиво распарсить и разложить по полкам! Я cдохну собирать разные строки стектрейса используя multiline, и потом это матчить регекспом, используя grok!
— Да. Поэтому пиши лог в json.
Это очень элегантное решение которое разруливает все вопросы с перформенсом и серчем. Девы должны сразу писать в джейсоне. Не буду останавливаться на этом, это слишком очевидно чтобы объяснять что-то еще.
> Кстати, в json писать умеют все. Начиная с nginx и haproxy, заканчивая log4j, log4net, log4py, etc.
Elasticsearch Интерналс
Он работает даже если его не трогать. Пусть работает. Главное не забывать писать в отдельные индексы:
Перформенс будет теряться на больших или размазанных выборках. Не нужно пытаться серчить все ерроры за миллион лет, ищите точное вхождение нужного ексепшена, который вызвал этот еррор.
С Еластиком интегрится очень много крутых штук. Например, для понимания того что происходит внутри еластика отлично подходит elasticsearch-kopf, с помощью его можно смотреть стату по всему кластеру: ноды/индексы/шарды/ресурсы/маппинги.
Очень интересно интегрироваться с Grafana, и потом рисовать, например, персентили скорости ответа нжинкса хомяка.
Graylog
Альтернатива
> Кстати, Уважаемый Сева из Grammarly рассказывал интереснейшую историю про Mozilla Heka, судя по отзывам эта вещь немного бревно, но универсальное. В общем, интересно что получится из этого.
Severity: Important
Резюмируя скажу, что ELK Stack на данный момент единственное продакшн решение для Logs aggregation, которое стабильно работает при любых адекватных и неадекватных нагрузках, отлично скейлится, и дает себя настраивать так, как это нужно конкретно Вам.
Важно помнить, что лучше не парсить логи, а писать их сразу в нормальном формате для быстрого индексирования.
Ведение журналов с использованием эластичного стека
Существует множество хороших средств централизованного ведения журналов, которые изменяются по затратам от бесплатных средств с открытым исходным кодом до более дорогостоящих вариантов. Во многих случаях бесплатные инструменты должны быть как или более надежными, чем оплаченные предложения. Одним из таких инструментов является сочетание трех компонентов с открытым исходным кодом: Elasticsearch, Logstash и Kibana.
Вместе эти средства называются стеком эластичных баз данных или ELK.
Эластичный стек
Эластичный стек — это мощный вариант для сбора информации из кластера Kubernetes. Kubernetes поддерживает отправку журналов в конечную точку Elasticsearch, и в большинстве случаеввсе, что необходимо для начала работы, — задать переменные среды, как показано на рис. 7-5:
Рис. 7-5. Переменные конфигурации для Kubernetes
Этот шаг устанавливает Elasticsearch в кластере и целевой объект, отправляя в него все журналы кластера.
рис. 7-6. Пример панели мониторинга Kibana, в которой показаны результаты запроса к журналам, принимаемым из Kubernetes
Каковы преимущества эластичного стека?
Эластичный стек обеспечивает централизованное ведение журналов с экономичным, масштабируемым и облачным способом. Его пользовательский интерфейс упрощает анализ данных, позволяя тратить время на получение ценных сведений из данных вместо борьбы с интерфейсом неуклюжим. Он поддерживает широкий спектр входных данных, так как распределенное приложение охватывает больше и разных типов служб, поэтому вы можете продолжать работать с данными журналов и метрик в системе. Эластичный стек также поддерживает быстрый поиск даже в больших наборах данных, что делает возможным даже для больших приложений запись подробных данных в журнал и по-прежнему иметь возможность видеть их в удобном для себя виде.
Logstash
Первый компонент — Logstash. Это средство используется для сбора данных журнала из большого спектра различных источников. Например, Logstash может считывать журналы с диска, а также отправлять сообщения из библиотек ведения журналов, например Serilog. Logstash может выполнять некоторую базовую фильтрацию и расширение журналов по мере их поступления. Например, если журналы содержат IP-адреса, Logstash можно настроить для выполнения географического поиска и получения страны или даже города происхождения сообщения.
Рис. 7-7. Serilog config для записи сведений журнала непосредственно в logstash по протоколу HTTP
Logstash будет использовать конфигурацию, подобную показанной на рис. 7-8.
Рис. 7-8. Конфигурация Logstash для использования журналов из Serilog
Для сценариев, в которых не требуется много операций с журналами, существует альтернатива Logstash, известного какнезначительное. Ритм — это семейство средств, которое может собирать разнообразные данные из журналов в данные сети и сведения о времени работы. Многие приложения будут использовать как Logstash, так и ритмы.
После того, как журналы собраны с помощью Logstash, им нужно поместить их в любое место. Хотя Logstash поддерживает множество различных выходов, одна из самых интересных — Elasticsearch.
Elasticsearch
Elasticsearch — это мощная поисковая система, которая может индексировать журналы по мере их поступления. Он позволяет быстро выполнять запросы к журналам. Elasticsearch может обрабатывать огромные объемы журналов, и в крайних случаях их можно масштабировать на нескольких узлах.
Сообщения журнала, которые были созданы для хранения параметров или которых были разделены с помощью обработки Logstash, можно запрашивать напрямую, так как Elasticsearch сохраняет эти сведения.
Рис. 7-9. Запрос Elasticsearch для поиска 10 ведущих страниц, посещенных пользователем
Визуализация информации с помощью веб-панелей мониторинга Kibana
Последним компонентом стека является Kibana. Это средство используется для предоставления интерактивных визуализаций на веб-панели мониторинга. Панели мониторинга могут создаваться даже пользователями, которые не являются техническими. Большинство данных, находящихся в Elasticsearch индексе, могут быть добавлены на панели мониторинга Kibana. Отдельные пользователи могут иметь разную панель мониторинга, и Kibana обеспечивает эту настройку, позволяя пользователям просматривать панели мониторинга.
Установка эластичного стека в Azure
Эластичный стек можно установить в Azure множеством способов. Как всегда, можно подготавливать виртуальные машины и устанавливать эластичный стек на них напрямую. Этот вариант является предпочтительным для некоторых опытных пользователей, так как он обеспечивает наивысшую степень настройки. При развертывании на основе инфраструктуры в качестве службы вы узнаете о значительных затратах на управление, которые применяют этот путь, чтобы стать владельцем всех задач, связанных с инфраструктурой, таких как обеспечение безопасности компьютеров и обновление исправлений.
Параметр с меньшими издержками заключается в использовании одного из многих контейнеров DOCKER, для которых уже настроен эластичный стек. Эти контейнеры можно удалить в существующий кластер Kubernetes и запустить вместе с кодом приложения. Контейнер себп/Elk — это хорошо документированный и протестированный контейнер эластичного стека.
ELK Stack для хранения логов Django приложения
Каждый из проектов, который перерастает этап прототипа, нуждается в организации логирования. Грамотное логирования решает уйму проблем и помогает понять состояние проекта. На начальном этапе логирование в файл меня устраивало пока проект не разросся и поиск по логам не начал отнимать время.
Решением было создание централизованного лог хранилища с агрегацией логов и поиском. Выбор пал на ELK стек. ELK — сочетание трех OpenSource проектов: ElasticSearch, Logstash и Kibana. ELK хранит логи, строит графики и есть поддержка полнотекстового поиска с фильтрами. В статье описывается процесс настройки ELK стека для хранения логов Django приложения.
Установка ELK
Для установки ELK стека будет использоваться Docker, за основу взят репозиторий docker-elk. Изменим настройку Logstash-а, добавим GROK паттерн для матчинга nginx логов и изменим output секцию, чтобы логи Django приложения и nginx логи сохранялись в разных индексах ElasticSearch-а. В итоге logstash.conf выглядит так:
После внесения изменений запускаем стек:
После запуска стек слушает следующее порты:
Архитектура логирования
Рассмотрим архитектуру логирования Django приложения.
Как видно из схемы, приложение состоит из сервисов: nginx, django application, celery worker. Каждый из сервисов отправлял логи в ELK стек. Рассмотрим настройку каждого сервиса по отдельности.
Запись Nginx логов в ELK
Для работы с nginx логами потребуется дополнительный сервис Filebeat. Процесс установки Filebeat детально описан на официальном сайте. Пример установки Filebeat сервиса на Ubuntu сервер:
Filebeat будет читать логи из файла и отправлять в Logstash. Пример конфигурации:
Запускаем наш Filebeat сервис и наблюдаем за появлением логов в Kibana.
Запись Django логов в ELK
Для взаимодействия Django с сервисом Logstash установите дополнительный пакет Python-logstash.
Изменим настройки Django приложения, чтобы логи отправлялись в Logstash сервис.
После этого приложение будет отправлять логи в Logstash. Пример использования:
После этого настройте Kibana под себя, чтобы отображать необходимую информацию. Пример скриншотов собственной настройки:
Система собирает логи сервисов, позволяет по ним удобно искать, строить графики и визуализации, позволяя в кратчайшие сроки обнаружить и исправлять проблемы.
Стек ELK
Что такое стек ELK?
ELK – это аббревиатура, используемая для описания стека из трех популярных проектов: Elasticsearch, Logstash и Kibana. Стек ELK, зачастую именуемый Elasticsearch, предоставляет возможность собирать журналы всех ваших систем и приложений, анализировать их и создавать визуализации, чтобы мониторить приложения и инфраструктуры, быстрее устранять неполадки, анализировать систему безопасности и многое другое.
E = Elasticsearch
Elasticsearch – это распределенный поисковый и аналитический движок на базе Apache Lucene. Он становится идеальным инструментом для различных примеров использования аналитики журналов и поиска благодаря поддержке различных языков, высокой производительности и документам JSON без схем. Подробнее »
21 января 2021 года Elastic NV объявила об изменении стратегии лицензирования программного обеспечения и о том, что новые версии Elasticsearch и Kibana под разрешительной лицензией Apache версии 2.0 (ALv2) выходить не будут. Вместо них предложены новые версии программного обеспечения по лицензии Elastic, а исходный код доступен по лицензии Elastic или SSPL. Эти лицензии не являются открытыми исходными кодами и не дают пользователям ту же свободу. Желая предоставить специалистам, которые работают с открытым исходным кодом, и нашим клиентам безопасный высококачественный комплект инструментов для поиска и аналитики с полностью открытым исходным кодом, мы создали проект OpenSearch – развиваемая сообществом ветвь открытого исходного кода Elasticsearch и Kibana с лицензией ALv2. Комплект OpenSearch состоит из поискового движка, OpenSearch и интерфейса визуализации и пользовательского интерфейса OpenSearch Dashboards.
L = Logstash
Logstash – это предназначенный для приема данных инструмент с открытым исходным кодом, который позволяет собирать данные из различных источников, преобразовывать их и отправлять в нужное место назначения. Благодаря встроенным фильтрам и поддержке более 200 подключаемых модулей Logstash обеспечивает пользователям простой доступ к данным независимо от их источника или типа. Подробнее »
K = Kibana
Kibana – это инструмент визуализации и изучения данных для просмотра журналов и событий. Kibana предлагает простые в использовании интерактивные диаграммы, встроенные агрегаторы и фильтры, а также геопространственную поддержку, благодаря чему является предпочтительным выбором для визуализации данных, хранящихся в Elasticsearch. Подробнее »
Стек ELK удовлетворяет потребности в сфере аналитики журналов. Когда большая часть ИТ-инфраструктуры перемещается в публичные облака, вам требуется решение для аналитики и управления журналами, которое позволит мониторить эту инфраструктуру, а также обрабатывать любые журналы серверов или приложений и данные навигации. Стек ELK дает простое, но надежное решение по анализу журналов для разработчиков и инженеров DevOps, которое позволяет получить полезные выводы из диагностики сбоев, производительности приложений и мониторинга инфраструктуры – за небольшую плату.
Почему стек ELK настолько популярен?
Потому что стек ELK удовлетворяет потребности в сфере аналитики журналов. Когда большая часть ИТ-инфраструктуры перемещается в публичные облака, вам требуется решение для аналитики и управления журналами, которое позволит мониторить эту инфраструктуру, а также обрабатывать любые журналы серверов или приложений и данные навигации. Стек ELK дает простое, но надежное решение по анализу журналов для разработчиков и инженеров DevOps, которое позволяет получить полезные выводы из диагностики сбоев, производительности приложений и мониторинга инфраструктуры – за небольшую плату.
Стек ELK. Выбор подходящего варианта
Вы можете развернуть стек ELK и управлять с помощью версий Elasticsearch и Kibana Apache 2.0 (до 7.10.2) под лицензией Apache 2.0 или самостоятельно управляемой альтернативой стека ELK с открытым исходным кодом через OpenSearch, OpenSearch Dashboards и Logstash. Вы предпочтете, чтобы разработчики или инженеры DevOps тратили время на создание инновационных приложений или управление операционными задачами, такими как развертывание, обновление, установка и исправление программного обеспечения, резервное копирование и мониторинг? Кроме того, вертикальное масштабирование в соответствии с нуждами вашего бизнеса или обеспечение безопасности и соответствия требованиям – это сложная задача при самостоятельном управлении.
Или выберите более простой, масштабируемый и безопасный вариант.
Знакомство с Amazon OpenSearch Service (преемник Amazon Elasticsearch Service)
Как начать работу с Amazon OpenSearch Service?
Вам повезло — мы создали пошаговое руководство, чтобы помочь вам на старте работы с Amazon OpenSearch Service. С уровнем бесплатного использования AWS вы можете запустить свой первый домен без риска и затрат.
Разбираемся с Machine Learning в Elastic Stack (он же Elasticsearch, он же ELK)
Напомним, что в основе Elastic Stack лежат нереляционная база данных Elasticsearch, веб-интерфейс Kibana и сборщики-обработчики данных (самый известный Logstash, различные Beats, APM и другие). Одно из приятных дополнений всего перечисленного стека продуктов — анализ данных при помощи алгоритмов машинного обучения. В статье мы разбираемся что из себя представляют эти алгоритмы. Просим под кат.
Машинное обучение — платная функция условно-бесплатного Elastic Stack и входит в пакет X-Pack. Чтобы начать им пользоваться достаточно после установки активировать 30-дневный триальник. После истечения пробного периода можно запросить поддержку о его продлении или купить подписку. Стоимость подписки рассчитывается не от объёма данных, а от количества используемых нод. Нет, объём данных влияет, конечно, на количество необходимых нод, но всё же такой подход к лицензированию более гуманный по отношению к бюджету компании. Если нет нужды в высокой производительности — можно и сэкономить.
ML в Elastic Stack написан на С++ и работает за пределами JVM, в которой крутится сам Elasticsearch. То есть процесс (он, кстати, называется autodetect) потребляет всё, что не проглотит JVM. На демо-стенде это не так критично, а вот в продуктивной среде важно выделить отдельные ноды для задач ML.
Алгоритмы машинного обучения делятся на две категории — с учителем и без учителя. В Elastic Stack алгоритм из категории «без учителя». По этой ссылке можно посмотреть математический аппарат алгоритмов машинного обучения.
Для проведения анализа алгоритм машинного обучения использует данные, хранящиеся в индексах Elasticsearch. Создавать задания для анализа можно как из интерфейса Kibana так и через API. Если делать это через Kibana, то некоторые вещи знать необязательно. Например, дополнительные индексы, которые использует алгоритм в процессе работы.
.ml-state — информация о статистических моделях (настройках анализа);
.ml-anomalies-* — результаты работы алгоритмов ML;
.ml-notifications — настройки оповещений по результатам анализа.
Структура данных в базе Elasticsearch состоит из индексов и хранящихся в них документах. Если сравнивать с реляционной базой данных, то индекс можно сравнить со схемой базы данных, а документ с записью в таблице. Это сравнение условно и приведено для упрощения понимания дальнейшего материала для тех, кто только слышал про Elasticsearch.
Через API доступен тот же функционал, что и через веб-интерфейс, поэтому для наглядности и понимания концепций мы будем показывать как настраивать через Kibana. В меню слева есть раздел Machine Learning, в котором можно создать новое задание (Job). В интерфейсе Kibana это выглядит как на картинке ниже. Сейчас мы разберем каждый типа задания и покажем виды анализа, которые можно тут сконструировать.
Single Metric — анализ одной метрики, Multi Metric — анализ двух и более метрик. В обоих случаях каждая метрика анализируется в изолированной среде, т.е. алгоритм не учитывает поведение параллельно анализируемых метрик как это могло показаться в случае Multi Metric. Чтобы провести расчёт с учётом корреляции различных метрик можно применить Population-анализ. А Advanced — это тонкая настройка алгоритмов дополнительными опциями для определённых задач.
Single Metric
Анализ изменений одной единственной метрики — самое простое, что можно тут сделать. После нажатия на Create Job, алгоритм поищет аномалии.
В поле Aggregation можно выбрать подход к поиску аномалий. Например, при Min аномальными будут считаться значения ниже типичных. Есть Max, Hign Mean, Low, Mean, Distinct и другие. Описание всех функций можно посмотреть по ссылке.
В поле Field указывается числовое поле в документе, по которому будем проводить анализ.
В поле Bucket span — гранулярность промежутков на таймлайне, по которым будет вестись анализ. Можно довериться автоматике или выбрать вручную. На изображении ниже приведён пример слишком низкой гранулярности — вы можете пропустить аномалию. С помощью этой настройки можно изменять чувствительность алгоритма к аномалиям.
Длительность собранных данных — ключевая вещь, которая влияет на эффективность анализа. При анализе алгоритм определяет повторяющиеся промежутки, рассчитывает доверительный интервал (базовые линии) и выявляет аномалии — нетипичные отклонения от обычного поведения метрики. Просто для примера:
Базовые линии при небольшом отрезке данных:
Когда алгоритму есть на чём поучиться — базовые линии выглядит так:
После запуска задания, алгоритм определяет аномальные отклонения от нормы и ранжирует их по вероятности аномалии (в скобках указан цвет соответствующей метки):
Warning (голубой): менее 25
Minor (yellow): 25-50
Major (orange): 50-75
Critical (red): 75-100
На графике ниже пример с найденными аномалиями.
Тут видно цифру 94, которая обозначает вероятность аномалии. Понятно, что раз значение близкое к 100, значит перед нами аномалия. В столбце под графиком указана уничижительно малая вероятность 0.000063634% появления там значения метрики.
Кроме поиска аномалий в Kibana можно запустить прогнозирование. Делается это элементарно и из того же самого представления с аномалиями — кнопка Forecast в верхнем правом углу.
Прогноз строится максимум на 8 недель вперёд. Даже если очень хочется — больше нельзя by design.
В некоторых ситуациях прогноз будет очень полезен, например, когда отслеживается пользовательская нагрузка на инфраструктуру.
Multi Metric
Переходим к следующей возможности ML в Elastic Stack — анализу нескольких метрик одной пачкой. Но это не значит, что будет анализироваться зависимость одной метрики от другой. Это то же самое, что и Single Metric только с множеством метрик на одном экране для удобства сравнения влияния одного на другое. Про анализ зависимости одной метрики от другой расскажем в части Population.
После нажатия на квадрат с Multi Metric появится окно с настройками. На них остановимся подробнее.
Для начала нужно выбрать поля для анализа и агрегацию данных по ним. Варианты агрегации тут те же, что и для Single Metric (Max, Hign Mean, Low, Mean, Distinct и другие). Далее данные при желании разбиваются по одному из полей (поле Split Data). В примере мы это сделали по полю OriginAirportID. Обратите внимание, что график метрик справа теперь представлен в виде множества графиков.
Поле Key Fields (Influencers) напрямую влияет на найденные аномалии. По умолчанию тут всегда будет хотя бы одно значение, а вы можете добавить дополнительные. Алгоритм будет учитывать влияние этих полей при анализе и показывать самые «влиятельные» значения.
После запуска в интерфейсе Kibana появится примерно такая картина.
Это т.н. тепловая карта аномалий по каждому значению поля OriginAirportID, которое мы указали в Split Data. Как и в случае с Single Metric, цвет обозначает уровень аномального отклонения. Похожий анализ удобно делать, например, по рабочим станциям для отслеживания тех, где подозрительно много авторизаций и т.д. Мы уже писали о подозрительных событиях в EventLog Windows, которые также можно сюда собирать и анализировать.
Под тепловой картой список аномалий, с каждого можно перейти на представление Single Metric для детального анализа.
Population
Чтобы искать аномалии среди корреляций между разными метриками в Elastic Stack есть специализированный Population-анализ. Именно с помощью него можно поискать аномальные значения в производительности какого-либо сервера по сравнению с остальными при, например, увеличении количества запросов к целевой системе.
На этой иллюстрации в поле Population указано значение, к которому будут относиться анализируемые метрики. В данном это имя процесса. В результате мы увидим как загрузка процессора каждым из процессов влияла друг на друга.
Обратите внимание, что график анализируемых данных отличается от случаев с Single Metric и Multi Metric. Это сделано в Kibana by design для улучшенного восприятия распределения значений анализируемых данных.
Из графика видно, что аномально вёл себя процесс stress (к слову сказать, порождённый специальной утилитой) на сервере poipu, который повлиял (или оказался инфлюэнсером) на возникновение этой аномалии.
Advanced
Аналитика с тонкой настройкой. При Advanced анализе в Kibana появляются дополнительные настройки. После нажатия в меню создания на плитку Advanced появляется вот такое окно с вкладками. Вкладку Job Details пропустили намеренно, там базовые настройки не относящиеся непосредственно к настройке анализа.
В summary_count_field_name опционально можно указать название поля из документов, содержащего агрегированные значения. В этом примере — количество событий в минуту. В categorization_field_name указывается название значение поля из документа, которое содержит некое переменное значение. По маске на это поле можно разбивать анализируемые данные на подмножества. Обратите внимание на кнопку Add detector на предыдущей иллюстрации. Ниже результат нажатия на эту кнопку.
Здесь дополнительный блок настроек для настройки детектора аномалий под определённую задачу. Конкретные кейсы использования (особенно по безопасности) мы планируем разобрать в следующих статьях. Для примера, посмотрите один из разобранных кейсов. Он связан с поиском редко появляющихся значений и реализуется функцией rare.
В поле function можно выбрать определённую функцию для поиска аномалий. Кроме rare, есть ещё пара интересных функций — time_of_day и time_of_week. Они вывляют аномалии в поведении метрик на протяжении дня или недели соответственно. Остальные функции анализа есть в документации.
В field_name указывается поле документа, по которому будет вестись анализ. By_field_name может использоваться для разделения результатов анализа по каждому отдельному значению указанного здесь поля документа. Если заполнить over_field_name получится population-анализ, который мы рассматривали выше. Если указать значение в partition_field_name, то по этому полю документа будут рассчитываться отдельные базовые линии для каждого значения (в роли значения могут выступать, например, название сервера или процесса на сервере). В exclude_frequent можно выбрать all или none, что будет означать исключение (или включение) часто встречающихся значений полей документов.
В статье мы попытались максимально сжато дать представление о возможностях машинного обучения в Elastic Stack, за кадром осталось ещё немало подробностей. Расскажите в комментариях какие кейсы удалось решить при помощи Elastic Stack и для каких задач вы его используете. Для связи с нами можно использовать личные сообщения на Хабре или форму обратной связи на сайте.
Мы разработали обучающий курс по основам работы с Elastic Stack, который адаптируется под конкретные потребности заказчика. Подробная программа обучения по запросу.
