监控

在生产环境中运行流式处理应用程序时，您要设法连续且无限期地执行该应用程序。对所有组件（而不仅仅是 Flink 应用程序）实施监控和适当的警报至关重要。否则，您有可能在早期错过新出现的问题，在操作事件完全呈现且更难缓解时才意识到该事件。需要监控的一般内容包括：

• 源是否在摄取数据？

• 数据是否从源头读取（从来源的角度来看）？

• Flink 应用程序是否正在接收数据？

• Flink 应用程序是否正常还是性能有所下降？

• Flink 应用程序是否一直将数据传入到接收器（从应用程序的角度来看）？

• 接收器正在接收数据吗？

然后，应考虑为 Flink 应用程序制定更具体的指标。此CloudWatch 仪表板提供了一个很好的起点。有关生产应用程序应监控哪些指标的更多信息，请参阅在适用于 Apache Flink 的亚马逊托管服务中使用 CloudWatch 警报。这些指标包括：

• records_lag_max 和 millisbehindLatest — 如果应用程序从 Kinesis 或 Kafka 使用，则这些指标会表明应用程序性能是否下降，是否需要进行扩展以匹配当前的负载。这是一个很好的通用指标，对于各种应用程序都很容易跟踪。但它只能用于被动扩展，即当应用程序性能已经有所下降时。

• CPU利用率heapMemoryUtilization和 — 这些指标可以很好地表明应用程序的总体资源利用率，并且可用于主动扩展，除非应用程序受到 I/O 限制。

• 停机时间 — 停机时间大于零表示应用程序已失败。如果该值大于 0，则应用程序不处理任何数据。

• lastCheckpointSize而且 lastCheckpointDuration— 这些指标监控状态下存储了多少数据以及检查点需要多长时间。如果检查点增加或花费很长时间，则应用程序会持续花费时间进行检查点操作，从而减少实际处理的周期。在某些时候，检查点可能会变得太大或花费很长时间以至于失败。除了监控绝对值外，客户还应考虑使用RATE(lastCheckpointSize)和RATE(lastCheckpointDuration)监控变化率。

• numberOfFailed检查点-此指标计算自应用程序启动以来失败的检查点数量。根据应用程序的不同，如果检查点偶尔失败，则是可以容忍的。但是，如果检查点经常出现故障，则该应用程序很可能运行状况不佳，需要进一步关注。我们建议通过监控RATE(numberOfFailedCheckpoints)而不是绝对值来设置梯度报警。