在 Apache Flink 的托管服务中进行监控 - Managed Service for Apache Flink

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)而不是绝对值来设置梯度报警。