Средство перезаписи / серьезность в rsyslog v7 перед отправкой на удаленный коллектор
У меня есть машина "A" с локальным rsyslogd и машина удаленного сборщика "B", которая в другом месте прослушивает свой собственный демон syslog и механизм обработки журналов. Все это прекрасно работает... за исключением того, что есть один процесс на A, который регистрирует в local0.notice, который не может обработать двигатель B.
Что я хочу сделать, это переписать local0.notice в local5.info до отправки события в B. К сожалению, я не могу изменить B и не могу изменить способ, которым процесс выполняет вход в систему A. Также я не могу обновить rsyslogd на A от v7.6 до v8 (который, кажется, имеет некоторые очень полезные функции, такие как mmexternal, которые могли бы помочь).
Я думаю, что я, должно быть, упускаю что-то очевидное, я не могу быть первым человеком, который нуждается в такой функции. По сути, все сводится к тому, чтобы дважды найти путь прохождения через rsyslog с фильтром между ними: один раз, когда процесс регистрируется, через фильтр для изменения prio, а затем снова для его пересылки.
Что я пробовал:
- настройте rsyslog для записи local0.notice в файл, а затем прочитайте этот файл с помощью директивы imfile, которая помечает его и устанавливает новый fac/sev, за которым следует оператор if, который ищет тег и вызывает действие omfwd. Я подумал, что, возможно, смогу убедить rsyslog написать файл на нужном прио, а затем заставить rsyslog вернуться и, естественно, поднять его. К сожалению, нет кости.
- загрузка модуля omprog, который вызывает logger -p local5.info, если syslogfacility-text == 'local0', остановка обработки там... и затем наличие другого элемента конфигурации для проверки syslogfacility-text == 'local5' и, если это так, вызов omfwd действие. Странно, но это работает, но не подавляет исходные сообщения, теперь я просто получаю два набора журналов, которые перенаправляются в B, один local0 и один local5.
Есть ли какие-нибудь решения там?
2 ответа
Это скорее взлом, чем решение, но я не смог найти "чистого" способа решить вашу проблему:
Полезная нагрузка UDP-пакета для сообщений local0.notice всегда начинается со значения <133> (16*8 + 5 в соответствии с rfc3164), тогда как local5.info отображается на <174> (21*8 + 6).
Вы можете использовать nfqueue+scapy для A, чтобы перезаписать все вхождения от <133> до <174> при отправке пакетов по проводам, и B будет получать и регистрировать сообщения local5.info вместо local0.notice.
Все другие UDP-пакеты системного журнала не будут затронуты и будут зарегистрированы как обычно.
Простой пример: https://byt3bl33d3r.github.io/using-nfqueue-with-python-the-right-way.html
RFC: https://www.ietf.org/rfc/rfc3164.txt
Скрипт для табличных значений PRI: http://www.digitalprognosis.com/opensource/scripts/syslog-priorities.py
Работая с syslog-ng, я полагаю, что вы можете сделать то, что вы ищете, используя его в качестве основного демона syslog на "Хосте A", и перенаправить ваше манипулируемое сообщение на "Хост B". Однако, поскольку вам нужно переписать "жестко запрограммированные" флаги сообщений, вам необходимо отключить собственный синтаксический анализ поля syslog-ng, чтобы можно было применять регулярное выражение к необработанному сообщению syslog (protocol).
Вы обнаружите, что Syslog-NG имеет очень мощный подход к манипулированию сообщениями, в общем, читая https://www.balabit.com/documents/syslog-ng-ose-latest-guides/en/syslog-ng-ose-guide-admin/html/chapter-manipulating-messages.html
Прочитав это, вы увидите, что, к сожалению, вам, вероятно, потребуется отключить собственный синтаксический анализ сообщений syslog-NG и работать с необработанными данными, установив следующую опцию в syslog-ng.conf:
flags(no-parse)
Это может вызвать проблемы. Например, вы больше не будете получать многострочные сообщения системного журнала как "одно сообщение", потому что syslog-ng должен проанализировать сообщение, чтобы понять, что это одно сообщение.