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

# 在适用于 Apache Flink 的亚马逊托管服务中使用 CloudWatch 警报
<a name="monitoring-metrics-alarms"></a>

使用 Amazon CloudWatch 指标警报，您可以监控您指定的时间段内的 CloudWatch 指标。告警根据指标或表达式在多个时间段内相对于某阈值的值执行一项或多项操作。操作的示例是向 Amazon Simple Notification Service (Amazon SNS) 主题发送通知。

有关 CloudWatch 警报的更多信息，请参阅[使用 Amazon CloudWatch 警报](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)。

## 查看建议的警报
<a name="monitoring-metrics-alarms-recommended"></a>

本节包含用于监控 Managed Service for Apache Flink 应用程序的推荐警报。

该表描述了推荐的警报，并包含以下各列：
+ **指标表达式：**要根据阈值进行测试的指标或指标表达式。
+ **统计数据：**用于检查指标的统计数据，例如，**平均值**。
+ **阈值：**使用此警报需要您确定一个阈值，该阈值定义了预期应用程序性能的极限。您需要通过在正常条件下监控您的应用程序来确定此阈值。
+ **描述：**可能触发此警报的原因以及可能的解决方法。


| 指标表达式 | Statistic | Threshold | 说明 | 
| --- |--- |--- |--- |
| downtime> 0 | 平均值 | 0 |  停机时间大于零表示应用程序已失败。如果该值大于 0，则应用程序不处理任何数据。推荐用于所有应用程序。该Downtime指标衡量中断的持续时间。停机时间大于零表示应用程序已失败。有关故障排除，请参阅[应用程序正在重新启动](troubleshooting-rt-restarts.md)。 | 
| RATE (numberOfFailedCheckpoints)> 0 | 平均值 | 0 | 此指标计算自应用程序启动以来失败的检查点数量。根据应用程序的不同，如果检查点偶尔失败，则是可以容忍的。但是，如果检查点经常出现故障，则该应用程序很可能运行状况不佳，需要进一步关注。我们建议监控 RATE（numberOfFailedCheckpoint），以报警梯度，而不是绝对值。推荐用于所有应用程序。使用此指标来监控应用程序运行状况和检查点进度。当状态数据运行正常时，应用程序会将状态数据保存到检查点。如果应用程序在处理输入数据方面没有取得进展，则检查点可能会由于超时而失败。有关故障排除，请参阅[检查点操作已超时](troubleshooting-chk-timeout.md)。 | 
| Operator.numRecordsOutPerSecond< 阈值 | 平均值 | 在正常条件下，应用程序发出的最小记录数。 | 推荐用于所有应用程序。低于此阈值可能表示应用程序在输入数据方面没有取得预期的进展。有关故障排除，请参阅[吞吐量太慢](troubleshooting-rt-throughput.md)。 | 
| records\$1lag\$1max\$1millisbehindLatest> 阈值 | 最大值 | 正常条件下的最大预期延迟。 | 如果应用程序从 Kinesis 或 Kafka 消耗，则这些指标表明应用程序是否落后，是否需要进行扩展以跟上当前负载。这是一个很好的通用指标，对于各种应用程序都很容易跟踪。但它只能用于被动扩展，即当应用程序性能已经有所下降时。推荐用于所有应用程序。将该records\$1lag\$1max指标用于 Kafka 来源，或使用 Kinesis 直播源的指标。millisbehindLatest超过此阈值可能表示应用程序在输入数据方面没有取得预期的进展。有关故障排除，请参阅[吞吐量太慢](troubleshooting-rt-throughput.md)。 | 
| lastCheckpointDuration> 阈值 | 最大值 | 正常条件下的最大预期检查点持续时间。 | 监控状态下存储了多少数据以及检查点需要多长时间。如果检查点增加或花费很长时间，则应用程序会持续花费时间进行检查点操作，从而减少实际处理的周期。在某些时候，检查点可能会变得太大或花费很长时间以至于失败。除了监控绝对值外，客户还应考虑使用RATE(lastCheckpointSize)和RATE(lastCheckpointDuration)监控变化率。如果lastCheckpointDuration持续增加，则超过此阈值可能表示应用程序在输入数据方面没有取得预期的进展，或者应用程序运行状况存在问题，例如背压。有关故障排除，请参阅[无限制的状态增长](troubleshooting-rt-stateleaks.md)。 | 
| lastCheckpointSize> 阈值 | 最大值 | 正常情况下预期的最大检查点大小。 | 监控状态下存储了多少数据以及检查点需要多长时间。如果检查点增加或花费很长时间，则应用程序会持续花费时间进行检查点操作，从而减少实际处理的周期。在某些时候，检查点可能会变得太大或花费很长时间以至于失败。除了监控绝对值外，客户还应考虑使用RATE(lastCheckpointSize)和RATE(lastCheckpointDuration)监控变化率。如果lastCheckpointSize持续增加，则超过此阈值可能表示应用程序正在积累状态数据。如果状态数据变得太大，则应用程序在从检查点恢复时可能会耗尽内存，或者从检查点恢复可能需要很长时间。有关故障排除，请参阅[无限制的状态增长](troubleshooting-rt-stateleaks.md)。 | 
| heapMemoryUtilization> 阈值 | 最大值 | 这可以很好地表明应用程序的总体资源利用率，并且可用于主动扩展，除非应用程序已 I/O 绑定。正常条件下的最heapMemoryUtilization大预期尺寸，建议值为 90%。 | 您可以使用此指标来监控整个应用程序中任务管理器的最大内存利用率。如果应用程序达到此阈值，则需要预置更多资源。您可以通过启用自动缩放或增加应用程序并行度来实现此目的。有关增加资源的更多信息，请参阅[实施应用程序扩展](how-scaling.md)。 | 
| cpuUtilization> 阈值 | 最大值 | 这可以很好地表明应用程序的总体资源利用率，并且可用于主动扩展，除非应用程序已 I/O 绑定。正常条件下的最cpuUtilization大预期尺寸，建议值为 80%。 | 您可以使用此指标来监控应用程序中任务管理器的最大 CPU 利用率。如果应用程序达到此阈值，则需要配置更多资源。您可以通过启用自动扩展或增加应用程序并行度来实现此目的。有关增加资源的更多信息，请参阅[实施应用程序扩展](how-scaling.md)。 | 
| threadsCount> 阈值 | 最大值 | 正常条件下的最threadsCount大预期尺寸。 | 您可以使用此指标来监视应用程序中任务管理器中的线程泄漏情况。如果此指标达到此阈值，请检查您的应用程序代码中是否有未关闭的线程正在创建中。 | 
| (oldGarbageCollectionTime \$1 100)/60\$1000 over 1 min period')> 阈值 | 最大值 | 预期的最大oldGarbageCollectionTime持续时间。我们建议设置一个阈值，使典型的垃圾收集时间为指定阈值的 60%，但应用程序的正确阈值会有所不同。 | 如果该指标持续增加，则可能表明整个应用程序的任务管理器中存在内存泄漏。 | 
| RATE(oldGarbageCollectionCount) > 阈值 | 最大值 | 正常条件oldGarbageCollectionCount下预期的最大值。您的应用程序的正确阈值会有所不同。 | 如果该指标持续增加，则可能表明整个应用程序的任务管理器中存在内存泄漏。 | 
| Operator.currentOutputWatermark - Operator.currentInputWatermark > 阈值 | 最小值 | 正常条件下的最小预期水位线增量。您的应用程序的正确阈值会有所不同。 | 如果该指标持续增加，则可能表明应用程序正在处理越来越旧的事件，或者上游子任务在越来越长的时间内没有发送水印。 |