这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
基数控制与计算链路
高基数问题
指标系统最容易被高基数字段拖垮。例如把 user_id、order_id 放进指标标签，会产生海量时间序列，存储和查询成本迅速失控。
什么字段适合做标签
| 适合做标签（有限集合） | 不适合做标签（无限集合） |
|---|---|
| service | user_id |
| api | request_id |
| status_code | trace_id |
| env | order_id |
| region |
原则：适合做标签的是有限集合；高基数字段留在日志里搜索，不进入指标标签。
指标计算的两条路径
| 路径 | 优点 | 缺点 |
|---|---|---|
| 应用直接上报 | 延迟低、语义清晰 | 需要业务改造 |
| 从结构化日志聚合 | 改造成本低、可回溯 | 语义依赖日志质量 |
怎么演进
早期可以从日志聚合开始，后续把核心服务改造成直接埋点。
关键：两条路径并存时，要定义指标口径，避免同一个错误率在两个看板上不一致。
一句话
指标标签只用有限集合字段（service/api/status_code/env/region），高基数字段留在日志里；指标来源从日志聚合起步、核心服务逐步埋点。口径要统一，标签要克制。
发现内容有问题？
告诉我们哪里需要改进。