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

Однажды на продакшене упал PostgreSQL: диск заполнился — journald в tmpfs не ограничен, при перезагрузке логи пропали, root cause не нашли сутки. Простой продлился более 8 часов, а команда потратила два дня на повторный анализ. Знакомая ситуация? Без правильной настройки журнал systemd становится чёрным ящиком. Наши инженеры с 10-летним опытом настраивают journald так, чтобы логи не терялись, диск не переполнялся, а данные уходили в централизованную систему. Это снижает MTTR на 70% и экономит до 40% бюджета на хранение за счёт ротации и сжатия. За 200+ проектов мы отработали типовые конфигурации, которые работают без сбоев. Мы используем Ansible для массовой раскатки, что сокращает время настройки fleet из 50+ машин до одного дня. На одном из проектов мы столкнулись с тем, что RateLimitBurst был слишком низким — шумный сервис терял критичные логи. После корректировки конфигурации и настройки пересылки в Loki MTTR снизился с 4 часов до 30 минут. Свяжитесь с нами для консультации — подберём оптимальную конфигурацию под вашу нагрузку.

Как настроить персистентное хранение и ограничение размера?

По умолчанию journald пишет в /run/log/journal/ — это tmpfs, данные теряются при ребуте. Чтобы включить постоянное хранение:

mkdir -p /var/log/journal systemd-tmpfiles --create --prefix /var/log/journal systemctl restart systemd-journald 

Конфигурация в /etc/systemd/journald.conf:

[Journal]
Storage=persistent
Compress=yes
SystemMaxUse=2G
SystemKeepFree=500M
SystemMaxFileSize=200M
SystemMaxFiles=10
MaxRetentionSec=1month
MaxFileSec=1week
RateLimitInterval=30s
RateLimitBurst=10000
ForwardToSyslog=no
ForwardToKMsg=no
ForwardToConsole=no

SystemMaxUse=2G — лимит на диске. Без него journald может съесть весь диск за несколько дней при интенсивной записи. RateLimitBurst=10000 защищает от шторма логов: если сервис генерирует больше 10000 сообщений за 30 секунд, остальные дропаются. Для шумных приложений (например, nginx debug) этот лимит можно поднять через drop-in конфиг.

Сравнение настроек: базовая vs прод

Почему RateLimit важен?

Без RateLimit бурст логов от сбойного сервиса может забить journald, вызвав потерю критичных сообщений от других юнитов. Настройка RateLimitInterval и RateLimitBurst — обязательный шаг для стабильности. Рекомендуем для большинства сервисов оставить 10000 сообщений за 30 секунд, а для шумных — увеличить до 50000.

Как фильтровать логи по приоритету и юниту?

Просмотр на конкретной машине:

# Логи конкретного юнита с отслеживанием
journalctl -u nginx.service -f
# Логи с момента последней загрузки
journalctl -b
# За последний час
journalctl --since "1 hour ago"
# Только ошибки и критичные
journalctl -p err -b
# JSON-вывод для парсинга
journalctl -u myapp -o json-pretty --since today
# Логи конкретного PID
journalctl _PID=1234

Для централизованной пересылки фильтрацию настраивают на стороне агента: в promtail через relabel_configs, в Filebeat через include_matches. Это позволяет отправлять только нужные логи, экономя трафик и хранилище.

Почему важно ограничивать размер журнала?

На сервере с интенсивной записью логов без SystemMaxUse journald может занять до 100% свободного места за 2-3 дня. Это приводит к сбоям демонов, отказу SSH и потере данных. Ограничение в 2G сберегает диск и не даёт умереть сервисам. К тому же правильная ротация сокращает MTTR — вы быстрее найдёте ошибку. Наши клиенты экономят около $90–130 на инфраструктуре за счёт сжатия и ротации.

Как отправить логи в централизованное хранилище?

Для отправки в Loki используйте promtail с journal input:

scrape_configs:
  - job_name: journal
    journal:
      max_age: 12h
      labels:
        job: systemd-journal
        host: ${HOSTNAME}
    relabel_configs:
      - source_labels: [__journal__systemd_unit]
        target_label: unit
      - source_labels: [__journal_priority_keyword]
        target_label: level

Для отправки в Elasticsearch через Filebeat:

filebeat.inputs:
  - type: journald
    id: everything
    include_matches:
      - _SYSTEMD_UNIT=nginx.service
      - _SYSTEMD_UNIT=postgresql.service
      - PRIORITY=0
      - PRIORITY=1
      - PRIORITY=2
      - PRIORITY=3

Сравнение promtail и filebeat для journald

scrape_configs:
  - job_name: journal
    journal:
      max_age: 24h
      labels:
        job: systemd-journal
        host: "${HOSTNAME}"
    relabel_configs:
      - source_labels: [__journal__systemd_unit]
        target_label: unit
      - source_labels: [__journal_priority_keyword]
        target_label: level
      - source_labels: [__journal__hostname]
        target_label: hostname
      - replacement: "auto"
        target_label: agent
    pipeline_stages:
      - drop:
          selector: '{level="debug"}'

Процесс настройки journald под ключ

1. Аудит текущей конфигурации journald на всех серверах.
2. Настройка персистентного хранения и ротации с калибровкой лимитов под вашу нагрузку.
3. Интеграция с централизованным логированием (Loki, Elasticsearch, Syslog).
4. Создание runbook для дежурных и документация.
5. Тестирование под нагрузкой: запускаем стресс-тест и проверяем, что логи не теряются.

Настройка одного сервера занимает до 4 часов. Для fleet из 50+ машин конфигурация раскатывается через Ansible за 1–2 дня. Стоимость рассчитывается индивидуально — свяжитесь для оценки вашего проекта. Мы гарантируем, что после настройки журнал будет работать надёжно.

Что входит в работу по настройке journald

• Документация: подробная схема конфигурации, описание лимитов, инструкция для дежурных.
• Интеграция с observability: подключение к Loki или Elasticsearch, настройка дашбордов Grafana.
• Runbook и обучение: сценарии реагирования на инциденты, обучение команды работе с journalctl.
• Поддержка после ввода: 2 недели мониторинга и корректировки конфигурации.

Типичные ошибки при настройке journald

Отсутствие персистентного хранения: после ребута логи пропадают — root cause не найти. Пропущен SystemMaxUse: при пиковой нагрузке journald забивает диск, сервисы падают. Слишком низкий RateLimitBurst: шумный сервис теряет критичные сообщения. Нет пересылки: логи остаются локально, централизованный мониторинг слеп. Наши инженеры устраняют эти риски — после настройки журнал работает предсказуемо.

Итог: правильная конфигурация systemd-journald — база любой observability. Если хотите перестать терять логи и снизить время простоя, закажите настройку journald в нашей команде. Свяжитесь для консультации — подберём конфигурацию под ваш проект. Наши специалисты имеют 10+ лет опыта и выполнили 200+ проектов по настройке журналов.

Официальная документация systemd-journald