[open-falcon] proc.num/name=crond

又被運維人員問了，我答不出來的問題：「為什麼明明用 ps 指令去查，只有一隻 crond 的 process ，但是看監控項對時間畫出的圖形，卻明顯的是 2、3~10 不等的數字。

運維人員把他下的指令給我看：

ps -ef | grep crond

我也看不出任何問題。


沒有辦法，只好去追 open-falcon 的源碼。在源碼中： agent 計算名稱為 $name 的進程個數的方式，是到 /proc/%d/status 找， status 檔裡頭 name 為 $name 的檔案個數。

於是我下了一個指令：
[root@foo ~]# find /proc -name status -exec grep -l crond {} \;
/proc/7811/task/7811/status
/proc/7811/status
/proc/8853/task/8853/status
/proc/8853/status

再下一個指令來看好了
[root@foo ~]# pstree | grep crond
     |-crond-+-crond---bash---sleep
     |       `-crond---sh---fwrsync-+-fwrsync---sleep

[open-falcon] 在 open-falcon 監控系統中看到 lambda-architecture 的影子

這 

個人的工作，是基於 open-falcon 發展適合公司內部使用的監控軟體，每次因為工作的需求，要在 open-falcon 上增加功能時，我就不由得開始思考，這樣子加功能好嗎？會不會不小心破壞了所謂的「概念一致性」(conceptual integrity)？那什麼是最重要的「概念」呢？哪些是可以妥協？哪些是不該妥協的？

網路上介紹 open-falcon 的文章裡，有一篇是講，編寫 open-falcon 的構思過程。我也提了，從抽象的層次看待 open-falcon ，它像是什麼。目的是希望提出抽象層次的觀點，講述其概念一致性。日後在思考增加新功能時，優先考慮不傷害概念一致性的解法。

 

左側兩張圖，是大數據計算常使用的 lambda-architecture 計算模型。概念是，大數據分析系統收集資料之後，將資料分成兩份，一條路是走 batch view ，另一條路是走 real time view。

其中，batch view 因為要用完整的資料做批次處理的關系，資料的處理會略有延遲。這段延遲的時間，如果還是有提供運算結果的需求，就由 real time view 的模組來提供資料。

這樣子處理大數據的模型，我彷彿也在 open-falcon 裡看到了「似曾相似的東西」。參考右圖。就是 graph 和 judge 。其中，graph 類似於 batch view 。一方面，graph 某種程度地可以保存一年的資料，也算是 immutable data。graph 的 batch view 是用 RRD tool 做的。對資料做了某些程度的篩選，特別適合用來畫圖。所以圖就是 open-falcon lambda architecture 的 batch view 或稱 precompute view 。

judge 處理 stream data ，而且會做「實時告警」，也就是一查到符合告警條件，就會立刻觸發。 judge 做的工作，是對不斷送進來的資料流做是否觸發告警條件的檢查。 judge 產生的告警，則可以視為是一種 real time view 或 incremental view 。

略有不同的地方，是大數據的 lambda architecture 其實暗示了 batch view 和 real time view 都通過 serving layer 來呈現，所以使用者不知道裡頭存在了這兩種運算模組，甚至感覺這是同樣的模組做出的運算結果。另一方面，操作 open-falcon 的使用者，其實也未必分得清楚，繪圖功能和告警功能是在兩個不同的模組獨立計算的。

[open-falcon] 利用 influxdb 來做 rrdtool 繪圖相關問題的除錯

最近公司基於 open-falcon 布署的監控系統，發現了一個難以理解的問題：「速度上限 10Gbps 的網卡，被監控系統量測出了 5Tbps 的超高速。」這樣子的問題該怎麼處理呢？

首先想到的解決方案是先從原始資料找起，但是，open-falcon 記錄這些數值的原始資料，是利用 RRDtool 來記錄的。所以一旦事發超過 12 小時，可以拿到的資料的精準度就大幅下降了。

所幸，當初公司也有把 open-falcon 的 transfer 模組，與 influxdb 加以串接。於是，我就可以在  influxdb 裡，找到由機器送過去的原始資料。

由於這一回要除錯的是網卡速度，我們就必須對資料的類別加以著墨。由 transfer 送往 Graph 和 influxdb 的資料，型態有 gauge 和 counter 。其中， gauge 比較單純，就是量測的數值本身，直接就可以被使用者所理解，例如：現在有幾個 processes 。而 counter 數值則是「累計數值」。為什麼要使用 counter 呢？ 比方說，網卡速度就會需要了。因為像 linux 系統，其實直接透過 /proc/net/dev 只能取得某一張網卡瞬間累計接收/送出的 bytes 數目，而無法直接取得網卡的瞬時速度。換言之，監控系統之所以可以顯示網卡的速度，那是監控系統已經透過 counter 的資料型態，將速度從累計數值推算出來了。

 很快地，我就在 influxdb 裡找到了原始的資料。由於是 counter 型別的累計數值，原始資料必然是穩定上昇的直線。

而計算出 5T 速度的時間區段，也正好是區線呈現斷斷續續、不是穩定上昇的時刻。透過 grafana 的功能將時間區間定得更細之後，就看得更清楚了。

後記：

處理這個問題之後，我也比較了一下 influxdb 和 RRDtool 的。

RRDtool 是比較早的時代就發展的系統，它的特性就是很善於捨棄比較不重要的資料。所以像是 counter 型別的資料，RRDtool 是先將資料加以做類似對時間「差分」的運算，再平均值後才儲存。缺點就是要除錯時，因為不容易取得原始資料而難以下手。

而 influxdb 則是直接儲存原始的資料。也因此，如果要用 grafana 來對 influxdb 的 counter 類型資料做繪圖時，差分的運算就要自己來做了。所幸 influxdb 本身的 query language 也提供了這部分的支援，像下方的 derivative 指令，就是做這個差分運算。

SELECT 8 * derivative(mean("value"),1s)