这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
统一字段与解析位置
统一字段
结构化日志最重要的是统一字段，否则每个团队各写各的，平台无法聚合。
统一字段
结构化日志是平台聚合的前提
| 字段 | 含义 | 示例 | 类型 |
|---|---|---|---|
time | 事件发生时间 | 2026-09-03T02:14:08.123Z | 基础 |
service | 服务名 | payment-service | 基础 |
instance | 实例或容器 ID | payment-7f3a2c | 基础 |
env | 环境 | prod | 基础 |
level | 日志级别 | ERROR | 基础 |
trace_id | 请求链路 ID | 4bf92f3577b34da6 | 基础 |
message | 原始消息 | pay callback failed | 基础 |
order_id | 业务订单号 | 882317 | 业务 |
user_id | 业务用户 | u_1024 | 业务 |
tenant_id | 租户 | t_42 | 业务 |
要点：
基础字段是平台能聚合的前提，业务字段遵循命名规范（如 order_id、user_id、tenant_id）。
否则每个团队各写各的，日志、指标、trace 就无法通过统一字段关联。
解析位置的三种选择
| 位置 | 优点 | 缺点 |
|---|---|---|
| 应用内结构化输出 | 最准确 | 需要业务改造 |
| Agent 侧解析 | 灵活 | 易受格式变化影响 |
| 服务端解析 | 集中处理，便于统一升级 | 增加后端计算压力 |
生产系统怎么选
生产系统通常组合使用：
- 核心服务尽量输出结构化 JSON。
- 历史服务先用解析规则兼容。
- 解析规则由服务端统一管理，便于升级。
组合思路：核心求准确，存量求兼容，规则集中管。
一句话
统一字段（time/service/instance/env/level/trace_id/message）是平台聚合的前提；解析位置按「核心结构化输出 + 存量正则兼容 + 服务端统一规则」组合。核心服务保准确，历史服务保接入。
发现内容有问题？
告诉我们哪里需要改进。