这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
日志解析
采集到日志之后，下一步是让日志变得可理解。原始日志往往是这样的：
2026-03-31 02:14:08 ERROR pay callback failed order=882317 cost=2300ms err=timeout人能读懂，但系统很难稳定地统计和关联。日志解析的目标是把它变成结构化事件：
配置要点
- 配置表达的是环境差异和运行参数，不是业务规则本身。
统一字段
结构化日志最重要的是统一字段，否则每个团队各写各的，平台无法聚合。基础字段通常包括：
| 字段 | 含义 |
|---|---|
| time | 事件发生时间 |
| service | 服务名 |
| instance | 实例或容器 ID |
| env | prod、staging 等环境 |
| level | 日志级别 |
| trace_id | 请求链路 ID |
| message | 原始消息 |
业务字段可以扩展，但要遵循命名规范，例如 order_id、user_id、tenant_id。
解析位置
日志解析有三种位置：
- 应用内结构化输出：应用直接输出 JSON，最准确，但需要业务改造。
- Agent 侧解析：靠正则或解析规则处理文本，灵活但容易受格式变化影响。
- 服务端解析：集中处理，便于统一升级，但会增加后端计算压力。
生产系统通常组合使用：核心服务尽量输出结构化 JSON，历史服务先用解析规则兼容。
时间与乱序
日志系统必须区分两个时间：
- 事件时间：日志在业务中发生的时间。
- 采集时间：日志进入平台的时间。
排障和指标计算通常应该使用事件时间，否则网络延迟或 Agent 积压会让时间线错乱。但事件时间也可能受机器时钟影响，所以平台需要记录采集时间，用于判断延迟和异常。
脱敏与过滤
解析阶段也是治理阶段。日志里可能包含手机号、邮箱、身份证、token、请求体等敏感信息。平台应该提供脱敏规则：
- token、密钥、密码直接替换。
- 手机号、邮箱保留部分字符。
- 超长字段截断，避免单条日志撑爆索引。
- 明确禁止记录完整银行卡、身份证等高敏数据。
日志解析完成后，日志才真正变成可查询、可聚合、可关联的数据。下一步我们会从这些事件中提炼指标。