指标系统最怕什么 很多团队一开始埋点很积极，过一阵就发现存储暴涨、查询变慢。高基数标签通常是罪魁祸首。 典型高危标签： user_id request_id 完整 URL 路径 动态错误信息 设计原则 指标看聚合趋势，不看单请求细节 单请求细节放到 trace 或日志 标签值集合必须可控 一个可行做法 http.route 用模板路由，如 /users/:id 错误类型归类为固定枚举 把业务自定义标签做白名单审核 工程措施 在 SDK 层做标签拦截 给 metric pipeline 增加 cardinality 预算告警 定期扫描 top N label pairs 小结 可观测性不是“埋得越多越好”。指标、日志、追踪各司其职，系统才能长期稳定运行。
问题是：微服务出问题了怎么办 假设你负责一个电商系统，用户下单失败，你知道问题在哪吗？ 用户 → API Gateway → Order Service → Inventory Service → Database ↓ Payment Service → 第三方支付 可能出问题的点太多了：网络超时、数据库慢查询、第三方接口挂了、代码 bug… 如果没有任何追踪手段，你只能靠经验和日志去猜。 分布式追踪就是来解决这个问题的。 核心概念：三根柱子 可观测性有三根支柱：Traces（追踪）、Metrics（指标）、Logs（日志）。这里重点聊 Traces。 Trace：一次请求的完整路径 一个 Trace 由多个 Span 组成，每个 Span 代表一个操作： Trace: 用户下单流程 ├── Span: 接收 HTTP 请求 │ ├── Span: 查询库存 (Inventory Service) │ │ ├── Span: SELECT * FROM inventory WHERE sku = ? │ ├── Span: 创建订单 (Order Service) │ │ ├── Span: INSERT INTO orders ... │ ├── Span: 调用支付 (Payment Service) │ │ └── Span: POST /api/pay 每个 Span 记录： ...