Резервный канал уведомлений: дойдёт ли алерт, если Telegram лёг

MAATRIX

Почти у каждого небольшого проекта алерты настроены на один канал — обычно это бот в Telegram, реже Slack или webhook в корпоративный чат. Пока канал жив, всё выглядит надёжно: сервис упал — пришло сообщение, вы отреагировали. Проблема в том, что сам канал доставки тоже может отказать, и часто отказывает именно тогда, когда сигнал важнее всего — во время масштабного сбоя, DDoS, блокировки или проблем у самого мессенджера. Разберём, почему единственный канал уведомлений — это скрытая точка отказа, и как выстроить резервную доставку так, чтобы она реально работала, а не просто существовала в конфиге.

Единая точка отказа в уведомлениях

Мониторинг обычно проектируют избыточным: несколько нод Prometheus, реплики Zabbix-сервера, резервные проверки Uptime Kuma с разных локаций. Но вся эта избыточность утыкается в одну точку, о которой редко думают — канал, по которому алерт физически доходит до человека. Если и Alertmanager, и Zabbix, и Uptime Kuma настроены слать сообщения в один и тот же Telegram-бот, у вас формально три независимых системы мониторинга и один канал связи. Если он отказывает, отказывают все три системы одновременно, хотя каждая по отдельности продолжает корректно работать и даже не подозревает о проблеме.

Это классическая ошибка проектирования отказоустойчивости: резервируют то, что легко резервировать (сборщики метрик, движки правил), и не резервируют то, что кажется мелочью — последний шаг доставки. Статистически именно этот шаг ломается чаще, чем сам мониторинг: он зависит от внешнего API со своими инцидентами, лимитами и блокировками, никак не связанными с состоянием вашей инфраструктуры.

Здесь важна корреляция отказов. Проблема не в том, что Telegram ломается часто сам по себе — он довольно стабилен. Проблема в том, что причины, из-за которых лежит ваш сервис, нередко задевают и канал уведомлений тоже: блокировка провайдером диапазона IP, в который попал и API Telegram; сбой у upstream-провайдера дата-центра, через который идёт и прод-трафик, и исходящие запросы бота; DDoS на сеть, из-за которого недоступны и сайт, и исходящие соединения сервера мониторинга. В момент, когда алерт нужнее всего, шансы, что единственный канал доставки тоже недоступен, выше, чем в среднестатистический день.

Как на практике отказывает Telegram и другие каналы

«Telegram лёг» на практике встречается реже, чем кажется по формулировке темы — гораздо чаще отказывает не сам мессенджер, а путь к нему конкретно с вашего сервера или конкретно для вашего бота:

• Блокировка Telegram или отдельных его доменов на уровне сети или провайдера. В ряде юрисдикций периодически блокируют доступ к Telegram целиком или к его API-эндпоинтам (api.telegram.org) без блокировки остального интернета. Сервер продолжает работать, отдаёт сайт пользователям, но исходящий запрос к Telegram API просто не проходит — таймаут или RST на уровне файрвола провайдера.
• Бот заблокирован пользователем или удалён из чата. Человеческий фактор: кто-то случайно нажал «Заблокировать бота» в личке, бота удалили из группового чата при чистке участников, поменяли админов канала и забыли перевыдать права боту. API в ответ на попытку отправки вернёт 403 Forbidden, и если эта ошибка не логируется отдельно — молчание выглядит так же, как отсутствие инцидентов.
• Истёк или отозван токен бота. При ротации секретов, компрометации токена или случайном /revoke у BotFather старый токен перестаёт работать мгновенно и без предупреждения.
• Rate limit на стороне Telegram. У Telegram Bot API есть ограничения на частоту сообщений — около 30 сообщений в секунду суммарно и жёсткие лимиты на сообщения в один и тот же чат. При каскадном инциденте, когда за минуту срабатывает полсотни правил алертов одновременно, часть сообщений может быть отброшена с 429 Too Many Requests, и именно нужное сообщение о падении основного сервиса потеряется в потоке.
• Проблема на стороне самого Telegram. Реже, но случается: региональные сбои датацентров Telegram, деградация конкретного региона API. Отдельно разбирали похожий случай, когда alertmanager технически отправил сообщение, но оно ушло в чат, который никто не открывал — доставка формально состоялась, а до человека сигнал не дошёл ровно с той же практической разницей, что и при полном отказе канала.

