基于Flink秒级计算时CPU监控图表数据中断问题

 基于Flink进行秒级计算时，发现监控图表中CPU有数据中断现象，通过一段时间的跟踪定位，该问题目前已得到有效解决，以下是解决思路：

 

一、问题现象

      以SQL02为例，发现本来10秒一个点的数据，有时会出现断点现象，会少1-2个点甚至更多：

 

二、问题定位

  针对该问题，根据数据处理链路，制定了数据输出跟踪示意图，如下所示：

 

    通过输出的实际数据发现：

   1.监控Agent的数据已经正确上报Kafka

   2.从Kafka中可以正确取到监控Agent上报的数据

   3.从计算完毕的Kafka中取不到丢失点的数据

   4.从InfluxDB中取不到丢失点的数据

 

   因此定位到数据是在Flink进行处理时丢失了，于是在Flink处理窗口中增加了输出，以确认一个窗口起止时间以及实际计算的数据都有哪些：

 

   以下是一个时间窗口中的数据，可以发现数据报数时，乱序现象比较严重：

三、问题解决

 

 如果我们以10秒为一个窗口，以一分钟为例，则Flink划分的计算时间窗口会如下所示：

 

[00:50,01:00)

[00:40,00:50)

[00:30,00:40)

[00:20,00:30)

[00:10,00:20)

[00:00,00:10)

 

 这里的窗口是一个前闭后开的时间段，也就是：[窗口开始时间,窗口结束时间)

 

 Flink基于Event Time+窗口+水位来解决乱序及延迟到达问题，当满足以下条件时，触发一个窗口里的数据进行计算：

 

a.水位时间>=窗口的结束时间

b.窗口中有需要计算的数据存在

 

当窗口已经触发计算，默认情况下，后续到达的数据将会被丢弃，所以当延迟及乱序很严重时，水位（延迟时间）越小，被丢弃的可能性越大

 

当初为了能快速计算，设置的窗口大小是10秒，水位（延迟时间）是0.5秒，从前面输出可以看到，数据乱序比较严重，加上传输延迟，设置的0.5秒时间太短，导致触发窗口计算时，一些数据会被丢弃，从而导致监控图表上出现断点情况。

 

在窗口大小固定的情况下，要解决该问题，有两个解决方案：

 

a.增加水位（延迟时间），先后调整到1秒、5秒、10秒（已经和窗口一样大！）

b.调整监控数据报数时间，对于监控插件类型的，固定首次报数时间是整分钟后2秒，保证每次报数，都落在同一个10秒内，且不会有太大乱序，也可以有效避免两次报数落在同一个10秒内

 

目前在只进行了解决方案a的情况下，已经有效解决了该问题，但仍会偶尔出现1个断点，实施方案b后，将从根本上解决该问题，同时可以进一步降低方案a的延迟时间，保证低延迟