Когда сервис перестаёт отвечать, хочется узнать об этом раньше, чем проблема обнаружится случайно. Для этого в моей домашней инфраструктуре работает Uptime Kuma, а уведомления отправляются в Telegram.
Но здесь есть две отдельные задачи: обнаружить неисправность и сообщить о ней. Красный статус в панели подтверждает только первую. Если оповещение не отправилось, о сбое можно долго не знать.
Поэтому при настройке мониторинга я проверяю не только сами проверки, но и путь уведомления.
От проверки до сообщения
Схема выглядит просто:
Проверка сервиса → изменение состояния → отправка в Telegram.
За этой короткой цепочкой стоят несколько условий. Проверка должна правильно определять состояние сервиса. К ней должен быть подключён нужный профиль уведомлений. Боту нужны действующий токен и доступ к месту назначения, а серверу — соединение с API Telegram.
Ошибка на любом из этих этапов может оставить уведомление недоставленным. При этом сама панель мониторинга продолжит открываться и показывать статусы.
Одной настройки бота недостаточно
В Uptime Kuma у меня используется общий профиль Telegram-уведомлений. Это позволяет подключать новые проверки к уже настроенному способу оповещения.
Но наличие профиля ещё не подтверждает, что он выбран у конкретного монитора. Поэтому при добавлении проверки я смотрю не только адрес и интервал, но и привязку уведомлений.
Иначе легко получить вполне рабочий монитор, который обнаруживает недоступность, сохраняет историю — и никому о ней не сообщает.
Что показала тестовая отправка
Для проверки использовалась штатная тестовая отправка Uptime Kuma через Telegram.
API вернул успешный результат и идентификатор сообщения. Также был проверен текст, который отправил сервис. Это подтвердило, что на момент теста сервер смог обратиться к Telegram и запрос на отправку был принят.
Здесь важно не приписывать проверке лишнего. Успешный ответ API не означает, что на телефоне включён звук, чат не заглушён и сообщение прочитано.
Техническая доставка и внимание человека — разные вещи. Чтобы проверить всю цепочку до конца, нужно отдельно убедиться, что уведомление видно на нужном устройстве.
Зачем нужны повторные попытки
Короткий сетевой сбой не всегда означает, что приложение действительно перестало работать. Один запрос может завершиться неудачно, а следующий уже получить нормальный ответ.
Для многих моих проверок используется интервал 60 секунд и две повторные попытки. Такая настройка помогает не превращать каждую кратковременную потерю соединения в отдельную тревогу.
У этого решения есть цена: подтверждение сбоя занимает дополнительное время. Поэтому уведомление не следует ожидать мгновенно после первой неудачной проверки.
Это выбранные параметры моей установки. Для разных сервисов допустимая задержка может отличаться.
Сообщение должно быть понятным
В уведомлении мне нужны три вещи: какой сервис проверяется, что произошло и когда это случилось.
Поэтому для оповещений настроены русские шаблоны. Сообщения о недоступности, восстановлении и повторной проверке должны различаться по смыслу, а название монитора — помогать понять, куда смотреть.
Подробная диагностика остаётся в Uptime Kuma. Уведомлению достаточно привлечь внимание и назвать проблему. Длинный технический вывод в Telegram не всегда помогает быстрее разобраться.
Восстановление тоже нужно видеть
Сообщение о недоступности открывает вопрос: проблема ещё продолжается или сервис уже заработал?
Поэтому оповещение о восстановлении для меня так же полезно, как сообщение о сбое. Оно помогает понять, вернулся ли сервис в рабочее состояние и как долго продолжалась недоступность.
При этом зелёный статус подтверждает выполнение конкретной проверки. Если монитор проверяет только открытие страницы, из этого нельзя сделать вывод, что все функции приложения работают исправно.
Иногда ошибается сама проверка
Есть ещё одна причина не воспринимать каждую тревогу как готовый диагноз.
При проверке одной DNS-записи монитор показывал ошибку, хотя нужный открытый ключ уже был опубликован. Причиной оказалось слишком строгое сравнение: допустимый вариант записи с явно указанным алгоритмом не совпадал с ожидаемой строкой.
После уточнения условия проверка получила успешный результат. Менять DNS ради зелёного индикатора не потребовалось.
Этот случай хорошо показывает, зачем разбирать причину уведомления. Оно сообщает о невыполненном условии проверки, а объяснение ещё предстоит найти.
Что я считаю результатом
После настройки мониторинга полезно иметь несколько отдельных подтверждений:
- проверка получает свежие результаты;
- к ней подключён нужный профиль уведомлений;
- тестовая отправка принимается Telegram;
- текст сообщения понятен;
- уведомление видно на устройстве, где его будут читать.
В моей настройке техническая отправка через Telegram была подтверждена тестом. Проверку звука, настроек чата и прочтения на телефоне она не заменяет.
Мониторинг нужен мне, чтобы вовремя узнавать о проблемах. Поэтому путь от проверки сервиса до понятного сообщения заслуживает такого же внимания, как и сами зелёные индикаторы.