首先想到的解決方案是先從原始資料找起，但是，open-falcon 記錄這些數值的原始資料，是利用 RRDtool 來記錄的。所以一旦事發超過 12 小時，可以拿到的資料的精準度就大幅下降了。
所幸，當初公司也有把 open-falcon 的 transfer 模組，與 influxdb 加以串接。於是，我就可以在 influxdb 裡，找到由機器送過去的原始資料。
由於這一回要除錯的是網卡速度，我們就必須對資料的類別加以著墨。由 transfer 送往 Graph 和 influxdb 的資料，型態有 gauge 和 counter 。其中， gauge 比較單純，就是量測的數值本身，直接就可以被使用者所理解，例如：現在有幾個 processes 。而 counter 數值則是「累計數值」。為什麼要使用 counter 呢？ 比方說，網卡速度就會需要了。因為像 linux 系統，其實直接透過 /proc/net/dev 只能取得某一張網卡瞬間累計接收/送出的 bytes 數目，而無法直接取得網卡的瞬時速度。換言之，監控系統之所以可以顯示網卡的速度，那是監控系統已經透過 counter 的資料型態，將速度從累計數值推算出來了。
而計算出 5T 速度的時間區段，也正好是區線呈現斷斷續續、不是穩定上昇的時刻。透過 grafana 的功能將時間區間定得更細之後，就看得更清楚了。
處理這個問題之後，我也比較了一下 influxdb 和 RRDtool 的。
RRDtool 是比較早的時代就發展的系統，它的特性就是很善於捨棄比較不重要的資料。所以像是 counter 型別的資料，RRDtool 是先將資料加以做類似對時間「差分」的運算，再平均值後才儲存。缺點就是要除錯時，因為不容易取得原始資料而難以下手。
而 influxdb 則是直接儲存原始的資料。也因此，如果要用 grafana 來對 influxdb 的 counter 類型資料做繪圖時，差分的運算就要自己來做了。所幸 influxdb 本身的 query language 也提供了這部分的支援，像下方的 derivative 指令，就是做這個差分運算。
SELECT 8 * derivative(mean("value"),1s)
