Системное логирование в Linux 2026: от journald и rsyslog до дашбордов в Grafana

Надежная система логирования - это основа мониторинга, безопасности и отладки любой Linux-инфраструктуры. В 2026 году стандартом де-факто стал гибридный подход, использующий systemd-journald для локального сбора структурированных данных и rsyslog для их централизованной пересылки, фильтрации и долгосрочного хранения. Это руководство предоставляет готовые к применению конфигурации, которые позволят вам быстро развернуть полный конвейер: от сбора логов на отдельных серверах до их визуализации в Grafana через Elasticsearch. Мы разберем архитектурные решения, сравним технологии и дадим конкретные инструкции по настройке и отладке.

Архитектура логирования в 2026: syslog против systemd-journald

В современных дистрибутивах Linux (Ubuntu 22.04+, RHEL/CentOS 9+) сосуществуют две основные подсистемы логирования. Они не исключают, а дополняют друг друга, решая разные задачи. Понимание их различий - ключ к построению эффективной архитектуры.

Systemd-journald: структурированные логи и быстрый поиск

Демон systemd-journald, входящий в состав systemd, собирает логи ядра, раннего запуска системы, служб и приложений в бинарные файлы, расположенные в /var/log/journal/. Основное преимущество - структурированность. Каждое сообщение снабжается метаданными: _PID (идентификатор процесса), _COMM (имя команды), _EXE (путь к исполняемому файлу), _SYSTEMD_UNIT (имя юнита systemd) и другими.

Для работы с журналом используется утилита journalctl. Ее ключевые параметры:

• journalctl --since "2026-06-01 00:00:00" --until "2026-06-02 12:00:00" - фильтр по времени.
• journalctl -f - слежение за логами в реальном времени (аналог tail -f).
• journalctl -u nginx.service - логи конкретной службы.
• journalctl -p err - вывод сообщений уровня ошибки и выше (по severity).

По умолчанию journald хранит логи только в оперативной памяти (volatile storage). Для персистентного хранения необходимо раскомментировать или добавить строку Storage=persistent в файле /etc/systemd/journald.conf. Управление размером журнала осуществляется параметрами SystemMaxUse= (максимальный объем на диске) и SystemKeepFree= (свободное место для сохранения).

Классический syslog (rsyslog): надежность, маршрутизация и legacy-совместимость

В то время как journald отлично справляется с локальным сбором, rsyslog остается промышленным стандартом для пересылки, фильтрации и долгосрочного хранения логов, особенно в гетерогенных средах. Его модель основана на понятиях facility (источник события: kern, mail, auth и т.д.) и severity (уровень критичности: от debug до emerg).

Rsyslog - это модульный демон с высокой надежностью. Он поддерживает протоколы TCP, UDP, RELP (Reliable Event Logging Protocol) для гарантированной доставки, предлагает мощный язык фильтрации RainerScript и может интегрироваться с множеством внешних систем, включая базы данных и очереди сообщений. Его главная роль в связке с journald - выступать в качестве надежного транспортного агента и маршрутизатора для централизованного сбора.

Сводная таблица: что выбрать для вашей задачи?

Рекомендации: Используйте journald для локального сбора и оперативного поиска на каждом сервере. Для централизованного сбора логов со всей инфраструктуры, их фильтрации и отправки в системы хранения (например, Elasticsearch) настройте rsyslog. В смешанных средах настройте пересылку логов из journald в rsyslog.

Настройка централизованного сбора логов с помощью rsyslog

Развернем сервер-коллектор, который будет принимать логи от всех клиентов в инфраструктуре.

Установка и базовая конфигурация rsyslog-сервера

Установите rsyslog на сервере, который будет выступать коллектором. Для систем на базе Debian/Ubuntu и RHEL/CentOS команды различаются:

# Для Debian/Ubuntu
sudo apt update && sudo apt install -y rsyslog

# Для RHEL/CentOS/Rocky Linux
sudo dnf install -y rsyslog

Основной файл конфигурации - /etc/rsyslog.conf. Для активации приема логов по сети раскомментируйте или добавьте следующие строки в секцию модулей:

