Одна из частых ошибок в мониторинге - считать сервис рабочим только потому, что его процесс запущен.
systemctl status myapp
показывает active (running), PID есть, порт вроде слушается - значит все хорошо? Не всегда.
Процесс может быть живым, но сам сервис уже фактически не работает:
завис на подключении к базе;
потерял доступ к Redis или очереди;
перестал обрабатывать запросы;
отвечает только частью функционала;
уперся в пул соединений;
ловит deadlock внутри приложения;
слушает порт, но возвращает 500.
Поэтому нормальная проверка должна отвечать не на вопрос: "процесс существует?" А на вопрос: "сервис реально выполняет свою задачу?"
▪️ Самый простой пример - HTTP health check:
curl -fsS http://127.0.0.1:8080/health
Если endpoint возвращает 200 OK, уже лучше, чем просто проверять PID. Но и здесь есть нюанс.
Плохой health check: /health -> 200 OK просто потому что приложение запустилось.
▪️ Хороший health check проверяет зависимости:
доступна ли база;
работает ли очередь;
можно ли читать конфиг;
не закончились ли critical ресурсы;
готов ли сервис принимать трафик;
В кубере это разделяют на разные проверки:
liveness - процесс жив или его надо перезапустить;
readiness - можно ли отправлять на него трафик;
startup - успел ли сервис нормально подняться.
Эту же логику полезно применять и без k8s. Например:
curl -fsS http://127.0.0.1:8080/ready
/ready может возвращать ошибку, если приложение живо, но база недоступна. В таком состоянии сервис лучше не убивать, но и трафик на него отправлять не надо.
▪️ Для обычного linux-сервера можно использовать health check в связке с systemd, HAProxy, Nginx, keepalived или внешним мониторингом. Пример проверки в скрипте:
#!/usr/bin/env bash
if curl -fsS http://127.0.0.1:8080/health >/dev/null; then
echo "OK"
exit 0
else
echo "FAIL"
exit 1
fi
Такой скрипт уже можно подключать к мониторингу или балансировщику.
#linux #monitoring
🧑💻 NetworkAdmin