本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
监控
在生产环境中运行流式处理应用程序时，您需要持续无限期地执行应用程序。对所有组件实施监控和适当报警是至关重要的，而不仅仅是 Flink 应用程序。否则，你可能会在早期错过新出现的问题，只有在运营事件完全解散且难以缓解时才意识到它。要监控的常规内容包括：
来源是否在摄取数据？
数据是否从源读取（从源的角度）？
Flink 应用程序是否正在接收数据？
Flink 应用程序能否跟上步伐，还是落后了？
Flink 应用程序是否将数据保留到接收器中（从应用程序的角度来看）？
接收器是否正在接收数据？
然后，应该为 Flink 应用程序考虑更具体的指标。该CloudWatch 仪表板
records_lag_max和millsBehindLatest— 如果应用程序使用的是 Kinesis 或 Kafka，则这些指标会指示应用程序是否落后，是否需要扩展以跟上当前的负载。这是一个很好的通用指标，可以轻松跟踪所有类型的应用程序。但是它只能用于响应式扩展，即当应用程序已经落后时。
cpuUtilization和heapMemoryUtilization— 这些指标可以很好地表明应用程序的总体资源利用率，除非应用程序受到 I/O 限制，否则可用于主动扩展。
停机时间— 停机时间大于零表示应用程序出现故障。如果该值大于 0，则应用程序不处理任何数据。
lastCheckpointSize和lastCheckpointDuration— 这些指标监控状态下存储了多少数据以及执行检查点需要多长时间。如果检查点增加或需要很长时间，应用程序将持续花费时间进行检查点操作，而实际处理的周期会减少。在某些时候，检查点可能会增加或需要很长时间以至于失败。除了监控绝对值外，客户还应考虑使用以下方法监控变化率
RATE(lastCheckpointSize)和RATE(lastCheckpointDuration).numberOfFailed检查点— 此指标计算自应用程序启动以来失败的检查点数。根据应用程序的不同，如果检查点偶尔失败，这是可以容忍的。但是，如果检查点经常出现故障，则应用程序可能不健康，需要进一步关注。我们建议监控
RATE(numberOfFailedCheckpoints)警报梯度而不是绝对值。