facility 与 severity 两个维度
syslog 规则由「设施.级别」组成，设施回答「谁产生的」，级别回答「多严重」。设施把日志按来源分类（内核、邮件、认证、计划任务、自定义应用等），级别是 0 到 7 的数字，数字越小越严重。规则中的级别表示「该级别及以上」：写 err 会同时匹配 emerg、alert、crit、err 四个级别。理解这两个维度，才能把日志分流到正确的文件、正确的主机，以及正确的留存策略上。
facility 与规则速查
facility 与规则速查
kern(0) 内核 user(1) 用户级 mail(2) 邮件 daemon(3) 守护进程
auth(4) 认证 syslog(5) 内部消息 lpr(6) 打印 news(7) 新闻
uucp(8) 串口 cron(9) 计划任务 authpriv(10) 敏感认证 ftp(11) 文件传输
local0-local7(16-23) 自定义应用（推荐业务日志使用）
severity：emerg(0) alert(1) crit(2) err(3) warning(4) notice(5) info(6) debug(7)
规则格式：facility.severity action
示例：authpriv.* /var/log/secure
cron.* /var/log/cron
local3.info /var/log/app/order.log
*.info;mail.none;authpriv.none /var/log/messages
*.* @@10.0.0.9:514 # @@ 走 TCP，@ 走 UDP关键设施与去向导引
| 设施 | 典型来源 | 处理建议 |
|---|---|---|
| authpriv | 登录、sudo、su 等认证事件 | 单独文件留存，设置更长的保留期，作为安全审计来源 |
| kern | 内核与防火墙（如 iptables 记录） | 与系统消息分开，便于排查网络与驱动问题 |
| cron | 计划任务执行结果 | 排查定时任务失败的第一落点 |
| local0-7 | 自研应用与中间件 | 业务日志优先占位，按业务域划分不同 local 号 |
| daemon | 多数系统服务的默认设施 | 消息混杂，接入集中平台前先确认应用是否可指定设施 |
改完配置的验证动作
改完配置的验证动作
logger -p local3.info -t order-app "分流测试" # 按规则发一条测试日志
tail -n 3 /var/log/app/order.log # 确认落到了目标文件
rsyslogd -N1 # 语法检查（重新加载前必做）
systemctl restart rsyslog # 重载配置使规则生效分流不生效时怎么查
- 规则顺序：rsyslog 自上而下匹配，先命中的规则先落盘；同一设施被多条规则匹配时可能写入两个文件
- 确认应用真的用了指定设施：先用 logger -p local3.info 打测试日志，排除应用自己写死了别的设施
- 检查包含顺序：/etc/rsyslog.d/ 下的片段按文件名排序加载，编号前缀写错会导致规则被后面的配置覆盖
- 核对日志文件权限与目录属主：属主或权限不对时写入静默失败，只在系统日志里留一条报错
- 系统走 journald 时：rsyslog 通过 imjournal 从日志库读取，journald 的速率限制会丢消息，突发量大的应用需调整 /etc/systemd/journald.conf 中的限制参数
系统带 systemd 时日志有两个入口：rsyslog 直接接收应用写入，以及从 journald 读取。排查「日志缺失」先确认消息到底没产生、被速率限制丢弃，还是写进了另一个文件。
业务应用接入标准 syslog 设施（推荐 local0-7）后，集中平台无需为每个应用单独开发采集器；同时应约定消息格式（时间戳带时区、含主机名与进程名），否则跨主机检索时排序会错乱。
远程转发注意两点：UDP 转发在拥塞时会丢包，安全审计类日志建议用 TCP（@@）；转发到集中平台后仍应保留本地副本，否则采集链路中断会造成日志缺口。