Сповіщення про недоступність сайту

Графіки в панелі показують стан машини, але не відповідають на питання «чи працює сайт?». Застосунок може зависнути, поки процесор простоює, і без зовнішньої перевірки ви дізнаєтеся про це від своїх клієнтів.

Зовнішні перевірки

Головне правило: не перевіряйте з тієї самої машини, яку моніторите. Скористайтеся будь-яким зовнішнім сервісом моніторингу доступності — їх багато, зокрема з безкоштовними тарифами на кілька адрес з інтервалом в одну хвилину. Налаштування, які справді важливі:

• Адреса перевірки. Не головна сторінка, а окремий маршрут на кшталт /healthz, який перевіряє і базу даних, і чергу. Інакше закешована головна сторінка віддаватиметься навіть тоді, коли бекенд мертвий.
• Очікувана відповідь. Код 200 плюс підрядок у тілі. Багато застосунків повертають 200 із повідомленням про помилку, коли ламаються.
• Поріг. Дві-три невдалі спроби поспіль, інакше будь-який збій мережі вас розбудить.
• Канал. Telegram або email. Переконайтеся, що сповіщення справді надходить: вимкніть сервіс на хвилину й зачекайте на повідомлення.

Не забудьте окрему перевірку терміну дії сертифіката — прострочений TLS-сертифікат виглядає як збій і трапляється регулярно.

Watchdog на самій машині

Зовнішній моніторинг повідомить вам, що сайт недоступний. Щоб він піднявся сам, налаштуйте 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 disk usage is over 85%"

Досконаліший варіант із готовими порогами пропонує Netdata.

Типові помилки

• Моніторинг на тій самій машині. Якщо машина впаде, загинуть і watchdog, і сповіщення.
• Занадто чутливий поріг. Потік хибних тривог означає, що ви пропустите справжню.
• Restart=always замість з'ясування причини. Перезапуск маскує витік пам'яті: сервіс падає щопівгодини, а ви цього не бачите. Перевірте systemctl show myapp -p NRestarts і journal.
• Перевірка лише через ping. Машина відповідає на ICMP навіть із цілком мертвим вебсервером.

Перше, що варто перевірити, коли спрацьовує сповіщення, — «Overview» у панелі /hosting/vds/m/<id>. Розрив на графіках означає проблему з машиною; рівні графіки, коли сайт недоступний, означають проблему в застосунку.