精细化控制日志需结合设施（如LOG_LOCAL3标识订单服务）与严重性（如LOG_ERR表示错误），通过priority组合和setlogmask掩码（如LOG_UPTO(LOG_WARNING)）实现动态过滤，Java用syslog4j指定facility，rsyslog按facility-text和severity匹配路由。
要精细化控制日志输出层级，关键不是只看“级别数字”，而是理解设施（facility）和严重性（level）如何组合成 priority，并通过掩码机制实现动态过滤。设施决定“谁在说话”，严重性决定“话有多重”，两者结合才能准确定位日志来源与价值。
设施（Facility）：定义日志来源类别
设施标识日志的产生主体，是分类归档和路由的前提。它不表示紧急程度，而是告诉 syslog 守护进程“这条日志来自哪里”。常见设施值如下：
- LOG_USER（默认值，数值1）：通用用户级应用，如 Java 服务、自研后台程序
- LOG_DAEMON（数值3）：系统守护进程，如 nginx、redis、自建 agent
- LOG_AUTH（数值4）或 LOG_AUTHPRIV（数值10）：权限、登录、认证类操作
- LOG_LOCAL0 ~ LOG_LOCAL7（数值16–23）：专为业务系统预留，可自由绑定模块，例如 LOG_LOCAL3 用于订单服务，LOG_LOCAL5 用于风控引擎
- LOG_KERN（数值0）：仅内核可用，用户进程无法直接使用
选择设施时，优先用 LOG_LOCALx 避免与其他系统服务冲突；若无特殊需求，LOG_USER 是安全起点。
严重性（Level）：刻画事件紧急程度
严重性共 8 级，数值越小越紧急，是日志分级过滤的核心依据：
- LOG_EMERG（0）：服务完全不可用，如 JVM 崩溃、数据库连接池耗尽且无法恢复
- LOG_ALERT（1）：需人工介入的高危信号，如检测到高频异常登录或敏感配置被篡改
- LOG_CRIT（2）：关键路径失败，如支付回调超时+重试3次仍失败
- LOG_ERR（3）：可恢复错误，如第三方 API 返回 5xx、本地文件写入失败
- LOG_WARNING（4）：潜在风险提示，如线程池活跃线程达阈值 80%、SSL 证书剩余有效期＜30天
- LOG_NOTICE（5）：重要正常事件，如服务启动完成、配置热更新成功、定时任务触发
- LOG_INFO（6）：常规运行快照，如每分钟请求数、缓存命中率统计
- LOG_DEBUG（7）：仅限开发/排障，含请求 ID、SQL 参数、堆栈片段等细节
生产环境建议以 LOG_NOTICE 为底线，避免 INFO 及以下淹没有效告警；调试阶段可临时启用 LOG_DEBUG，但上线前必须关闭。
Priority 组合与掩码控制逻辑
priority = facility | level，例如 LOG_LOCAL3 | LOG_ERR 表示“订单服务发生的错误”，其整数值为 19（16+3）。这个组合值被 syslog 函数接收后，由守护进程按规则分发。
真正实现“精细化控制”的是 setlogmask() —— 它不决定“发什么”，而是决定“收什么”：
- LOG_UPTO(LOG_WARNING)：接收 0–4 级（emerg 到 warning），屏蔽 notice 及更轻消息
- LOG_MASK(LOG_ERR) | LOG_MASK(LOG_CRIT)：只收 err 和 crit，跳过 warning 及以下
- 不调用 setlogmask 时，默认接收全部级别（等价于 LOG_UPTO(LOG_DEBUG)）
注意：掩码作用于当前进程，多线程程序中应在主线程初始化后统一设置，避免子线程继承默认全量策略。
配置落地建议
在实际部署中，需软硬结合：
- Java 应用用 syslog4j 时，在 SyslogConfig 中显式指定 facility（如 SyslogConstants.FACILITY_LOCAL3），并映射 logback 的 level 到 syslog level
- Linux 侧 rsyslog 配置中，用 if $syslogfacility-text == 'local3' and $syslogseverity 实现按设施+级别分流
- 远程转发场景下，优先选用 TCP + TLS，避免 UDP 丢包导致关键错误日志缺失
- 定期审查 /etc/rsyslog.conf 中的 filter 规则，防止因 facility 拼写错误（如 local3 写成 local03）导致日志静默丢失
