Как хранить логи клиента rsyslog отдельно от локальных сообщений сервера

Вопрос или проблема

Родные. У меня есть сервер rsyslog. Логи, отправленные с клиента rsyslog, сохраняются в отдельный файл, но также попадают в локальный файл сообщений на сервере rsyslog. Я хочу, чтобы клиентские логи не появлялись в файле сообщений на стороне сервера. Это rsyslog.conf на стороне сервера: это работало для одного клиента, но если у меня 200000 клиентов, я не могу найти решение для обработки этого.

# файл конфигурации rsyslog

# Для получения дополнительной информации см. /usr/share/doc/rsyslog-*/rsyslog_conf.html
# или последнюю версию онлайн по адресу http://www.rsyslog.com/doc/rsyslog_conf.html 
# Если у вас возникают проблемы, см. http://www.rsyslog.com/doc/troubleshoot.html

#### ГЛОБАЛЬНЫЕ ДИРЕКТИВЫ ####

# Где размещать вспомогательные файлы
global(workDirectory="/var/lib/rsyslog")

# Использовать формат временной метки по умолчанию
module(load="builtin:omfile" Template="RSYSLOG_TraditionalFileFormat")

$ModLoad imudp
$UDPServerRun 514

#$ModLoad imtcp
#$InputTCPServerRun 514
#### МОДУЛИ ####

module(load="imuxsock"    # обеспечивает поддержку локального системного логирования (например, через команду logger)
       SysSock.Use="off") # Отключить прием сообщений через локальный сокет логов; 
              # локальные сообщения теперь извлекаются через imjournal.
module(load="imjournal"         # предоставляет доступ к системному журналу systemd
       StateFile="imjournal.state") # Файл для хранения позиции в журнале
#module(load="imklog") # считывает сообщения ядра (те же самые читаются из journald)
#module(load="immark") # обеспечивает способность сообщения --MARK--

$imjournalRatelimitInterval 0

$template syslog,"/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log"
# Включить все конфигурационные файлы в /etc/rsyslog.d/
include(file="/etc/rsyslog.d/*.conf" mode="optional")
#### ПРАВИЛА ####
if $fromhost-ip == '192.168.42.XXX' then ?syslog
& stop
if $fromhost-ip != '192.168.42.XXX' then /var/log/messages
# Логировать все сообщения ядра на консоль.
# Логирование чем-то еще захламляет экран.
kern.*                                                 /dev/console

# Логировать все (кроме почты) с уровнем info и выше.
# Не логировать личные сообщения аутентификации!
#*.info;mail.none;authpriv.none;cron.none                /var/log/messages

# Файл authpriv имеет ограниченный доступ.
authpriv.*                                              /var/log/secure

# Убедите, что все почтовые сообщения логируются в одном месте.
mail.*                                                  -/var/log/maillog

# Логировать задачи cron
cron.*                                                  /var/log/cron

# Все получают сообщения об аварийных ситуациях
*.emerg                                                 :omusrmsg:*

# Сохранить критические и выше ошибки новостей в специальный файл.
uucp,news.crit                                          /var/log/spooler

# Сохранить сообщения загрузки также в boot.log
local7.*                                                /var/log/boot.log

Я хочу, чтобы логи 200000 клиентов не появлялись в файле сообщений на стороне сервера. Может кто-нибудь помочь мне?

Вы можете использовать startswith от rsyslog (см. условия фильтра).

Вместо указания конкретного IP, вы можете проверить диапазон IP:

if $fromhost-ip startswith '192.168.' then {
    ?syslog
    & stop
}

или для нескольких диапазонов IP:

if ($fromhost-ip startswith '192.168.' or $fromhost-ip startswith '10.0.') then {
    ?syslog
    & stop
}

Примечание:

Вы можете удалить эту строку:

if $fromhost-ip != '192.168.42.XXX' then /var/log/messages

так как & stop уже завершает обработку логов из совпадающих диапазонов IP, предотвращая их запись в /var/log/messages (или куда-то еще).

.

Ответ или решение

Чтобы настроить раздельное хранение логов от клиентов rsyslog и локальных сообщений на сервере, нужно внести изменения в конфигурацию файла rsyslog на стороне сервера. Ваша задача — исключить попадание клиентских логов в файл /var/log/messages. Рассмотрим, как это сделать, учитывая конфигурацию с большим количеством клиентов, например, 200 000.

  1. Использование фильтрации по IP-адресам. Вместо проверки конкретного IP-адреса клиента, можно использовать предикат startswith, чтобы охватить диапазон IP-адресов. Это особенно полезно в случае, если вы работаете с большим количеством клиентов в заданном диапазоне подсети. Рассмотрим следующую конфигурацию фильтрации:

    if $fromhost-ip startswith '192.168.' then {
        ?syslog
        & stop
    }

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

  2. Удаление избыточной проверки. Если вы уже используете & stop после фильтрации некоторых адресов, нет необходимости в отдельной строке, проверяющей оставшиеся IP на соответствие и направляющей их в /var/log/messages. Удалите старую проверку, чтобы избежать дублирования логики:

    # Удалить эту строку
    # if $fromhost-ip != '192.168.42.XXX' then /var/log/messages
  3. Оптимизация хранения логов. Для распределенных систем с большим количеством клиентов рекомендуется использовать структурированную файловую систему. Убедитесь, что у вас настроена система хранения, обеспечивающая быструю запись и доступ к данным, например, использование бэкендов для партиции логов по дате и времени или logrotate для управления размером файлов.

  4. Просмотр и мониторинг конфигурации. После внесения изменений обязательно проверьте выполненные настройки. Используйте тестовые логи, чтобы убедиться, что логи каждого клиента поступают в заданный файл, и только локальные сообщения пишутся в /var/log/messages. Дополнительно настройте мониторинг для проверки заполнения диска и производительности системы.

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

Следуя этим рекомендациям, вы сможете настроить раздельное логирование, не перегружая системные ресурсы и обеспечивая целостность и доступность логов для анализа и мониторинга.

Оцените материал
Добавить комментарий

Капча загружается...