Централізований збір log-файлів позбавляє від хаосу: замість того, щоб бігати по кожному вузлу, ви отримуєте єдиний пункт для пошуку інцидентів, аудиту та аналітики. У цій статті розберемося, як підняти rsyslog-агрегатор на сервері Linux, як грамотно фільтрувати потоки подій і налаштувати надійну ротацію через Logrotate. Додамо кілька порад з безпеки, автоматизації та розв’язання типових проблем. Це база для надійного спостереження і Linux моніторинг у продакшені.

Архітектура та потік логів

Мінімальна схема: є один сервер Linux-агрегатор з rsyslog, що приймає події по UDP/TCP (або RELP), зберігає їх у структурі каталогів по хостах і застосовує ротацію через Logrotate. Клієнти rsyslog надсилають свої log-файли Linux за селекторами (все або частину), опційно з TLS-шифруванням на порт 6514. Далі ці логи можна переганяти у SIEM/ELK/Grafana Loki, або просто аналізувати локально.

Налаштування rsyslog на сервері-агрегаторі

1) Встановлення пакунків

# Debian/Ubuntu
sudo apt update
sudo apt install -y rsyslog rsyslog-relp logrotate

# RHEL/CentOS/Rocky/Alma
sudo dnf install -y rsyslog rsyslog-relp logrotate
sudo systemctl enable --now rsyslog

2) Відкриття портів для прийому

# UFW (Ubuntu)
sudo ufw allow 514/udp
sudo ufw allow 514/tcp
# для TLS/RELP за потреби
sudo ufw allow 6514/tcp
sudo ufw allow 20514/tcp

# firewalld (RHEL-сімейство)
sudo firewall-cmd --permanent --add-port=514/udp
sudo firewall-cmd --permanent --add-port=514/tcp
sudo firewall-cmd --permanent --add-port=6514/tcp
sudo firewall-cmd --permanent --add-port=20514/tcp
sudo firewall-cmd --reload

3) Конфігурація rsyslog для прийому і збереження

Створимо правило з динамічним шляхом /var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log:

sudo tee /etc/rsyslog.d/10-remote-server.conf >/dev/null <<'EOF'
module(load="imudp")
input(type="imudp" port="514")
module(load="imtcp")
input(type="imtcp" port="514")
# Опційно надійний протокол RELP
module(load="imrelp")
input(type="imrelp" port="20514")

# Шаблон збереження у папки по хостах/процесах
template(name="RemoteFormat" type="string"
         string="/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log")

# Зберігаємо тільки віддалені події (не локальні)
if ($fromhost-ip != "127.0.0.1") then {
  action(type="omfile" dynaFile="RemoteFormat")
  stop
}
EOF

sudo systemctl restart rsyslog

Тепер агрегатор приймає логи і розкладає їх по хостам. Переконайтесь, що каталог створюється автоматично при першому записі.

Конфіг клієнтів rsyslog: надсилаємо події на агрегатор

Швидкий варіант (мінімум змін)

# Надсилати все по TCP на порт 514 (дві @ — TCP)
echo '*.* @@log.example.lan:514' | sudo tee /etc/rsyslog.d/90-forwarding.conf
sudo systemctl restart rsyslog

Гнучкий варіант із селекторами та чергою

sudo tee /etc/rsyslog.d/90-forwarding.conf >/dev/null <<'EOF'
# Приклад: все, крім debug; authpriv і kern завжди шлемо
action(
  type="omfwd"
  target="log.example.lan"
  port="514"
  protocol="tcp"
  queue.type="LinkedList"
  queue.filename="fwd-main"
  action.resumeRetryCount="-1"
)

# Тонкі фільтри (опційно)
if ($syslogseverity-text == 'debug') then stop
EOF

sudo systemctl restart rsyslog

Опційно: TLS/6514 для захисту

Якщо передаєте чутливі логи через незахищені мережі, використовуйте TLS на 6514 та сертифікати. Базовий приклад для клієнта (після налаштування сертифікатів):

sudo tee /etc/rsyslog.d/91-tls-forward.conf >/dev/null <<'EOF'
action(
  type="omfwd"
  target="log.example.lan"
  port="6514"
  protocol="tcp"
  StreamDriver="gtls"
  StreamDriverMode="1"             # TLS on
  StreamDriverAuthMode="x509/name"  # Перевірка ім'я в сертифікаті
  tls.cacert="/etc/rsyslog.d/ca.crt"
  tls.mycert="/etc/rsyslog.d/client.crt"
  tls.myprivkey="/etc/rsyslog.d/client.key"
)
EOF
sudo systemctl restart rsyslog

