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