日志格式与字段规范
做日志分析，第一道坎是什么？
不是告警规则怎么写，也不是监控平台怎么搭。
而是——日志本身。
我见过太多团队，工具买了一大堆，结果日志格式五花八门，连时间戳都统一不了。分析根本没法往下做。说白了，日志格式是分析的起点，也是告警的基石。
这一章，我们就来把这块基石打牢。
标准字段三件套：时间戳、级别、消息体
「核心字段」看起来简单，但坑特别多。我先把三件套列出来：
| 字段 | 作用 | 常见坑 |
|---|---|---|
| 时间戳 | 记录事件发生的精确时刻 | 精度不足、时区混乱、格式不统一 |
| 日志级别 | 标识事件严重程度（INFO/WARN/ERROR） | 级别滥用、自定义级别无标准 |
| 消息体 | 事件的具体描述 | 信息不完整、包含敏感数据、过长 |
时间戳：第一道坑
我个人的习惯是，一律用Unix时间戳（毫秒级）存到日志里。为什么？因为它不带时区歧义。
举个例子：
我曾经踩过一个坑：
有一次做跨机房链路分析，A机房用"2024-03-15 14:23:10"，B机房用"2024-03-15T14:23:10+08:00"。两条日志时间差恰好8小时，排查了一下午才发现是时区问题。
所以，建议统一成这种格式：
2024-03-15T06:23:10.456Z // ISO 8601 + 毫秒 + UTC
或者
1710483790456 // 毫秒级Unix时间戳如果你用了机器可读的格式，那后续的时序分析、聚合查询会顺手很多。嗯，这里要注意，文本格式一定要固定，不要今天用"yyyy-MM-dd"，明天用"dd/MM/yyyy"。
日志级别：别乱用
级别是告警的第一触发信号。我的经验是，团队内部必须有个级别定义表：
| 级别 | 含义 | 触发场景 |
|---|---|---|
| FATAL | 系统不可用，必须立即介入 | 数据库连接池耗尽、关键节点崩溃 |
| ERROR | 功能异常，需人工处理 | 消息发送失败、MQ连接断开 |
| WARN | 非正常状态，但系统可自愈 | 重试超过3次、响应时间超阈值 |
| INFO | 常规操作记录 | 消息发送成功、通道建连完成 |
| DEBUG | 调试用，生产环境禁止高频输出 | 某变量的值、某分支的走向 |
我记得有一次，研发同学把所有异常都打成了INFO，理由是"ERROR太难看"。结果告警根本触达不到。你想想看，日志级别如果自己骗自己，那分析就是瞎子摸象。
消息体：结构化才是王道
消息体是最容易「放飞自我」的字段。有些人写长句子，有些人只写一个"成功"。这都不行。
我推荐采用键值对格式：
[IM通道] 消息发送失败 | channel=wechat | msgId=abc123 |
errorCode=40005 | retryCount=2 | duration=1203ms这样写的好处很明显：
- 后续解析时直接按key提取
- 相同维度的值可以做聚合（比如统计"errorCode=40005"出现了多少次）
- 方便做搜索和过滤
自定义字段归纳总结
标准字段之外，每个团队都会有业务自定义字段。我见过最乱的日志，一条日志里塞了30多个不重复的键。
怎么治？我的做法是：归类。
| 类别 | 字段举例 | 说明 |
|---|---|---|
| 标识类 | msgId, sessionId, traceId | 用于链路追踪和去重 |
| 性能类 | duration, memoryUsage, qps | 系统健康度监控 |
| 错误类 | errorCode, errorMsg, stackTrace | 故障定位 |
| 业务类 | channel, targetUser, msgType | 业务维度分析 |
我个人的经验是，一个通道日志的自定义字段不要超过10个。超过了，说明日志这层做过度了，该另建事件表。
字段规范最佳实践
最后，我给一个贴在我工位上的清单：
- 时间戳用UTC+毫秒，不要用本地时间
- 日志级别严格遵守定义，别混用
- 消息体必须包含「发生了什么事 + 关键上下文」
- 自定义字段统一命名风格（我习惯用 camelCase）
- 敏感信息（手机号、密码）用掩码处理，不要明文
- 每条日志控制在一行内，不要有换行（不然解析时头大）
核心观点：
日志是分析的血肉，字段是骨架。骨架歪了，肉再多也立不起来。
好，字段规范就讲到这里。标准字段打好底，自定义字段归纳好，你这套日志体系的根基就算稳了。