Linux 日志好用的关键是快速定位、机器可解析、权限分明、分级可控；需按业务语义重定义 CRITICAL/ALERT/NOTICE/TRACE 四级，每条日志强制含 ts、level、svc、rid、msg 五字段 JSON 结构，并前置脱敏敏感信息。
Linux 日志要真正好用，关键不在“记下来”，而在“能快速定位、可机器解析、权限分明、分级可控”。日志不是堆砌信息，而是结构化表达系统行为的语言。下面从分级设计和结构化落地两个核心维度，给出可直接上手的实践方案。
日志级别必须对齐业务语义，而非仅靠 DEBUG/INFO/WARN/ERROR
默认的 syslog 级别（emerg ~ debug）太笼统，容易导致误判或漏报。应结合服务角色重新定义含义：
- CRITICAL：进程崩溃、磁盘满、证书过期、核心连接池耗尽——需立即人工介入
- ALERT：主备切换触发、API 成功率突降超 10%、认证密钥轮换失败——需自动告警 + 人工核查
- NOTICE：服务启动完成、配置热加载成功、定时任务开始执行——记录状态变更，不告警
- TRACE：仅在调试环境启用，标记函数入口 / 出口、SQL 参数占位符替换后值（脱敏）、HTTP header 摘要
避免在生产环境混用 INFO 打调试信息，也禁止用 ERROR 掩盖配置错误（如 env 变量缺失应归为 ALERT，而非 ERROR）。
每条日志必须含 5 个强制字段，且顺序固定
结构化不是选配，是解析前提。推荐使用 JSON 格式写入，字段顺序统一为：
- ts：ISO8601 格式时间戳（如“2024-05-22T14:23:18.123Z”），不依赖本地时区
- level：大写英文（CRITICAL/ALERT/NOTICE/TRACE），与上文分级一致
- svc：服务名（如“auth-api”），小写短横线分隔，不含版本号
- rid：请求 ID（如“req-8a3f9b2d”），跨服务调用必须透传，无则填“-”
- msg：纯文本描述，不含结构化键值，不拼接变量（变量全放 “data” 对象里）
示例（一行完整日志）：
{“ts”:”2024-05-22T14:23:18.123Z”,”level”:”ALERT”,”svc”:”auth-api”,”rid”:”req-8a3f9b2d”,”msg”:”token refresh failed after 3 retries”,”data”:{“user_id”:”u-7721″,”error_code”:”E_TOKEN_EXPIRED”,”retry_count”:3}}
用 rsyslog + jq 或 systemd-journald 做实时结构化 路由
不建议应用层直接写文件——易丢日志、难限速、权限混乱。推荐两种轻量方案：
- rsyslog + template + action：在 /etc/rsyslog.d/50-app-struct.conf 中定义模板，将含 “svc”:”auth-api” 的日志转写到 /var/log/auth-api.json，并用imfile 模块监控该路径供 ELK 采集
- systemd-journald + structured logging：应用用 sd_journal_print() 或标准输出 JSON，journald 自动识别 PRIORITY 和SYSLOG_IDENTIFIER；通过 journalctl -o json 导出，再用 jq 过滤：journalctl SYSLOG_IDENTIFIER=auth-api -o json | jq ‘select(.level==”ALERT”)’
禁用 /var/log/messages 混写多服务日志，避免 grep 大海捞针。
敏感字段必须在写入前脱敏，不依赖下游过滤
密码、手机号、身份证号、token 等，不能指望 ELK 或 SIEM 事后过滤——日志文件本身已是风险载体。应在应用写日志前完成脱敏：
- 手机号：138****1234（保留前 3 后 4，中间 4 星）
- JWT token：“eyJhb…[TRUNCATED:SHA256]”（截断 + 哈希摘要，不存原文）
- SQL 语句：“UPDATE users SET email = ? WHERE id = ?”（参数全部替换为?）
- HTTP body：{“name”:”John”,”card_number”:”[REDACTED]”}（白名单字段才保留，其余一律掩码）
脱敏逻辑必须内置在日志 SDK 中，不可由业务代码临时拼接。上线前用含 敏感数据 的测试用例验证脱敏覆盖率。
