

# 关于监控 AWS Glue 流式传输作业
<a name="glue-streaming-monitoring"></a>

监控流式处理作业是构建 ETL 管道的关键部分。除了使用 Spark UI 之外，您还可以使用 Amazon CloudWatch 来监控各项指标。以下是 AWS Glue 框架发出的流式处理指标列表。有关所有 AWS Glue 指标的完整列表，请参阅[使用 Amazon CloudWatch 指标监控 AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html)。

AWS Glue 使用结构化流式处理框架处理输入事件。您可以直接在代码中使用 Spark API，也可以利用 `GlueContext` 提供的 `ForEachBatch` 发布这些指标。要了解这些指标，我们需要先了解 `windowSize`。

**windowSize**：`windowSize` 是您提供的微批次间隔。如果指定的窗口大小为 60 秒，则 AWS Glue 流式处理作业将等待 60 秒（如果届时上一批次还未完成，则会等待更长时间），然后才会从流式处理数据源批量读取数据，并应用 `ForEachBatch` 中提供的转换。这也称为触发间隔。

我们详细看一下这些指标，以了解运行状况和性能特征。

**注意**  
这些指标每 30 秒发出一次。如果 `windowSize` 少于 30 秒，则报告的指标就是一个聚合。例如，假设 `windowSize` 为 10 秒，并且对于每个微批次，您稳定处理 20 条记录。在这种情况下，为 numRecords 发出的指标值为 60。  
如果没有可用的数据，则不会发出指标。此外，对于使用者滞后指标，必须启用该功能才能获取相关指标。

# 直观展示 AWS Glue 流式传输指标
<a name="glue-streaming-monitoring-visualizing"></a>

要绘制视觉指标：

