В мае мы представили построение SQL-графиков и оповещений в ответ на запросы клиентов, которым требовались более сложные условия для уведомлений. Пользователи могли задавать их с помощью произвольного ClickHouse SQL, включая проверки всплесков ошибок относительно скользящей базовой линии. Однако такая гибкость означала необходимость писать и поддерживать SQL-код для расчета базовых линий и определения момента срабатывания оповещений.
Многие из этих требований сводились к обнаружению необычных значений по сравнению с недавней историей. Пользователи хотели применять такие проверки к существующим визуализациям на базе конструктора запросов, поэтому мы добавили во встроенную систему обнаружения аномалий Managed ClickStack использование z-оценок. Пользователи могут настраивать чувствительность и просматривать предварительный результат того, как часто оповещение срабатывало бы за предыдущий день. Мы уделили особое внимание предотвращению ложных срабатываний из-за небольших колебаний в в остальном стабильных метриках.
Команды, переходящие на Managed ClickStack, включая тех, кто мигрирует из Grafana, также принесли с собой десятки тысяч существующих оповещений. Мы улучшили планировщик и внедрили шардинг для распределения вычислений между несколькими воркерами, чтобы справляться с нагрузкой от оповещений в масштабе.
Чтобы упростить управление такими крупными наборами оповещений, мы также улучшили поиск и фильтрацию в пользовательском интерфейсе оповещений, добавили графики, отображающие активность оповещений, и расширили историю вычислений, чтобы помочь пользователям исследовать причины срабатывания или сбоя оповещения.
В этой статье мы рассмотрим эти изменения и то, как они помогают командам переносить больше своих задач по мониторингу и оповещениям в Managed ClickStack.
ClickStack уже некоторое время поддерживает оповещения по статическим пороговым значениям. Они отлично работают, когда есть четкий лимит, который нужно соблюдать. Однако их становится сложнее настраивать, когда вы ищете изменения в поведении, особенно для сервисов с разными нормальными рабочими диапазонами.
Например, рассмотрим сервис, у которого уровень ошибок обычно держится на уровне 0,1%. Увеличение до 0,9% — это существенное изменение, но статический порог, установленный на 1%, промолчит. Снижение этого порога может сработать для данного сервиса, хотя для другого сервиса с более высоким фоновым уровнем ошибок потребуется другая настройка.
Сравнение каждого сервиса с его собственной историей дает нам способ обнаруживать такие изменения без необходимости поддерживать отдельный пороговый уровень для каждого из них. Наша первоначальная реализация обнаружения аномалий использует z-оценки — распространенный статистический подход для сравнения значения с его недавней историей. Это позволяет оценивать каждый сервис по его собственной базовой линии, хотя определение способа расчета этой базовой линии имеет свои нюансы.
Z-оценка измеряет, насколько далеко значение находится от среднего значения базовой линии, выраженное в стандартных отклонениях. Следовательно, ее чувствительность зависит от того, насколько сильно метрика варьируется в нормальном состоянии: изменение, которое является необычным для стабильного сервиса, может быть обычным делом для «шумного». Это создает проблему для системы оповещений, поскольку статистически необычное изменение не всегда достаточно велико, чтобы привлекать к себе внимание.
Мы столкнулись с этим во время разработки. Наша первая попытка оценивала как среднее значение базовой линии, так и стандартное отклонение по короткому периоду непосредственно перед окном оценки. Когда мы протестировали это на метрике памяти, которая практически не менялась, стандартное отклонение было близко к нулю. Даже крошечные колебания приводили к высоким z-оценкам и многократному срабатыванию детектора, несмотря на отсутствие значимых изменений в использовании памяти.
Мы решаем эту проблему, вычисляя ожидаемое значение и стандартное отклонение за разные периоды. Ожидаемое значение берется из скользящего среднего семи исторических одноминутных баскетов, взятых на один интервал оценки раньше. Мы вычисляем стандартное отклонение за более длительный период базовой линии — по умолчанию два часа. Короткое среднее устанавливает уровень, с которым мы сравниваем, в то время как более длинная история показывает нам, какая вариация является нормальной. Затем мы делим разницу между наблюдаемым и ожидаемым значениями на это стандартное отклонение, чтобы вычислить z-оценку.
Мы также требуем изменения как минимум на 5% относительно ожидаемого значения. Это предотвращает создание оповещений крошечными движениями в стабильных метриках просто потому, что они дают большую z-оценку. Для нашего примера с частотой ошибок увеличение с 0,1% до 0,9% легко удовлетворяет этому требованию, даже если оно составляет менее одного процентного пункта.
Мы также обнаружили, что неполные данные могут выглядеть как аномалия. Коллекторы часто отправляют данные пакетами, поэтому оценка минуты сразу после ее окончания может создать впечатление, что стабильный поток прервался. В результате оценка аномалий выделяет 30 секунд на прибытие данных перед проверкой окна.
Мы также обнаружили, что неполные данные могут выглядеть как аномалия. Коллекторы часто отправляют данные пакетами, поэтому оценка минуты сразу после ее окончания может создать впечатление, что стабильный поток прервался. В результате оценка аномалий выделяет 30 секунд на прибытие данных перед проверкой окна.
Вы можете настроить оповещение об аномалии непосредственно из существующего графика в конструкторе запросов, изменив тип оповещения на «Обнаружение аномалий» (Anomaly detection). Помимо чувствительности, вы выбираете, какой объем истории использовать в качестве базовой линии и какое направление изменения должно вызывать оповещение. Значения по умолчанию — порог z-оценки 3 и двухчасовая базовая линия.
Для примера с частотой ошибок вы бы выбрали «Выше ожидаемого диапазона» (Above the expected range), так нас интересует необычное увеличение количества ошибок. Оповещение о пропускной способности может использовать «Ниже ожидаемого диапазона» (Below the expected range) для обнаружения неожиданного падения запросов. Если изменения в любом из направлений требуют расследования, выберите «Вне ожидаемого диапазона» (Outside the expected range). Это подойдет для оповещения об объеме запросов, где как внезапный всплеск, так и внезапное падение могут указывать на проблему.
В каждом случае ожидаемый диапазон рассчитывается с использованием недавней истории метрики и настроенной чувствительности. Если на графике значения сгруппированы по сервисам, каждый сервис оценивается независимо по собственной истории, поэтому сервисы с разным уровнем трафика могут использовать одну и ту же конфигурацию оповещений.
Выбор правильной чувствительности по-прежнему зависит от данных. Мы хотели, чтобы пользователи видели, как поведет себя их конфигурация перед сохранением, поэтому редактор включает предварительный просмотр за предыдущие 24 часа. На графике отображается ожидаемый диапазон и отмечается, куда были бы отправлены уведомления. По мере настройки чувствительности предварительный просмотр обновляется, позволяя проверить, улавливает ли оповещение важные для вас всплески и как часто оно срабатывало бы при в остальном нормальном поведении.
Эта первая реализация предназначена для обнаружения внезапных отклонений от недавнего поведения. Постепенное ухудшение может остаться незамещенным, так как базовая линия следует за ним. Затяжная проблема также может стать частью ожидаемого диапазона, позволяя оповещению разрешиться, пока проблема продолжается. Повторяющиеся суточные и недельные паттерны также требуют иного подхода. Мы намерены устранить эти ограничения в последующих релизах, включая добавление поддержки сезонности. Наконец, мы по-прежнему рекомендуем использовать статические пороговые оповещения для постоянных лимитов, таких как частота ошибок, которая должна оставаться ниже 1%.
За последние несколько месяцев мы заметили высокий уровень внедрения Managed ClickStack, особенно среди команд, стремящихся к минимально возможным удельным затратам на наблюдаемость в больших масштабах. Такие масштабные развертывания часто включают в себя десятки тысяч существующих алертов. Поддержка таких клиентов означает обеспечение способности системы алертинга справляться с нагрузкой по мере роста как количества алертов, так и частоты их проверки.
Когда у клиентов было большое количество алертов, планировщику могло потребоваться больше времени на их оценку, чем было доступно до следующего запланированного запуска. Позднее механизм заполнения пропусков проверял все пропущенные окна оценки, но это означало, что проблемы могли быть обнаружены с опозданием. Эти рабочие нагрузки помогли нам определить, где именно планировщик нуждался в улучшении.
Сами запросы алертов выполнялись в ClickHouse быстро. Большая часть времени уходила на загрузку конфигураций алертов и ожидание соединений. Прежде чем могла начаться оценка, планировщик должен был найти сохраненные поисковые запросы, элементы дашбордов и связанные с ними источники данных. Эти поиски выполнялись последовательно, часто многократно запрашивая ту же информацию для алертов, которые использовали общий дашборд или источник.
Чтобы решить эту проблему, мы изменили планировщик так, чтобы он загружал полную конфигурацию только для тех алертов, которые должны сработать, выполняя эти поиски параллельно и повторно используя общие метаданные в рамках каждого запуска.
Запись результатов была связана с похожей проблемой. Каждый алерт создавал отдельные записи в базе данных, что приводило к лишним операциям записи. Теперь мы записываем эти результаты пакетно, сокращая количество операций с базой данных. Мы также увеличили пул соединений ClickHouse и ограничили очередь оценки, чтобы планировщик контролировал объем передаваемой на обработку работы за раз.
Уведомления создавали еще один источник задержек. Ранее оценка ожидала отправки вебхука, поэтому медленная конечная точка уведомлений могла задерживать планировщик. Чтобы решить эту проблему, мы перенесли доставку в фоновую очередь. Уведомления для конкретного алерта сохраняют свой порядок, в то время как оценка может продолжаться, не дожидаясь ответа от Slack или другого пункта назначения.
Эти изменения увеличили объем работы, с которым мог справиться один рабочий процесс оценки алертов. Для поддержки этого нам потребовалось распределить нагрузку между несколькими воркерами. Это привело нас к необходимости внедрения шардирования оценки алертов.
Каждый алерт назначается на шард с использованием хэша его ID. Каждый воркер использует одно и то же правило назначения и оценивает алерты, принадлежащие его шарду. При стабильном количестве шардов каждый алерт имеет одного владельца. Добавление воркеров перераспределяет алерты по бóльшему количеству шардов, позволяя емкости оценки расти вместе с рабочей нагрузкой. Количество шардов автоматически определяется на основе потребности в оценке.
Частота здесь имеет значение: алерт, проверяемый каждые 30 секунд, требует вдвое больше оценок, чем тот, который проверяется каждую минуту. Когда количество шардов меняется, право собственности переходит между воркерами, а механизм заполнения пропусков покрывает окна оценки, пропущенные во время перехода.
С внедрением этих улучшений мы уверены, что Managed ClickStack сможет справиться даже с самыми требовательными рабочими нагрузками алертинга.
Создав инфраструктуру для оценки алертов в больших масштабах, нам также нужно было сделать управление этими наборами практичным. Пользователям необходимо находить алерты, относящиеся к их сервисам, и понимать, что именно сработало. За последние несколько месяцев мы выпустили ряд поэтапных улучшений пользовательского интерфейса алертов для поддержки этих рабочих процессов.
Первым требованием было поддержание отзывчивости страницы алертов по мере роста коллекций. Теперь страница загружает алерты пачками по 100 штук и отображает только те строки, которые в данный момент видны на экране. Это позволяет пользователям просматривать большие коллекции без необходимости загружать и отображать каждый алерт одновременно.
Найти конкретный алерт также становится сложнее, когда их выбирается из десятков тысяч. Теперь у алертов есть собственные названия и теги, которые можно использовать для их организации и поиска независимо от сохраненного запроса или графика на дашборде, к которому они принадлежат. Вы можете выполнять фильтрацию по состоянию, типу источника или по тому, использует ли алерт статический порог или обнаружение аномалий. Также есть фильтр по созданным вами алертам.
Например, команда может пометить свои алерты тегами сервиса и окружения, а затем отфильтровать список, чтобы отобразить только срабатывающие алерты для конкретного производственного сервиса. Фильтры сохраняются в URL, что позволяет добавить представление в закладки или поделиться им с другим членом команды.
Как только вы нашли алерт, его меню действий предоставляет доступ к редактированию, открытию базового источника, экспорту в Terraform и удалению. Каждая строка также показывает все настроенные каналы уведомлений, что упрощает проверку того, куда именно отправляются уведомления. Если вы уже расследуете инцидент, вы можете подтвердить алерт и отключить его на время от 30 минут до 24 часов.
Мы также расширили информацию, доступную для отдельных алертов. У каждого алерта есть страница с подробной информацией, на графике которой отмечено, когда он сработал и восстановился. Полоса недавних результатов оценки предоставляет историю рядом с графиком, помогая пользователям понять, срабатывал ли алерт непрерывно или неоднократно переключался между состояниями.
Таблица оценки предоставляет более подробную информацию, когда требуется провести расследование. В ней фиксируются наблюдаемое значение и количество затронутых алертингом рядов, а также длительность выполнения запросов и отправки уведомлений. Она также отображает ошибки и информацию о том, были ли заполнены пропущенные окна оценки. Если ожидаемое уведомление не пришло, вы можете проверить, завершился ли запрос ошибкой или тайм-аутом, либо успешна ли оценка при сбое доставки уведомления.
Теперь, когда система алертинга способна поддерживать десятки тысяч алертов, мы уверены, что сможем справиться с более сложными требованиями к алертингу, с которыми команды обычно работают с помощью таких инструментов, как Grafana.
Сезонность — это следующий шаг в обнаружении аномалий. Нормальное поведение сервиса в понедельник утром может сильно отличаться от его поведения в выходные дни. Мы планируем учитывать эти повторяющиеся паттерны, сравнивая значения с базовыми показателями для соответствующего времени суток или дня недели. Мы также будем кэшировать исторические вычисления, чтобы ограничить дополнительные затраты на запросы при таких сравнениях.
Проведенная работа также выявила возможности для улучшения обнаружения зашумленных данных и маломощных сервисов. Мы планируем изучить оценки, которые менее чувствительны к выбросам, включая оценки на основе медианы и квантильные диапазоны. Алерты по уровню ошибок требуют особого внимания при низком трафике, так как небольшое количество неудачных запросов может дать большой процентный измененний. Модели, учитывающие объем запросов, должны помочь отличить эти колебания от изменений, заслуживающих расследования.
Мы также хотим сделать эти возможности более простыми в настройке, добавив более простые пресеты чувствительности и возможность автоматического создания начальных алертов аномалий при подключении телеметрии. Мы также планируем изучить методы машинного обучения там, где они могут улучшить обнаружение, продолжая добавлять функции в ответ на конкретные требования клиентов.
Вслед за нашим анонсом поддержки PromQL и TimeSeries, еще одним приоритетом стало оповещение по метрикам Prometheus. Закрытая предварительная версия включает хранение и выполнение запросов к метрикам, а также их визуализацию в ClickStack. Поддержка оповещений на основе запросов PromQL — важный следующий шаг, который позволит пользователям перенести свои основные рабочие нагрузки по мониторингу метрик в Managed ClickStack.
Следите за дальнейшими анонсами в ближайшие месяцы.
/)
