journald与syslog、rsyslog的区别、优缺点及选型咨询

1. journald与syslog基础说明 #

syslog #

syslog是类Unix系统中发展超过30年的经典日志规范，同时也指代实现该规范的日志服务程序，核心分为客户端和服务端两个角色：客户端负责产生并发送日志，服务端负责接收、过滤、存储或转发日志。标准定义了日志的设备类型（facility）和日志等级（level），方便不同服务的日志分类处理，默认存储为明文格式，通常存放在/var/log/目录下，常见的日志文件包括/var/log/messages（系统通用日志）、/var/log/auth.log（鉴权相关日志）等。目前主流的syslog实现版本为rsyslog、syslog-ng，比传统的syslogd功能更丰富。

journald #

journald是systemd生态内置的日志管理服务，和systemd深度绑定，目前所有预装systemd的主流Linux发行版（CentOS 7+/Ubuntu 16.04+/Debian 9+等）都默认启用journald。它采用二进制格式存储日志，默认临时存储在/run/log/journal（重启后清空），开启持久化配置后会存储到/var/log/journal。journald默认自动采集所有systemd管理服务的标准输出、标准错误，以及内核日志、syslog协议日志，自带PID、服务名、UID、时间戳等结构化元数据，无需解析即可直接过滤查询。

2. journald与rsyslog核心差异、优劣势及选型建议 #

核心差异点 #

• 存储格式：journald是二进制存储，rsyslog默认明文存储，也支持自定义输出JSON等结构化格式
• 依赖绑定：journald强依赖systemd生态，非systemd发行版（如Alpine、自定义配置的Gentoo）无法使用；rsyslog无系统依赖，全类Unix系统均可部署
• 采集范围：journald开箱自动采集systemd全量服务日志，无需额外配置；rsyslog默认仅接收syslog协议日志，要采集服务标准输出、文件日志需要额外配置规则
• 查询方式：journald必须使用专属命令journalctl查询日志；rsyslog存储的明文日志可直接用cat/grep/awk等常规文本工具查询

各自优劣势 #

journald优势

• 零配置开箱即用，无需修改服务启动脚本即可完成全量systemd服务日志采集
• 自带结构化元数据，支持按服务名、PID、时间范围、日志等级快速过滤，无需自行解析文本日志
• 日志默认压缩存储，相同日志量占用磁盘空间远小于明文存储
• 自带日志自动轮转，不需要额外搭配logrotate等工具配置规则
• 支持日志落盘加密，安全性更高

journald劣势

• 二进制格式一旦文件损坏，全量日志不可读，可靠性低于明文日志
• 强绑定systemd，兼容性差
• 原生转发能力弱，不支持直接转发到数据库、消息队列、第三方日志平台，需要额外配置适配工具
• 大流量日志场景下读写性能远低于rsyslog

rsyslog优势

• 高性能，支持每秒数万条日志的接收、处理、转发，可支撑企业级大流量日志场景
• 生态成熟，内置丰富的过滤、转换、输出规则，支持把日志投递到文件、数据库、消息队列、远端日志中心等多种目的地
• 明文存储兼容性好，即使日志文件部分损坏，剩余内容仍然可读，故障排查不需要依赖专属工具
• 全平台兼容，无systemd绑定限制

rsyslog劣势

• 配置门槛高，不同来源的日志需要编写对应的采集、处理规则，新手容易配置出错
• 默认syslog格式没有结构化元数据，要提取字段需要自行编写正则解析规则
• 默认需要搭配logrotate实现日志轮转，额外增加配置成本
• 无内置压缩，相同日志量占用磁盘空间更大

选型建议 #

• 个人桌面、单节点小型服务器、日常调试场景：优先选journald，无需额外配置，查询服务日志便利，不需要手动检索/var/log下的多个日志文件
• 中大型集群、需要集中化日志管理、日志量较大的生产环境：优先选rsyslog，也可以用journald作为本地采集端，把日志转发给rsyslog做后续处理和转发，兼顾采集便利性和转发性能
• 非systemd操作系统：直接选用rsyslog，无journald使用条件
• 对日志安全性要求高、需要加密存储的场景：优先选journald的持久化加密存储方案

内容的提问来源于stack exchange，提问作者M_Zakaria