你的监控测试策略是混乱吗？

Source: Dev.to

Introduction

如今，许多云实现采用无服务器架构——例如 AWS Lambda 和 API Gateway——来提供微服务或其他业务逻辑功能，而无需管理服务器。
这种模式已经相当成熟，我们拥有大量工具和方法来确保无服务器代码的性能符合预期。我们可以在本地开发和测试，使用流水线部署，并将发布非功能代码的风险降到最低。

在与团队合作时，我会推荐以下最佳实践：

• 通过 CI/CD 部署 Lambda。
• 设置日志保留期限。
• 启用监控以捕获错误、故障或超时。

测试代码功能（正常路径测试）相对直接，但 测试我们的监控是否真正捕获了我们关心的事件——以及在检测到问题时警报是否会触发，可能更为复杂。

我们还应测试 不正常路径：系统在出现错误时的行为。在受监管的行业中，测试必须是可重复且可审计的，而手动引入错误会让这变得困难。直接在代码中添加测试钩子（例如 if TEST then …）会污染业务逻辑，应该避免。

混沌工程 可以提供帮助。我之前曾撰写过关于使用 AWS Fault Injection Simulator (FIS) 实现“即服务的混沌工程”。虽然对服务器进行混沌实验相对容易（例如 SSH 进入、增加 CPU 负载、限制网络），但对无服务器工作负载进行同样操作则不太明显——直到 re:Invent 2024，AWS 宣布了针对 Lambda 的新 FIS 功能。

新的 Lambda‑FIS 功能

FIS 现在支持三种方式来扰动 Lambda 函数：

1. 延迟 函数的启动。
2. 强制 函数产生错误。
3. 修改 函数返回的响应。

要使用这些功能，必须执行四个设置步骤：

1. 添加 Lambda Layer，使 FIS 能够与 Lambda 运行时交互。

2. 创建 S3 存储桶，用于在 FIS 与 Layer 之间传递配置和运行时数据。

3. 向 Lambda 配置添加环境变量：

   AWS_FIS_CONFIGURATION_LOCATION   # S3 存储桶（以及可选前缀）
   AWS_LAMBDA_EXEC_WRAPPER          # Layer 中的可执行文件，例如 /opt/aws-fis/bootstrap

4. 授予 Lambda 的执行角色 读取和列出该存储桶内容的权限。

有关完整细节，请参阅 AWS 文档。

定义实验模板

一旦 Lambda 配置了 FIS 层，您就通过 实验模板 来定义 要 测试的内容。模板由多个组件组成，我们关注的两个是：

示例模板（YAML）

Description: "Inject latency, errors, and 4xx responses into tagged Lambdas"
Targets:
  MyLambdas:
    ResourceType: "aws:lambda:function"
    ResourceArns:
      - "arn:aws:lambda:{{region}}:{{account}}:function:*"
    SelectionMode: "ALL"
    Filters:
      - Tags:
          my-chaos-tag: "true"
Actions:
  Delay:
    ActionId: "aws:fis:lambda:delay"
    Parameters:
      duration: "30s"
  Error:
    ActionId: "aws:fis:lambda:error"
    Parameters:
      errorType: "Runtime"
  Response:
    ActionId: "aws:fis:lambda:response"
    Parameters:
      statusCode: "404"

您可以随后对所有带有标签 my-chaos-tag=true 的 Lambda 运行实验。

预期监控结果

启用监控（例如 CloudWatch 仪表盘）后，您应该会看到类似下图的模式。

基线（无混沌）

+-------------------+-------------------+-------------------+
| Invocations       | Duration (ms)    | Error Count       |
+-------------------+-------------------+-------------------+
| steady line       | flat line        | zero              |
+-------------------+-------------------+-------------------+

实验期间

这些变化会自动出现——无需代码修改或手动基础设施调整——提供了一个可重复、可审计的实验。

仓库与部署

我已经创建了一个 GitHub 仓库，里面包含了您自行尝试所需的所有内容：

• CloudFormation 模板 部署：
  • 一个示例 Lambda（预先配置了 FIS 层）。
  • 一个用于调用 Lambda 的 API Gateway。
  • 一个示例 CloudWatch 仪表板。
  • 一个 FIS 实验模板。
• 部署和使用说明。

🔗 Repository:

当堆栈完成后，它会输出 API Gateway 的 URL。

简单负载生成脚本

#!/usr/bin/env bash
# Continuous calls to the API Gateway to generate baseline traffic
while :; do
    curl -s "" &
    sleep 0.5
done

1. 运行脚本以建立基准。
2. 启动 FIS 实验模板。
3. 观察上述仪表板的变化。

结论

在监控无服务器工作负载时，我们应采用 正式、可重复的测试方法，而不是依赖 “没事的” 假设。将 AWS FIS 与 Lambda 层结合使用可以让我们：

• 在不触及应用代码 的情况下注入延迟、错误和响应变化。
• 生成 可审计、可复现的混沌实验。
• 验证我们的监控、告警和仪表盘是否按预期响应。

试一试吧——你的合规审计员（以及值班工程师）会感谢你的！

在您的测试流程中引入混沌工程

通过 Lambda‑specific 测试，我们可以摆脱手动调试配置或侵入式的 if TEST then … 代码块，采用一种将 混沌工程 作为测试流程重要组成部分的方法。

为什么采用这种方法？

• 验证我们的监控 – 确保仪表盘和警报能够在真实问题发生时提醒我们。
• 审计我们的弹性 – 为利益相关者提供可重复、记录在案的证据，证明我们的监控方法稳健且适用。
• 简化我们的代码 – 让代码专注于业务价值，降低单元测试的负担。

拥抱混沌让我们能够证明监控的有效性，并在团队需要时提供所需的全局视图，而不是在周日凌晨 3:00 醒来处理突发情况。

所以，尽管去在测试中引入混沌吧——你的团队会感谢你的！