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并存时的日志分流逻辑。
