Этот урок - база. Разберем три кита: кольцевой буфер ядра и команду dmesg, каталог /var/log с его файлами, и демон rsyslog, который раскладывает сообщения по полочкам. И отдельно - как это все стыкуется с journald на современном Linux с systemd. После урока на вопрос "где логи Linux" ты будешь отвечать не "ну где-то в var", а точно знать, куда смотреть под конкретную задачу.
Кольцевой буфер ядра и команда dmesg
Сначала про ядро. Когда Linux грузится, само ядро еще до старта всех сервисов уже работает: находит процессоры, инициализирует драйверы, видит диски и сетевые карты. Все эти сообщения оно складывает в специальную область памяти - кольцевой буфер (kernel ring buffer). Кольцевой потому, что размер у него фиксированный (задается параметром log_buf_len, по умолчанию обычно сотни килобайт): когда буфер заполняется, новые записи затирают самые старые. Это не файл на диске, это кусок оперативки. Отсюда главное следствие: на нагруженном сервере, который сыпет сообщениями, dmesg может уже не содержать того, что было час назад.
Читается буфер командой dmesg (от "display message"). Запускай ее, когда речь про железо, драйверы, диски, сеть на низком уровне или загадочные убийства процессов нехваткой памяти (OOM). Это первое место, куда смотрит опытный админ при словах "сервер сам перезагрузился" или "диск отвалился".
Голый dmesg выводит время в секундах с момента загрузки ("[12345.67]") - читать неудобно. Поэтому почти всегда добавляют -T (человеческое время):
Код: Выделить всё
sudo dmesg -T | tail -20Кусок вывода и как его читать:
Код: Выделить всё
[Sun Jun 14 03:12:44 2026] EXT4-fs (sda1): mounted filesystem with ordered data mode
[Sun Jun 14 09:41:02 2026] usb 1-2: new high-speed USB device number 4 using xhci_hcd
[Sun Jun 14 11:07:55 2026] Out of memory: Killed process 2841 (mysqld) total-vm:4193280kB, anon-rss:3905120kBКогда сообщений много, фильтруй по уровню важности. Запрос dmesg error решается флагом -l (он же --level):
Код: Выделить всё
sudo dmesg -T --level=err,warn,critКод: Выделить всё
sudo dmesg -T --level=err+Код: Выделить всё
sudo dmesg -T -w
Каталог /var/log: где какие лог файлы Linux лежат
dmesg - это только ядро и только то, что сейчас в памяти. История и все остальное живут на диске, в каталоге /var/log. Это главный адрес, когда спрашивают, где логи Linux. Глянем, что там есть:
Код: Выделить всё
ls -lh /var/log- Кто входил, неудачные пароли, sudo, ssh - /var/log/auth.log (Debian, Ubuntu, Astra Linux) или /var/log/secure (RHEL, Fedora, RED OS).
- Общие системные события, сервисы - /var/log/syslog (Debian-семейство) или /var/log/messages (RHEL-семейство).
- Сообщения ядра на диске - /var/log/kern.log (Debian, Ubuntu). По сути та же информация, что в dmesg, но сохраненная и с историей за дни.
- Установка и обновление пакетов - /var/log/dpkg.log и /var/log/apt/ (Debian, Ubuntu) или /var/log/dnf.log, /var/log/dnf.rpm.log (Fedora, RHEL). Сюда смотрят, когда "после обновления все сломалось".
- Свои каталоги сервисов - /var/log/nginx/, /var/log/mysql/, /var/log/postgresql/ и так далее. Каждый крупный сервис обычно пишет к себе.
Код: Выделить всё
sudo grep "Failed password" /var/log/auth.log | tailКод: Выделить всё
Jun 14 22:17:03 web01 sshd[5120]: Failed password for invalid user admin from 203.0.113.7 port 51422 ssh2Код: Выделить всё
sudo grep "Failed password" /var/log/auth.log | grep -oE "from [0-9.]+" | sort | uniq -c | sort -rn | headrsyslog, journald и ротация: кто все это пишет
Возникает вопрос: а кто, собственно, раскладывает сообщения по этим файлам? Исторически этим занимается демон логирования rsyslog. Программы и ядро отдают ему сообщения, у каждого есть facility (категория: auth, kern, mail, cron) и priority (важность). rsyslog по своим правилам решает, в какой файл что положить. Правила лежат тут:
Код: Выделить всё
cat /etc/rsyslog.conf
ls /etc/rsyslog.d/А теперь важная актуализация на 2026. На современном Linux с systemd центральным сборщиком стал journald, а не rsyslog. journald собирает все в одном месте: сообщения ядра, ранний boot, stdout/stderr сервисов, syslog-сообщения - и хранит в структурированном бинарном журнале. rsyslog на таких системах работает уже не сборщиком, а читателем: он вычитывает сообщения из журнала и при желании дублирует их в привычные текстовые файлы. По умолчанию journald даже не форвардит в syslog (ForwardToSyslog=no), потому что rsyslog забирает данные сам. А целый ряд дистрибутивов (Amazon Linux 2023, минимальные образы Fedora/RHEL) идут вообще без rsyslog - и тогда /var/log/messages и /var/log/syslog просто нет, все живет только в journald. Это не поломка, это новая норма: не ищи файл, спрашивай journalctl.
Чтобы текстовые логи не съели весь диск, есть демон logrotate. Раз в сутки (по systemd-таймеру logrotate.timer) он переименовывает разросшиеся файлы (syslog становится syslog.1, потом syslog.2.gz и так сжимается), а самые старые удаляет. Поэтому ты часто видишь рядом auth.log, auth.log.1, auth.log.2.gz. Если ищешь старое событие - не забудь про архивы:
Код: Выделить всё
sudo zgrep "Failed password" /var/log/auth.log.2.gzСвязь dmesg и journalctl -k: одно ядро, два источника
И вот ключевая связь, которую обязательно нужно понять. dmesg и journalctl -k показывают одни и те же сообщения ядра. Флаг -k - это синоним --dmesg, он неявно включает фильтр текущей загрузки. Разница в том, что dmesg читает текущий буфер в оперативке (то, что не затерлось), а journalctl -k - сохраненный на диск журнал, в том числе за прошлые загрузки:
Код: Выделить всё
journalctl -k -b -1Код: Выделить всё
sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journaldAstra Linux логи и типичные грабли
Тема astra linux логи всплывает часто, потому что там своя специфика безопасности. Astra основана на Debian, поэтому база знакомая: /var/log/auth.log, /var/log/syslog, /var/log/kern.log на месте, dmesg и journalctl работают как обычно. Но добавляется подсистема мандатного контроля PARSEC со своим аудитом. Информация о входах и выходах пользователей пишется в журнал /var/log/parsec/user.mlog, а читается он не grep-ом, а специальной утилитой userlog (события там типа auth - вход и exit - выход). Есть и общий каталог журналов PARSEC. Вывод практический: для разбора "кто-когда-работал" на Astra одного auth.log может не хватить - смотри еще и userlog. В сертифицированных сборках аудит ядра (Linux Audit, auditd) обычно включен жестче, чем в обычном Debian, так что часть событий ищется через ausearch/aureport.
Теперь грабли, на которые новички наступают стабильно:
- Permission denied или Operation not permitted на dmesg - не баг, а защита kernel.dmesg_restrict=1. Решение простое: sudo dmesg.
- Логов нет, а вы уверены, что они должны быть - на чисто systemd-системах (Amazon Linux 2023, минимальный Fedora/RHEL) текстовых /var/log/syslog и /var/log/messages может не быть вообще: rsyslog не установлен, все ушло в journald. Не ищи файл - спрашивай journalctl.
- journalctl -b -1 ругается "Failed to find boot" - журнал не persistent. Нет каталога /var/log/journal - нет истории за прошлые загрузки. Включи persistent заранее, а не после аварии.
- "Кончилось место на диске" из ниоткуда - часто это раздутые логи. Проверь и текстовые (du -sh /var/log/*), и журнал (journalctl --disk-usage). Виновник нередко один разбухший файл сервиса с включенным debug либо распухший journald.
- Ищешь вчерашнюю ошибку, а ее нет - ее уже заротировали или затерли. В текстовых логах загляни в .log.1 и .gz через zgrep; в журнале добавь --since/--until.
- Путаешь dmesg и kern.log/journalctl -k - буфер ядра не бесконечный, старое затирается. Для истории за дни нужен файл на диске или persistent-журнал, а не голый dmesg.
Открой терминал и пройди по шагам, читая вывод, а не просто копируя:
- sudo dmesg -T | tail -30 - посмотри последние сообщения ядра. Найди строки про свои диски (sda, nvme) и сеть.
- sudo dmesg -T --level=err+ - есть ли ошибки и что серьезнее? Прочитай, о чем они.
- ls -lh /var/log и du -sh /var/log/* - оцени, какие файлы самые жирные. Затем journalctl --disk-usage - сколько ест журнал.
- sudo tail -20 /var/log/auth.log (или /var/log/secure) - найди свои входы и sudo. Если файла нет - sudo journalctl -u ssh --since today.
- journalctl --list-boots - сколько загрузок помнит система? Если только одна - persistent-журнал у тебя выключен.
- journalctl -k -b -1 - если система переживала перезагрузку и журнал persistent, глянь, что было до нее.
- Сравни: совпадают ли последние строки в sudo dmesg -T и в journalctl -k? Должны - это и есть та самая связь "одно ядро, два источника".
- Чем dmesg отличается от /var/log/kern.log и от journalctl -k, если все три про ядро?
- В какой файл смотреть, если кто-то подбирает пароль по ssh, и чем отличается путь на RHEL от Debian?
- Что делает --level=err+ в dmesg и чем он удобнее, чем перечислять уровни руками?
- Почему на свежей системе journalctl -b -1 может выдать ошибку и как это лечится заранее?
Ядро, железо, диски, OOM - это dmesg (с -T для времени, --level=err+ для ошибок, -w чтобы следить). История и все остальное - на диске: текстом в /var/log (auth.log/secure для входов, syslog/messages для общего, kern.log для ядра, dpkg/dnf для пакетов) и в бинарном журнале journald. Раскладывает текст rsyslog, чистит logrotate - поэтому помни про .gz-архивы и zgrep. А на современном Linux 2026 года главный сборщик уже journald: на части дистрибутивов текстовых файлов нет вовсе, все читается через journalctl, и именно persistent-журнал спасает при разборе внезапных ребутов. dmesg и journalctl -k - это одно и то же ядро, только из памяти и с диска. Знаешь, куда смотреть под задачу - и диагностика перестает быть гаданием.