# Позволяет принимать логи по UDP (порт 514)
module(load="imudp")
input(type="imudp" port="514")

# Позволяет принимать логи по TCP (порт 514) - рекомендуется для надежности
module(load="imtcp")
input(type="imtcp" port="514")

Для организации хранения логов с разных хостов в отдельные директории создайте правило в конце файла /etc/rsyslog.conf или в отдельном файле в /etc/rsyslog.d/ (например, remote-logs.conf):

# Шаблон для формирования пути к файлу на основе имени хоста-отправителя
template(name="RemoteLogs" type="string" string="/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log")

# Правило: все входящие сообщения сохранять по шаблону
:fromhost-ip, !isequal, "127.0.0.1" ?RemoteLogs
& stop

Создайте директорию для хранения и перезапустите службу:

sudo mkdir -p /var/log/remote
sudo systemctl restart rsyslog
sudo systemctl enable rsyslog

Проверьте, что rsyslog слушает нужные порты: sudo netstat -tulpn | grep 514.

Настройка клиентов для пересылки логов на сервер

На клиентских серверах необходимо настроить отправку локальных логов на сервер-коллектор. Есть два основных метода.

Метод 1: Прямая настройка rsyslog на клиенте. Добавьте в конец файла /etc/rsyslog.conf строку (замените 192.168.1.100 на IP вашего сервера-коллектора):

*.* @@192.168.1.100:514  # Отправка по TCP (два символа @)
# или
*.* @192.168.1.100:514   # Отправка по UDP (один символ @)

Метод 2: Пересылка логов из journald через rsyslog. На системах, где journald является основным источником, настройте связку. Убедитесь, что в /etc/rsyslog.conf загружен модуль imjournal:

module(load="imjournal") # предоставляет доступ к журналу systemd

Затем добавьте правило для пересылки всех сообщений из journald на удаленный сервер:

*.* @@192.168.1.100:514

После изменения конфигурации на клиенте перезапустите службу: sudo systemctl restart rsyslog.

Для проверки отправьте тестовое сообщение с клиента: logger "Test message from client host". Через несколько секунд проверьте на сервере-коллекторе в директории /var/log/remote/<client_hostname>/ появление нового файла с этим сообщением.

Фильтрация и маршрутизация логов: работа с facility и severity

Мощь rsyslog раскрывается в возможности тонкой фильтрации и маршрутизации логов на основе их источника (facility) и важности (severity). Это позволяет снизить информационный шум и направлять критичные события в отдельные каналы для оперативного реагирования.

Правила фильтрации на основе severity (уровня критичности)

Уровни severity в syslog (от наименее к наиболее критичным): debug, info, notice, warning, err, crit, alert, emerg. В RainerScript для фильтрации по severity используется свойство $syslogseverity или $syslogseverity-text.

Пример правила, которое записывает все сообщения уровня error и критичнее в отдельный файл, игнорируя при этом debug-сообщения:

# В файле /etc/rsyslog.d/01-severity-filter.conf
# Запись ошибок и критических событий в отдельный файл
if $syslogseverity <= 3 then {  # 3 соответствует уровню 'error'
    action(type="omfile" file="/var/log/critical_errors.log")
}

# Игнорирование всех debug-сообщений (severity=7)
if $syslogseverity == 7 then {
    stop
}

Это правило можно адаптировать для отправки критичных логов не только в файл, но и, например, на email администратора или в отдельный индекс Elasticsearch для приоритетного мониторинга.

Маршрутизация по facility (источнику событий)

Facility определяет подсистему, сгенерировавшую сообщение. Например: auth/authpriv (аутентификация), cron (планировщик задач), mail (почта), kern (ядро).

Пример разделения логов по источникам:

# Логи аутентификации (включая неудачные попытки входа) в отдельный файл для аудита
if $syslogfacility-text == 'authpriv' then {
    action(type="omfile" file="/var/log/secure/audit.log")
}

# Логи cron-задач в свой файл
if $syslogfacility-text == 'cron' then {
    action(type="omfile" file="/var/log/cron.log")
}

