Как узнать, когда Zabbix не может достучаться до Telegram

http://www.zabbix.com/

В прошлом посте мы настроили уведомления Zabbix в Telegram и разобрали ошибки, которые возвращает сам Telegram. Проблема в том, что сервер мониторинга должен ещё суметь соединиться с серверами ТГ. На территории РФ сейчас это не всегда получается из-за ограничений РКН. На стороне Zabbix при этом триггер срабатывает, action выполняется, а сообщение не покидает сервер. В итоге пропустите алерт.

Когда Telegram недоступен для Zabbix

Встроенного оповещения о проваленных уведомлениях в Zabbix нет, поэтому недоступность Telegram нужно ловить отдельной проверкой. Всё ниже относится к Zabbix 7.0 и штатному media type Telegram.

Как это выглядит в Zabbix

В тексте ошибки как максимум увидите каким образом оборвалось соединение, но причину он вам не скажет. Скрипт media type передаёт ответ HTTP-клиента и не отличает блокировку от сбоя DNS или сети.

Искать эти тексты нужно в Reports / Action log, у строк со статусом Failed. Вот что там может встретиться.

Выбивание по таймауту, ответа нет. Это самый медленный вариант, при котором каждая попытка ждёт полного таймаута media type (у Telegram из коробки это 30 секунд), затем следует пауза 10 секунд. После трёх попыток проходит примерно 110 секунд и строка получает статус Failed.

Соединение отвергнуто сразу. Наиболее частые причины, что адрес разрешается через DNS, но на нужном порту никто не отвечает, либо соединение отклоняется где-то в середине пути.

TCP-соединение смогло установиться, но сразу после начала TLS-рукопожатия его сбросили. На уровне Zabbix это выглядит как он отправил приветствие и получил отказ.

А вот тут соединение закрыли без сброса посреди TLS-рукопожатия (HTTP-клиент увидел неожиданный конец потока).

До Telegram запрос даже не дошёл, сервер не смог обратиться к DNS. Причину такой ошибки нужно искать в доступе к DNS (это уже точно не API Telegram, но вот в контексте недавних падений серверов имен Яндекс кейс вполне реальный).

Все варианты, кроме таймаута, возвращаются за миллисекунды, поэтому три попытки заканчиваются примерно за 22 секунды. В логе сервера на каждую попытку остаётся одна строка примерно такого вида:

В ней нет ни id алерта, ни chat id. С конкретной проблемой её можно связать только по времени.

Неудачная отправка в Telegram в Action log

Как узнать о невозможности доставки

Недоступность Telegram можно заметить отдельным элементом данных, который регулярно обращается к api.telegram.org, и триггером на отсутствие значений. Разумеется сообщение об этом триггере нужно отправлять через другой канал. В противном случае потеряете и его.

В шаблоне Zabbix server health за уведомлениями следят лишь через загрузку процессов alerter, alert manager и alert syncer. Элемента данных и триггера на проваленные отправки в Zabbix нет. Неудачная отправка видна как строка Failed в Reports / Action log и как запись в логе сервера.

На любом хосте создайте элемент данных типа HTTP agent. В примере ниже это хост tg-db_01:

  • Key tg.api.reach
  • URL https://api.telegram.org/
  • Retrieve mode Headers
  • Follow redirects выключено
  • Required status codes 200-399
  • Timeout 5s
  • Update interval 2m
  • Type of information Text

Корневой адрес Telegram отвечает кодом 302 и перенаправляет на страницу про ботов. Собственно поэтому мы и отключаем переход по редиректу и допускаем коды 300-399 как нормальные.

Триггер строим на nodata():

Здесь нужен именно nodata(), а не last(). Если соединение не устанавливается, элемент данных переходит в состояние unsupported с ошибкой Cannot perform request: Connection timed out after 5002 milliseconds. С этими настройками проблема открывается примерно через четыре минуты после потери доступа к Telegram.

Ловушка с коротким интервалом

Засада в том, что HTTP-поллер Zabbix держит HTTPS-соединение с Telegram открытым, пока сервер не закроет его по простою, а это до 75 секунд. Если опрашивать чаще, проверка переиспользует старое соединение и не заметит, что новые уже блокируются. Есть смысл выставлять интервал от 2 минут, чтобы было с запасом.

Примечание: блокировка часто сказывается именно на новых соединениях, поэтому старые ещё несколько минут будут отвечать кодом 302, хотя уведомления уже не уходят.

Для триггера создайте action с отправкой через Email или другой независимый от Telegram канал. Пусть это будет то, на что вы обратите внимание.

Запасной канал

Чтобы дежурный получил и исходные важные алерты, добавьте запасной канал в action, который их отправляет.

Далее в том же шаге операции: сставьте в поле Send only to значение — All —, чтобы action отправлял уведомление во все каналы оповещения пользователя. Пусть лучше Zabbix попытается дойти до вас всеми доступными путями.

Отправка во все media пользователя в одном шаге

Вторым шагом эскалации. Такой шаг не ждёт ошибки доставки Telegram. Он срабатывает, когда истекает длительность первого шага (минимум 60 секунд), а проблема остаётся открытой.

В Zabbix готовые media type из коробки выключены, в том числе Email. Если попытаетесь отправить алерт через такой канал, то эта попытка завершится мгновенно без повторов с такой ошибкой:

В Alerts / Media types включите запасной канал.

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

Надежная отправка сообщений

Если вдруг не хотите обкладывать алертами и мониторингом еще и инфраструктуру отправки алертов в ТГ, то можете воспользоваться сервисом Incident Garden.

С ним вы можете получать алерты в ТГ или даже звонки на мобильные номера РФ.

Дашборд Incident Garden

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