Когда сайт перестаёт открываться, служба не запускается или сервер ведёт себя странно, первым делом нужно заглянуть в логи. Почти всё, что происходит на сервере, где-то записывается. Сложность в том, чтобы знать, где именно искать и как быстро найти нужное среди тысяч строк. В этой статье разберём, где на современном Linux хранятся логи, научимся пользоваться командой journalctl, найдём ошибки и попытки подбора пароля к SSH, посмотрим логи Nginx и разберёмся, как не дать логам занять весь диск. Все примеры сделаны на тестовом сервере с Debian 12.
Где Linux хранит логи
Долгое время логи в Linux были обычными текстовыми файлами в каталоге /var/log. Их записывала служба syslog. Сообщения о входах на сервер попадали в файл auth.log, общие системные сообщения в syslog, а каждая программа могла вести и собственные файлы. Такой подход прост и понятен, но у него есть недостатки. Чтобы найти, что происходило с конкретной службой в определённый час, приходилось искать по нескольким файлам, а формат строк у разных программ различался.
В системах с systemd появился единый журнал. Его ведёт служба systemd-journald. Она собирает сообщения ядра, системных служб и всё, что программы, запущенные как службы, выводят в консоль. Каждая запись хранится вместе со сведениями о том, какая служба её создала, с каким приоритетом и в какой момент загрузки сервера. Благодаря этому журнал можно отфильтровать по службе, времени или уровню важности одной командой, не перебирая файлы. Хранится журнал в двоичном виде в каталоге /var/log/journal, поэтому читают его не текстовым редактором, а командой journalctl.
На наших серверах с Debian 12 классической службы syslog нет, и журнал остаётся единственным местом для системных логов. Поэтому привычных файлов /var/log/syslog и /var/log/auth.log вы там не найдёте, о чём предупреждает файл /var/log/README. При этом многие программы по-прежнему пишут собственные текстовые логи в /var/log. Например, Nginx ведёт файлы access.log и error.log в папке /var/log/nginx. Получается, что на сервере есть два вида логов, и для каждого нужен свой способ чтения.
1. Читайте журнал командой journalctl
Без параметров journalctl выводит весь журнал с самых старых записей, а это обычно слишком много. Ниже команды, которые пригодятся чаще всего.
# Последние 50 строк всего журнала
journalctl -n 50
# Следить за новыми записями в реальном времени, выход по Ctrl+C
journalctl -f
# Записи конкретной службы
journalctl -u nginx
# Записи за последний час или за определённый промежуток
journalctl --since "1 hour ago"
journalctl --since "2026-10-21 10:00" --until "2026-10-21 10:30"
# Только с текущей загрузки сервера
journalctl -bПараметры можно сочетать. Например, journalctl -u ssh --since today покажет все записи службы SSH за сегодняшний день. Если вывод не помещается на экран, journalctl открывает его в программе просмотра. Листать можно стрелками, искать текст клавишей /, а выйти клавишей q.
2. Найдите ошибки
У каждой записи журнала есть приоритет. Параметр -p err оставляет только ошибки и более серьёзные сообщения, а вместе с -b только те, что появились после последней загрузки.
journalctl -p err -b
Только ошибки с момента загрузки сервера
Если не работает конкретная служба, начните с её статуса и последних строк её лога. Как это делать, подробно рассказано в статье про службы systemd.
systemctl status nginx
journalctl -u nginx -n 503. Проверьте, кто пытается войти по SSH
Любой сервер с открытым портом SSH постоянно атакуют программы, которые перебирают пароли. Это видно в журнале службы ssh.
journalctl -u ssh --since "1 hour ago" | grep -E "Failed password|Invalid user"
Перебор паролей к root и к несуществующим пользователям, адреса скрыты
На нашем тестовом сервере за одни сутки в журнале набралось 2510 таких строк. Это обычный фон интернета, а не атака именно на вас, но он хорошо показывает, почему вход по паролю лучше заменить на SSH-ключ, а перебор блокировать. Как это сделать, рассказано в статьях про SSH-ключи и fail2ban.
Список неудачных входов в более коротком виде показывает команда lastb, а успешных команда last.
lastb -n 10
last -n 104. Смотрите логи Nginx и других программ
Программы, которые ведут собственные логи, обычно пишут их в отдельную папку внутри /var/log. У Nginx это два файла.
- access.log содержит по строке на каждый запрос к сайту, с IP-адресом посетителя, адресом страницы и кодом ответа.
- error.log содержит ошибки, например отказ в доступе к файлу или недоступный бэкенд.
# Последние строки и слежение в реальном времени
tail -n 50 /var/log/nginx/error.log
tail -f /var/log/nginx/access.log
# Найти в логе запросы, на которые сайт ответил ошибкой 502
grep '" 502 ' /var/log/nginx/access.logТекстовые логи не растут бесконечно. Их каждый день переименовывает и сжимает программа logrotate. Для Nginx на тестовом сервере она настроена хранить логи за 14 дней, а старые части складывает рядом в файлы вида access.log.1 и сжатые access.log.2.gz. Читать сжатые файлы можно командами zcat и zgrep.
5. Освободите место, которое занимают логи
Посмотреть, сколько места занимает журнал и папки с логами, можно двумя командами.
journalctl --disk-usage
du -sh /var/log/* | sort -h | tail
Журнал занимает 24 МБ, это основная часть /var/log
Если журнал разросся, его можно сократить до нужного размера или удалить записи старше определённого срока. Удаляются только старые архивные части, текущие записи остаются.
# Оставить журнал размером не больше 500 МБ
journalctl --vacuum-size=500M
# Удалить записи старше двух недель
journalctl --vacuum-time=2weeksЧтобы журнал больше не разрастался, задайте предел в файле /etc/systemd/journald.conf, например строкой SystemMaxUse=500M, и перезапустите службу командой systemctl restart systemd-journald.
Не удаляйте логи командой rm
Если программа держит файл лога открытым, после rm она продолжит писать в уже удалённый файл, и место на диске не освободится. Чтобы очистить большой текстовый лог, обнулите его командой truncate -s 0 /var/log/nginx/access.log.
Частые вопросы
No such file or directory: /var/log/syslog
На сервере нет службы syslog, и системные сообщения хранятся только в журнале. Читайте их командой journalctl. Если вам нужны именно текстовые файлы, установите rsyslog командой apt install -y rsyslog, он будет вести классические файлы логов рядом с журналом.
journalctl показывает не все записи
Обычный пользователь видит только свои записи. Запускайте journalctl от имени root или через sudo, либо добавьте пользователя в группу adm.
В логе время отличается от моего
Логи пишутся по часовому поясу сервера. На наших серверах это Europe/Berlin. Проверить пояс можно командой timedatectl, а смотреть записи по UTC позволяет параметр journalctl --utc.
Наши ресурсы
Telegram-канал: https://t.me/f3cloud_news
Официальный сайт: https://f3cloud.com