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"对象里）
示例（一行完整日志）：
jm-jsjkxyjs02-zlm-405
下载
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
用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中，不可由业务代码临时拼接。上线前用含敏感数据的测试用例验证脱敏覆盖率。
