这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
链路追踪
指标能告诉我们“支付接口 P95 变慢了”，日志能告诉我们“某个订单处理失败了”，但在微服务架构中，一次请求可能经过 API 网关、订单服务、支付服务、库存服务、消息队列和数据库。链路追踪要回答的问题是：这次请求到底卡在哪里？
Trace 与 Span
链路追踪的基本模型是：
- Trace：一次完整请求的全局轨迹。
- Span：请求中的一个操作，例如调用订单服务、查询数据库、发送消息。
一个 trace 由多个 span 组成：
trace_id=abc
API Gateway 20ms
Order Service 180ms
Payment Service 150ms
MySQL query 120ms每个 span 需要记录开始时间、结束时间、服务名、操作名、父 span、状态和错误信息。
上下文传播
链路追踪能工作，关键在于上下文传播。入口服务生成 trace_id，后续每次 HTTP、RPC、消息队列调用都要把它传下去。常见方式是放在请求头：
traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01如果某个服务没有继续传递 trace，上下游链路就会断开。平台需要监控 trace 覆盖率，发现未接入或传播失败的服务。
采样策略
不是所有请求都能完整追踪。高流量服务如果 100% 采集 trace，存储成本会很高。常见采样策略有：
- 固定比例采样，例如 1%。
- 错误请求全量采样。
- 慢请求提高采样率。
- 重要租户或核心链路定向采样。
采样要避免一个问题：入口采样后，下游必须遵循同一个采样决策，否则 trace 会残缺。
与日志和指标关联
链路追踪不能孤立存在。日志里要带 trace_id，指标标签里可以保留服务和接口维度，告警里应该给出典型 trace 链接。
排障路径应该是：
告警 -> 指标看板 -> 慢 trace -> 相关日志 -> 根因例如，告警显示支付回调 P95 超过 2 秒，点击看板看到延迟集中在 Payment Service，再打开慢 trace 发现 MySQL 查询耗时异常，最后通过 trace_id 搜到 SQL 参数和错误日志。
链路追踪让单次请求透明化。下一章会把日志、指标、trace 和告警放到可视化工作台里。