В этой статье на примере Ubuntu/Debian разберём:
- как смотреть логи systemd-сервисов через
journalctl; - как читать файлы логов в реальном времени через
tail -f; - как быстро фильтровать ошибки и нужные строки с помощью
grep; - что делать, если «логов нет» или они пустые.
Шаг 1. Быстрая диагностика сервиса через systemctl
Если проблема связана с сервисом (nginx, apache2, postgresql, php-fpm), начинаем со статуса:
sudo systemctl status nginx
Если нужно проверить другой сервис — просто меняем имя:
sudo systemctl status apache2
sudo systemctl status postgresql
sudo systemctl status php8.2-fpm
Подсказка: если сервис «упал», ниже в статусе почти всегда есть 2–10 строк с причиной. Но детали всё равно лежат в журнале.
Шаг 2. journalctl: логи сервисов systemd
journalctl — это журнал systemd. Он показывает логи сервисов, ядра и системных сообщений.
Логи конкретного сервиса
sudo journalctl -u nginx
Последние 100 строк (быстро)
sudo journalctl -u nginx -n 100 --no-pager
Логи «в реальном времени» (как tail -f)
sudo journalctl -u nginx -f
Логи за сегодня
sudo journalctl -u nginx --since today
Логи за последние 30 минут
sudo journalctl -u nginx --since "30 min ago"
Важно: выйти из режима просмотра/следования — клавиша q (или Ctrl+C, если включён -f).
Шаг 3. tail -f: логи файлов (nginx, apache, приложения)
Не все логи идут в systemd-journal. Веб-серверы и приложения чаще пишут в файлы в /var/log.
Nginx
sudo tail -f /var/log/nginx/error.log
sudo tail -f /var/log/nginx/access.log
Apache
sudo tail -f /var/log/apache2/error.log
sudo tail -f /var/log/apache2/access.log
PostgreSQL (часто логируется в /var/log/postgresql)
sudo ls -la /var/log/postgresql
sudo tail -f /var/log/postgresql/postgresql-*.log
Если файла нет: значит сервис логирует в другое место или через journal. Начните с systemctl status и journalctl -u.
Шаг 4. grep: быстро найти ошибки и нужные строки
grep помогает быстро отфильтровать важное: ошибки, конкретный URL, IP, слово «failed».
Найти ошибки в nginx error.log
sudo grep -i "error" /var/log/nginx/error.log | tail -n 50
Найти 500-ответы в access.log (пример)
sudo grep " 500 " /var/log/nginx/access.log | tail -n 50
Найти запросы от конкретного IP
sudo grep "203.0.113.10" /var/log/nginx/access.log | tail -n 50
Фильтрация journalctl через grep
sudo journalctl -u nginx --since today --no-pager | grep -i "fail" | tail -n 50
Совет: если лог огромный, не пытайтесь читать его целиком. Обычно хватает последней сотни строк + фильтрации по ключевым словам.
Если «ничего не видно»: типичные причины
-
Сервис пишет не туда — используйте
journalctl -u SERVICEили проверьте конфиги логирования. -
Нет прав — почти все логи требуют
sudo. -
Лог пустой — возможно, ошибка не воспроизводится. Запустите проблемное действие и смотрите лог в режиме
-f. -
Логи ротируются — старые файлы могут быть с суффиксом
.1,.2.gz. Для просмотра сжатых логов используйтеzcatилиzgrep.
Итоги
systemctl status— быстрый взгляд на проблему сервиса.journalctl -u SERVICE— логи systemd-сервисов, включая режим «в реальном времени».tail -f— просмотр файловых логов (nginx/apache/приложения).grep— фильтрация ошибок, IP, статусов и ключевых слов.
Вывод: умение быстро открыть нужный лог и найти в нём причину ошибки — один из самых полезных навыков для работы с VPS. Чаще всего проблема решается не «магическими настройками», а двумя строками из error.log.