Flink系列知识讲解之：网络监控、指标与反压

Flink系列知识之：网络监控、指标与反压

在上一篇博文中，我们介绍了 Flink 网络协议栈从高层抽象到底层细节的工作原理。本篇博文是网络协议栈系列博文中的第二篇，在此基础上，我们将讨论如何监控网络相关指标，以识别吞吐量和延迟方面的反压或瓶颈等影响。如果您对网络协议栈不熟悉，我们强烈建议您先阅读网络协议栈深度剖析，然后继续阅读本文。

网络监控

网络监控最重要的部分可能是监控反压，即操作符算子接收数据的速度超过其处理速度的情况¹。这种行为会导致上游发送方受到反压，原因可能有两个：

• 接收器处理性能较慢
  • 出现这种情况的原因可能是接收器本身受到了反压，无法保持与发送器相同的处理速度，或者由于垃圾回收、系统资源不足或 I/O 而暂时受阻。
• 网络通道速度较慢
  • 尽管在这种情况下接收方并没有（直接）参与，但由于在同一台机器上运行的所有子任务共享的网络带宽可能被超量占用，因此我们称发送者受到了反向压力。请注意，除了 Flink 的网络堆栈，可能还有更多的网络用户，如source和sink，分布式文件系统（检查点、网络附加存储）、日志和指标数据都会在网络通道中传输。

如果出现反压，这种压力会向上游传递，最终到达Flink应用的源头，从而使其变慢。这种反压机制本身并不是坏事，某种程度来说是应用程序根据当前资源情况的一种自我保护机制，只是说明您缺乏资源来应对当前的负载。不过，您可能会希望通过改进应用程序，使其能够在不使用更多资源的情况下应对更高的负载。
为此，您需要找到：
(1) 瓶颈在哪里（哪个任务/操作符算子）；
(2) 造成瓶颈的原因。Flink 提供两种机制来识别瓶颈所在：

• 直接通过 Flink 的网络用户界面（Flink web UI）和反压监控器（backpressure monitor）
• 间接地通过一些网络指标。

Flink Web UI可能是快速排除故障的第一入口，但也有一些缺点，我们将在下文中解释。另一方面，Flink 的网络指标（netwrok metrics）更适合持续监控和推理造成反压的瓶颈的确切问题所在。我们将在下面的章节中介绍这两种方法。在这两种情况下，您都需要确定从source到sink的背压具体来源。值得注意的是，反压的根源节点并不一定会在反压面板体现出高反压，因为反压面板监控的是发送端，如果某个节点是性能瓶颈并不会导致它本身出现高反压，而是导致它的上游出现高反压。总体来看，如果我们找到第一个出现反压的节点，那么反压根源要么是就这个节点，要么是它紧接着的下游节点。

反压监控

反压监控可以通过 Flink 的 Web UI² 进行监控。原理是反压监控器周期性地通过 Thread.getStackTrace() 对所有TaskManager上的运行Task线程的栈信息进行采样，得到线程被阻塞在请求 Buffer（意味着被下游队列阻塞）的频率来判断该节点是否处于反压状态。这些Task要么是无法以buffer的生产速度被发送到网络缓冲区，要么是下游Task处理缓冲区的速度很慢，导致基于credit-based流量控制时，返回给上游发送端的credit值较小（或等于0）。
反压监控器（backpressure monitor）将显示被阻止的请求buffer与总请求的比率。由于某些反压被认为是正常/临时的，因此它将显示以下状态：

• OK for ratio ≤ 0.10,
• LOW for 0.10 < Ratio ≤ 0.5, and
• HIGH for 0.5 < Ratio ≤ 1.

虽然可以调整刷新间隔、采样次数或采样延迟等