Як налаштувати централізоване журналювання за допомогою Rsyslog в AlmaLinux

Rsyslog — це демон (сервіс) призначений для реєстрації та журналювання системних подій. Він дозволяє збирати повідомлення від операційної системи та різних сервісів, фільтрувати їх за потрібними параметрами та записувати у відровідні файли журналів.

Однією з ключових переваг Rsyslog є гнучкість налаштування. За допомогою правил і фільтрів можна визначити, які повідомлення потрібно зберігати, куди їх записувати та які журнали пересилати на інші сервери. Rsyslog підтримує роботу як з UDP, так і з TCP, що дозволяє вибирати відповідний спосіб передачі журналів залежно від вимог до надійності та продуктивності.

Окрім локальної обробки журналів, за допомогою Rsyslog можна налаштувати централізований сервер журналювання, на який інші Linux-сервери надсилатимуть свої системні логи. Це особливо корисно в інфраструктурах із великою кількістю серверів, а також може бути корисним для виконання вимог щодо захисту та контролю доступу до інформації. Зберігаючи журнали на окремому сервері, можна централізовано керувати доступом до них, контролювати термін їх зберігання та налаштовувати ротацію. Це може бути частиною комплексу технічних заходів для виконання вимог GDPR та інших політик інформаційної безпеки.

Для розгортання такого сервера можна використовувати надійний SSD VPS або виділений сервер з SSD – залежно від кількості клієнтів, обсягу логів та вимог до дискового простору.

У цьому посібнику ми налаштуємо AlmaLinux як центральний Rsyslog-сервер, а також покажемо, як налаштувати клієнтський сервер для надсилання журналів на нього.

Для прикладу використаємо таку схему:

192.168.10.10 – центральний Rsyslog-сервер
└── 192.168.10.41 – (Клієнт 1)

На центральному сервері журнали віддалених машин зберігатимуться в каталозі:

/var/log/servers/<IP-адреса-клієнта>/

Наприклад:

/var/log/servers/192.168.10.41/

За замовчуванням Rsyslog використовує порт 514 для Syslog. У цьому посібнику для простоти використаємо UDP, а наприкінці також покажемо, як перейти на TCP.

Що нам знадобиться

Перед початком виконання робіт, переконайтесь, що у вас є:

  • два сервери або віртуальні машини на AlmaLinux;
  • root-доступ або користувач із правами sudo до серверів/віртуальних машин.

У прикладах цієї статті будемо використовувати:

Rsyslog-сервер: 192.168.10.10
(Сервер який отримує журнали подій від інших серверів)
Клієнт: 192.168.10.41
(Надсилє свої журнали подій на центральний Rsyslog-сервер)

Замініть ці адреси на ті, що використовуються у вашій мережі.

Налаштовуємо центральний Rsyslog-сервер

Встановлення Rsyslog на центральному сервері

Спочатку встановимо Rsyslog на центральний сервер з AlmaLinux.

Оновіть інформацію про пакети:

sudo dnf update -y

Потім встановіть Rsyslog:

sudo dnf install -y rsyslog

Після завершення встановлення запустіть службу та додайте її до автоматичного запуску:

sudo systemctl enable --now rsyslog

Перевірте її стан:

sudo systemctl is-active rsyslog

Якщо все налаштовано правильно, ви побачите:

active

Налаштування Rsyslog на головному сервері

Тепер налаштуємо наш rsyslog-сервер з AlmaLinux для приймання журналів віддалених серверів.

Замість редагування основного файлу /etc/rsyslog.conf рекомендується створити окремий конфігураційний файл у /etc/rsyslog.d/. Rsyslog автоматично обробляє .conf-файли з цього каталогу.

Створіть новий файл /etc/rsyslog.d/10-remote.conf

Додайте:

# Enable UDP syslog reception
module(load="imudp")

# Listen for incoming syslog messages on UDP port 514
input(
    type="imudp"
    port="514"
)

# Store remote logs in a separate directory for each client
template(
    name="RemoteLogs"
    type="string"
    string="/var/log/servers/%FROMHOST-IP%/%PROGRAMNAME%.log"
)

