介绍

在我的文章《适用于无服务器应用程序的 Amazon DevOps Guru - 第 10 部分 Aurora Serverless v2 上的异常检测》中，我们了解到，在使用 Java 21 托管的 Lambda 函数的情况下，DevOps Guru 能够成功检测 Aurora (Serverless v2) PostgreSQL 数据库的异常情况运行时通过 JDBC 连接到它。我们仅将数据库从 0.5 ACU 扩展到 1 ACU，并通过调用 Lambda 函数在数分钟内同时按 id 数百次检索产品，在数据库上创建了非常高的负载。我们看到 DevOps Guru 正确指出了数据库连接总数的增加和数据库 (CPU) 负载持续较高的情况。 在本文中，我想弄清楚 DevOps Guru 是否会通过执行相同的实验来检测异常，但使用 Aurora Serverless v2 的数据 API 和 AWS SDK for Java 而不是 JDBC。

使用数据 API 对 Aurora Serverless v2 进行异常检测

让我们看看我们的示例应用程序并使用 SAM 模板来创建基础架构并部署下图所示的应用程序：

该应用程序创建存储在 Aurora Serverless v2 PostgreSQL 数据库中的产品，并使用数据 API 按 ID 检索它们。我们将用来按 id 检索产品的相关 Lambda 函数是 GetProductByIdViaAuroraServerlessV2DataApi，其处理程序实现是 GetProductByIdViaAuroraServerlessV2DataApiHandler。

和上一篇文章一样，我们使用hey工具来进行这样的压力测试

hey -z 15m -c 300 -H "X-API-Key: XXXa6XXXX" https://XXX.execute-api.eu-central-1.amazonaws.com/prod/productsWithDataApi/1   

在此示例中，我们使用 300 个并发容器调用 API 网关端点 15 分钟。在 prod/productsWithoutDataApi 端点后面，将调用 Lambda 函数 GetProductByIdViaAuroraServerlessV2WithoutDataApi，它将通过 id 1 从 Aurora Serverless v2 PostgreSQL 数据库检索产品。

我们在 [SAM 模板]((https://github.com/Vadym79/AWSLambdaJavaAuroraServerlessV2DataApi/blob/master/template.yaml) Aurora 数据库集群中进行配置，从最小容量 0.5 扩展到最大容量 1 ACU（即非常小的数据库大小），以防增加负载以节省成本。

  AuroraServerlessV2Cluster:
    Type: 'AWS::RDS::DBCluster'
...
      ServerlessV2ScalingConfiguration:
        MinCapacity: 0.5
        MaxCapacity: 1

Aurora（无服务器 v2）数据库管理可用数据库连接的最大数量，与数据库大小（在我们的例子中是 ACU 设置）成比例，还使用 ​​Aurora Serverless v2 的数据 API（这与 v1 存在巨大差异，v1 将成为到 2024 年底将不再支持，硬配额为每秒 1000 个数据库连接）。有关更多信息，请阅读有关 Aurora Serverless v2 的最大连接数的文档。因此，随着调用次数的增加，我们预计很快就会达到最大可用数据库连接数和高数据库 (CPU) 负载，这样数据库将无法响应新的 Lambda 函数请求来检索产品id（Lambda 也会遇到）。 这样我们就会引发异常，并想知道 DevOps Guru 是否能够检测到它。它能够，有点......产生了以下见解：

并且已识别出以下聚合异常指标：

与我的文章 Amazon DevOps Guru for the Serverless applications - 第 10 部分 Aurora Serverless v2 上的异常检测中描述的使用 JDBC 而不是 Data API 时识别的聚合异常指标相比，我们完全搞乱了 Aurora 数据库异常指标：数据库连接总和和数据库 (CPU) 负载，但正确地看到 Lambda 中的错误，该错误在 15 秒内定义的时间内运行，因为数据库无法响应。

.

那么，有什么区别呢？ 让我们探讨一下我们使用 JDBC（非数据 API）和数据 API 在 Aurora Serverless v2 PostgreSQL 集群上重现的两个事件：

就 ACU 利用率/扩展而言，它们看起来相同：

就其他数据库指标而言，例如：CPU 利用率、DatabaseConnection DBLoad(CPU)，存在巨大差异：

• 对于 JDBC（非数据 API）和数据 API 情况，CPU 利用率看起来相同。但 DevOps Guru 似乎没有考虑这个指标，因为我们甚至没有在 JDBC 实验中看到它
• DBLoad(CPU) 对于数据 API 使用率来说非常低。似乎对于 Dat API，Aurora Serverless v2 数据库前面有一些负载均衡器，用于监视连接使用情况并保护数据库免于过载。
• 对于数据 API 使用情况，DatabaseConnection 指标未显示（或显示为 0）。原因是我们不管理 Data API 的数据库连接，它是在另一端为我们完成的。当然，它们仍然发挥着我们在 Aurora Serverless v2 的最大连接数中了解到的重要作用，但该指标似乎在 CloudWatch 指标中暴露于外部，甚至 DevOps Guru 也无法访问真实数字。

由于这一点以及非常低的 DBLoad(CPU)，与 JDBC 用例相比，没有生成针对具有数据 API 使用情况的 Aurora Serverless v2 集群的 DevOps Guru 见解。

我做了第二个实验，直接连接到 Aurora Serverless v2 集群，并编写脚本来创建负载测试，方法是使用标准方式（非数据 API）编写通过 id 多次获取产品的脚本。与我们对 hey 工具所做的类似，但直接访问数据库而不是调用 Api Gateway。在将数据库置于负载之下后，我使用如上所述的 hey 工具开始了相同的实验，并想看看会发生什么。产生了相同的见解，但这次具有以下异常指标：

现在我们至少看到了额外的 Aurora Serverless v2 数据库连接总和异常指标，但 DBLoad(CPU) 指标仍然缺失。

异常图形如下所示：

当然，这个实验并不干净，因为我相继进行了两次负载测试，并且部分是并行的：第一个测试直接连接到数据库而不使用 API Gateway，第二个测试使用 Data API。这证实了我最初的假设，即数据库连接总和指标是为 Aurora Serverless v2（以及一般的 RDS）生成 DevOps Guru 见解的非常重要的标准，并且在使用数据 API 的情况下通常不会公开。
我已经联系了 Devops Guru 团队并与他们分享了我的见解，希望他们能够改进服务。或者首先将修复将数据库连接公开为 CloudWatch 指标，以便将 Aurora Serverless v2 与数据 API 结合使用。

结论

在本文中了解到，如果 Lambda 函数通过数据 API 连接到 Java 21 托管运行时，DevOps Guru 可以成功检测 Aurora (Serverless v2) PostgreSQL 数据库的异常，但只能显示与 Lambda 函数相关的异常指标由于数据库没有响应而超时。其主要原因似乎是，在将 Aurora Serverless v2 与数据 API 结合使用时，作为 CloudWatch 指标的数据库连接不会公开（或始终显示为 0）。 Aurora Serverless v2 数据库指标（数据库连接总数）仅在第二次人工实验期间显示。