syslog 是日志协议标准，rsyslogd 是其高性能实现，rsyslog.service 是 systemd 管理单元；二者在架构、功能和配置上存在本质差异，需分层理解与验证。
如果您在排查 Linux 系统问题时发现日志行为异常、日志缺失或配置不生效，则可能是由于对 syslog 协议与 rsyslog 实现之间的关系理解不清所致。以下是深入解析二者本质 区别 的步骤：
一、厘清概念层级：协议、实现与服务
syslog 本身不是某个具体程序，而是一套定义日志格式、设施（facility）和优先级（priority）的 标准协议；rsyslogd 是该协议的一个高性能、模块化实现程序；rsyslog.service 则是 systemd 用于管理 rsyslogd 进程的控制单元。混淆这三层会导致配置错误或服务启停失效。
1、运行 ps aux | grep rsyslog 可确认 rsyslogd 进程是否正在运行。
2、执行 systemctl status rsyslog.service 可验证服务单元状态及其依赖关系。
3、查看 man 3 syslog 可了解应用程序调用 syslog()函数写入日志的标准接口规范。
二、对比核心差异：功能与架构演进
rsyslog 并非简单替代 syslog，而是对其能力边界进行实质性扩展。原始 syslog 守护进程（如 syslogd+klogd 组合）采用单线程、UDP 为主、无持久队列的设计；rsyslog 则引入 多线程处理、磁盘 / 内存混合队列、RELP 可靠传输、TLS 加密通道 等机制，显著提升吞吐量与可靠性。
1、检查当前系统使用的日志守护进程：ls -l /usr/sbin/{syslogd,rsyslogd}，若 rsyslogd 存在且被启用，则 syslogd 通常未被使用。
2、运行 rsyslogd -v 输出版本信息，确认是否启用 imtcp、ommysql 等模块支持。
3、比对 /etc/syslog.conf 与/etc/rsyslog.conf是否存在共存——若 rsyslog 已启用，前者将被忽略。
三、定位日志流向：从内核到文件的完整路径
Linux 日志并非直接由应用程序写入 /var/log 下的文件，而是经由 syslog API → rsyslogd 接收 → 规则匹配 → 输出目标的链路。理解该路径有助于诊断日志丢失或错位问题。例如，kern.* 规则未启用时，dmesg 内容不会落盘至 /var/log/kern.log。
1、确认 rsyslog 是否加载内核日志模块：grep -i "modload.*imklog" /etc/rsyslog.conf。
2、检查规则文件中是否包含 kern.* /var/log/kern.log 或类似语句。
3、手动触发内核日志：dmesg -n 8 && echo "test kernel log" > /dev/kmsg，随后观察 /var/log/kern.log 是否新增条目。
四、验证配置生效：语法检查与重载机制
rsyslog 配置错误不会导致服务启动失败，但会使部分规则静默失效。必须通过语法校验与强制重载双重手段确保变更落地。配置中任意一行语法错误（如缺少空格、误用 $ 符号）都可能导致后续规则跳过。
1、执行 rsyslogd -N1 进行一次配置语法检查，返回 0 表示无误。
2、修改配置后，必须运行 sudo systemctl reload rsyslog.service 而非 restart，以避免中断日志接收。
3、检查 rsyslog 启动日志：journalctl -u rsyslog.service --since "1 minute ago"，确认无 error 或warning提示。
五、区分典型日志文件归属来源
/var/log/ 目录下各文件并非均由同一机制生成，需依据其内容特征反推来源。例如 /var/log/secure 由 authpriv facility 规则写入，而 /var/log/btmp 由系统底层直接 编码 写入，rsyslog 无法控制 btmp 的生成与格式，仅能记录其访问事件。
1、使用 logger -p authpriv.info "test auth log" 测试是否写入 /var/log/secure。
2、运行 lastb 读取 /var/log/btmp，确认其内容为二进制编码且无法被 rsyslog 规则匹配。
3、比对 tail -n 5 /var/log/messages 与journalctl -n 5，识别 systemd-journald 与 rsyslog 并存时的日志分流逻辑。
