使用 AWS X-Ray 的分布式追踪与结构化日志

在 AWS 上部署应用

Dunieski Otano

Amazon Web Services Solutions Architect

没人找到的慢请求

  • 单个请求耗时 4 秒
  • 各服务日志各自看都正常
  • 没人能看到完整链路

放大镜沿分布式服务图追踪一个慢请求，红色节点为瓶颈

在 AWS 上部署应用

分布式追踪解决什么问题

左侧为各服务各自为政的红色日志孤岛；右侧为绿色 X-Ray 甘特图时间线，将同一请求贯穿 API Gateway、Lambda、DynamoDB 与外部 API

  • 一次请求会触达多个服务
  • 仅靠日志无法展现端到端路径
  • 用追踪将整次请求串联起来
  • 精确看到时间花在哪里
在 AWS 上部署应用

Segments、Subsegments 与服务地图

  • Segment：单个服务完成的工作
  • Subsegment：Segment 内部单元，如一次 DB 调用
  • Service map：所有 Segment 的可视化图
  • 每个节点展示延迟与错误

X-Ray 追踪结构：每个服务一个 segment，DB 调用为 subsegment，汇总为服务地图，节点显示延迟与错误率

在 AWS 上部署应用

注解 vs 元数据

注解（Annotations）

  • 已索引的键值对，可筛选
  • 用于可检索项，如客户等级

元数据（Metadata）

  • 额外细节，未索引
  • 用于提供上下文，但无法检索
在 AWS 上部署应用

用 trace ID 关联日志

  • 每个追踪都有唯一的trace ID
  • 在结构化日志中包含该 trace ID
  • 可从慢追踪跳转到对应日志行
  • 日志与追踪合为一次调查

结构化日志行中高亮 xray_trace_id 字段，箭头从 X-Ray 追踪视图指向 CloudWatch Logs 中匹配的日志行以便关联分析

在 AWS 上部署应用

读服务地图定位瓶颈

X-Ray 服务地图中高延迟节点被高亮，向下钻取至追踪时间线，最长的 segment 被标记为瓶颈

  • 先看服务地图，而非日志
  • 找到延迟最高的节点
  • 钻取其追踪时间线
  • 最长的 segment 就是嫌疑点
在 AWS 上部署应用

贯穿完整请求的追踪

  • API Gateway、Lambda 与下游调用均被追踪
  • 各自将segment 写入同一追踪
  • 一个 trace ID 连接日志与各段
  • 每次请求皆具端到端可见性

从 API Gateway 经 Lambda 到 DynamoDB 与外部 API 的端到端分布式追踪；每个段头部可见同一 trace ID，将所有日志与段关联起来

在 AWS 上部署应用

让我们一起练习吧！

在 AWS 上部署应用

Preparing Video For Download...