# Write all remote messages to the dynamic log file
*.* action(
    type="omfile"
    dynaFile="RemoteLogs"
    createDirs="on"
    dirCreateMode="0750"
    fileCreateMode="0640"
)

Збережіть файл.

Пояснимо як працюють ці налаштування

Рядок:

module(load="imudp")

завантажує модуль imudp, який дозволяє Rsyslog приймати Syslog-повідомлення через UDP.

Далі:

input(
    type="imudp"
    port="514"
)

змушує Rsyslog слухати UDP-порт 514.

Шаблон:

string="/var/log/servers/%FROMHOST-IP%/%PROGRAMNAME%.log"

визначає, де будуть зберігатися журнали.

Наприклад, якщо клієнт має IP:

192.168.10.41

а повідомлення надсилає sshd, Rsyslog збереже його тут:

/var/log/servers/192.168.10.41/sshd.log

Це дозволяє легко розділяти журнали різних серверів і сервісів.

Налаштування доступу до журналів

Створимо основний каталог для віддалених журналів та встановимо права доступу:

sudo mkdir -p /var/log/servers
sudo chmod 0750 /var/log/servers

Перевірте чи використовується у вас на сервері SELinux:

getenforce

Якщо у відповіді ви отримали enforcing або permissive виконайте кроки наведені нижче, в іншому випадку перейдіть до наступного розділу “Перевірка конфігурації Rsyslog”.

sudo restorecon -Rv /var/log/servers

Перевірити контекст можна за допомогою:

ls -Zd /var/log/servers

Перевірка конфігурації Rsyslog

Перед перезапуском Rsyslog на центральному сервері варто перевірити конфігурацію на синтаксичні помилки.

Виконайте:

sudo rsyslogd -N1

Якщо конфігурація правильна, наприкінці ви побачите повідомлення на кшталт:

End of config validation run. Bye.

Якщо з’явилася помилка, не перезапускайте службу, а перевірте налаштування, виправте помилки і тільки після цього перезапускайте rsyslog.

Перезапускаємо Rsyslog

Перезапустіть службу rsyslog:

sudo systemctl restart rsyslog

Перевірте її стан:

sudo systemctl is-active rsyslog

Також перевіримо, чи Rsyslog слухає UDP-порт 514:

sudo ss -lunp | grep ':514'

Очікуваний результат буде приблизно таким:

UNCONN 0 0 0.0.0.0:514 0.0.0.0:* users:((“rsyslogd”,…))
Тепер сервер готовий приймати віддалені журнали.

Обмеження клієнтів, яким дозволено надсилати журнали

На багатьох серверах з AlmaLinux типовим мережевим інструментом захисту є firewalld. AlmaLinux також рекомендує використовувати firewall-cmd для керування правилами firewall.

Тут і подальшому, якщо ви використовуєте інший інструмент мережевого захисту, зробіть відповідні зміни в налаштуваннях вашого мережевого фільтру, та ігноруйте команди пов’язані з firewalld.
sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="192.168.10.41" port port="514" protocol="udp" accept'

Де, 192.168.10.41 – IP сервера від якого наш центральній rsyslog-сервер буде отримувати журнали.

Застосуйте зміни:

sudo firewall-cmd --reload

Перевірте:

sudo firewall-cmd --zone=public --list-rich-rules

Це краще, ніж залишати Syslog-порт відкритим для всього Інтернету.

Налаштування клієнтського сервера

Тепер налаштуємо інший AlmaLinux-сервер, який буде надсилати журнали на центральний Rsyslog-сервер.

У нашому прикладі:

Клієнт: 192.168.10.41
Rsyslog-сервер: 192.168.10.10
Порт: 514/UDP

На клієнті встановимо та запустимо Rsyslog:

sudo dnf install -y rsyslog
sudo systemctl enable --now rsyslog

Перевіртимо її статус:

sudo systemctl is-active rsyslog

Налаштування пересилання журналів

Створимо окремий конфігураційний файл /etc/rsyslog.d/90-remote.conf

Додайте в нього:

# Forward all logs to the central Rsyslog server

