llmdocsсправочник разработчика

journald и логи

Материал из llmdocs — справочник разработчика
Портал: Linux и командная строка
journald и логи
Службаsystemd-journald (часть systemd)
Инструмент просмотраjournalctl
Хранениедвоичный журнал в /var/log/journal (постоянно) или /run/log/journal (до перезагрузки)
Источникиядро, stdout/stderr служб, syslog, sd_journal API
Уровни важности0 (emerg) — 7 (debug), по RFC 5424
Традиционные инструментыrsyslog, /var/log, logrotate

journald (служба systemd-journald) — компонент systemd, который собирает логи со всей системы: сообщения ядра, стандартный вывод и поток ошибок каждой службы, сообщения syslog. Записи хранятся в структурированном двоичном журнале с метаданными — время, служба, PID, пользователь, уровень важности, — по которым их можно быстро фильтровать. Просматривают журнал утилитой journalctl.[2]

Логи — первое, куда смотрят при любой проблеме на сервере: почему не запустилась служба, что случилось перед падением, кто подключался по SSH.

Как устроен журнал

Служба, запущенная systemd, может не заботиться о файлах логов: всё, что она пишет в stdout и stderr, автоматически попадает в журнал с пометкой, от какого юнита оно пришло. Каждая запись — набор полей: MESSAGE, PRIORITY, _SYSTEMD_UNIT, _PID, _UID, _HOSTNAME, _BOOT_ID и другие. Приложения могут добавлять собственные поля через API.

Журнал хранится в /var/log/journal/, если каталог существует (постоянное хранение), иначе — в /run/log/journal/, в памяти до перезагрузки. Размер ограничивается настройками в /etc/systemd/journald.conf, например SystemMaxUse=1G; старые записи удаляются автоматически.[3]

journalctl

journalctl -u nginx                     # логи одной службы
journalctl -u nginx -f                  # следить в реальном времени
journalctl -u nginx --since "1 hour ago"
journalctl -u nginx --since "2026-11-09 10:00" --until "2026-11-09 11:00"
journalctl -b                           # с момента текущей загрузки
journalctl -b -1 -p err                 # ошибки предыдущей загрузки (после сбоя)
journalctl -k                           # сообщения ядра (как dmesg)
journalctl -p warning                   # уровень warning и важнее
journalctl _PID=1234                    # по полю
journalctl -u myapp -o json-pretty -n 5 # последние 5 записей со всеми полями
journalctl -u myapp -o cat              # только текст сообщений
journalctl --disk-usage                 # сколько места занимает журнал
sudo journalctl --vacuum-time=14d       # удалить записи старше 14 дней

Фильтры комбинируются: journalctl -u nginx -u php-fpm -p err --since today.[1]

Уровни важности

Уровни унаследованы от протокола syslog (RFC 5424):[4]

Код Имя Значение
0 emerg система неработоспособна
1 alert нужно немедленное действие
2 crit критическое состояние
3 err ошибка
4 warning предупреждение
5 notice нормальное, но значимое событие
6 info информационное сообщение
7 debug отладка

Традиционные логи: /var/log

До systemd логи писал демон syslog (сегодня — обычно rsyslog) в текстовые файлы каталога /var/log (см. Файловая система Unix (FHS)). Многие системы используют оба механизма: journald принимает сообщения и передаёт их rsyslog, а тот раскладывает по файлам.

Файл Содержимое
/var/log/syslog или /var/log/messages общий системный журнал (Debian/Ubuntu и RHEL соответственно)
/var/log/auth.log или /var/log/secure входы, sudo, SSH
/var/log/nginx/, /var/log/postgresql/ логи отдельных приложений
/var/log/kern.log сообщения ядра

Текстовые файлы растут бесконечно, поэтому их ротирует утилита logrotate: по расписанию переименовывает текущий файл, сжимает старые и удаляет самые давние.[5] Работа с текстовыми логами — основная область grep, sed и awk и tail -f.

Логи в контейнерах

В Docker приложения тоже пишут в stdout и stderr, а драйвер логирования сохраняет вывод (docker logs -f container). Драйвер journald отправляет логи контейнеров прямо в журнал хоста. Для драйвера по умолчанию json-file важно задать ограничение размера (max-size, max-file), иначе логи заполнят диск. В Kubernetes логи читают через kubectl logs.

Централизованное логирование

Когда серверов и контейнеров много, логи собирают в одно место:

  • Сборщики — Vector, Fluent Bit, Promtail/Alloy, rsyslog — читают журнал и файлы и отправляют дальше.
  • Хранилища — Grafana Loki (индексирует только метки, дёшево),[6] Elasticsearch/OpenSearch (полнотекстовый поиск), ClickHouse.
  • Интерфейсы — Grafana, Kibana.

Связь логов с метриками и трассировками описывает статья Логирование и трассировка (OpenTelemetry).

Хорошие практики

  • Пишите структурированные логи (JSON или пары ключ-значение) с идентификатором запроса — их можно фильтровать и агрегировать.
  • Не логируйте секреты, пароли, токены и лишние персональные данные.
  • Используйте уровни осмысленно: error — то, что требует внимания, debug — выключен в продакшене.
  • Включите постоянное хранение журнала (mkdir -p /var/log/journal), чтобы логи переживали перезагрузку и можно было разобрать причину сбоя.
  • Ограничьте размер логов и следите за свободным местом на диске.

См. также

Источники

  1. journalctl — manual
  2. systemd-journald.service — manual
  3. journald.conf — manual
  4. RFC 5424 — The Syslog Protocol
  5. logrotate — GitHub
  6. Grafana Loki — документация
Категории: