Соблазн собрать полноценный мониторинг с сотнями метрик возникает у всех. На небольшом проекте он заканчивается одинаково: дашборды красивые, никто в них не смотрит, а падение замечает пользователь. Работает обратный подход — очень мало проверок, но каждая означает конкретное действие.
Перед добавлением проверки полезно ответить: что я сделаю, когда она сработает в три часа ночи? Если ответа нет или он звучит как «посмотрю утром», проверка не нужна. Она либо станет фоновым шумом, либо приучит игнорировать оповещения, что хуже, чем не иметь их вовсе.
У меня осталось четыре:
| Проверка | Что означает срабатывание |
|---|---|
| HTTP-код главной страницы | Сервис не отвечает или отвечает ошибкой |
| Свободное место на диске | Через несколько дней упадёт всё сразу |
| Срок сертификата | Автопродление сломалось, есть время починить |
| Сервис в systemd активен | Процесс не поднялся после перезагрузки |
Проверка, живущая на том же сервере, бесполезна ровно в тот момент, когда нужна: сервер лёг вместе с ней. Нужен внешний наблюдатель — сторонний сервис или просто другая машина.
Минимальный вариант на голом shell, если ставить нечего:
#!/bin/bash
URL="https://example.test/"
CODE=$(curl -s -o /dev/null -w '%{http_code}' --max-time 10 "$URL")
if [ "$CODE" != "200" ]; then
curl -s -X POST "$WEBHOOK" -d "text=Проверка $URL вернула $CODE"
fiЗапускается по таймеру раз в пять минут. Такой скрипт покрывает главный сценарий отказа и стоит нисколько.
Проверка раз в минуту звучит надёжнее, чем раз в пять, но приносит ложные срабатывания на любой сетевой икоте. Практичный компромисс — интервал в пять минут и требование двух неудач подряд перед оповещением. Реальное падение никуда не денется за десять минут, а разовые обрывы отсеются сами.
Отдельно стоит проверять сам канал оповещений. Мониторинг, который молчит потому, что у него протух токен для отправки сообщений, выглядит точно так же, как мониторинг, у которого всё хорошо.
Нет графиков загрузки процессора, нет алертов на память, нет счётчиков запросов. Не потому, что это плохо, а потому, что на этом масштабе они ничего не решают: высокая загрузка сама по себе не проблема, если сервис отвечает. А когда перестанет отвечать, об этом скажет первая же проверка.