基於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的延遲時間，保證低延遲