1. 转到 Amazon CloudWatch 控制台中的**指标**，然后选择**浏览**选项卡。然后在“自定义命名空间”下选择 **Glue**。  
![\[屏幕截图显示了如何在监控 AWS Glue 流式处理作业时在 Amazon CloudWatch 控制台中访问指标。\]](http://docs.aws.amazon.com/zh_cn/glue/latest/dg/images/streaming-monitoring-1.png)

1. 选择**作业指标**以显示所有作业的指标。

1. 依次按 JobName=glue-feb-monitoring 和 JobRunId=ALL 筛选指标。您可以单击“\$1”号（如下图所示），将其添加到搜索筛选条件。

1. 选中您感兴趣的指标对应的复选框。在下图中，我们选择了 `numberAllExecutors` 和 `numberMaxNeededExecutors`。  
![\[屏幕截图显示了如何在监控流式处理作业时对指标应用平均值。\]](http://docs.aws.amazon.com/zh_cn/glue/latest/dg/images/streaming-monitoring-2.png)

1. 选择这些指标后，您可以转到**绘成图表的指标**选项卡，应用您的统计数据。

1. 由于指标每分钟发出一次，因此可以对 `batchProcessingTimeInMs` 和 `maxConsumerLagInMs` 应用一分钟的“平均值”。对于 `numRecords`，您可以应用每分钟的“总和”值。

1. 您可以使用**选项**选项卡为图表添加水平 `windowSize` 注释。  
![\[屏幕截图显示了在监控流式处理作业时为图表添加 windowSize 注释。\]](http://docs.aws.amazon.com/zh_cn/glue/latest/dg/images/streaming-monitoring-3.png)

1. 选择指标后，创建控制面板并添加。下面是一个示例控制面板。  
![\[屏幕截图显示了一个监控流式处理作业的示例控制面板。\]](http://docs.aws.amazon.com/zh_cn/glue/latest/dg/images/streaming-monitoring-4.png)

# 使用 AWS Glue 流式传输指标
<a name="glue-streaming-monitoring-metrics"></a>

该部分介绍了每个指标以及它们之间的相互关系。

## 记录数（指标：streaming.numRecords）
<a name="glue-streaming-monitoring-metrics-num-records"></a>

该指标指示正在处理的记录数。

![\[屏幕截图显示了监控流式处理作业中的记录数。\]](http://docs.aws.amazon.com/zh_cn/glue/latest/dg/images/streaming-monitoring-5numrecords.png)


该流式处理指标让您可以了解窗口中正在处理的记录数。除了正在处理的记录数，它还可以帮助您了解输入流量的行为。
+ 指标 \$11 显示了一个流量稳定、无流量突发的例子。通常，类似于 IoT 传感器这样的应用程序，它们会定期收集数据并将其发送到流式处理数据源。
+ 指标 \$12 显示了一个在原本稳定的负载下流量突发的例子。这可能发生在点击流应用中，比如黑色星期五这样的营销活动，点击量激增
+ 指标 \$13 显示了一个流量不可预测的例子。不可预测的流量确实意味着存在问题。这是输入数据的性质决定的。回到 IoT 传感器的例子，您可以想象有数百个传感器将天气变化事件发送到流式处理数据源。天气变化不可预测，因此数据也不可预测。了解流量模式是调整执行程序数量的关键。如果输入量很大，可以考虑使用自动扩缩（稍后会详细介绍）。

![\[屏幕截图显示了监控流式处理作业中使用的记录数和 Kinesis PutRecords 指标。\]](http://docs.aws.amazon.com/zh_cn/glue/latest/dg/images/streaming-monitoring-6putrecords.png)


您可以将此指标与 Kinesis PutRecords 指标相结合，确保摄取的事件数和读取的记录数几乎相同。当您试图理解滞后时，这特别有用。随着摄取速率的提高，AWS Glue 的 `numRecords` 读取量也随之增加。

## 批处理时间（指标：streaming.batchProcessingTimeInMs）
<a name="glue-streaming-monitoring-metrics-batch-processing-time"></a>

批处理时间指标有助于确定集群是预置不足还是预置过度。

![\[屏幕截图显示了监控流式处理作业中的批处理时间。\]](http://docs.aws.amazon.com/zh_cn/glue/latest/dg/images/streaming-monitoring-7batchprocess.png)


该指标指示处理每个微批次记录所用的毫秒数。其主要目标是监控这段时间，确保其小于 `windowSize` 间隔。只要在下一个窗口间隔内恢复，`batchProcessingTimeInMs` 暂时超时也没关系。指标 \$11 显示了处理作业所需的或多或少的稳定时间。但如果输入记录数在增加，处理作业所需的时间就会增加，如指标 \$12 所示。如果 `numRecords` 没有增加，但处理时间却在增加，则需要深入了解执行程序的作业处理情况。最好设置阈值和警报，确保 `batchProcessingTimeInMs` 在 120% 以上的时间不会超过 10 分钟。有关设置警报的更多信息，请参阅[使用 Amazon CloudWatch 警报](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)。

## 使用者滞后（指标：streaming.maxConsumerLagInMs）
<a name="glue-streaming-monitoring-metrics-consumer-lag"></a>

使用者滞后指标有助于您了解在处理事件时是否存在滞后。如果滞后太高，那么即使 windowSize 是正确的，也可能会错过业务所依赖的处理 SLA。您必须使用 `emitConsumerLagMetrics` 连接选项明确启用此指标。有关更多信息，请参阅 [KinesisStreamingSourceOptions](https://docs.aws.amazon.com/glue/latest/webapi/API_KinesisStreamingSourceOptions.html)。

![\[屏幕截图显示了监控流式处理作业中的滞后。\]](http://docs.aws.amazon.com/zh_cn/glue/latest/dg/images/streaming-monitoring-8lag.png)


## 派生指标
<a name="glue-streaming-monitoring-metrics-derived"></a>

为了获得更深入的见解，您可以创建衍生指标，以进一步了解 Amazon CloudWatch 中的流式处理作业。

![\[屏幕截图显示了监控流式处理作业中的衍生指标。\]](http://docs.aws.amazon.com/zh_cn/glue/latest/dg/images/streaming-monitoring-9derived.png)


您可以使用衍生指标构建图表，来决定是否需要使用更多 DPU。虽然自动扩缩可以帮助您自动完成此操作，但您可以使用衍生指标来确定自动扩缩是否有效。
+ **InputRecordsPerSecond** 指示获取输入记录的速率。其衍生如下：输入记录数（glue.driver.streaming.numRecords）/WindowSize。
+ **ProcessingRecordsPerSecond** 指示处理记录的速率。其衍生如下：输入记录数（glue.driver.streaming.numRecords）/batchProcessingTimeInMs。

如果输入速率高于处理速率，则可能需要添加更多容量来处理作业或提高并行度。

## 自动扩缩指标
<a name="glue-streaming-monitoring-metrics-autoscaling"></a>

当输入流量激增时，应考虑启用自动扩缩并指定最大工作线程数量。这样，您就可以获得两个额外的指标：`numberAllExecutors` 和 `numberMaxNeededExecutors`。
+ **numberAllExecutors** 是主动运行的作业执行程序数量
+ **numberMaxNeededExecutors** 是为满足当前负载所需的最大（主动运行和待处理）作业执行程序数量。

这两个指标有助于您了解自动扩缩是否正常运行。

![\[屏幕截图显示了监控流式处理作业中的自动扩缩。\]](http://docs.aws.amazon.com/zh_cn/glue/latest/dg/images/streaming-monitoring-10autoscaling.png)


AWS Glue 将在几个微批次中监控 `batchProcessingTimeInMs` 指标，然后执行以下两个操作之一。如果 `batchProcessingTimeInMs` 接近于 `windowSize`，则会扩展执行程序；如果 `batchProcessingTimeInMs` 相对低于 `windowSize`，则会缩减执行程序。此外，还将使用一种算法来逐步扩缩执行程序。
+ 指标 \$11 显示了活动执行程序如何扩展，以满足处理负载所需的最大执行程序数量。
+ 指标 \$12 显示了自 `batchProcessingTimeInMs` 较低以来活动执行程序是如何缩减的。

您可以使用这些指标来监控当前执行程序级别的并行度，并相应地调整自动扩缩配置中的最大工作线程数量。

## 如何获得最佳性能
<a name="glue-streaming-monitoring-performance"></a>

Spark 会尝试为每个分片创建一个任务，以便从 Amazon Kinesis 流中读取数据。每个分片中的数据成为一个分区。然后，它将根据每个工作线程上的内核数量（每个工作线程的内核数量取决于您选择的工作线程类型 `G.025X`、`G.1X` 等），在执行程序/工作线程中分配这些任务。但任务的分配方式是不确定的。所有任务均在各自的内核上并行执行。如果分片数量多于可用的执行程序内核数量，任务就会排队。

您可以使用上述指标和分片数量的组合，为执行程序配置稳定的负载，并留出一定的突发空间。建议您运行几次作业迭代，以确定工作线程的大致数量。对于不稳定/突发的工作负载，您也可以通过设置自动扩缩和最大工作线程来实现。

根据业务的 SLA 要求设置 `windowSize`。例如，如果您的业务要求处理后的数据不能滞后超过 120 秒，那么将 `windowSize` 设置为至少 60 秒，这样使用者的平均滞后就会少于 120 秒（参阅上文有关使用者滞后的部分）。从那里开始，根据分片的 `numRecords` 和数量，规划 DPU 中的容量，确保 `batchProcessingTimeInMs` 在大部分时间里都低于 70% 的 `windowSize`。

**注意**  
热分片会导致数据倾斜，这意味着某些分片/分区比其他分片/分区大得多。这可能会导致一些并行运行的任务耗时更长，造成任务滞后。因此，在上一批任务全部完成之前，下一批任务无法启动，这将影响 `batchProcessingTimeInMillis` 和最大滞后。