# Логи ядра (kernel) направляем на отдельный сервер мониторинга
if $syslogfacility-text == 'kern' then {
    action(type="omfwd" Target="monitor.example.com" Port="10514" Protocol="tcp")
}

Комбинируя условия по facility и severity, вы можете создавать сложные правила маршрутизации. Например, отправлять все critical и emerg сообщения от любых источников в Telegram-канал или Slack через внешний скрипт, а логи уровня info от почтовой системы - в отдельный файл для периодического анализа.

Интеграция с Elastic Stack и визуализация в Grafana

Хранение логов в текстовых файлах удобно для разовых проверок, но для анализа трендов, построения дашбордов и оперативного поиска инцидентов необходима специализированная система. Связка rsyslog → Elasticsearch → Grafana стала стандартом для таких задач.

Настройка отправки логов из rsyslog в Elasticsearch

Для прямой отправки логов из rsyslog в Elasticsearch необходим модуль omelasticsearch. Установите его:

# Debian/Ubuntu
sudo apt install -y rsyslog-elasticsearch

# RHEL/CentOS
sudo dnf install -y rsyslog-elasticsearch

Создайте конфигурационный файл, например, /etc/rsyslog.d/60-elasticsearch.conf. В нем нужно загрузить модуль, задать шаблон для индекса Elasticsearch и определить правило отправки.

# Загрузка модуля вывода в Elasticsearch
module(load="omelasticsearch")

# Шаблон для имени индекса. Индекс будет создаваться ежедневно.
template(name="es-index" type="list") {
    constant(value="syslog-")
    property(name="timereported" dateFormat="rfc3339" position.from="1" position.to="10")
}

# Правило: отправлять все сообщения, кроме локальных (от rsyslog), в Elasticsearch
if $fromhost-ip != "127.0.0.1" then {
    action(type="omelasticsearch"
           server="localhost"
           serverport="9200"
           template="es-index"
           searchIndex="es-index"
           dynSearchIndex="on"
           bulkmode="on"
           uid="rsyslog"
           pwd="ваш_пароль")
}

Замените server="localhost" на адрес вашего кластера Elasticsearch, при необходимости настройте аутентификацию. После перезагрузки rsyslog (sudo systemctl restart rsyslog) логи начнут поступать в Elasticsearch. Вы можете проверить это, выполнив запрос к API Elasticsearch: curl -X GET "localhost:9200/syslog-2026.06.02/_search?pretty" или используя Kibana для просмотра данных.

Создание дашбордов в Grafana для мониторинга системных логов

После того как логи попали в Elasticsearch, вы можете подключить его как источник данных в Grafana и создать информативные дашборды.

