监控 Amazon EMR Serverless 完整性：使用 Amazon CloudWatch 实时监控

关键要点

• Amazon EMR Serverless 允许用户在不管理集群的情况下运行开源大数据框架。
• 新推出的 CloudWatch 监控功能能够近乎实时地监控 EMR Serverless 工作节点的资源利用情况。
• 本文将介绍如何通过 CloudWatch 指标来监控 EMR Serverless 工作节点，以优化资源利用、识别错误并进行故障排查。

Amazon EMR Serverless 使用户能够运行如 Apache Spark 和 Apache Hive等开源大数据框架，而无需管理任何集群和服务器。利用 EMRServerless，用户可以在任何规模下运行分析工作负载，系统会自动扩展资源以秒级响应数据量和处理要求的变化。

我们新推出了适用于 EMR Serverless 的工作指标，可以在 中监控 Spark 和 Hive 作业的 vCPU、内存、临时存储及磁盘 I/O 分配和使用情况。

本文是关于 EMR Serverless 完整性的系列文章之一，将讨论如何使用这些 CloudWatch 指标在近乎实时的基础上监控 EMRServerless 工作节点。

EMR Serverless 的 CloudWatch 指标

在每个 Spark 作业层级，EMR Serverless 向 CloudWatch生成以下新指标，涵盖驱动程序和执行器。这些指标提供了作业性能、瓶颈和资源利用的详细洞察。

使用 CloudWatch 监控 EMR Serverless 作业的好处：

• 优化资源利用 ：掌握资源使用模式，从而优化 EMR Serverless 配置，以获得更高的效率和成本节约。例如，vCPU 或内存的过度使用可以揭示资源浪费，从而优化工作节点的规格，实现潜在的成本节约。
• 诊断常见错误 ：无需深入日志文件，通过监控临时存储的使用情况，快速识别和缓解常见错误。
• 获取近实时洞察 ：CloudWatch 提供近乎实时的监控功能，使您在作业运行时跟踪 EMR Serverless 作业的性能，以快速检测异常或性能问题。
• 配置警报和通知 ：通过设置 CloudWatch 警报，并结合 、，在特定指标达到关键水平时通过电子邮件或短信接收通知。
• 进行历史分析 ：CloudWatch 存储历史数据，允许您分析时间序列趋势，识别模式并为资源规划和工作负载优化做出明智的决策。

解决方案概览

为了进一步增强这种可监控性体验，我们创建了一个解决方案，将 EMR Serverless 应用程序的所有指标集中在一个 CloudWatch 仪表板上。每个 EMR Serverless 应用程序需要启动一个 模板。您可以使用同一个 CloudWatch仪表板监控所有提交到单个 EMR Serverless 应用程序的作业。如需了解更多关于该仪表板的信息以及如何将该解决方案部署到您的帐户中，请参阅 。

在接下来的部分中，我们将逐步介绍如何使用该仪表板进行以下操作：

• 优化资源利用，以在不影响作业性能的情况下节省成本
• 诊断常见错误造成的故障，同时无需深入日志文件，以便有效解决这些错误

前提条件

要运行本文提供的示例作业，您需要使用 或 (AWS CLI) 创建一个默认设置的 ，然后根据提供的 EMR Serverless 应用程序 ID 启动 中的 CloudFormation 模板。

您需要将本文中的所有作业提交到同一个 EMR Serverless 应用程序。如果您想监控其他应用程序，可以为自己的 EMR Serverless 应用程序 ID 部署此模板。

优化资源利用

在运行 Spark 作业时，您通常从默认配置开始。没有对实际资源利用情况的可视化支持，优化工作负载往往充满挑战。我们注意到客户经常调整的一些最常见配置包括 spark.driver.cores、spark.driver.memory、spark.executor.cores 和 spark.executor.memory。

为了展示新添加的 CloudWatch 仪表板的工作节点级别指标如何帮助您微调作业配置以实现更好的性价比和资源利用率，让我们运行以下 ，利用 NOAA 综合地面数据库 (ISD) 数据集进行一些转换和聚合。

请使用以下命令在 EMR Serverless 中运行该作业。提供您的 Amazon Simple Storage Service（AmazonS3）存储桶和启动 CloudFormation 模板所用的 EMR Serverless 应用程序 ID。确保使用相同的应用程序 ID提交本文中的所有示例作业。此外，提供一个 (IAM) 。

