深入理解Flink网络栈:监控、指标及反压(上)

在之前的博文中，我们介绍了Flink的网络栈从高级抽象到低级细节是如何工作的。本系列网络栈博文的第二篇将会进一步探讨这些细节，并讨论监控与网络相关的指标，以识别诸如背压或吞吐量和延迟瓶颈等影响。虽然这篇文章简要介绍了如何处理背压，但未来的文章将进一步研究调整网络栈的主题。如果您不熟悉网络栈，我们强烈建议先深入阅读第一篇文章然后继续。

Monitoring

网络监控中最重要的部分可能是监控背压，这种情况下系统接收的数据速率高于处理速度¹。这种行为将导致发送者受到压力，可能由两件事引起：

• 接收端很慢。这可能是因为接收端本身是背压，无法以与发送方相同的速率继续处理，或者被垃圾收集，缺少系统资源或I / O暂时阻止。

• 网络Channel很慢。尽管在这种情况下不直接牵扯到接收端，我们称为发送端背压，因为在同一台机器上运行的所有子任务共享的网络带宽可能超额预订。请注意，除了Flink的网络栈之外，可能还有更多的网络用户，例如源和接收器，分布式文件系统（检查点，网络附加存储），日志记录和指标。之前的容量规划博客文章提供了更多详情。

如果您不熟悉背压以及它与Flink的交互方式，我们建议您阅读2015年关于背压的博客文章。

如果发生背压，它将向上游冒泡并最终到达您的源并减慢它们的速度。这本身并不是一件坏事，只是说你缺乏当前负载的资源。但是，您可能希望改进工作，以便在不使用更多资源的情况下处理更高的负载。为此，您需要找到（1）瓶颈在哪里（在哪个任务/operator处）和（2）导致它的原因。Flink提供了两种识别瓶颈的机制：

• 直接通过Flink的Web UI及其背压监视器，

• 或间接通过一些网络指标。

Flink的Web UI可能是快速排除故障的第一个入口点，但有一些缺点我们将在下面解释。另一方面，Flink的网络指标更适合持续监控和推理导致背压的瓶颈的确切性质。我们将在下面介绍这两个部分。在这两种情况下，您都需要确定从source到sink的背压来源。当前和未来调查的起点很可能是最后一次经历背压的Operator。这个特定的 Operator 也很可能首先引起背压。

Backpressure Monitor

背压监视器仅通过Flink的WebUI²进行曝光。由于它是仅在请求时触发的活动组件，因此目前无法通过指标提供。背压监视器通过Thread.getStackTrace（）对所有TaskManagers上的正在运行的任务线程进行采样，并计算缓冲请求中阻塞任务的样本数。这些任务要么无法按照生成的速率发送网络缓冲区，要么下游任务处理它们的速度很慢，并且没有发送任何信用( credits )。背压监视器将显示阻塞请求与总请求的比率。由于某些背压被认为是正常/临时，它将显示状态

• OK for ratio ≤ 0.10,

• LOW for 0.10 < Ratio ≤ 0.5, and

• HIGH for 0.5 < Ratio ≤ 1.

虽然您可以调整刷新间隔，样本数或样本之间的延迟等内容，但通常情况下，您不需要触碰这些内容，因为默认值已经提供了足够好的结果。

您还可以通过REST API访问背压监视器：

背压监控器可以帮助您找到背压源自何处（在哪个任务/Operator处）。但是，它不支持您进一步推断它的原因。此外，对于较大的作业或更高的并行度，背压监视器变得太拥挤而无法使用，并且可能还需要一些时间来收集来自所有TaskManagers的所有信息。另请注意，抽样可能会影响您的正常运行工作。