Всем привет! Меня зовут Дмитрий Передрий, я старший инженер сопровождения BI.ZONE WAF. В этом году сфокусировался на развитии и модернизации систем мониторинга. В последнем проекте добился хорошего результата и хочу этим поделиться.
Главным врагом систем мониторинга я вижу огромное количество ложноположительных срабатываний. В статье покажу один интересный и эффективный способ борьбы с ними.
Устройство системы мониторинга в продуктах вроде WAF
Когда имеете дело с WAF, вы работаете со множеством прокси-серверов, которые вдобавок фильтруют клиентский трафик. В таких условиях необходимо не только следить за состоянием своей инфраструктуры, но и обращать внимание на доступность защищаемых интернет-ресурсов. Это нужно, чтобы моментально отлавливать любые серьезные проблемы с оборудованием, сетью или ядром продукта, не допуская продолжительного даунтайма объектов защиты.
В итоге в системе под мониторингом:
Все ноды, участвующие в работе сервиса.
Домены клиентов.
Особенно много трудозатрат требуют веб-ресурсы, так как необходимо отслеживать состояние каждого из них. При этом ресурсы клиентов сильно отличаются по функциональности: от простого сайта для регистрации до высоконагруженного API. Но все же у них есть одна общая черта — особенности реализации бэкенда.
Под этим я понимаю множество факторов на стороне клиента, влияющих на доступность ресурсов. Например:
грамотно настроенный внешний интерфейс,
распределение нагрузки между сервисами,
отказоустойчивость.
Я еще молчу про технические работы на стороне апстрима без предупреждения.
Все это порождает множество ошибок в логах и коды ответа 5xx на ровном месте, что заставляет отдел поддержки постоянно проверять состояние сервиса и сомневаться: «Не мы ли виноваты в недоступности?» Имея дело с большим количеством доменов, вы не раз столкнетесь с феноменом усталости от сигналов тревоги (alarm fatigue) в отделе. Он проявляется в постоянном пропуске незначительных инцидентов, несвоевременной реакции на масштабный сбой, а также усиливает выгорание сотрудников.
Теперь, когда мы разобрали контекст, давайте сформулируем основные проблемы, с которыми сталкивается такая система.
Проблематика
Главным фактором, за счет которого возможно снизить количество ложноположительных срабатываний, я считаю влияние состояния клиентского апстрима на оценку работоспособности сервиса.
Это основной недостаток систем мониторинга, построенных на подходе blackbox. Односторонний взгляд на доступность домена позволяет зафиксировать сам факт проблемы, но не дает достаточно данных для автоматизированного анализа метрик. В результате приходится подключать человека для постаналитики триггера.
Рассмотрим, как это обычно выглядит на практике. В стандартных триггерах, настроенных для контроля доступности:
|
Нестабильность апстрима в такой модели автоматически приводит к срабатыванию, потому что оценивается вся цепочка проксирования трафика целиком.
При срабатывании триггера остается только гадать, где именно произошел сбой:
Проблема может находиться на балансировщике, ноде фильтрации или на стороне апстрима. По сути, вся цепочка остается для нас черным ящиком, что существенно усложняет локализацию сбоя.
В итоге сотруднику приходится выполнять лишние шаги в диагностике. Это приводит к значительным потерям времени.
Я считаю, что важно разделять зоны ответственности и типы мониторинга. Инженеры продукта отвечают за состояние своего оборудования. Доступность доменов — это отдельный класс задач, требующий собственного подхода и инструментов. Дополнительное применение метода Trinity в этом случае поможет корректно локализовать проблемы.
Далее мы намеренно отходим от клиентоориентированного подхода. Пристегните ремни, формулировка звучит спорно, но на практике это оказалось выгодно и для клиентов, и для команды защиты.
Исключение клиентского влияния
Предлагаю изменить систему мониторинга, совместив в ней подходы blackbox и whitebox.
Для удобства разобью изменения на три логических блока:
Чтобы корректно совместить подходы, в каждом из блоков должны произойти изменения. Идея в том, чтобы собирать минимальный набор метрик, достаточный для автоматизированного анализа. На их основе можно выявлять проблемы на инсталляциях. При этом фиксировать проблему будем только в том случае, если она находится в нашей зоне ответственности. В случае проблем на стороне апстрима система автоматически отправит клиентам уведомление о неполадках на бэкенде.
Для успешной реализации нам понадобится:
любой инструмент для мониторинга (я использовал Zabbix);
прокси внутри инфраструктуры, чтобы SNAT был легитимным;
немного свободного времени.
Я сделал проект в Zabbix, позже повторил в связке Prometheus и blackbox exporter. При необходимости его можно адаптировать под любой другой инструмент мониторинга. |
Сбор метрик
Для начала увеличим количество собираемых метрик.
Как я писал ранее, мониторинг на основе подхода blackbox имеет ряд недостатков. Такая система фиксирует сам факт проблемы, но не дает возможности определить, где именно произошел сбой.
Чтобы задействовать механизмы анализа, расширим набор метрик вдвое, добавив новый веб-сценарий. Проверку нужно настроить так, чтобы ее маршрут шел в обход оборудования, состояние которого требуется отслеживать.
Новая схема сбора метрик будет выглядеть следующим образом:
Дополнительный веб-сценарий будет опрашивать апстрим напрямую и получать его актуальный статус. Это позволит отсекать сторонние ошибки и реагировать только на сбои подконтрольного оборудования.
Добавляя всего одну метрику (в нашем случае — удваивая их количество), можно значительно повысить аналитический потенциал системы мониторинга. На практике такой набор является оптимальным минимумом.
Важно учитывать, что эффективность растет нелинейно. Бесконтрольное увеличение числа проверок быстро приведет к перегрузке системы.
Варианты комбинирования и анализа метрик рассмотрим в блоке «Обработка».
Сам веб-сценарий будет выглядеть примерно так:
На этом шаге стоит учесть некоторые риски:
При резком переводе всех веб-ресурсов на схему с двойной проверкой увеличится нагрузка на серверы мониторинга. Стоит заранее рассчитать запас мощности.
Zabbix не поддерживает построение запросов с использованием Server Name Indication (SNI). Для такой инфраструктуры потребуется использовать external scripts или другой инструмент (например, blackbox exporter).
Обработка
После того как метрики собраны, возникает вопрос, как их обрабатывать. Здесь открывается простор для фантазии. Например, можно комбинировать ответы веб-сценария, строя логические выражения. Главная задача — внедрить механизм автоматического анализа, благодаря которому триггер сможет определить, на каком компоненте произошел сбой.
Необходимо добиться детектирования следующих сценариев:
Чтобы регистрировать проблему только при сбое на оборудовании СЗИ, добавим дополнительный шаг в логику выражений триггеров. Он будет учитывать состояние клиентской инфраструктуры при анализе.
Отличия работы выражений можно показать схематично:
Рассмотрим минимальный набор триггеров, который покрывает большую часть требований и дает наиболее достоверную картину состояния системы.
Будем отслеживать три состояния:
тайм-аут при попытке подключения,
некорректный статус-код ответа,
увеличение времени обработки запроса.
Timeout was reached
Если вы задавались вопросом, к чему в названии отсылка к «Матрице», — обозначение Trinity было образовано от самого первого прототипа триггера. Его логическое выражение включало три функции. Название оказалось удачным: короткое, узнаваемое и легко запоминается. Я стал использовать его для обозначения триггеров нового типа — в документации и при сборке шаблонов. В среде, где много формализма, иногда полезно позволять себе такие шалости. Достаточно вспомнить Guru meditation или процесс ping-pong.
Добавление новой функции позволяет срабатывать триггеру только при проблеме на стороне защищаемой цепочки. Вы также можете заметить увеличение обрабатываемых метрик в функции count с 3 до 5. Оно определяет количество запросов веб-сценария, которые участвуют в расчете. Интервал между проверками составляет 30 секунд. Это означает, что сигнал о полной недоступности сервиса поступает через две с половиной минуты. При восстановлении работоспособности триггер сбрасывается сразу после успешной проверки.
Увеличение периода детектирования также расширяет «окно синхронизации» между результатами проверок. Запросы из двух веб-сценариев проходят разными маршрутами, достигают цели и возвращают значения за разное время. В один момент одна проверка может еще фиксировать ошибку, в то время как другая уже вернет положительный результат. Более длинный интервал сглаживает такие расхождения и снижает количество ложных срабатываний.
Описанные выше настройки в тестах показали наилучший результат.
Если захотите воспроизвести это в своей системе, замените в выражении |
Bad status code
Логическое выражение триггера, сигнализирующего о некорректном коде ответа. В этом случае также увеличен период, в рамках которого определяется наличие проблемы.
Bad response time
На мой взгляд, это самый интересный триггер.
Сценарий увеличения времени ответа входит в стандартный набор триггеров и описан в манускриптах Four Golden Signals и RED. Однако в системах blackbox при оценке этого показателя вы, по сути, не получаете конкретной информации, какой именно компонент повлиял на рост времени ответа.
Работая с тысячами веб-ресурсов, любой сетевой лаг может привести к срабатыванию десятков триггеров. В процессе диагностики нередко выясняется, что у всех затронутых доменов один общий апстрим. При общении с клиентом может выясниться, что это внеплановые технические работы или перезапуск сервисов. За одну рабочую смену таких срабатываний может накапливаться несколько сотен.
Именно здесь наиболее заметна польза от совмещения подходов в некий greybox-мониторинг.
Представленные выше настройки в тестах показали наилучший результат.
Результат
Та-дам! Мы получили систему с автоматизированным предварительным анализом метрик.
Настроенные триггеры покрывают большую часть кейсов и позволяют сформировать достоверную картину состояния системы. Важную роль играет и сам подход к построению алертов: в рамках него можно настраивать сложные триггеры, которые будут отсекать лишний шум.
Благодаря такой настройке меняется и сам результат. Система перестает фиксировать только факт проблемы и позволяет отслеживать состояние оборудования.
Если все же к вам приходят с вопросом: «Почему домен недоступен извне?», вы можете предоставить логи с разных маршрутов трафика. По ним будет видно, что апстрим перестал отвечать даже на прямые запросы. Объемные метрики в таких случаях дают более наглядную картину.
Подход Trinity не привязан к конкретным решениям вроде WAF. Его можно применять в любой инфраструктуре, где HTTP-трафик проходит через промежуточные компоненты: прокси, балансировщики, CDN или другие узлы. В таких схемах каждый элемент цепочки остается для наблюдателя черным ящиком, что это усложняет локализацию проблемы. Trinity добавляет точки наблюдения на разных участках цепочки и позволяет определить, где именно возникает сбой. Благодаря этому метод универсален и эффективно работает в различных сетевых инфраструктурах.
Отдельный эффект — снижение нагрузки на поддержку. У нее появляется возможность делиться знаниями с клиентами. Например, создавать чаты с уведомлениями о триггерах, где сотрудники могут оперативно освещать ситуацию.
Проект показал высокий КПД. Примерно за месяц удалось существенно сократить трудозатраты сотрудников. По моим расчетам, отдел поддержки стал экономить более 127 часов рабочего времени в месяц. Надеюсь, этот подход окажется полезным и в ваших системах.
Плюсы:
Более точные триггеры.
Больше метрик для сложного анализа.
Реальная картина состояния инфраструктуры.
На 90,5% меньше ложноположительных срабатываний.
Минус: понимание, что штат отдела поддержки можно оптимизировать.
P. S. Откуда взялась цифра в 90,5%
Незадолго до внедрения системы я подсчитал количество срабатываний старых триггеров. Раньше их было несколько тысяч в месяц, а после внедрения показатель снизился до 251.