bash aws emr-serverless start-job-run \ --name emrs-cw-dashboard-test-1 \ --application-id <APPLICATION_ID> \ --execution-role-arn <JOB_ROLE_ARN> \ --job-driver '{ "sparkSubmit": { "entryPoint": "s3://<BUCKETNAME>/scripts/windycity.py", "entryPointArguments": ，该作业创建一个包含几百万行的庞大 Spark 数据框。通常，此操作由 Spark 驱动程序执行。在提交作业时，我们还配置了 spark.rpc.message.maxSize`，这是处理大量列数据框任务序列化所要求的。

bash aws emr-serverless start-job-run \ --name emrs-cw-dashboard-test-3 \ --application-id <APPLICATION_ID> \ --execution-role-arn <JOB_ROLE_ARN> \ --job-driver '{ "sparkSubmit": { "entryPoint": "s3://<BUCKETNAME>/scripts/create-large-disk.py", "sparkSubmitParameters": "-- conf spark.rpc.message.maxSize=2000" } }'

几分钟后，该作业失败，并在 作业详情 部分中显示“释放容器时遇到错误”的错误信息。

![CloudWatch删除)

当遇到不具描述性的错误消息时，进一步调查变得至关重要，我们需要检查驱动程序和执行器日志以进行故障排查。不过，在深入日志之前，让我们首先查看 CloudWatch 仪表板，尤其是驱动程序指标，因为释放容器通常由驱动程序执行。

![CloudWatch删除)

我们可以看到 Driver CPU Used 和 Driver Storage Used 的数值均在其分配值范围内。但检查 DriverMemory Allocated 和 Driver Memory Used 后发现，驱动程序使用了分配给它的全部 16GB内存。默认情况下，EMR Serverless 驱动程序的内存分配为 16GB。

让我们重新运行该作业，给驱动程序分配更多内存。首先将驱动程序内存设置为 27GB，因为 spark.driver.memory + spark.driver.memoryOverhead 的总值应小于 30GB，以确保正常运行。spark.rpc.message.maxSize 将保持不变。

bash aws emr-serverless start-job-run \ —name emrs-cw-dashboard-test-4 \ —application-id <APPLICATION_ID> \ —execution-role-arn <JOB_ROLE_ARN> \ —job- driver '{ "sparkSubmit": { "entryPoint": "s3://<BUCKETNAME>/scripts/create- large-disk.py", "sparkSubmitParameters": "--conf spark.driver.memory=27G --conf spark.rpc.message.maxSize=2000" } }'

这次作业成功完成。让我们查看 CloudWatch 仪表板以观察驱动程序内存利用情况。

![CloudWatch删除) ![CloudWatch删除)

如上图所示，当前的内存分配为 30GB，但作业运行期间，驱动程序内存利用率没有超过 21GB。因此，我们可以在这里进一步优化成本，将 spark.driver.memory 的值降低。我们使用设置为 22GB 重新运行相同的作业，作业仍然成功，同时驱动程序内存利用率得到了提升。

执行器错误

使用 CloudWatch进行监控非常适合诊断驱动程序相关的问题，因为每个作业只有一个驱动程序，而驱动程序使用的实际资源就是这一单一驱动程序的资源使用情况。相对而言，执行器指标是汇总在所有工作节点上的。不过，您可以利用该仪表板为作业提供适当数量的资源，以确保作业成功，从而避免资源的过度分配。

举个例子，让我们运行以下 ，该作业通过处理多年的超大 NOAA 数据集来模拟所有工作节点上的磁盘超利用率。该作业还会暂时将一个非常大的数据框缓存到磁盘上。

bash aws emr-serverless start-job-run \ --name emrs-cw-dashboard-test-5 \ --application-id <APPLICATION_ID> \ --execution-role-arn <JOB_ROLE_ARN> \ --job-driver '{ "sparkSubmit": { "entryPoint": "s3://<BUCKETNAME>/scripts/noaa-disk.py" } }'

几分钟后，我们看到该作业的 作业详情 部分显示“设备空间不足”的错误，表明某些工作节点的磁盘空间耗尽。

![CloudWatch删除)

检查仪表板的 Running Executors 指标，我们发现有 99 个执行器正在运行。每个工作节点的默认存储为 20GB。

![CloudWatch删除)

因为这是一个 Spark 任务失败，让我们从仪表板检查 Executor Storage Allocated 和 ExecutorStorage Used 指标（因为驱动程序不会执行任何任务）。

![CloudWatch 执行节点磁盘使用情况](https://d2908q01vomqb2.cloudfront.net