Alerting best practices
Проектирование и настройка эффективной системы оповещения требует времени. Это руководство сосредоточено на построении систем оповещения, которые масштабируются вместе с реальной эксплуатацией.
Описанные здесь практики намеренно изложены на высоком уровне и применимы независимо от инструментов. Используете ли вы Prometheus, Grafana Alerting или другой стек, действуют одни и те же ограничения: сложные системы, несовершенные сигналы и люди на дежурстве.
Работа над оповещениями никогда не завершается. Они развиваются вместе с инцидентами, организационными изменениями и системами, которые они призваны защищать.
Prioritize symptoms, but don’t ignore infrastructure signals
Оповещения должны в первую очередь обнаруживать сбои, заметные пользователю, а не поведение внутренних компонентов. Пользователям не важно, что под перезапустился; им важно, когда приложение работает медленно или даёт сбой. Оповещения на основе симптомов напрямую связаны с влиянием на пользователя.
Метрики надёжности, влияющие на пользователей — задержка, ошибки, доступность — являются лучшими сигналами для вызова дежурного, чем инфраструктурные события или внутренние ошибки.
Тем не менее инфраструктурные сигналы тоже важны. Они могут служить индикаторами раннего предупреждения и часто полезны, когда зрелость оповещений низка. Устойчивый всплеск использования CPU или памяти может не оправдывать вызов дежурного, но может помочь объяснить или предвидеть сбои на основе симптомов.
Инфраструктурные оповещения, как правило, шумные и часто игнорируются, когда с ними обращаются как с сигналами для вызова дежурного. Обычно они лучше подходят для каналов с более низкой серьёзностью, таких как дашборды, списки оповещений или не вызывающие дежурного назначения, например выделенный канал в Slack, где за ними можно следить, не прерывая дежурство.
Ключ — в балансе по мере роста зрелости ваших оповещений. Используйте инфраструктурные оповещения для поддержки диагностики и предотвращения, а не как замену оповещениям на основе симптомов.
Escalate priority based on confidence
Приоритет оповещения часто связывают с влиянием на пользователя и срочностью реакции, но уверенность должна определять, когда необходима эскалация.
В этом контексте эскалация определяет, как уведомляются реагирующие по мере роста уверенности. Это может включать повышение приоритета оповещения, расширение уведомления, вызов дополнительных реагирующих или открытие инцидента, как только вмешательство явно требуется.
Ранние сигналы часто неоднозначны, и уверенность в непреходящем сбое обычно низка. Слишком ранний вызов создаёт шум; слишком поздний означает, что пользователи страдают дольше, прежде чем кто-то начнёт действовать. Небольшое или внезапное увеличение задержки может не оправдывать немедленных действий, но может указывать на развивающийся сбой.
Уверенность растёт по мере того, как сигналы становятся сильнее или начинают коррелировать.
Эскалация оправдана, когда проблемы устойчивы или подкрепляются несколькими сигналами. Например, высокая задержка в сочетании с растущей частотой ошибок или одно и то же событие, срабатывающее в течение продолжительного периода. Такие паттерны снижают вероятность преходящего шума и повышают вероятность реального влияния.
Используйте уверенность в влиянии на пользователя для управления эскалацией и избегайте ненужных вызовов дежурного.
Scope alerts for scalability and actionability
В распределённых системах избегайте создания отдельных правил оповещения для каждого хоста, сервиса или эндпоинта. Вместо этого определяйте правила оповещения, которые масштабируются автоматически, используя многомерные правила оповещения. Это уменьшает дублирование правил и позволяет оповещениям масштабироваться по мере роста системы.
Начинайте просто. По умолчанию используйте одно измерение, например service или endpoint, чтобы оповещения оставались управляемыми. Добавляйте измерения только когда они улучшают действенность. Например, когда отсутствие такого измерения, как region, скрывает сбои или не даёт достаточно информации для быстрого реагирования.
Дополнительные измерения, такие как region или instance, могут помочь определить первопричину, но больше — не всегда лучше.
Design alerts for first responders and clear actions
Оповещения следует проектировать для первого реагирующего, а не для человека, создавшего оповещение. Любой на дежурстве должен быть способен понять, что не так и что делать дальше, без глубокого знания системы или конфигурации оповещений.
Избегайте расплывчатых оповещений, которые вынуждают реагирующих тратить время на выяснение контекста. Каждое оповещение должно чётко объяснять, почему оно существует, что его вызвало и как расследовать. Используйте аннотации, чтобы ссылаться на соответствующие дашборды и runbook’и, что необходимо для более быстрого разрешения.
Оповещения должны указывать на реальную проблему и быть действенными, даже если влияние низкое. Информационные оповещения добавляют шум, не улучшая надёжность.
Если никакие действия невозможны, это не должно быть оповещением — рассмотрите использование дашборда. Со временем оповещения ведут себя как технический долг: легко создавать, дорого поддерживать и трудно удалять.
Проводите регулярный обзор оповещений и удаляйте те, которые не ведут к действию.
Alerts should have an owner and system scope
Оповещения без принадлежности часто игнорируются. У каждого оповещения должен быть владелец: команда, отвечающая за поддержку оповещения и реагирование при его срабатывании.
Оповещения также должны определять область системы, например сервис или инфраструктурный компонент. Область обеспечивает организационный контекст и связывает оповещения с владельцем. Определять чёткие области проще, когда сервисы рассматриваются как полноценные сущности, а организации строятся вокруг владения сервисами.
Service Center в Grafana Cloud может помочь организовать сервис-ориентированное представление вашей системы и согласовать область оповещений с принадлежностью.
После того как определены область, принадлежность и приоритет оповещения, маршрутизация определяет, куда попадают оповещения и как они эскалируются. Маршрутизация уведомлений так же важна, как и сами оповещения.
Оповещения должны доставляться нужной команде и в нужный канал в зависимости от приоритета, принадлежности и рабочих процессов команды. Используйте политики уведомлений, чтобы определить дерево маршрутизации, соответствующее контексту вашего сервиса или области:
- Определите родительскую политику для маршрутизации по умолчанию в пределах области.
- Определите вложенные политики для конкретных случаев или проблем с более высоким приоритетом.
Prevent notification overload with alert grouping
Без группировки оповещений реагирующие могут получать множество уведомлений об одной и той же основной проблеме.
Например, сбой базы данных может вызвать несколько оповещений одновременно, таких как повышенная задержка, более высокая частота ошибок и внутренние ошибки. Вызов дежурного отдельно по каждому симптому быстро превращается в спам уведомлений, несмотря на то что первопричина одна.
Группировка уведомлений объединяет связанные оповещения в одно уведомление. Вместо получения множества вызовов по одной и той же проблеме реагирующие получают одно оповещение, представляющее инцидент и включающее все связанные сработавшие оповещения.
Группировка должна следовать операционным границам, таким как сервис или владелец, определённым политиками уведомлений. Нижестоящие или каскадные сбои следует группировать вместе, чтобы они проявлялись как одна проблема, а не как множество.
Существует также ограничение на количество уведомлений, которые можно отправлять в секунду. Вы можете настроить параметры Contact Point, чтобы снизить расход на электронную почту, настроив одиночные уведомления по email вместо отдельных уведомлений по email. Чтобы это настроить, перейдите в нужный Contact Point для email и включите Single email в необязательных настройках.
Mitigate flapping alerts
Кратковременные всплески сбоев часто вызывают оповещения, которые быстро разрешаются автоматически. Оповещения о преходящих сбоях создают шум и приводят к тому, что реагирующие начинают их игнорировать.
Требуйте, чтобы проблемы сохранялись, прежде чем оповещать. Задайте период pending, чтобы определить, как долго условие должно оставаться истинным до срабатывания. Например, вместо немедленного оповещения о высокой частоте ошибок требуйте, чтобы она оставалась выше порога в течение нескольких минут.
Также стабилизируйте оповещения, настраивая диапазоны запросов и агрегации. Использование необработанных данных делает оповещения чувствительными к шуму. Вместо этого оценивайте по временному окну и агрегируйте данные, чтобы сгладить короткие всплески.
# Reacts to transient spikes. Avoid this.
cpu_usage > 90
# Smooth fluctuations.
avg_over_time(cpu_usage[5m]) > 90Для оповещений по задержке и ошибкам процентили часто полезнее средних значений:
quantile_over_time(0.95, http_duration_seconds[5m]) > 3Наконец, избегайте быстрых уведомлений о разрешении и повторном срабатывании, используя
keep_firing_for или
пороги восстановления, чтобы оповещения оставались активными недолго во время восстановления. Оба варианта уменьшают дребезг и лишние уведомления.
Graduate symptom-based alerts into SLOs
Когда оповещение на основе симптома срабатывает часто, это обычно указывает на проблему надёжности, которую следует измерять и управлять ею более осознанно. Часто это признак того, что оповещение может развиться в цель уровня обслуживания (SLO).
Традиционные оповещения создают давление необходимости реагировать немедленно, тогда как бюджеты ошибок вводят запас времени для действий, меняя подход к срочности. Тогда оповещения можно определять в терминах скорости расходования бюджета ошибок, а не реагируя на каждое незначительное отклонение.
SLO также объединяют разные команды вокруг общих целей по надёжности, предоставляя общее определение того, как выглядит «хорошо». Они помогают объединить несколько оповещений по симптомам в одну ориентированную на пользователя цель.
Например, вместо того чтобы несколько команд настраивали оповещения о высокой задержке, можно использовать одно SLO всеми командами для отражения общей производительности API.
Другие случаи использования см. в разделе когда оповещениям нужно SLO.
Integrate alerting into incident post-mortems
Каждый инцидент — это возможность улучшить оповещения. После каждого инцидента оценивайте, помогли ли оповещения реагирующим действовать быстро или добавили ненужный шум.
Оцените, какие оповещения сработали и как они повлияли на реагирование на инцидент. Проверьте, не сработали ли оповещения слишком поздно, слишком рано или без достаточного контекста, и скорректируйте пороги, приоритет или эскалацию на основе того, что фактически произошло.
Используйте silences во время активных инцидентов, чтобы уменьшить повторяющиеся уведомления, но тщательно ограничивайте их область, чтобы не заглушить несвязанные оповещения.
Разборы инцидентов (post-mortems) должны оценивать оповещения вместе с первопричинами и извлечёнными уроками. Если реагирующим не хватало ключевой информации во время инцидента, обогатите оповещения дополнительным контекстом, дашбордами или лучшими рекомендациями.
Alerts should be continuously improved
Оповещения — это итеративный процесс. Оповещения, которые не пересматриваются и не уточняются, теряют эффективность по мере изменения систем и паттернов трафика.
Планируйте регулярные обзоры существующих оповещений. Удаляйте оповещения, которые не ведут к действию, и настраивайте оповещения или пороги, которые срабатывают слишком часто, не давая полезного сигнала. Уменьшайте ложные срабатывания, чтобы бороться с усталостью от оповещений.
Отдавайте приоритет ясности и простоте в дизайне оповещений. Более простые оповещения легче понять, поддерживать и доверять им под давлением. Предпочитайте меньше качественных, действенных оповещений большому количеству малоценных.
Используйте дашборды и инструменты observability для расследования, а не оповещения.