首先得说，遇到这种“本地日志正常，但转发突然挂了，重启rsyslog没用只有重启服务才好”的问题确实挺挠头的，结合你描述的场景（自动apt更新触发、systemd服务配置了syslog参数、rsyslog转发规则正常），我来帮你拆解可能的原因和排查方向：

核心现象复盘 #

• 集中式syslog收不到app服务器的日志，但每个app服务器本地的/var/log/syslog里能看到完整日志
• 重启rsyslog服务完全没效果，只有逐个重启systemd应用服务后，日志才恢复转发
• 事发时间点刚好和自动apt-get update/upgrade重合

可能的原因分析 #

1. systemd服务与rsyslog的socket连接失效

当你的systemd应用服务启动时，会主动打开本地的syslog socket（比如/dev/log）来发送日志。如果apt更新过程中重启了rsyslog或者systemd-journald，这个已建立的socket连接会被强制断开，但运行中的systemd服务不会主动重新建立连接。

这时候会出现一种矛盾的现象：systemd会把服务的日志写入自身的journald（最终同步到本地syslog），但因为socket连接失效，这些日志无法传递给rsyslog的转发模块。而重启应用服务后，systemd会重新初始化日志发送通道，建立新的socket连接，rsyslog就能正常接收并转发了。

2. rsyslog队列损坏或转发线程卡住

你配置了queue.saveonshutdown="on"，如果apt更新时rsyslog被强制杀死（而非正常关闭），可能导致磁盘上保存的队列文件损坏。重启rsyslog时，它加载了损坏的队列数据，导致转发线程卡死，无法处理新的日志条目。

不过这种情况通常重启rsyslog会重新初始化队列，所以可能性稍低，但可以排查：重启服务后产生的新日志没有进入损坏的旧队列，而是使用了新的队列空间，因此能正常转发。

3. systemd/rsyslog更新后的兼容性bug

apt更新可能升级了systemd或rsyslog包，导致两者之间的日志传输逻辑出现临时兼容性问题。比如：

• systemd对SyslogFacility/SyslogIdentifier的处理方式改变，导致日志的facility标记错误，rsyslog的local0.*转发规则无法匹配
• rsyslog的omfwd模块更新后，对来自systemd的日志元数据处理异常，导致转发逻辑不触发

重启应用服务后，systemd重新生成正确的日志元数据，rsyslog就能正常识别并转发了。

4. rsyslog转发模块的连接缓存失效

如果apt更新了rsyslog的omfwd模块，可能存在连接缓存的bug：rsyslog认为已经和集中式服务器保持连接，但实际连接早已断开，且重试机制没有触发。这时候rsyslog不会尝试发送任何日志，直到有新的日志流（重启服务后的新日志）触发模块重新初始化连接。

下一步排查建议 #

1. 查apt更新记录：查看/var/log/apt/history.log，确认事发时更新了哪些包（重点看systemd、rsyslog、libsystemd相关组件），这能直接缩小问题范围。
2. 检查rsyslog自身日志：查看/var/log/syslog或/var/log/rsyslog.log（如果启用的话），找重启rsyslog时的错误信息，比如队列加载失败、omfwd模块初始化报错等。
3. 手动测试日志转发：在app服务器上执行logger -p local0.info "test forward message"，看这条测试日志能不能传到集中式syslog。如果可以，说明rsyslog转发规则正常，问题出在systemd服务的日志通道上；如果不行，就是rsyslog本身的转发逻辑有问题。
4. 验证systemd日志元数据：用journalctl -u <你的应用服务名> -o verbose查看日志的详细元数据，确认SYSLOG_FACILITY是否为local0，SYSLOG_IDENTIFIER是否和服务配置一致。
5. 检查rsyslog队列文件：如果配置了队列保存，队列文件默认在/var/spool/rsyslog/下，检查文件大小、权限是否正常，有没有损坏迹象（比如文件为空或者大小异常）。

临时缓解方案 #

如果后续还出现类似问题，可以考虑在apt自动更新后，添加脚本重启所有相关的systemd应用服务，或者给应用服务的systemd配置添加PartOf=rsyslog.service，这样rsyslog重启时会自动重启这些服务，避免手动操作。

备注：内容来源于stack exchange，提问作者edmz