Rsyslog 通过 TCP 发送时丢失消息

Rsyslog 通过 TCP 发送时丢失消息

我试图在 Windows 平台上构建一个自定义 Syslog 服务器,首先,我正在实现一个基本的 TCP 侦听器(服务器)。我遇到了问题,并在 StackOverflow 上提出了这个问题:问题

后来,我意识到即使我在两台独立的 Linux 机器上使用两个 Rsyslog,问题仍然存在。

这是客户端计算机上的 rsyslog.conf:

local3.*    @@192.168.1.199:514

这是服务器上的 rsyslog.conf:

local3.*    /var/log/test.log

这是发送日志消息的脚本(在客户端上):

#!/bin/dash

for i in 1 2 3 4 5 6 7 8 9 10
do
logger -i -t Test -p local3.debug "This is test $i"
done

这是服务器收到的输出文件(test.log):

2016-08-02T00:10:33-07:00 ubuntu Test[37023]: This is test 2
2016-08-02T00:10:33-07:00 ubuntu Test[37024]: This is test 3
2016-08-02T00:10:33-07:00 ubuntu Test[37025]: This is test 4
2016-08-02T00:10:33-07:00 ubuntu Test[37026]: This is test 5
2016-08-02T00:10:33-07:00 ubuntu Test[37027]: This is test 6
2016-08-02T00:10:33-07:00 ubuntu Test[37028]: This is test 7
2016-08-02T00:10:33-07:00 ubuntu Test[37029]: This is test 8
2016-08-02T00:10:33-07:00 ubuntu Test[37030]: This is test 9
2016-08-02T00:10:33-07:00 ubuntu Test[37031]: This is test 10

显然,第一条消息This is test 1是触发 TCP 连接的消息,并且已被丢弃。

我可以设置 rsyslog 上的任何设置来防止这种情况发生吗?

编辑:

我想指出的是,这种情况仅在连接已经建立时才会发生;如果我在第一次运行脚本后立即第二次运行该脚本,则第二次脚本运行将生成This is test 1

我也很高兴这个问题得到了赞成票,但我觉得很奇怪,没有多少人注意到这个问题,并试图解决这个问题。记录日志的人通常都是认真了解他们的系统哪里出了问题的人,但他们却认为只要正确设置配置,一切都会正常运作?我想尝试更多的东西,但我对 Unix 系统真的很陌生,所以我不知道如何解决这个问题。

更新:

我做了进一步的测试。看来我的做法并不完全正确。似乎只有当我systemctl restart rsyslog在服务器(接收)机器上这样做时才会发生这种情况,但在客户端机器上也是如此。

我的猜测是,客户端认为它仍然处于连接状态(而服务器端则不是),并尝试发送下一条消息。这是当客户端意识到连接已断开时,并尝试重新建立新连接的情况。

奇怪的是,我不知道为什么客户端会认为丢失的消息已被送达。

我知道有 RELP,但最终我会在 Windows 平台上使用中央系统日志服务器。我该如何使用 TCP 来避免这个问题,或者获取(或构建)一个在支持 RELP 的 Windows 上运行的系统日志服务器(收集器)?

相关内容