Elastic Stack 7.14: настраиваем ML anomaly detection для логов сетевого оборудования

Elastic Stack 7.14 вышел на этой неделе, и главное из того, что нам интересно - не Fleet (хотя и он стал заметно удобнее), а изменения в ML anomaly detection. Конкретно: улучшенный count detectors и возможность задавать custom rules прямо в job без дополнительных танцев с API. Это задело нас за живое, потому что мы давно смотрели в сторону ML-based алертинга для сетевых логов у одного из клиентов.

Ниже - что мы сделали, что сработало, что ещё непонятно.

Контекст: откуда вообще задача

У клиента - средней величины распределённая сеть: несколько площадок, маршрутизаторы Cisco, коммутаторы, VPN-концентраторы. Syslog с оборудования идёт в Elasticsearch уже пару лет. Объём - несколько миллионов событий в сутки.

Исторически мониторинг строился на threshold-правилах в Kibana: если за 5 минут больше N ошибок определённого типа - алерт. Схема понятная, простая, и... шумная. Количество ложных срабатываний было такое, что дежурный инженер уже начинал автоматически игнорировать часть алертов. А это ровно та точка, где мониторинг перестаёт работать как мониторинг.

Задача была переформулирована: снизить шум, не потеряв реальные инциденты. Один из путей - ML anomaly detection вместо жёстких порогов.

Что такое anomaly detection в Elastic ML

Elastic ML работает с X-Pack и требует как минимум Gold-лицензии или trial. У клиента лицензия есть, так что этот вопрос мы опускаем.

Суть: ML job обучается на исторических данных, строит модель нормального поведения для выбранных метрик, а затем в real-time оценивает отклонения. Результат - anomaly_score от 0 до 100. Алерт только если score превышает заданный порог, причём этот порог уже про «насколько необычно» относительно baseline, а не «сколько штук за период».

Для сетевых логов это принципиально: количество ошибок на маршрутизаторе в понедельник в 10 утра и в субботу ночью - принципиально разное, и threshold-правило либо будет игнорировать пики в рабочее время, либо кричать на нормальные ночные значения.

Что мы настроили

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

Job 1 - частота ошибок по хосту. count detector с разбивкой по host.name. Job анализирует частоту событий с log.level: error в разрезе каждого устройства. Baseline строится отдельно для каждого хоста - это важно, потому что core-маршрутизаторы генерируют принципиально другой объём логов, чем edge-коммутаторы.

detector: count
by_field_name: host.name
influencers: [host.name, event.category]
bucket_span: 15m

Job 2 - необычные комбинации сообщений. rare detector по message.keyword в разрезе хоста. Ловит появление типов сообщений, которые для данного хоста нетипичны. Именно этот detector показал себя лучше всего для обнаружения начала деградации оборудования: за несколько часов до того как устройство начинает активно сыпать ошибками, в логах появляются единичные редкие сообщения о внутренних состояниях.

Custom rules в 7.14 - зачем нам это

До 7.14 если нужно было научить job игнорировать определённые условия (например, плановое обслуживание или известное поведение конкретного старого коммутатора) - приходилось лезть в API и руками добавлять custom rules через _ml/detectors endpoint. Не страшно, но неудобно и плохо документировано для нас.

В 7.14 custom rules доступны прямо в Kibana при создании и редактировании job. Мы добавили несколько правил:

• Игнорировать аномалии для конкретного хоста в период планового обслуживания - через scope с filter_type: include и calendar-based exception.
• Понизить порог для старого коммутатора - у него исторически более высокий фоновый шум, и model это уже учитывает в baseline, но дополнительно мы явно указали condition: actual < 10 для игнорирования мелких отклонений.

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

Fleet и агенты - для нас побочная тема

7.14 принёс существенные улучшения в Fleet - централизованное управление Elastic Agents. Нас это затрагивает постольку поскольку: агенты уже были развёрнуты раньше, и обновление через Fleet прошло без неожиданностей. Отметим только что elastic-agent в 7.14 стал стабильнее в смысле потребления памяти - было несколько случаев утечки на предыдущих минорных версиях, здесь это, судя по всему, закрыли.

Результаты за первые дни

Запустили в режиме наблюдения (anomaly detection работает, алерты отключены, смотрим только на score) параллельно со старыми threshold-правилами. Смотрели на пересечение: сколько threshold-алертов соответствуют реальным инцидентам, и как ML job оценивает эти же периоды.

По итогам нескольких дней наблюдений: количество событий с высоким anomaly score (выше 75) заметно ниже, чем количество threshold-алертов за тот же период, при этом все реальные инциденты, которые мы знали заранее, были отмечены с высоким score. Ложные срабатывания - то есть высокий threshold при нормальном поведении по ML - убрались примерно на 40% относительно исходного числа алертов.

Цифра пока предварительная - несколько дней это не статистика, аномалии бывают разные, и мы ещё не видели это на реальном инциденте в режиме боевого алертинга. Но направление понятное.

Что осталось непонятным

Интерпретируемость модели. ML job выдаёт score, но объяснение «почему именно сейчас» часто размытое. influencers помогают понять что влияет, но причинность нужно всё равно разбирать руками.

Drift модели. Инфраструктура меняется - добавляется оборудование, меняется топология. Насколько быстро ML job адаптируется к изменению baseline без переобучения - пока открытый вопрос. Документация говорит что модели обновляются continuously, но как это ведёт себя при резких изменениях конфигурации - не проверяли.

Стоимость ресурсов. ML jobs требуют выделенных ML nodes. У клиента они уже есть, но для небольших инсталляций это дополнительные затраты, которые нужно закладывать.

Если коротко: Elastic ML anomaly detection - инструмент не для «поставил и забыл», а для «настроил, понаблюдал, донастроил». Но даже в текущем состоянии он даёт заметно меньше шума, чем пороговые правила. Для задач DWH и аналитики где важна не только инфраструктура, но и качество сигнала - это имеет смысл.