*.* action(
    type="omfwd"
    target="192.168.10.10"
    port="514"
    protocol="udp"
)

Замініть 192.168.10.10 на IP-адресу вашого центрального Rsyslog-сервера.

Модуль omfwd використовується Rsyslog для пересилання повідомлень через UDP або TCP. Він є вбудованим, тому окремо завантажувати його не потрібно.

Налаштовуємо чергу в rsyslog для випадку недоступності сервера

У продакшен-середовищі ми рекомендємо не обмежуватися простим:

*.* action(
    type="omfwd"
    target="192.168.10.10"
    port="514"
    protocol="udp"
)

Якщо центральний сервер тимчасово недоступний, частина повідомлень може бути втрачена.

Для цього можна налаштувати чергу Rsyslog:

*.* action(
    type="omfwd"
    target="192.168.10.10"
    port="514"
    protocol="udp"

    queue.type="linkedlist"
    queue.filename="remote_fwd"
    queue.saveOnShutdown="on"
    action.resumeRetryCount="-1"
)

Ця конфігурація дозволяє Rsyslog тимчасово зберігати повідомлення в черзі та повторювати спроби відправлення, якщо сервер призначення недоступний. Red Hat також рекомендує використовувати action queue для захисту від втрати повідомлень при недоступності віддаленого сервера.

Важливо: для максимально надійного журналювання краще використовувати TCP замість UDP. UDP не гарантує доставку пакетів.

Перевірка конфігурації клієнта

Перевіримо конфігурацію:

sudo rsyslogd -N1

Якщо помилок немає, перезапустіть Rsyslog:

sudo systemctl restart rsyslog

Перевірте чи запустилась служба Rsyslog:

sudo systemctl is-active rsyslog

Відповідь має бути:

active

Тестування віддаленого журналювання

Тепер перевіримо, чи клієнт може надсилати повідомлення на сервер.

На клієнтському сервері виконайте:

logger "Test message from AlmaLinux client"

Ця команда створить тестове Syslog-повідомлення.

Поверніться на Rsyslog-сервер.

Перевірте каталог:

sudo ls -la /var/log/servers

Ви повинні побачити каталог із IP-адресою клієнта:

192.168.10.41

Перевірте його:

sudo ls -la /var/log/servers/192.168.10.41/

Серед файлів має з’явитися файл, пов’язаний із програмою, яка створила повідомлення.

Знайти тестове повідомлення можна за допомогою:

sudo grep -R "Test message from AlmaLinux client" /var/log/servers/

Або використати tail:

sudo tail -f /var/log/servers/192.168.10.41/*.log

Якщо все працює правильно, ви побачите ваше тестове повідомлення.

Використання TCP замість UDP в Rsyslog

UDP простий та швидкий, але він не гарантує доставку повідомлень.

Для продакшин-систем, де втрата журналів неприпустима, краще використовувати TCP. Документація RHEL для Rsyslog описує imtcp на сервері та omfwd з protocol=”tcp” на клієнті.

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

Відкрийте файл для редагування /etc/rsyslog.d/10-remote.conf та замініть в ньому всі записи “imudp” на “imtcp” або додайте в нього:

# Enable TCP syslog reception
module(load="imtcp")

input(
    type="imtcp"
    port="514"
)

template(
    name="RemoteLogsTCP"
    type="string"
    string="/var/log/servers/%FROMHOST-IP%/%PROGRAMNAME%.log"
)

*.* action(
    type="omfile"
    dynaFile="RemoteLogsTCP"
    createDirs="on"
    dirCreateMode="0750"
    fileCreateMode="0640"
)

Відкрийте TCP-порт у firewalld:

sudo firewall-cmd --permanent --zone=public --remove-rich-rule='rule family="ipv4" source address="192.168.10.41" port port="514" protocol="tcp" accept'
sudo firewall-cmd --reload

Де, 192.168.10.41 – IP сервера від якого наш центральній rsyslog-сервер буде отримувати журнали.

Перевірте конфігурацію:

sudo rsyslogd -N1

Після цього перезапустіть службу rsyslog:

sudo systemctl restart rsyslog

Перевірте порт:

sudo ss -ltnp | grep ':514'

Налаштування Rsyslog на клієнті для TCP

На клієнті відкрийте файл /etc/rsyslog.d/90-remote.conf для редагування і змініть в ньому protocol=”udp” на protocol=”tcp” або вставте в нього наступні налаштування замінивши попередні:

*.* action(
    type="omfwd"
    target="192.168.10.10"
    port="514"
    protocol="tcp"

    queue.type="linkedlist"
    queue.filename="remote_fwd"
    queue.saveOnShutdown="on"
    action.resumeRetryCount="-1"
)

Перевірте файл конфігурації rsyslog:

sudo rsyslogd -N1

Перезапустіть:

sudo systemctl restart rsyslog

Тепер створіть тестове повідомлення:

logger "Test TCP message from AlmaLinux client"

На сервері перевірте:

sudo grep -R "Test TCP message from AlmaLinux client" /var/log/servers/

Перевірка роботи Rsyslog

Якщо журнали не надходять на сервер, перевірте систему в такому порядку.

1. Перевірте Rsyslog

На центральному Rsyslog-сервері:

sudo systemctl is-active rsyslog

На клієнті:

sudo systemctl is-active rsyslog

2. Перевірте конфігурацію

На обох серверах:

sudo rsyslogd -N1

3. Перевірте порт

На сервері:

sudo ss -lunp | grep ':514'

Для TCP:

sudo ss -ltnp | grep ':514'

4. Перевірте firewalld

sudo firewall-cmd --list-all

5. Перевірте SELinux

getenforce

Якщо використовується Enforcing, перевірте контекст каталогу:

ls -Zd /var/log/servers

6. Перевірте журнали Rsyslog

sudo journalctl -u rsyslog -n 100 --no-pager

Для перегляду журналу в реальному часі:

sudo journalctl -u rsyslog -f

7. Перевірте мережеве з’єднання

З клієнта можна перевірити доступність порту TCP:

nc -vz 192.168.10.10 514

Для UDP така перевірка менш надійна, тому для діагностики можна скористатися tcpdump.

На Rsyslog-сервері:

sudo tcpdump -ni any udp port 514

Після цього на клієнті:

logger "tcpdump test message"

Якщо пакети видно в tcpdump, мережеве з’єднання працює, і проблему потрібно шукати в конфігурації Rsyslog або SELinux.

Ротація віддалених журналів на головному rsyslog-сервері

Якщо Rsyslog-сервер збирає логи від великої кількості машин, каталог /var/log/servers може швидко збільшуватися.

Тому в продакшен-середовищі варто налаштувати logrotate.

Створіть файл /etc/logrotate.d/remote-rsyslog

Додайте в нього:

/var/log/servers/*/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 root root
}

Ця конфігурація:

  • ротуватиме журнали щодня;
  • зберігатиме 14 старих копій;
  • стискатиме старі журнали;
  • не видаватиме помилку, якщо файл відсутній;
  • не створюватиме порожні журнали.

Перед використанням у продакшен середовищі перевірте вашу конкретну схему каталогів і вимоги до зберігання логів.

Централізоване логування за допомогою Rsyslogd налаштовано: Підсумки

В цій інструкції ми налаштували централізоване журналювання в AlmaLinux за допомогою Rsyslog: підготували сервер для приймання логів, налаштували клієнтський сервер для їх пересилання, перевірили роботу UDP/TCP-з’єднання, додали чергу для надійнішої доставки та налаштували ротацію журналів.

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

Хоча в інструкції для прикладу наведена конфігурація з двох серверів – центрального Rsyslog-сервера та одного клієнта, — цей підхід можна використовувати для будь-якої кількості клієнтських серверів. Достатньо налаштувати кожен із них на пересилання журналів до центрального Rsyslog-сервера.

Для стабільної роботи централізованого журналювання важливо мати надійну серверну інфраструктуру. Якщо вам потрібен сервер для централізованого логування, моніторингу, резервного копіювання чи інших задач, ви можете розглянути швидкі SSD VPS або виділенний сервер з SSD відповідної конфігурації на нашому сайті.

Прокрутка до верху