Фільтрація та розділення логів

rsyslog підтримує property-based фільтри. Наприклад, відкинути «шумні» сервіси або класти їх у окремі файли:

# На сервері-агрегаторі, у 10-remote-server.conf — приклади:
# Окремий файл для sshd
if ($programname == 'sshd') then {
  action(type="omfile" dynaFile="/var/log/remote/%HOSTNAME%/sshd.log")
  stop
}

# Відкинути health-check з певного IP
if ($fromhost-ip == '10.10.10.10' and $programname == 'healthcheck') then stop

# Знизити «шум» для cron
if ($programname == 'CRON' and $msg contains 'pam_unix') then stop

Ротація логів з Logrotate

Щоб log-файли не розросталися, налаштуємо Logrotate. Він зазвичай запускається через cron та systemd timers автоматично.

sudo tee /etc/logrotate.d/remote-logs >/dev/null <<'EOF'
/var/log/remote/*/*.log {
  daily
  rotate 14
  compress
  delaycompress
  missingok
  notifempty
  dateext
  dateformat -%Y%m%d
  create 0640 syslog adm
  sharedscripts
  postrotate
    systemctl reload rsyslog >/dev/null 2>&1 || true
  endscript
}
EOF

# Перевірка і примусовий запуск
sudo logrotate -d /etc/logrotate.conf   # dry-run, перевірити логіку
sudo logrotate -f /etc/logrotate.d/remote-logs

Альтернативні способи

  • systemd-journald → rsyslog: на клієнтах лишаємо journald як є, а rsyslog читає з journal і шле далі.
  • syslog-ng: альтернатива rsyslog з подібними можливостями.
  • Fluent Bit/Filebeat → Elasticsearch/Opensearch або Grafana Loki: варіант для складнішої аналітики і дашбордів.

GUI-спосіб (за потреби)

Для базового перегляду локальних журналів зручно використати Cockpit (веб-консоль). А для централізованого сховища логи з rsyslog можна подавати у Graylog або Grafana Loki з веб-інтерфейсом пошуку і візуалізації. Це хороше доповнення до вашого процесу Linux моніторинг.

FAQ

Як швидко перевірити надсилання логів?

# На клієнті
logger -t test "hello from client"

# На сервері перевірте нові файли
sudo find /var/log/remote -type f -mmin -1
sudo tail -n 50 /var/log/remote/CLIENT_HOSTNAME/test.log

UDP чи TCP/RELP?

UDP 514 — простий, але без підтвердження доставки. TCP 514 — надійніший. RELP 20514 — найкращий вибір для критичних подій (гарантована доставка і відновлення після розривів).

Що з SELinux?

# Якщо використовуєте нестандартний порт, додайте контекст:
sudo semanage port -a -t syslogd_port_t -p tcp 20514
sudo systemctl restart rsyslog

Як обмежити розмір каталогу з логами?

Поєднуйте ротацію (daily/weekly + rotate N + compress) з моніторингом диска. За потреби обмежуйте селектори на клієнті, відкидайте «шумні» події на сервері.

Чому бачу дублікати записів?

Ймовірно, на сервері не стоїть інструкція stop у правилі після збереження, або клієнт шле події кількома способами. Перевірте порядок правил і використовуйте stop.

Чи конфліктує Logrotate з journald?

Ні, journald обслуговує власні двійкові журнали, rsyslog — текстові. Logrotate працює саме з файлами rsyslog. Це паралельні підсистеми.

Порада від Kernelka

Тримайте окремі шаблони для різних рівнів важливості (crit, err, info) та сервісів. Так ви швидко відфільтруєте потрібне, а при інциденті зекономите дорогоцінні хвилини ⏱️. І не забувайте про резервні копії критичних логів — це частина здорової стратегії безпеки.

Підсумок

  • Підняли rsyslog на сервері-приймачі, відкрили порти і налаштували динамічні шляхи збереження.
  • Сконфігурували клієнти: просте надсилання або гнучка доставка з чергою і фільтрами.
  • Увімкнули TLS/6514 за потреби підвищеної безпеки.
  • Налаштували Logrotate: ротація, компресія, пост-скрипт перезапуску.
  • Розглянули альтернативи (syslog-ng, Fluent Bit, Loki/Graylog) та інтеграцію з GUI.
  • Перекрили типові проблеми: перевірка logger, SELinux, дублікати, контроль місця.
  • Автоматизація через cron та systemd timers вже вбудована — залишилось періодично перевіряти здоров’я системи.