Как настроить централизованный сбор логов с помощью Rsyslog/Syslog-ng на VPS?

Что понадобится

• Две и более VPS под управлением Ubuntu или Debian. На одной из них будет сервер логов, остальные — клиенты.

• Права sudo и доступ по SSH к каждому серверу.

• Открытый порт (по умолчанию 514/UDP или 514/TCP) на сервере для приёма сообщений.

• Установленный пакет rsyslog или syslog-ng — оба решения совместимы и поддерживают пересылку данных по сети.

Rsyslog чаще используется по умолчанию в Ubuntu и Debian, поэтому в статье будут показаны примеры именно с ним. Однако все шаги аналогичны и для Syslog-ng.

Совет: если сервер логов расположен в другой сети, убедитесь, что фаервол разрешает входящие соединения на выбранный порт (обычно 514).

Подготовка сервера логов (Rsyslog)

На центральном сервере будет собираться информация от всех клиентских VPS. Для этого нужно включить приём сообщений по сети и определить директории хранения.

Проверяем наличие Rsyslog

sudo apt update
sudo apt install rsyslog -y

После установки убедитесь, что служба активна:

sudo systemctl status rsyslog

Включаем приём удалённых логов

Откройте конфигурацию:

sudo nano /etc/rsyslog.conf

Найдите и раскомментируйте строки (уберите символ #):

$ModLoad imudp
$UDPServerRun 514

$ModLoad imtcp
$InputTCPServerRun 514

Это позволит принимать логи по протоколам UDP и TCP. Сохраните файл и перезапустите сервис:

sudo systemctl restart rsyslog

Совет: TCP надёжнее, чем UDP, так как гарантирует доставку сообщений, но немного повышает нагрузку. Для критичных систем используйте TCP.

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

После подготовки центрального сервера нужно настроить каждый клиент так, чтобы он пересылал свои системные сообщения по сети. В Rsyslog это делается одной строкой конфигурации.

Устанавливаем Rsyslog на клиенте

sudo apt update
sudo apt install rsyslog -y

Убедитесь, что служба активна:

sudo systemctl status rsyslog

Добавляем правило пересылки логов

Откройте конфигурацию Rsyslog:

sudo nano /etc/rsyslog.conf

В конец файла добавьте одну из следующих строк (в зависимости от выбранного протокола):

Через UDP:

*.* @server_ip:514

Через TCP:

*.* @@server_ip:514

Здесь server_ip — это IP-адрес центрального сервера логов. Символ @ означает UDP, а @@ — TCP. После добавления строки сохраните изменения и перезапустите службу:

sudo systemctl restart rsyslog

Теперь все системные сообщения будут автоматически дублироваться на центральный сервер.

Совет: если на клиенте настроен фаервол (UFW), разрешите исходящие соединения на порт 514:

sudo ufw allow out 514/tcp
sudo ufw allow out 514/udp

Проверка приёма и структура хранения логов

После настройки сервер и клиенты можно протестировать, чтобы убедиться, что сообщения действительно поступают в хранилище логов.

Проверяем логи на сервере

На сервере логов выполните команду:

sudo tail -f /var/log/syslog

Если всё настроено правильно, в выводе появятся строки, содержащие имя или IP клиентской машины:

Oct 14 13:25:10 vps-client1 sshd[1423]: Accepted password for root from 10.0.0.25 port 45678 ssh2

Разделяем логи по хостам

Чтобы хранить логи каждого клиента в отдельной папке, откройте файл:

sudo nano /etc/rsyslog.d/remote.conf

и добавьте:

$template RemoteLogs,"/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log"
*.* ?RemoteLogs
& ~
  

Теперь все логи будут сохраняться в каталоге /var/log/remote/имя_хоста, что удобно для анализа и резервного копирования.

Совет: можно подключить утилиты визуализации вроде Logwatch или GoAccess, чтобы анализировать полученные логи через веб-интерфейс.

Фильтрация и безопасность передачи логов

Передача логов по сети может содержать конфиденциальные данные — имена пользователей, IP-адреса, сообщения об ошибках. Поэтому важно обеспечить безопасность и фильтрацию пересылаемых событий.

Ограничение по типу сообщений

Если нужно отправлять только определённые типы логов (например, только ошибки и авторизацию), настройте фильтры в конфигурации клиента:

authpriv.* @@server_ip:514
*.err @@server_ip:514
  

Так будут пересылаться только журналы авторизации (authpriv) и ошибки уровня error со всех сервисов.

Использование TCP вместо UDP

UDP не гарантирует доставку сообщений — пакеты могут теряться при высоких нагрузках. Для надёжных систем рекомендуется использовать TCP:

*.* @@server_ip:514

Шифрование логов с помощью TLS

Rsyslog поддерживает безопасную передачу сообщений через TLS. Для этого на сервере нужно создать сертификат и включить соответствующие модули.

На сервере:

sudo mkdir -p /etc/rsyslog-keys
cd /etc/rsyslog-keys
sudo openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 -nodes

Добавьте в /etc/rsyslog.conf:

$DefaultNetstreamDriver gtls
$DefaultNetstreamDriverCAFile /etc/rsyslog-keys/cert.pem
$ModLoad imtcp
$InputTCPServerStreamDriverMode 1
$InputTCPServerStreamDriverAuthMode anon
$InputTCPServerRun 6514
  

Теперь сервер будет принимать зашифрованные логи по порту 6514/TCP.

На клиенте:

Добавьте строку пересылки:

*.* @@(o)server_ip:6514

Символ (o) указывает на использование TLS-соединения. После перезапуска службы сообщения будут отправляться в зашифрованном виде.

Совет: можно дополнительно ограничить приём логов только с доверенных IP-адресов через правила iptables или ufw.

Итоги

• Настроили централизованный сбор логов с помощью Rsyslog — все сообщения теперь хранятся на одном сервере.

• Включили приём сообщений по TCP/UDP и добавили клиентов для пересылки системных событий.

• Создали структуру каталогов по хостам и фильтры для различных типов логов.

• Обеспечили безопасность передачи данных с помощью TLS и ограничений по IP.

Вывод: централизованный сбор логов упрощает администрирование и повышает безопасность серверной инфраструктуры. Все события можно анализировать в одном месте, быстро находить ошибки и отслеживать подозрительные активности. Для крупных проектов дополнительно можно интегрировать Rsyslog или Syslog-ng с системами вроде ELK Stack или Grafana Loki для визуализации данных и построения дашбордов.