基于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的延迟时间，保证低延迟