在 Apache Flink 的托管服务中进行监控 - Managed Service for Apache Flink
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

Amazon Managed Service for Apache Flink 之前称为 Amazon Kinesis Data Analytics for Apache Flink。

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

在 Apache Flink 的托管服务中进行监控

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

  • 源是否在摄取数据?

  • 数据是否从源头读取(从来源的角度来看)?

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

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

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

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

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

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

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

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

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

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