Log reading basics
Логи полезны только тогда, когда их читают системно.
Главная ошибка — открыть огромный файл и искать “что-то странное”. Лучше сначала сузить область: сервис, время, ошибка, request path или порт.
Смотреть последние строки файла
sudo tail -n 100 /var/log/nginx/error.log
Следить в реальном времени:
sudo tail -f /var/log/nginx/error.log
Смотреть journal systemd-сервиса
sudo journalctl -u nginx --no-pager -n 100
За последний час:
sudo journalctl -u nginx --since "1 hour ago" --no-pager
В реальном времени:
sudo journalctl -u nginx -f
Фильтровать ошибки
sudo journalctl -u nginx --since "1 hour ago" --no-pager \
| grep -Ei 'error|failed|denied|timeout|refused|permission'
Для файла:
sudo grep -Ei 'error|failed|denied|timeout|refused|permission' /var/log/nginx/error.log | tail -n 80
Смотреть access log
Если access log включён:
sudo tail -n 100 /var/log/nginx/access.log
Искать конкретный статус:
sudo awk '$9 ~ /^4|^5/ {print}' /var/log/nginx/access.log | tail -n 80
Найти 404
sudo awk '$9 == 404 {print}' /var/log/nginx/access.log | tail -n 50
Найти 500+
sudo awk '$9 >= 500 {print}' /var/log/nginx/access.log | tail -n 50
Сузить по времени
Для journal:
sudo journalctl -u nginx --since "2026-05-19 10:00" --until "2026-05-19 11:00" --no-pager
Для обычных файлов проще использовать grep по дате, если формат лога содержит timestamp.
Что искать в первую очередь
| Признак | Возможная причина |
|---|---|
permission denied | права на файл, директорию, socket |
bind() failed | порт занят или нет прав |
connect() failed | upstream недоступен |
no such file | неверный путь, не задеплоен файл |
timeout | upstream, сеть, долгий ответ |
certificate | TLS или путь к сертификату |
rewrite or internal redirection cycle | ошибка rewrite/try_files |
Логи и HTTP-проверки вместе
Логи лучше читать рядом с curl.
В одном окне:
sudo journalctl -u nginx -f
В другом:
curl -kI https://getsrv.app/no-such-page
curl -kI https://getsrv.app/ru/docs/
Так проще увидеть, какой запрос порождает ошибку.
Не все ошибки одинаково важны
Разовые 404 на мусорные пути — нормально.
Опаснее:
- много 500;
- повторяющиеся permission denied;
- сервис постоянно рестартует;
- один и тот же endpoint стабильно падает;
- после деплоя резко появились одинаковые ошибки.
Минимальный набор
sudo systemctl status nginx --no-pager
sudo journalctl -u nginx --since "30 minutes ago" --no-pager
sudo tail -n 100 /var/log/nginx/error.log
curl -kI https://getsrv.app/
curl -kI https://getsrv.app/no-such-page
Правило
Сначала фиксируйте:
- что именно сломалось;
- когда началось;
- какой сервис отвечает;
- какой HTTP-код виден;
- какая ошибка есть в логах.
После этого исправление обычно становится очевиднее.