Какой стандартный инструмент логирования используется в Linux?

Стандартный инструмент логирования в Linux: демон systemd-journald

В современных дистрибутивах Linux (начиная с systemd-эпохи) стандартным и системным инструментом логирования является системный журнал (systemd journal), управляемый демоном systemd-journald. Он заменил классический syslogd в большинстве дистрибутивов (RHEL/CentOS 7+, Ubuntu 16.04+, Debian 8+ и т.д.) и является неотъемлемой частью системы инициализации systemd.

Ключевые особенности и принципы работы

systemd-journald выполняет сбор логов из множества источников:

• Сообщения ядра (kmsg)
• Логи служб systemd (stdout/stderr демонов)
• Сообщения классического syslog (если syslog-демон также установлен)
• Аппаратные логи (через udev)
• Сообщения из пользовательских сессий

Основные технические отличия от традиционного syslog:

• Бинарный формат хранения. Логи хранятся в бинарных файлах (обычно в /run/log/journal/ для volatile-логов и /var/log/journal/ для персистентных). Это позволяет хранить дополнительные метаданные (поля) для каждого события.
• Структурированность. Каждая запись журнала содержит набор строго типизированных полей (_SYSTEMD_UNIT=, _PID=, _UID=, _HOSTNAME=, _COMM=, пользовательские поля и т.д.), что делает фильтрацию и анализ эффективными.
• Интеграция с systemd. Прямая привязка логов к юнитам systemd (_SYSTEMD_UNIT) и cgroups.
• Централизованное управление. Конфигурация осуществляется через файлы /etc/systemd/journald.conf и директорию /etc/systemd/journald.conf.d/.

Основные команды для работы с журналом

Работа с журналом ведется через утилиту journalctl. Вот несколько наиболее частых примеров:

# Просмотр всех логов в режиме реального времени (аналог tail -f)
journalctl -f

# Просмотр логов конкретного сервиса (юнита systemd)
journalctl -u nginx.service

# Просмотр логов с определенной временной метки
journalctl --since "2024-01-15 09:00:00" --until "2024-01-15 10:00:00"

# Просмотр логов ядра
journalctl -k

# Просмотр логов с детальными метаданными (все поля)
journalctl -o verbose

# Фильтрация по полю (например, по идентификатору процесса)
journalctl _PID=1234

# Постраничный просмотр с поиском (аналогично less)
journalctl

# Экспорт логов в классический текстовый формат (например, для внешних SIEM)
journalctl --output=short > /tmp/system.log

Конфигурация журнала

Основной файл конфигурации — /etc/systemd/journald.conf. Важные параметры для DevOps:

[Journal]
# Хранение логов: "volatile" (только в памяти), "persistent" (на диск), "auto"
Storage=persistent
# Максимальный размер журнала на диске
SystemMaxUse=10G
# Максимальное время хранения логов
MaxRetentionSec=1month
# Сжатие старых логов
Compress=yes
# Скорость записи логов (лимитирование для защиты от flood)
RateLimitIntervalSec=30s
RateLimitBurst=10000

Совместная работа с классическим syslog

Несмотря на статус стандартного инструмента, systemd-journald часто работает в паре с rsyslog или syslog-ng. Это делается для:

1. Совместимости со старыми приложениями, пишущими напрямую в /dev/log.
2. Требований compliance (например, хранение логов в простом текстовом формате /var/log/messages).
3. Централизованного сбора логов с множества серверов.

В такой схеме journald выступает как первичный сборщик, который затем перенаправляет сообщения в традиционный syslog-демон (например, rsyslog), если это настроено (ForwardToSyslog=yes в конфигурации).

Преимущества с точки зрения DevOps

• Централизованность: единая команда journalctl для просмотра логов ядра, служб и приложений.
• Мощная фильтрация: возможность фильтровать логи по любому системному полю без использования grep.
• Цепочка корней доверия: логи могут быть криптографически подписаны для обеспечения целостности и обнаружения несанкционированных изменений.
• Автоматическая ротация и сжатие: не требует внешних утилит вроде logrotate (хотя их тоже можно использовать).

Таким образом, отвечая на вопрос: стандартным системным инструментом является systemd-journald, но в производственных средах он часто интегрирован в более широкую экосистему логирования, включающую как классические syslog-демоны, так и облачные решения (Loki, ELK Stack).