Оповещения о падении сайта

Графики в панели показывают состояние машины, но не отвечают на вопрос «открывается ли сайт». Приложение может зависнуть при спокойном процессоре, и без внешней проверки вы узнаете об этом от клиентов.

Проверка снаружи

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

• Адрес проверки. Не главную страницу, а отдельный маршрут вроде /healthz, который проверяет и базу, и очередь. Иначе кэшированная главная будет отдаваться при мёртвом бэкенде.
• Ожидаемый ответ. Код 200 плюс подстрока в теле. Многие приложения при поломке отдают 200 с текстом ошибки.
• Порог. Две-три неудачные попытки подряд, иначе вас разбудит любая сетевая икота.
• Канал. Telegram или почта. Проверьте, что оповещение реально доходит: отключите сервис на минуту и дождитесь письма.

Не забудьте отдельную проверку срока сертификата — истёкший TLS выглядит как падение и случается регулярно.

Сторож на самой машине

Внешний контроль скажет, что сайт лежит. Чтобы он поднимался сам, настройте systemd. В юните службы:

[Service]
Restart=always
RestartSec=5
StartLimitBurst=5
StartLimitIntervalSec=120

Так служба переживёт случайное падение, но не будет бесконечно биться в цикле при поломке конфигурации. После правки: systemctl daemon-reload && systemctl restart myapp.

Для приложений, которые не падают, а зависают, добавьте проверку по HTTP. Пара юнитов — таймер и сервис:

cat >/etc/systemd/system/healthcheck.service <<'EOF'
[Service]
Type=oneshot
ExecStart=/usr/local/bin/healthcheck.sh
EOF

cat >/etc/systemd/system/healthcheck.timer <<'EOF'
[Timer]
OnUnitActiveSec=60
[Install]
WantedBy=timers.target
EOF

systemctl enable --now healthcheck.timer

Сам скрипт:

#!/bin/sh
curl -fsS --max-time 10 http://127.0.0.1:8080/healthz >/dev/null || systemctl restart myapp

Оповещение о состоянии машины

Отдельно полезно узнавать о заканчивающемся месте и памяти до аварии. Простейший вариант — задание cron, которое шлёт сообщение в Telegram при превышении порога:

0 * * * * root [ "$(df --output=pcent / | tr -dc 0-9)" -gt 85 ] && curl -s -X POST "https://api.telegram.org/bot$TOKEN/sendMessage" -d chat_id=$CHAT -d text="Диск на VDS занят более 85%"

Более развитый вариант с готовыми порогами даёт Netdata.

Частые ошибки

• Мониторинг на той же машине. Упала машина — умер и сторож, и оповещение.
• Слишком чувствительный порог. Поток ложных тревог приводит к тому, что настоящую вы пролистаете.
• Restart=always вместо разбора причины. Перезапуск маскирует утечку памяти: служба падает каждые полчаса, а вы этого не видите. Проверяйте systemctl show myapp -p NRestarts и журнал.
• Проверка только по ping. Машина отвечает на ICMP и с полностью мёртвым веб-сервером.

Первое, что стоит проверить при тревоге, — «Обзор» в панели /hosting/vds/<id>. Обрыв графиков означает проблему с машиной, ровные графики при недоступном сайте — проблему в приложении.