TLDR：我有一个集中式系统日志服务器，它突然停止接收来自应用服务器的系统日志消息。只有当我重新启动每个应用服务器上运行的每个单独的服务时，消息才会恢复。为什么？
每个应用服务器都有 N 个不同的应用程序，这些应用程序被定义为 systemd 服务。它们都记录到 STDOUT，其 ~.service~ 文件配置如下：
SyslogFacility=local0
SyslogIdentifier=app_name
在每个应用服务器上我都运行 rsyslog 并将其配置为转发到集中式 syslog 服务器：
local0.* action(type="omfwd"
queue.type="LinkedList"
action.resumeRetryCount="-1"
queue.size="10000"
queue.saveonshutdown="on"
target="syslog_server1" Port="514" Protocol="tcp")
这是可行的，并且到目前为止没有出现任何问题。
今天，在似乎是自动的 apt-get 更新之后（它是唯一与时间相吻合的事情），不再有消息记录到集中式系统日志服务器。
我tcpdump登录了 syslog 服务器，没有收到来自应用服务器的消息。消息是从不同的外部网络记录的，但不是来自同一 vpc 中的应用服务器。我怀疑是网络问题，但连接正常。我甚至暂时禁用了防火墙。
我现在在应用服务器中运行 tcpdump 来查看系统日志消息是否发送到端口 514，但没有消息。在应用服务器上重新启动 rsyslog 没有任何效果。
唯一能让信息再次流通的就是重启每个人这些应用服务器上的 systemd 服务。
值得注意的是，在这段时间内，消息都被记录到每个应用服务器的本地系统日志中，只是没有被转发到集中式系统日志服务器。
这让我很困惑：如果这些消息在本地系统日志中，就意味着系统日志在某个时候有这些消息，对吗？如果确实有，那么重新启动rsyslog可能会有一些效果。但重新启动rsyslog什么也没改变。
重启单个应用服务做过会产生影响。但是，systemd 如何工作，以至于 STDOUT 消息最终会出现，/var/log/syslog但不会被 rsyslog 转发？systemd 是否直接写入/var/log/syslog并同时写入 rsyslog 本身，这就是为什么需要重新启动？为什么需要重新启动？重新启动后释放/重置了什么？