你的仪表盘一片绿，警报也没响，可用户还是抱怨“慢得要命”。问题出在哪？监控告诉你系统“活着”，但只有追踪才能告诉你它为什么“活得别扭”。这是可观测性要解决的核心困惑——不是有没有问题，而是问题藏在哪个角落。

日志、指标、追踪常被并列提起，它们有层次之分：监控发现异常（比如延迟高涨），指标显示“什么在变差”，但定位“谁拖了后腿”必须靠追踪。一个下游服务的微妙卡顿，可能在指标上被平均抹平，却深埋在请求的完整链路里。AWS X-Ray 正是为这个缺口而生，它通过分布式追踪把跨服务的调用链路变成可视地图，让你一眼看到延迟卡在哪里。

要把追踪落到实处，首先要理解几个 X-Ray 的零件。每次请求会生成一个追踪结果，它由多个段组成，每个服务贡献一个段，而服务内部更细的调用则划为子段。当你想知道“某个特定用户的全部请求轨迹”，就需要在代码里埋入注释。注释会被索引，支持筛选和搜索；而元数据只存详细信息，不参与索引，适合放调试时用的堆栈或上下文。这条区分很实用，因为如果你把什么都扔进注释，索引成本会飙升——只把用户ID、订单类型这种搜索键放进注释就够了。

采样规则是成本控制的开关。默认策略是每秒追踪一次请求，外加额外5%的流量，这对于高频API能有效控制花费。你可以自定义采样率：对订单创建这种关键接口，设为100%追踪；对探测健康的端点，保持1%就够了。规则按优先级评估，数字越小优先级越高，所以先匹配重要路径的规则，剩下的由默认兜底。记住，追踪太少会错过偶发故障，太多又烧钱，按接口价值分级采样是落地时的必选项。

X-Ray 与计算环境的集成方式也不一样。在Lambda 上，只需打开“主动追踪”开关，运行环境会自动帮你把基本追踪信息发出去，连守护进程都不用手动装。但要想添加自定义子段和注释，就得在函数代码里集成 X-Ray SDK。到了EC2 或 ECS，守护进程就必须自行部署和管理。不同环境的责任边界清晰，选型时别因为“无服务器”就以为万事大吉——核心的埋点逻辑还得自己写。

追踪能看清链路，可离散的日志怎么办？答案是一枚“关联ID”。当请求从客户端一路穿过 API 网关、多个Lambda、消息队列再到数据库，让同一个唯一ID跟全程，然后在每个服务的日志里把这次请求的 ID 打上。这样，你既能从 X-Ray 的地图找到慢调用，又能凭关联ID从各自为战的日志群里捞出这次请求的全过程。再把关联ID作为注释写入 X-Ray，两套体系就打通了：从追踪里跳到日志，或从日志反查到追踪，都只要一个ID。

告警也要避免碎片化。CloudWatch 的组合告警允许你把多个指标条件打包，用“全部满足”的逻辑来触发，从而抑制单个接口波动带来的噪音。例如只有当API 延迟和5xx 错误率同时超标时才通知，不必为偶尔的抖动一惊一乍。告警状态分为 OK、报警和不足数据三种，组合告警本身又是一种独立的状态，配置得当能大幅减少“狼来了”式的疲劳。

回到最初的困惑：当监控图表平静如水，而用户感受波涛汹涌时，我们缺的不是更多指标，而是一套能关联请求、串联服务、按需采样的追踪习惯。从 X-Ray 的段与注释，到采样规则和守护进程部署，再搭配关联ID打通日志，最后用组合告警收敛噪音——这条路径正是从“我被通知出事了”走向“我明白为什么出事”的过程。下次当你面对仪表盘上的绿色心安时，不妨追问一句：那些没被追踪到的请求里，又埋着多少无声的抱怨？