Ни один из этих сценариев не требует, чтобы «упал весь Telegram» — достаточно локальной проблемы именно на вашем маршруте доставки, и результат один: критичный алерт не приходит.

Принцип: второй независимый канал доставки

Решение не в том, чтобы искать более надёжный мессенджер — надёжного единственного канала не существует в принципе, у любого сервиса есть свои инциденты. Решение — отправлять критичные алерты минимум по двум независимым каналам одновременно, а не последовательно с фолбэком через час. Независимость здесь ключевое слово, и она должна выполняться на нескольких уровнях:

• Разный протокол/провайдер доставки. Telegram Bot API и SMTP-почта — хороший пример: у них нет общей инфраструктуры, общей точки блокировки, общего провайдера. Если заблокирован Telegram, почта чаще всего продолжает работать, и наоборот.
• Разный получающий сервис на стороне человека. Если и основной, и резервный канал в итоге приходят на один и тот же телефон с одним и тем же интернет-соединением — вы всё ещё не устранили точку отказа полностью, но снизили её до уровня «личное устройство/сеть человека», а не «внешний сервис». Идеально, когда хотя бы один канал (например, почта) дублируется на другое устройство или на почтовый клиент, синхронизирующийся независимо.
• Разная точка входа алерта в систему уведомлений. Если у вас общий скрипт-обёртка, который сначала пытается отправить в Telegram, и только при ошибке HTTP-запроса шлёт письмо, — это уже лучше, чем ничего, но хуже, чем параллельная отправка в оба канала сразу. Последовательный фолбэк добавляет задержку и зависит от того, что ошибка вообще будет корректно поймана и обработана — а если Telegram не вернёт ошибку, а просто зависнет на таймауте в 30 секунд, вы потеряете драгоценное время на инцидент, прежде чем сработает резерв.

На практике для большинства небольших и средних проектов достаточно связки «мессенджер + email»: мессенджер — для скорости и удобства (пуш на телефон), email — как медленный, но исторически самый независимый и живучий канал доставки, который работает даже когда всё остальное в интернете штормит. У нас есть отдельный разбор про настройку почтовых уведомлений от сервера — эта же связка отлично подходит именно как резерв к мессенджеру, а не только как основной канал.

Настройка резервного канала: Alertmanager, Zabbix, Uptime Kuma

Для Prometheus Alertmanager резервирование настраивается через несколько получателей на один маршрут — continue: true заставляет проверить и следующие маршруты вместо остановки на первом совпадении:

route:
  receiver: telegram-primary
  routes:
    - match:
        severity: critical
      receiver: telegram-primary
      continue: true
    - match:
        severity: critical
      receiver: email-backup

receivers:
  - name: telegram-primary
    telegram_configs:
      - bot_token: "123456:AA...token"
        chat_id: -1001234567890
        parse_mode: "HTML"

  - name: email-backup
    email_configs:
      - to: "oncall@example.com"
        from: "alertmanager@example.com"
        smarthost: "smtp.example.com:587"
        auth_username: "alertmanager@example.com"
        auth_password: "app-specific-password"
        require_tls: true

Важный нюанс: если оба маршрута совпадают по условию severity: critical, Alertmanager отправит уведомление в оба receiver'а параллельно, а не последовательно с ожиданием ошибки — это и есть нужное поведение для по-настоящему независимого резерва.

В Zabbix резервирование делается через типы носителей (Media types) и действия (Actions). Заводите два media type — Telegram (встроенный webhook-скрипт или шаблон) и Email — и привязываете оба к пользователю в разделе Users → Media:

Users → <ваш пользователь> → Media
  Type: Telegram      | Severity: Disaster, High | Active: включено
  Type: Email          | Severity: Disaster, High | Active: включено

Zabbix при срабатывании триггера с нужным severity отправит уведомление по обоим media type независимо, каждое по своему транспорту.

В Uptime Kuma ещё проще: в Настройки → Notifications добавляете оба провайдера (Telegram-бота и SMTP, или ntfy/Pushover как третий вариант), а затем в конкретном мониторе отмечаете галочками оба, а не один — без правки YAML или конфигов. Если основной канал ещё не настроен вообще, статья про настройку алертов в Telegram на VPS с нуля пригодится как первый шаг перед резервированием.

