Налаштування 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 burst логів від збійного сервісу може забити 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 — ви швидше знайдете помилку. Наші клієнти економлять десятки тисяч гривень на інфраструктурі за рахунок стиснення та ротації.

Як відправити логи в централізоване сховище?

Для відправки в 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