📚 课程目录第3章 AWS性能观测工具链实战

3. AWS性能观测工具链实战

性能问题很少由单一工具直接给出答案。一次线上延迟升高，可能同时涉及应用内部调用链、实例资源水位、配置变更记录、成本结构变化以及资源规格是否合理。AWS 提供的七类观测工具各自覆盖不同维度：CloudWatch 负责指标与日志，X-Ray 负责分布式追踪，CloudTrail 负责 API 操作审计，Config 负责资源配置合规与变更历史，Trusted Advisor 负责最佳实践检查，Compute Optimizer 负责资源规格建议，Cost Explorer 负责成本与用量分析。真正有效的做法不是逐个打开控制台，而是围绕一个性能问题建立“指标—追踪—变更—配置—建议—成本”的联合视图。

一、先明确每个工具回答什么问题

CloudWatch 回答“现在和过去发生了什么指标变化”，核心对象是指标（Metric）、维度（Dimension）、命名空间（Namespace）、告警（Alarm）和日志组（Log Group）。X-Ray 回答“请求在哪个服务、哪个下游、哪段代码变慢”，核心对象是 Trace、Segment、Subsegment 和 Service Map。CloudTrail 回答“谁在什么时间调用了哪个 API”，核心对象是 Event、UserIdentity、EventSource 和 EventName。Config 回答“资源配置是否符合规则、何时被改过”，核心对象是 Configuration Item、Config Rule 和 Resource Timeline。Trusted Advisor 回答“当前账户在成本、性能、安全等维度有哪些最佳实践缺口”。Compute Optimizer 回答“这个实例或卷的规格是否过大或过小”。Cost Explorer 回答“成本按服务、标签、账户如何分布，趋势是否异常”。

二、联合排查的典型路径

假设某 Web 服务在 14:00 出现 P99 延迟从 180ms 升至 1.2s。第一步在 CloudWatch 中查看 ALB 的 TargetResponseTime 和 EC2 的 CPUUtilization，发现延迟升高但 CPU 仅 35%，说明瓶颈不在计算资源。第二步打开 X-Ray Service Map，发现 order-service 到 payment-api 的调用平均耗时从 90ms 升至 800ms，且 payment-api 的 Subsegment 中数据库查询占 700ms。第三步用 CloudTrail 查询 13:50–14:00 的 ModifyDBInstance 或 UpdateParameterGroup 事件，确认是否有参数变更。第四步用 Config 查看 RDS 实例的配置时间线，确认 max_connections 或 innodb_buffer_pool_size 是否被修改。第五步用 Compute Optimizer 检查该 RDS 实例规格是否长期偏低。第六步用 Cost Explorer 按标签查看该服务成本是否因规格调整而异常上升。这条路径把六个工具串成一条可复现的排查链。

三、自定义仪表盘搭建

CloudWatch Dashboard 是联合视图的落地载体。建议按“服务维度”而非“工具维度”组织。以下是一个订单服务的仪表盘 JSON 片段示例，包含延迟、错误、追踪和成本四个区域：

{
  "widgets": [
    {
      "type": "metric",
      "x": 0, "y": 0, "width": 12, "height": 6,
      "properties": {
        "title": "ALB P99 延迟与 5xx",
        "metrics": [
          [ "AWS/ApplicationELB", "TargetResponseTime", "LoadBalancer", "app/order-alb/xxx", { "stat": "p99" } ],
          [ ".", "HTTPCode_Target_5XX_Count", ".", ".", { "stat": "Sum", "yAxis": "right" } ]
        ],
        "period": 60,
        "view": "timeSeries"
      }
    },
    {
      "type": "metric",
      "x": 12, "y": 0, "width": 12, "height": 6,
      "properties": {
        "title": "EC2 CPU 与内存",
        "metrics": [
          [ "AWS/EC2", "CPUUtilization", "InstanceId", "i-0abc123" ],
          [ "CWAgent", "mem_used_percent", "InstanceId", "i-0abc123" ]
        ],
        "period": 60
      }
    },
    {
      "type": "log",
      "x": 0, "y": 6, "width": 24, "height": 6,
      "properties": {
        "title": "X-Ray 慢请求 Trace",
        "query": "SOURCE '/aws/xray/traces' | fields @timestamp, trace_id, duration | filter duration > 800 | sort @timestamp desc | limit 20"
      }
    }
  ]
}

实际搭建时，建议把 X-Ray 的 Trace ID 与 CloudWatch Logs 的 @requestId 做关联，这样从仪表盘看到慢请求后可以直接跳转到日志。Cost Explorer 的区域可以用 aws-cost-explorer 自定义 widget 或通过 Lambda 定时拉取成本数据写入自定义指标，再在 Dashboard 中展示。Trusted Advisor 和 Compute Optimizer 没有原生 Dashboard widget，通常用 EventBridge 定时触发 Lambda，把检查结果和优化建议写入 CloudWatch 自定义指标，再统一展示。

四、关键参数与判断依据

工具	关键参数/字段	判断依据示例
CloudWatch	Period、Statistic、Alarm 阈值	P99 > 500ms 持续 3 个周期触发告警
X-Ray	Duration、Error、Fault、ResponseTime	某 Subsegment 占比 > 60% 总耗时
CloudTrail	EventName、EventTime、UserIdentity	变更时间与延迟升高时间窗口重合
Config	ResourceType、Configuration、Relationships	配置项与基线不一致
Trusted Advisor	Category、Status、FlaggedResources	性能类检查出现 warning
Compute Optimizer	Finding、UtilizationMetrics、Recommendation	Over-provisioned 或 Under-provisioned
Cost Explorer	Service、Tag、UsageType、UnblendedCost	单位请求成本环比上升 > 20%

建议为每个核心服务建立统一标签（如 Service=order、Env=prod），这样 CloudWatch 指标、X-Ray 追踪、Cost Explorer 成本都能按同一维度聚合，避免仪表盘碎片化。

CloudTrail 默认只保留 90 天事件历史，长期审计需创建 Trail 并投递到 S3；Config 需要单独开启记录器并配置要记录的资源类型，否则无法回溯配置变更。两者是排查“变更引发性能问题”的关键，不能只依赖 CloudWatch 指标。

最后，联合工具链的价值不在于工具数量，而在于形成“发现异常—定位层级—回溯变更—验证配置—评估规格—核算成本”的闭环。仪表盘只是这个闭环的展示层，真正的判断仍依赖对指标基线、追踪拓扑和变更记录的交叉比对。