Почему независимость каналов нужно проверять технически

Мало добавить второй receiver в конфиг — нужно убедиться, что он действительно независим от первого на уровне инфраструктуры, а не только по названию. Частая ошибка: и Telegram-бот, и «резервная» почта отправляются с одного и того же сервера через один и тот же исходящий IP. Если у хостинг-провайдера заблокирован исходящий трафик (например, порт 25 или 587 для SMTP закрыт по умолчанию для новых VPS — это массовая практика у многих провайдеров против спама), недоступны могут оказаться сразу оба канала, просто по разным причинам, но с одной и той же первопричиной — сетевые ограничения конкретного сервера.

Проверить исходящий SMTP с сервера мониторинга можно так:

# Проверка, что исходящий 587 вообще открыт
nc -zv smtp.example.com 587

# Ручная отправка тестового письма через msmtp
echo -e "Subject: test alert\n\nПроверка резервного канала" | msmtp --debug oncall@example.com

Если провайдер блокирует исходящий SMTP на уровне сети, для email-резерва лучше использовать внешний транзакционный сервис (SMTP-релей стороннего провайдера рассылок) вместо прямой отправки с того же VPS — тогда доставка идёт через инфраструктуру, физически не связанную с вашим сервером, и падение вашей сети не убивает оба канала разом.

Второй момент независимости — учётные данные и владелец сервиса. Если Telegram-бот и почтовый аккаунт зарегистрированы на один и тот же email, который в свою очередь получает 2FA-код в тот же Telegram — при компрометации или блокировке аккаунта у вас может одновременно накрыться доступ к управлению обоими каналами, даже если сама доставка технически работает.

Регламент периодической проверки резервного канала

Настроенный, но никогда не проверявшийся резервный канал — это иллюзия защиты, а не защита. Конфиг может быть синтаксически верным и годами не срабатывать ни разу, потому что критичных алертов давно не было — а значит, никто не узнает, что SMTP-пароль устарел или домен для email потерял MX-запись, до реального инцидента. Разбор похожего сценария с проверкой самого мониторинга на живучесть есть в статье «кто сторожит сторожа» — с резервным каналом действует ровно тот же принцип: не настроил и забыл, а настроил и регулярно тестируешь.

Практическая схема проверки:

1. Раз в месяц — тестовый алерт по обоим каналам одновременно. Отправьте синтетическое тестовое уведомление (не настоящий инцидент) через оба маршрута и зафиксируйте факт получения в обоих местах. Для Alertmanager это можно сделать через amtool:

amtool alert add alertname="test-backup-channel" severity="critical" \
  --alertmanager.url=http://localhost:9093

1. Автоматизируйте проверку через systemd timer, чтобы не забывать делать это вручную:

# /etc/systemd/system/backup-channel-test.timer
[Unit]
Description=Ежемесячная проверка резервного канала алертов

[Timer]
OnCalendar=monthly
Persistent=true

[Install]
WantedBy=timers.target

1. Ведите короткий журнал проверок — дата, оба ли канала доставили, время доставки. Это не бюрократия ради бюрократии: журнал за полгода наглядно покажет, если резервный канал стабильно приходит на 3–5 минут позже основного, и вы успеете это учесть до того, как задержка станет критичной во время реального инцидента.

1. Раз в квартал — учебная тревога с полным циклом, включая проверку, что человек на дежурстве реально увидел и отреагировал на алерт из резервного канала, а не только что письмо технически долетело до почтового ящика. Подробный разбор формата такой тревоги — в статье про регулярную проверку алертов раз в квартал.

Отдельно полезен паттерн dead man's switch — сервис вроде healthchecks.io, которому ваш мониторинг обязан «отмечаться» по расписанию; если отметки не приходит, healthchecks.io сам присылает уведомление по своим каналам, независимым от вашей инфраструктуры целиком. Это резерв уже другого уровня — не для алертов о падении сервиса, а для случая, когда упал сам мониторинг и не может отправить вообще ничего. Подробнее — в статье про мониторинг cron-задач через healthchecks.io.

Частые вопросы