Автор: Фрэнк Рознер
При наличии нескольких экземпляров Prometheus Alertmanager может быть сложно сопоставить оповещения в разных средах. Было бы здорово, если бы вы могли ретроспективно анализировать все свои оповещения с помощью SQL? Давайте реализуем бессерверный конвейер аналитики предупреждений с использованием таких сервисов AWS, как SNS, Kinesis Firehose, S3, Glue, Athena и CloudFormation.
С сотнями клиентов, распределенных в более чем 50 странах, наши синхронные каналы оповещения могут время от времени перегружаться. Несмотря на шум, ретроспективный анализ проблем в широком диапазоне компонентов и сред становится настоящей проблемой.
Решение, необходимое для достижения этих целей:
- Анализируйте оповещения по нескольким параметрам. Во время крупных региональных или глобальных сбоев бывает сложно отслеживать оповещения, поступающие в разных системах и связанные с одной и той же проблемой. Когда ваш канал оповещения в Slack становится перегруженным, вам нужно решение, которое упрощает анализ и сопоставление этих оповещений во всех ваших регионах и средах. Таким образом, мы можем легко выяснить, каких клиентов затронул конкретный сбой.
- Улучшить оповещения. Сложно определить правила для полезных оповещений. При мониторинге метрик и пороговых значений существует золотая середина между чрезмерно шумными оповещениями и необнаруженными проблемами. Анализ предупреждений на глобальном уровне позволяет увидеть слишком чувствительные сигналы или, возможно, даже ложные тревоги.
- Понимание общего состояния системы. Составление исторического обзора всех оповещений с ежедневными, еженедельными или ежемесячными сводками дает обзор состояния системы, которым мы можем поделиться с заинтересованными сторонами.
Помимо этих целей, мы искали масштабируемое и экономичное решение, в котором мы платим только за то, что фактически используем. Вот почему архитектура решения полностью основана на бессерверных компонентах с оплатой по факту использования. В следующем разделе более подробно объясняется архитектура.
Архитектура
Наша инфраструктура содержит несколько экземпляров Prometheus Alertmanager, которые уже пересылают оповещения в Slack и PagerDuty. Следующая цель — пересылать оповещения в наш новый аналитический конвейер.
Оповещения отправляются экземплярами Alertmanager в центральную тему SNS. В последних версиях Alertmanager это можно сделать напрямую через SNS-приемник, без необходимости в дополнительном компоненте.
Шаблон предупреждающего сообщения представляет собой строку в формате CSV. Это позволяет нам просто группировать отдельные сообщения через поток доставки Firehose в CSV-файлы без заголовков, которые будут храниться на S3.
Затем мы можем настроить таблицу Glue на основе схемы CSV, определенной в Alertmanager, и указать ее на местоположение приемника Firehose S3, чтобы запросить данные с помощью Athena с использованием SQL.
Все компоненты AWS создаются и управляются с помощью CloudFormation для обеспечения воспроизводимости. Это также позволяет контролировать версии конфигурации.
Выполнение
Alertmanager
Чтобы Alertmanager отправлял предупреждения в SNS, вы просто настраиваете приемник SNS и направляете ему предупреждения. Конфигурация приемника содержит ARN целевой темы, тему сообщения, тело сообщения, а также детали аутентификации. В следующем фрагменте кода показано, как настроить конфигурацию Alertmanager с помощью шаблона Helm при условии, что вы управляете Alertmanager в Kubernetes с помощью Helm.
Приятной особенностью Helm является то, что вы можете управлять шаблонами сообщения и темы в отдельных файлах. Шаблон темы просто содержит имя оповещения, а шаблон сообщения определяет схему CSV. Вы можете получить доступ к различным переменным, которые Alertmanager заменяет на основе метаданных предупреждений и доступных меток метрик.
Прежде чем мы сможем развернуть эту конфигурацию, нам нужно создать тему SNS и учетные данные для доступа. Итак, давайте сделаем это дальше.
Социальные сети, Пожарный шланг, S3
Настройка конвейера загрузки в виде CloudFormation YAML утомительна, но проста. Вам потребуется настроить следующие ресурсы:
- AWS::SNS::Topic, который будет получать строки CSV от Alertmanager
- AWS::KinesisFirehose::DeliveryStream, который буферизует строки CSV в более крупные пакеты и записывает их в S3.
- AWS::S3::Bucket для хранения пакетов CSV. Рассмотрите возможность включения шифрования и добавления правила жизненного цикла для удаления старых данных и предотвращения бесконечного увеличения счета.
- AWS::IAM::Role для потока доставки, который позволяет нам записывать данные в корзину S3
- AWS::SNS::Subscription, которая перенаправляет сообщения в Firehose.
- AWS::IAM::Role для подписки, включая политику, позволяющую SNS отправлять сообщения в Firehose.
- AWS::IAM::User с разрешениями на отправку сообщений в SNS вместе с AWS::IAM::AccessKey, который будет использоваться для аутентификации приемника Alertmanager SNS. В идеале вы храните учетные данные в AWS::SecretsManager::Secret.
После создания этих ресурсов вы можете передать учетные данные и тему ARN в Alertmanager и начать прием данных. Далее давайте посмотрим, как сделать данные доступными для запросов через Athena.
Афина и клей
Athena можно использовать для запроса файлов на S3. Однако ей нужно знать, как анализировать эти файлы, и здесь на помощь приходит Glue. Внешняя таблица Glue содержит всю необходимую информацию, чтобы Athena успешно анализировала наши CSV-файлы и делала их доступными для запросов через SQL.
Сначала мы создадим AWS::Glue::Database, которая содержит одну AWS::Glue::Table. Следующий фрагмент CloudFormation содержит определения для обоих ресурсов. Давайте пройдемся по нему шаг за шагом.
Настроить базу данных несложно. Мы лишь указываем, в каком Каталоге он должен находиться, и предоставляем некоторые метаданные, например описание. Определение таблицы немного сложнее, потому что нам нужно указать формат и местоположение файла.
Во-первых, мы устанавливаем тип таблицы как внешний, что означает, что данные расположены на S3. Параметр местоположения дескриптора хранилища содержит соответствующее имя корзины. Мы собираемся использовать стандартные форматы ввода и вывода текста Hadoop/Hive, поскольку мы работаем с файлами CSV, которые основаны на тексте. Параметры сериализации/десериализации (SerDe) содержат специфическую логику синтаксического анализа CSV.
Мы предполагаем, что данные хранятся на S3 с префиксом firehose/, который необходимо настроить в потоке доставки Firehose. Затем Firehose ставит перед каждым пакетом отметку времени создания с почасовым разрешением. Мы можем использовать функцию проекции раздела, чтобы получить ключ раздела таблицы из этого префикса, чтобы мы могли эффективно запрашивать предупреждения по временному диапазону.
После подготовки базы данных и таблицы мы, наконец, можем запросить оповещения. Давайте посмотрим в следующем разделе!
Применение
Запускать запросы в Athena через консоль AWS очень просто. Начните с выбора базы данных предупреждений в каталоге данных AWS и выберите созданную вами таблицу.
Обратите внимание: если вы используете Athena впервые, вам нужно настроить корзину для сохранения результатов запроса. Вы можете использовать то же ведро, что и Firehose, или создать отдельное, если хотите.
Следующий запрос можно использовать для получения количества предупреждений для каждой среды с 20 января 2022 г.:
В зависимости от меток, которые вы указали в своей схеме CSV, вы можете анализировать свои оповещения по своему желанию. Вы также можете запросить данные через приложение, а не через консоль AWS, если хотите.
Заключение
Эта бессерверная архитектура предупреждений представляет собой простое и экономичное решение для запроса предупреждений во многих экземплярах Alertmanager. Однако самая большая проблема заключается в том, что любые изменения схемы CSV должны оставаться обратно совместимыми, и они должны синхронизироваться между всеми вашими экземплярами Alertmanager и Glue.
Если вы можете обойтись одним экземпляром Alertmanager и анализировать оповещения на основе показателей Alertmanager, это будет гораздо более простым, хотя и менее гибким решением. Как вы исторически анализируете свои оповещения? Вам нужно управлять несколькими экземплярами Alertmanager в своей инфраструктуре? Дайте нам знать об этом в комментариях!
Подпишитесь на Технический блог DataStax, чтобы узнать больше историй разработчиков. Посетите наш канал YouTube для учебных пособий и здесь Разработчики DataStax в Твиттере, чтобы узнать последние новости о нашем сообществе разработчиков.
