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

# 在 Managed Service for Apache Flink 中监控
<a name="monitoring"></a>

在生产环境中运行流式处理应用程序时，您要设法连续且无限期地执行该应用程序。对所有组件（而不仅仅是 Flink 应用程序）实施监控和适当的警报至关重要。否则，您有可能在早期错过新出现的问题，在操作事件完全呈现且更难缓解时才意识到该事件。需要监控的一般内容包括：
+ 源是否在摄取数据？
+ 数据是否从源头读取（从来源的角度来看）？
+ Flink 应用程序是否正在接收数据？
+ Flink 应用程序是否正常还是性能有所下降？
+ Flink 应用程序是否一直将数据传入到接收器（从应用程序的角度来看）？
+ 接收器正在接收数据吗？

然后，应考虑为 Flink 应用程序制定更具体的指标。此[CloudWatch 仪表板](https://github.com/aws-samples/kda-metrics-dashboard)提供了一个很好的起点。有关生产应用程序应监控哪些指标的更多信息，请参阅[在适用于 Apache Flink 的亚马逊托管服务中使用 CloudWatch 警报](monitoring-metrics-alarms.md)。这些指标包括：
+ **records\$1lag\$1max** 和 **millisbehindLatest** — 如果应用程序从 Kinesis 或 Kafka 使用，则这些指标会表明应用程序性能是否下降，是否需要进行扩展以匹配当前的负载。这是一个很好的通用指标，对于各种应用程序都很容易跟踪。但它只能用于被动扩展，即当应用程序性能已经有所下降时。
+ **CPU利用**率**heapMemoryUtilization**和 — 这些指标可以很好地指示应用程序的总体资源利用率，除非应用程序已绑定，否则可用于主动扩展。 I/O 
+ **停机时间** — 停机时间大于零表示应用程序已失败。如果该值大于 0，则应用程序不处理任何数据。
+ **lastCheckpointSize**而且 *lastCheckpointDuration*— 这些指标监控状态下存储了多少数据以及检查点需要多长时间。如果检查点增加或花费很长时间，则应用程序会持续花费时间进行检查点操作，从而减少实际处理的周期。在某些时候，检查点可能会变得太大或花费很长时间以至于失败。除了监控绝对值外，客户还应考虑使用`RATE(lastCheckpointSize)`和`RATE(lastCheckpointDuration)`监控变化率。
+ **numberOfFailed检查点**-此指标计算自应用程序启动以来失败的检查点数量。根据应用程序的不同，如果检查点偶尔失败，则是可以容忍的。但是，如果检查点经常出现故障，则该应用程序很可能运行状况不佳，需要进一步关注。我们建议通过监控`RATE(numberOfFailedCheckpoints)`而不是绝对值来设置梯度报警。