Сообщить об ошибкеКороткий ответ
Единого рецепта нет — нужно явно спроектировать независимый, по возможности более простой "сторожевой" слой (например, внешний dead man's switch / healthcheck, отдельный минимальный стек в другом домене отказа), который детектирует именно недоступность самого observability-стека, а не полагаться на то, что система, которая должна сигнализировать о проблемах, сама просигнализирует о собственном отказе.
Как это работает подробнее
типичная схема — "dead man's switch": правило, которое должно постоянно срабатывать (heartbeat) и отправлять сигнал во внешнюю независимую систему (например, другой облачный провайдер или SaaS типа отдельного uptime-мониторинга); если сигнал не приходит в течение ожидаемого интервала, внешняя система сама поднимает алерт о том, что основной observability-стек, вероятно, недоступен или не функционирует. Также важно физически разделить failure domain: если Alertmanager и Prometheus работают в том же кластере/регионе, что и мониторируемые сервисы, сбой всего региона лишает одновременно и сервис, и видимость в него.
Компромисс: полностью независимый резервный observability-стек в другом регионе/провайдере даёт максимальную гарантию видимости при крупном сбое, но кратно увеличивает стоимость и сложность эксплуатации (двойная конфигурация, синхронизация правил); минималистичный внешний heartbeat дешевле и проще, но покрывает только факт "жив/не жив", не давая детальной картины при частичной деградации. Выбор должен обсуждаться пропорционально бизнес-стоимости "слепого" периода — кандидату стоит явно проговорить, что чрезмерная инвестиция в meta-monitoring для некритичного внутреннего сервиса может быть неоправданной, а для платёжного продукта — обязательной.
Пример кода
# Dead man's switch: алерт, который должен ВСЕГДА быть в состоянии firing
- alert: DeadMansSwitch
expr: vector(1)
labels:
severity: none
annotations:
description: "Этот алерт всегда активен; его отсутствие означает сбой Alertmanager или пайплайна алертов"Что использовать на практике
- Практика. критичные компоненты собственного observability-стека (сам Prometheus, Alertmanager, pipeline логов) нужно мониторить так же, как любой другой production-сервис — с собственными SLO, дашбордами и алертами, но через отдельный, по возможности более надёжный и простой канал (например, простая externally-hosted проверка
curlк/healthzAlertmanager раз в минуту с уведомлением через совершенно другой канал, не зависящий от того же Alertmanager). Избыточность стоит добавлять пропорционально критичности — для небольшой компании может быть достаточно простого внешнего heartbeat-сервиса, для крупной — полноценного резервного observability-стека в другом регионе/провайдере. - Практика. Внешний сервис (например, Healthchecks.io или аналог в другом облаке) настраивается на ожидание регулярного webhook от этого алерта; если webhook не приходит дольше ожидаемого интервала (например, 10 минут), внешний сервис сам отправляет уведомление команде — это и обнаружит сбой собственного Alertmanager, который иначе остался бы незамеченным.
Подводные камни
- Частые ошибки. мониторить observability-стек через сам этот observability-стек (например, алерт "Prometheus недоступен" настроен в том же Prometheus, который недоступен) — классическая логическая ошибка единой точки отказа; не тестировать meta-monitoring регулярно (chaos-тест: сознательно остановить Alertmanager и убедиться, что внешний heartbeat-алерт действительно сработал), из-за чего обнаруживается неработоспособность защитного механизма только в реальный момент сбоя; переусложнять meta-monitoring до такой степени, что он сам становится ещё одной хрупкой системой, требующей отдельного наблюдения без конца.