☰

Rsyslog 通过 TCP 发送时丢失消息

tag-icon • tag-icon rsyslog tcp-ip
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 上运行的系统日志服务器（收集器）？

相关内容