更新 2：我已通过以下链接中的新问题回答了这个问题。根本原因是 telegraf 的行为，默认情况下，它会在收到最后一条消息 5 秒后断开 TCP 连接。这可能是设计使然，但我对他们的文档有疑问，这让我很难发现这是一个潜在的修复方法。
也许现在可以删除这个问题？
更新 1：我没有对这个问题进行大量编辑，使当前的答案变得毫无意义，而是根据发布此问题后收到的新信息提出了一个新问题。
syslog-ng / telegraf：空闲时发生 EOF - 不兼容？
我在 docker-compose 堆栈中使用 syslog-ng 开源版本 (OSE) v3.31.2。
我有来自不同主机通过 UDP 到达网络的 syslog 消息（我只能这样做，因为我的客户端使用 Boost::Log，而它不支持通过 TCP 的 syslog，只支持 UDP），并且我已将 syslog-ng 设置为将这些消息转发到下游的另一个服务。这恰好是 telegraf，它利用了inputs.syslog 模块，但我还不确定这是否重要。
我的配置如下：
@version: 3.29
@include "scl.conf"
options {
flush-lines(1);
};
source s_network {
udp(ip(0.0.0.0) port(514));
};
destination d_file {
file("/var/log/messages");
};
destination d_telegraf {
syslog("telegraf" port(6514) transport(tcp));
};
log {
source(s_network);
destination(d_telegraf);
destination(d_file);
};
我已明确将全局flush-lines值设置为 1。我认为这是默认值，但我想确定一下。我希望在收到日志消息后立即转发它们。
大多数情况下，这种方法都是有效的 - 日志的各个“行”通过 UDP 514 到达 syslog-ng，并立即写入文件/var/log/messages，而且在几乎所有情况下，它们也会立即转发到 TCP 端口 6514 上的 telegraf。
我发现的问题是，syslog-ng 经常会将多行传入日志保留长达 30-60 秒左右，然后将它们大量发送到 telegraf。这种情况似乎没有什么规律，但经常发生。奇怪的是，文件中/var/log/messages缺少的日志条目会立即写入，只是网络传输延迟了。我原以为这样flush-lines(1)可以避免这种缓冲，但似乎没有。
我已经使用 Wireshark 来确定延迟的位置，它位于 syslog-ng 的数据包输出中，位于 syslog-ng 和 telegraf TCP 端口 6514 之间。
我确实想知道这是否可能是 TCP Nagle 算法的问题 —— 如果是这样，有没有办法为 syslog-ng 的 syslog 目标驱动程序打开 TCP_NO_DELAY 套接字选项？
最终，我要寻找的是一种快速、低延迟的系统日志服务，它可以尽快聚合和传递日志以供下游实时审查。
编辑：我尝试在 syslog-ng 和遥测之间切换到 UDP 传输，这似乎响应更快，长时间的偶尔延迟也消失了。然而，这将使将来的连接保护变得困难。
答案1
您遇到的情况是不正常的。上述配置应该尽快将日志同时转发到d_telegraf和。d_file
我相信您遇到了连接问题，这一定是 60 秒延迟的原因，这是重新连接计时器的默认值。
您可以使用全局选项降低此值time-reopen()，例如：
options {
time-reopen(1);
};
您还可以在前台启动 syslog-ng（在调试模式下）来调查连接问题：
$ syslog-ng -Fdev
答案2
尝试使用 flush-lines(0) 将该行全部删除。