Как мониторить HTTP сервис и проверить его доступность и ответ из терминала?

Что проверяют

Умеете ли вы быстро понять, жив ли сервис и что именно он отвечает, без браузера и дашбордов. Следом обычно спрашивают, как превратить разовую проверку в регулярную и чем проверка HTTP отличается от проверки хоста.

Как отвечать

Основной инструмент curl, и сильный ответ сразу показывает рабочую команду:

curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' --max-time 5 https://api.example.com/health

• -w: выводит код ответа и тайминги. Кроме time_total полезны time_namelookup, time_connect, time_appconnect (TLS) и time_starttransfer, по ним видно, где тормозит: DNS, соединение или само приложение;
• -f: без флага curl завершается с кодом 0 даже на ответ 500, с ним на кодах от 400 выходит с ошибкой 22, и на это можно опираться в скриптах;
• -L, -v, --resolve: следовать редиректам, увидеть заголовки и TLS-рукопожатие, отправить запрос на конкретный бэкенд в обход DNS;
• тело ответа: curl -s .../health | jq .status проверяет не только код, но и содержимое.

Для повторения хватит watch -n 5 '<команда>' или цикла while true; do ...; sleep 5; done. Открытый порт без HTTP проверяется через nc -zv host 443.

На Python то же пишется через httpx или requests с явным timeout: проверка кода, времени ответа и поля в JSON, а для многих адресов асинхронный httpx.AsyncClient. Для постоянного мониторинга назовите готовые решения: Prometheus с blackbox_exporter и алертами или Uptime Kuma.

Где спотыкаются

Проверяют доступность через ping. ICMP говорит только о том, что хост отвечает, часто закрыт файрволом, а упавшее приложение на живом сервере он не заметит.

Не ставят таймаут. requests без timeout может ждать ответа бесконечно, и скрипт мониторинга зависает вместе с сервисом.

Используют curl -I и считают успехом любой выход без ошибки. -I шлёт HEAD, на который часть сервисов отвечает иначе, чем на GET, а без -f скрипт не отличит 200 от 503.