Проверка, которая замечает не только падение

Обычный пинг зелёный, пока сервер отдаёт хоть что-нибудь. А самый неприятный вид поломки выглядит иначе: сервис отвечает 200 и в теле ответа честно пишет, что очередь растёт, а база не отвечает. Клиенты это уже чувствуют, а мониторинг ещё нет.

Что внутри

1. Срабатывание по расписанию — вход.
2. Запрос к /health сделан с выключенным «падать на плохом коде»: нам нужно тело ответа в любом случае, даже когда код не двухсотый.
3. Что именно ответил — развилка на три исхода. Условия проверяются сверху вниз, и дальше первого сработавшего ничего не считается.
4. Две ветки пишут в Telegram разными словами, третья молча заканчивается.

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

Что настроить под себя

• Адрес и условия. Сценарий рассчитан на ответ вида {"status": "ok"}. Если ваш сервис отвечает иначе, поправьте выражение во второй строке развилки: там читается nodes.check.output.body.status.
• Тексты сообщений. В них подставляются код ответа и значение поля, чтобы по одному сообщению было понятно, куда идти смотреть.
• Третья ветка намеренно ничего не отправляет. Хотите подтверждения «жив», добавьте туда отправку, но помните: уведомление, которое приходит каждые полчаса, перестают читать через день.

Что подключить

Бот Telegram и цель «Расписание» на вкладке «Публикация». Адрес проверки может быть внутренним, если он доступен из интернета; закрытый контур сценарий не увидит.