View a markdown version of this page

实验计划文件 - AWS 规范性指导
稳定状态可观测性要求实验定义假设实验过程实验时间表实验结果已识别的缺陷

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

实验计划文件

稳定状态

进程名称 宠物收养网站

物理架构

（链接到架构图。）

逻辑架构

（链接到逻辑图。）

定义稳定状态

使用最大内容绘图（LCP）衡量，宠物收养网站的平均页面加载时间为2.5秒或更短，99个百分位延迟（P99）为4.0秒或更短，基准为5000个并发用户。

稳定状态指标

跨用户群捕获的 LCP 指标和黄金指标（延迟、吞吐量、错误率、饱和度）。

稳态可观测性

LCP 将被用户的浏览器捕获，发送到 Amazon CloudWatch，然后使用 CloudWatch RUM 进行检查。在 60 秒的时间段内，将汇总该时间段内所有请求的平均时间和 P99 LCP 时间。顶级黄金指标是通过使用捕获的 CloudWatch。

实现稳态的过程

Grafana K6 将用于创建负载，该负载可模拟大约 5K 并发用户的正常生产流量水平。

可观测性要求

团队应该能够查看以下内容：

  • 稳定状态：要验证应用程序是否处于正常状态，需要观察什么？

  • 故障状况：故障状态将如何显示在仪表板上？ 例如：

    • 应触发的警报

    • 应该生成的日志

  • 故障影响：要查看预计会受到影响的组件（影响范围），应注意什么？

  • 恢复：如何看待和衡量恢复以捕获 MTTR？

  • 调试：有关实验失败的故障排除详细信息。

下表提供了可观测性要求图表的建议和示例。你应该根据你的具体实验来定义应该观察的内容。

需要注意什么 链接到可观测性工具 正在观察到什么

输入来源

Grafana K6 仪表板

  • 正在运行的容器数量

  • 每秒请求数

应用程序的整体运行状况

  • 宠物收养 CloudWatch 仪表板

  • 宠物收养用户体验仪表板 (RUM)

  • Amazon EKS 健康节点数

  • 亚马逊 EKS 节点 CPU 利用率

工作流程运行状况

宠物收养 CloudWatch 仪表板

LCP 时间，黄金指标

跟踪

宠物收养 X-Ray 仪表板

  • 请求延迟

  • 请求计数

  • 失败次数

日志

宠物收养 CloudWatch 日志

Pod 遇到的任何错误都将发送到 CloudWatch Logs。

实验定义

实验名称 亚马逊 EKS p PetSite od CPU stress

实验源代码

（链接到实验源存储库。）

实验描述

本实验探讨了 PetSite 应用程序 pod 的 CPU 使用率的增加将如何影响整体客户体验。 通过向每个正在运行的 PetSite pod 注入 CPU 压力，我们将能够了解是否会对客户产生影响以及这种影响的程度。

实验要求或参数

应用程序负载：平均产量

Pod 标签选择器：app=petsite

实验持续时间

10 分钟

Environment

Alpha 测试环境

实验目标资源

PetSite 应用程序窗格

通过负载生成工具引入的实验基线

  • 54% 的请求的 LCP 小于 2.5 秒。

  • 46% 的请求的 LCP 小于 4 秒。

  • 未发现任何错误。

退避条件

无

假设

假设会怎样 影响 恢复

如果在正常生产级流量下， PetSite应用程序 pod 在 10 分钟内经历或导致 CPU 使用率超过 60%，那么稳定状态会怎样？

 

P99 为 4.0 秒或更短的 P50 用户的 LCP 时间将保持在 2.5 秒以下。消费者应该能够加载 PetSite 登录页面。

检测：

  • CPU 压力将通过中配置的警报进行检测 CloudWatch。

  • LCP 指标还将针对用户体验下降生成警报。

自我修复：

  • 微服务架构的分布式特性意味着许多 Pod 实例在多个可用区中运行。 

  • EKS 集群控制平面将从受影响的 pod 转移流量，并在工作节点上启动新的 pod。

恢复： 

当 CPU 利用率恢复正常时，LCP 应自动恢复。

实验过程

根据您的特定实验量身定制以下示例 step-by-step流程：

  1. 验证对所有 Amazon CloudWatch、 CloudWatch RUM 和 AWS X-Ray 控制面板的访问权限和功能。

  2. 验证应用程序环境的运行状况：

    1. 使用 CloudWatch控制面板确认 EKS 集群运行正常。

    2. 通过示例 URL 访问测试宠物收养网站应用程序部署。

  3. 启动负载以达到稳定状态：

    1. 确认负载生成器正在运行并且每秒发送 5000 个请求。

    2. 等待 5 分钟，让应用程序达到稳定状态。

    3. 使用 CloudWatch RUM 控制面板确认应用程序的稳定状态。

  4. 启动故障（实验）：

    1. 打开控制 AWS FIS 台。

    2. 运行实 pet-adoption-pod-stress验。

    3. 确认实验正在控制台中运行。

  5. 观察故障对应用程序的影响：

    1. 从 CloudWatch RUM 和 CloudWatch 仪表板中捕获屏幕截图，并记下任何异常数据点。

    2. 实验完成后 AWS FIS，捕获更多屏幕截图以记录应用程序在没有 stress 的情况下是否恢复到稳定状态，并记下数据点中的任何异常。

    3. 如果稳定状态未恢复，请采取措施恢复应用程序并记录所采取的步骤。

  6. 验证环境是否已恢复正常：

    • 查看所有业务、用户体验、应用程序和基础架构指标，以验证系统是否已恢复到已知状态。如果有帮助，请捕获仪表板屏幕截图

实验时间表

确保捕捉 end-to-end实验的时间表，从负载生成、故障注入、影响观察和应用程序恢复开始，到停止负载生成时结束。以下示例说明了这一点。

混沌实验的时间表示例。

实验结果

实验运行 ID 实验结果

PET-ADOPT-EXP-23

（链接到实验结果。）

已识别的缺陷

  • Kubernetes 集群没有检测到 PetSite pod 的 CPU 损失，因此它没有安排额外的部署。

  • 该实验没有导致4XX或5XX的错误率增加。

  • 我们需要调整 Pod 的运行状况检查，以考虑资源限制时对 LCP 的影响。