1. Подключение источника данных. В интерфейсе Grafana перейдите в Configuration → Data Sources → Add data source. Выберите тип "Elasticsearch". Укажите URL (например, http://localhost:9200), версию Elasticsearch и имя индекса (можно использовать шаблон syslog-*).

2. Создание дашборда. Вот примеры полезных панелей:

• График "Ошибки в минуту": Создайте панель типа "Time series". В запросе к Elasticsearch используйте фильтр по полю syslogseverity: 3 (или syslogseverity_keyword: "err"). В метриках выберите агрегацию "Count" и группировку по интервалу "1m". Это позволит видеть всплески ошибок в системе.
• Таблица "Последние критические события": Используйте панель типа "Logs" или "Table". Настройте запрос с фильтром syslogseverity <= 2 (crit, alert, emerg). В качестве отображаемых полей выберите @timestamp, hostname, syslogtag (или app-name), message. Эта панель даст мгновенный обзор самых серьезных проблем.
• Статистика "Топ источников логов (по facility)": Панель типа "Stat" или "Pie chart". В запросе примените агрегацию "Terms" по полю syslogfacility_text. Вы увидите, какие подсистемы генерируют больше всего сообщений, что помогает выявить аномальную активность.

Для более глубокого анализа безопасности вы можете интегрировать эти дашборды с другими системами сбора логов, рассмотренными в нашем сравнении стеков мониторинга.

Типовые проблемы и их решение (Troubleshooting)

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

Диагностика проблем с пересылкой логов

Если логи с клиентов не поступают на сервер-коллектор, действуйте по порядку:

1. Проверьте состояние служб: На клиенте и сервере выполните sudo systemctl status rsyslog. Служба должна быть активна (active) и работать (running).
2. Проверьте сетевую доступность и firewall: Убедитесь, что порт 514 (или выбранный вами) открыт на сервере-коллекторе. Проверьте связность: telnet <server_ip> 514 с клиента. Отключите или настройте firewall (iptables, firewalld, nftables) для разрешения входящих подключений на этот порт.
3. Отправьте тестовое сообщение: На клиенте используйте logger -p local0.err "Test ERROR message". Проверьте локальный журнал клиента (tail -f /var/log/syslog или journalctl -f), чтобы убедиться, что сообщение было сгенерировано.
4. Проверьте логи самого rsyslog: На сервере и клиенте изучите внутренний лог rsyslog: tail -f /var/log/rsyslog.log или journalctl -u rsyslog -f. Часто там содержатся подробные сообщения об ошибках конфигурации или проблемах с подключением.

Оптимизация производительности и управления дисковым пространством

Система логирования не должна сама становиться причиной проблем.

• Ротация логов rsyslog: Настройте logrotate для файлов, в которые пишет rsyslog. Пример конфигурации для /etc/logrotate.d/rsyslog-remote:

  /var/log/remote/*/*.log {
      daily
      rotate 30
      compress
      delaycompress
      missingok
      notifempty
      sharedscripts
      postrotate
          /usr/lib/rsyslog/rsyslog-rotate
      endscript
  }
  

• Лимиты journald: Чтобы journald не заполнил диск, отредактируйте /etc/systemd/journald.conf. Установите SystemMaxUse=1G (или другой разумный лимит) и SystemKeepFree=15%. После изменения выполните sudo systemctl restart systemd-journald.
• Фильтрация на этапе сбора: Самый эффективный способ снизить нагрузку - не собирать ненужные логи. Используйте правила в rsyslog на клиентах, чтобы отбрасывать debug-сообщения или логи от неважных приложений до их отправки по сети.
• Сжатие в Elasticsearch: Включите сжатие индексов в Elasticsearch с помощью codec (например, best_compression) и настройте политики ILM (Index Lifecycle Management) для автоматического удаления старых данных.

Если вы настраиваете логирование для Python-приложений в продакшене, обратите внимание на практические методы оптимизации производительности, которые помогут избежать падения скорости работы сервисов.

Итоги и рекомендации для 2026 года

Архитектура системного логирования в 2026 году оформилась в четкий и эффективный гибридный конвейер. Systemd-journald служит для быстрого, структурированного сбора логов на каждом узле. Rsyslog выступает в роли надежного и гибкого транспортного уровня, обеспечивающего централизацию, фильтрацию по facility/severity и совместимость. Elasticsearch (или альтернативы вроде Grafana Loki) предоставляет масштабируемое хранилище для долгосрочного анализа, а Grafana - инструмент для оперативной визуализации и алертинга.

Ключевые рекомендации:

1. Используйте связку journald → rsyslog → Elasticsearch как стандарт для новых проектов.
2. Настройте фильтрацию логов на уровне rsyslog-клиентов, чтобы уменьшить объем передаваемых данных и нагрузку на сеть и хранилище.
3. Обязательно настройте лимиты дискового пространства для journald и политики ротации/удаления для файлов rsyslog и индексов Elasticsearch.
4. Интегрируйте дашборды Grafana с системами алертинга (например, через встроенные Alert Rules) для мгновенного реагирования на критические события (severity crit, alert, emerg).

Тренд будущего - движение в сторону еще большей структурированности и стандартизации, в том числе за счет таких фреймворков, как OpenTelemetry. Однако описанный стек остается фундаментальным, проверенным решением для обеспечения наблюдаемости (observability) любой Linux-инфраструктуры в 2026 году. Для автоматизации развертывания подобных систем в Kubernetes изучите наше практическое руководство по сбору логов в Kubernetes.