关键在于建立可落地的facility与severity分类基线：内核日志映射kern，业务服务用local1，认证操作用auth/authpriv，网络设备日志归local2；severity按后果定义，如emerg/crit对应服务中断，err对应单次失败，warning为持续异常；各平台需针对性配置确保执行。
要让全网异构服务器（如Tina Linux嵌入式设备、CentOS服务器、交换机等）的日志在统一平台可比、可筛、可分析，关键不是“统一所有日志内容”，而是建立一套可落地的Facility与Severity分类基线——即明确哪些模块归哪类设施、什么情况打什么级别，且各平台能按此映射执行。
统一Facility映射规则：避免local7滥用，按语义归类
不同系统对facility支持程度不同（如Tina Linux常用kern/daemon/auth，交换机默认用local4~local7），但可通过配置强制收敛：
-
内核及驱动层日志：全部映射到
kern—— 包括Tina平台dmesg输出、交换机硬件告警、ARM SoC温度异常等 -
业务服务进程日志：统一使用
local1—— 例如自研IPC服务、视频转码模块、OTA升级守护进程，不再混用daemon或local7 -
用户认证与权限操作：严格限定为
auth或authpriv—— SSH登录、Web后台鉴权、sudo命令均走此路径，禁用user或daemon替代 -
网络设备侧日志：交换机/路由器需显式配置facility值（如华为用
info-center source default facility local2），将其BGP/ACL/端口up-down事件归入local2，便于与服务器网络服务（如iptables日志）对齐
Severity分级必须绑定行为，而非主观描述
“warning”“error”不能由开发随意填写，应按触发后果定义：
- emerg / alert / crit：服务已中断或即将不可用 —— 如NTP失步超5分钟、磁盘剩余空间＜3%、主备切换失败
- err：单次功能失败但服务仍在线 —— 如某次HTTP请求返回500、一次CAN总线校验错误、数据库连接超时
- warning：异常状态持续存在但未影响主流程 —— 如CPU温度＞85℃、SSL证书剩余有效期＜7天、某传感器读数连续3次超阈值
- notice / info：仅用于关键状态变更记录 —— 如服务启动完成、配置热加载成功、固件版本升级完毕；禁止用info打循环日志
-
debug：仅测试环境开启，生产环境syslogd配置中直接屏蔽
*.debug，防止刷屏
跨平台配置落地要点
不同系统需针对性适配，确保基线不被绕过：
-
Tina Linux（busybox syslogd）：修改
/etc/syslog.conf，用local1.* -/var/log/app.log接收业务日志，并在应用启动脚本中用logger -p local1.info -t "myapp"打点 -
CentOS/Ubuntu（rsyslogd）：在
/etc/rsyslog.d/10-baseline.conf中定义模板，将local1日志写入独立文件并添加HOSTNAME字段，便于溯源 -
网络设备（华为/H3C/思科）：关闭默认local7泛发，用
info-center source VTY facility local3将CLI操作日志定向至local3，再通过info-center loghost发往中心syslog服务器 -
日志接收端（rsyslog server）：配置
$RuleSet remote绑定UDP 514端口，对不同facility设置不同队列和磁盘缓冲，防止高并发丢包
验证与守门机制
基线生效后需持续校验：
- 用
tcpdump -i any port 514 -A -c 20抓包，检查PRI值是否符合facility×8+severity公式（如local1.info = 1×8+6 = 14 → ） - 定期扫描
/var/log/messages和远程接收目录，统计各facility占比，发现local7或user突增即触发整改 - CI/CD流水线中加入日志规范检查脚本：解析应用源码中的
logger或syslog()调用，拒绝LOG_USER、LOG_DEBUG等非基线参数合入
