调查容器故障

我们将使用 DevOps Agent 来调查和解决在 AWS 上运行的容器化应用程序中的故障。

已经提前部署了 AWS Retail Store Sample Application，这是一个功能完整的电子商务应用程序，允许用户浏览产品、将商品添加到购物车并完成购买。这个经过刻意过度设计的应用程序展示了微服务模式，并提供了真实的故障排查场景。

访问应用程序

我们可以通过 Application Load Balancer URL 访问 Retail Store 应用，在浏览器中打开 URL 以探索应用：

  • Home Page - 精选产品和分类
  • Catalog - 浏览所有产品（由 Catalog 服务提供支持）
  • Cart - 添加/删除商品（由 Carts 服务提供支持）
  • Checkout - 完成购买（由 Checkout 服务提供支持）
  • Orders - 订单确认（由 Orders 服务提供支持）
  • image-20260315140720273

整体架构

该应用程序在 Amazon ECS with Fargate 上运行，位于具有跨多个可用区的公有和私有子网的 VPC 内。用户通过 Application Load Balancer 访问应用程序，该负载均衡器将流量路由到 UI 服务。UI 服务随后通过 AWS Cloud Map 进行服务发现，与后端微服务进行通信。

该应用程序遵循微服务架构，每个服务可独立部署并拥有自己的数据存储。

微服务

组件 语言 描述 后端
UI Java (Spring Boot) 商店前端，提供网页服务 调用其他服务
Catalog Go 产品目录 API Aurora MySQL
Cart Java (Spring Boot) 购物车管理 DynamoDB
Checkout Node.js (NestJS) 结账编排 ElastiCache Redis
Orders Java (Spring Boot) 订单处理 Aurora PostgreSQL + Amazon MQ

基础设施组件

计算

  • ECS Cluster 使用 Fargate 容量提供商
  • 5 个 ECS Services（每个微服务一个）
  • Application Load Balancer 用于流量分发

数据存储

  • Amazon Aurora MySQL - Catalog 数据库
  • Amazon Aurora PostgreSQL - Orders 数据库
  • Amazon DynamoDB - Cart 存储
  • Amazon ElastiCache (Redis) - Checkout 会话状态
  • Amazon MQ (RabbitMQ) - 订单消息队列

网络

  • VPC 包含公有和私有子网
  • NAT Gateway 用于出站互联网访问
  • Security Groups 控制服务间通信

安全控制

  • IAM Roles - 具有范围权限的任务执行角色和任务角色
  • Security Groups - 限制服务与数据存储之间的流量
  • Private Subnets - 后端服务和数据库不可公开访问
  • Secrets Manager - 安全存储数据库凭证
  • VPC Endpoints - 与 AWS 服务的私有连接（可选）

可观测性

Workshop 环境包含开箱即用的生产级可观测性配置：

CloudWatch Logs

  • 所有微服务的 ECS 任务日志
  • 捕获网络流量的 VPC Flow Logs
  • 用于容器调试的 ECS Exec 会话日志

Container Insights（增强模式）

  • 每个服务详细的 CPU、内存和网络指标
  • 任务级别的性能可见性
  • 用于任务状态变更的 ECS 生命周期事件

CloudWatch Alarms（每个服务：ui、catalog、carts、checkout、orders）

  • CPU 利用率 > 80%
  • 内存利用率 > 80%
  • 运行中的任务数 < 1（服务健康状态）

ALB Alarms

  • 5XX 错误率监控
  • 目标响应时间（p95 > 2 秒）
  • 不健康主机检测

CloudWatch Dashboard

  • 预构建的仪表板，包含 CPU、内存、任务数、ALB 指标和网络 I/O 小部件

ALB Access Logs

  • 具有加密存储和 30 天生命周期策略的 S3 存储桶

这些可观测性组件对于故障排查场景至关重要。我们将使用 CloudWatch Logs、Container Insights 指标和告警来诊断问题。

场景 1：产品Catalog服务无法启动

在 Cloud IDE 终端中执行以下命令以注入故障：

ecs-lab1-start

image-20260315141228610

此实验将Catalog服务的任务定义修改为使用不存在的 CloudWatch 日志组。当 ECS 尝试启动新任务时，由于日志配置无效，任务将会失败。

该问题模拟了一种常见的错误配置，例如：

  • 日志组名称拼写错误
  • 日志组已被删除，但任务定义仍引用它
  • 未启用 awslogs-create-group 选项

观察症状

要查看服务状态，打开 Amazon ECS 控制台 ，选择 devops-agent-workshop-ecs-cluster，然后点击 Services 选项卡并选择 catalog 服务。

检查特定任务：

  1. 点击 Tasks 选项卡
  2. 点击任务 ID 以打开任务详情

image-20260315141434344

注意： 注入问题后，等待 1-2 分钟，以便服务尝试任务部署并在 Events 选项卡中显示错误。

注入问题后，我们将注意到：

  • Catalog任务无法启动 - 任务始终无法达到 RUNNING 状态
  • 服务事件显示错误 - 出现 ResourceInitializationError 消息
  • 服务始终无法达到稳定状态 - 部署卡住
  • 没有新日志出现 - CloudWatch 日志组没有目录的最新日志流

image-20260315141501776

使用 DevOps Agent 进行故障排查

在 Web App 中，点击 Incident Response， 点击 Start investigation 并输入调查：

尝试以下调查提示词：

为什么 devops-agent-workshop-ecs-cluster 中的catalog服务无法启动新task？
检查 devops-agent-workshop-ecs-cluster 中catalog服务的事件。失败的task的原因是什么？

image-20260315141847782

过几分钟后，DevOps Agent定位到报错的原因：

image-20260315142352549

生成Mitigation Plan后，我们可以按里面的操作来恢复环境：

image-20260315142714080

这里直接回退，以进行后面的DevOps Agent实验

ecs-lab1-fix