> Полный список статей есть в [llms.txt](https://docs.f3cloud.com/llms.txt). Markdown-версия есть у каждой страницы, достаточно добавить .md к её адресу. Эта страница в Markdown: [https://docs.f3cloud.com/ru/linux/linux-logs.md](https://docs.f3cloud.com/ru/linux/linux-logs.md). # Логи в Linux – journalctl, /var/log и где искать ошибки на сервере Логи в Linux. Где хранятся логи на сервере с Debian и Ubuntu, как читать журнал systemd командой journalctl, искать ошибки и попытки взлома по SSH, смотреть логи Nginx и освобождать место, которое занимают логи. Проверено на Debian 12. Когда сайт перестаёт открываться, служба не запускается или сервер ведёт себя странно, первым делом нужно заглянуть в логи. Почти всё, что происходит на сервере, где-то записывается. Сложность в том, чтобы знать, где именно искать и как быстро найти нужное среди тысяч строк. В этой статье разберём, где на современном 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` выводит весь журнал с самых старых записей, а это обычно слишком много. Ниже команды, которые пригодятся чаще всего. ```bash # Последние 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` только те, что появились после последней загрузки. ```bash journalctl -p err -b ```
Вывод journalctl -p err -b с ошибками службы SSH

Только ошибки с момента загрузки сервера

Если не работает конкретная служба, начните с её статуса и последних строк её лога. Как это делать, подробно рассказано в статье про [службы systemd](https://docs.f3cloud.com/ru/linux/systemd-services.md). ```bash systemctl status nginx journalctl -u nginx -n 50 ``` *** ## 3. Проверьте, кто пытается войти по SSH Любой сервер с открытым портом SSH постоянно атакуют программы, которые перебирают пароли. Это видно в журнале службы `ssh`. ```bash journalctl -u ssh --since "1 hour ago" | grep -E "Failed password|Invalid user" ```
Строки журнала SSH с неудачными попытками входа под root и несуществующими пользователями, IP-адреса скрыты

Перебор паролей к root и к несуществующим пользователям, адреса скрыты

На нашем тестовом сервере за одни сутки в журнале набралось 2510 таких строк. Это обычный фон интернета, а не атака именно на вас, но он хорошо показывает, почему вход по паролю лучше заменить на SSH-ключ, а перебор блокировать. Как это сделать, рассказано в статьях про [SSH-ключи](https://docs.f3cloud.com/ru/vps/security/ssh-klyuchi.md) и [fail2ban](https://docs.f3cloud.com/ru/vps/security/fail2ban.md). Список неудачных входов в более коротком виде показывает команда `lastb`, а успешных команда `last`. ```bash lastb -n 10 last -n 10 ``` *** ## 4. Смотрите логи Nginx и других программ Программы, которые ведут собственные логи, обычно пишут их в отдельную папку внутри `/var/log`. У Nginx это два файла. * **access.log** содержит по строке на каждый запрос к сайту, с IP-адресом посетителя, адресом страницы и кодом ответа. * **error.log** содержит ошибки, например отказ в доступе к файлу или недоступный бэкенд. ```bash # Последние строки и слежение в реальном времени 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. Освободите место, которое занимают логи Посмотреть, сколько места занимает журнал и папки с логами, можно двумя командами. ```bash journalctl --disk-usage du -sh /var/log/* | sort -h | tail ```
Размер журнала systemd и самые большие папки в /var/log

Журнал занимает 24 МБ, это основная часть /var/log

Если журнал разросся, его можно сократить до нужного размера или удалить записи старше определённого срока. Удаляются только старые архивные части, текущие записи остаются. ```bash # Оставить журнал размером не больше 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://t.me/f3cloud_news)\ **Официальный сайт:** [https://f3cloud.com](https://f3cloud.com/ru)