我有一台机器“A”，上面有一个本地 rsyslogd，还有一台远程收集器机器“B”，它在别处监听自己的 syslog 守护进程和日志处理引擎。一切运行良好……除了 A 上有一个在 local0.notice 上记录日志的进程，这是 B 的引擎无法处理的。
我想要做的是在事件发送到 B 之前将 local0.notice 重写为 local5.info。不幸的是，我无法更改 B，也无法更改该进程在 A 上记录日志的方式。我也无法将 A 上的 rsyslogd 从 v7.6 升级到 v8（它似乎有一些非常有用的功能，比如 mmexternal，可能会有所帮助）。
我想我肯定忽略了一些显而易见的东西，我不可能是第一个需要这种功能的人。基本上，这归结为找到某种方法，通过中间的过滤器两次传递 rsyslog：一次作为进程日志，通过过滤器更改优先级，然后再次转发它。
我尝试过的：
- 配置 rsyslog 以将 local0.notice 记录到文件中，然后使用 imfile 指令读取该文件，该指令标记该文件并设置新的 fac/sev，然后使用 if 语句查找标记并调用 omfwd 操作。我想我也许可以说服 rsyslog 以正确的优先级写入文件，然后让 rsyslog 回来并自然地拾取它。遗憾的是，没有成功。
- 加载一个 omprog 模块，如果 syslogfacility-text == 'local0'，则调用 logger -p local5.info，并在那里停止处理...然后让另一个配置元素检查 syslogfacility-text == 'local5'，如果是，则调用 omfwd 操作。奇怪的是，这有效，但不会压缩原始消息，现在我只得到两组转发到 B 的日志，一组是 local0，一组是 local5。
有没有什么解决方案？
答案1
这更像是一种黑客手段而不是解决方案，但我无法找到任何“干净”的方法来解决您的问题：
local0.notice 消息的 UDP 数据包有效负载始终以 <133> 值（根据 rfc3164，为 16*8 + 5）开头，而 local5.info 映射到 <174>（21*8 + 6）。
您可以在 A 上使用 nfqueue+scapy 来在线路上发送数据包时重写所有出现的 <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
答案2
在使用 syslog-ng 后，我相信您可以将其用作“主机 A”上的主要 syslog 守护程序，并将处理后的消息转发到“主机 B”，从而实现您的目标。但是，由于您需要重写“硬编码”消息标志，因此您需要禁用 syslog-ng 自己的字段解析，以便您可以将正则表达式应用于原始 syslog（协议）消息。
你会发现 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.conf 中设置以下选项来禁用 Syslog-NG 自己的 syslog 消息解析并处理原始数据：
flags(no-parse)
这可能会导致问题。例如，您将不再收到多行 syslog 消息作为“一条消息”，因为 syslog-ng 需要解析该消息才能理解它是一条消息。