先說說背景：實驗是做雲端計算的，幾年的積累下來，有一套自己的IaaS平臺，在IaaS上，有一套自己的CaaS，然後在IaaS和CaaS之上，又跑著許多的web應用。如何能將這個雲平臺以及平臺上的各種應用監控起來呢？下面 的文章將會逐一分解我的思考點。

從目的出發，思考監考能帶來什麼

 對實驗室來說，使用監控最主要的目的是以下兩個：
* 實時監控應用的健康檢測，在出現問題時能及時報警。
* 長時監控歷史趨勢的檢視與分析。

監控體系的模組

 基於以上，我認為實驗室的監控體系應該大致有五個層次：資料採集、資料轉發、資料儲存、報警和預警、資料分析。下面著重說說每個層次的關注點：
1. 資料採集：資料採集落實到軟體層面就是一個sdk（對於應用的監控）或者一個指令碼（對於伺服器資源的監控）。資料採集主要需要關注的點在於：

• 所需監控的資源欄位設計
• 指令碼分發方式，最理想的肯定是伺服器分發，但是考慮到平臺需要監控的資源型別差異性較大，目前考慮手動部署指令碼和手動整合sdk的方式
• 資料採集方式，有push和pull兩種，push是指客戶端主動傳送監控資料，pull是監控伺服器主動請求監控資料，考慮到不同監控業務的不同需求，時間間隔也不盡相同，這裡選擇push方式，主動將客戶端資料傳送給伺服器。

2.資料轉發：資料轉發模組主要是降低請求流量。試想，如果有10000個客戶端向一臺伺服器傳送監控資訊，伺服器和受到了DDoS沒什麼區別。所以這裡就需要設定轉發模組叢集降低流量的壓力，一方面，將大量的短資料整合為少量的長資料，另一方面決策監控資料發往哪裡，所以，轉發模組主要需要關注的地方在：

• 請求訊息的整合傳送
• 選擇發往的伺服器，最開始，儲存/分析資料的伺服器可以是一個，但是如果擴充套件為叢集時，轉發模組就需要通過規則以及一致性雜湊演算法選擇對於某類監控需要發往的伺服器。

3.資料儲存：資料儲存主目前可以考慮使用資料庫的場景有三個：

• 監控的持久化儲存，這個部分儲存的資料必然是常年海量的，一般會用來做一個歷史性的分析，而且這裡的資料刪/改的可能性不大，因此使用Hbase這種列式儲存進行持久化。
• 配置資訊：配置資訊包括監控的應用資訊，使用者資訊甚至規則資訊等平臺需要儲存的非監控資訊，這些資訊控制平臺的運轉，需要頻繁的CRUD操作，因此適合使用MySQL資料庫。
• 需要展示的統計資料：這些資料是分析持久化儲存資料之後得出的一些統計性結果，通過定期任務算好後儲存，相比於持久化儲存資料，這部分資料量不大而且請求更為頻繁，可以儲存MySQL
• 告警的快取：如果告警設定是一個有狀態的檢測，那麼告警模組需要儲存一個監控序列，這些序列存在時間相對較短，會被頻繁的讀寫刪且對響應要求較高，一方面，可以將這些資訊直接存在執行時中，另一方面，可以考慮一些NoSQL資料庫，如redis。

4.資料分析：資料分析是指，平臺根據不同的業務需求，對持久化儲存的資料進行分析任務，資料分析可能的形態是：

• 有一個任務下發機制，將需要分析的任務通過web表單/.java檔案等方式出發一個數據分析任務
• 有一個計算平臺，可以是單機的，也可以是分散式的
• 使用者下發分析任務，資料分析模組直接從Hbase中獲取資料，在單機/sprak/hadoop叢集下分析資料，分析結果可支援寫如Hbase或者MySQL中。

5.預警和告警：不同於資料分析，資料告警要求實時性，因此建議單獨羅列出來實現。在一開始，資料轉發模組就可以根據規則將資料分別轉發至資料儲存和告警兩個模組，儲存做資料的持久化，而告警模組直接分析資料。這樣也帶來了複雜性，所以在一開始，可以將告警模組整合到分析模組中。

監控體系架構圖

 監控體系如下圖所示:

 下面自下而上的解釋各個模組的功能及互動：

• Collector: 負責監控資訊的採集,併發往forward叢集
• Forward: 負責合併同類監控資訊，並通過一致性雜湊演算法，轉發策略將監控資料發往告警叢集和儲存叢集
• 告警叢集:主要接收下發的告警規則，對傳送來的資料進行分析，產生告警，傳送到告警佇列中
• 儲存叢集:主要負責資料的持久化工作
• rules：主要負責下發規則，一方面，將具體的任務指令碼/規則配置到告警叢集，另一方面，配置轉發模組，只發送對應的監控資料給告警模組，降低流量的壓力
• alert：內部負責維護一個佇列，並以郵件/簡訊的形式將佇列中的告警資訊推送出去
• mysql：維護叢集運轉的資訊，儲存一些分析後的資料
• analysis：通過下發分析任務，基於儲存叢集做資料分析
• web/api：作為dashborad，方便使用者檢視，配置整個監控系統

需要被監控的資源：

 從採集內容上來看，監控可以從以下兩個方面來看：
1. 物理機/虛擬機器/容器執行時各項指標,如cpu、記憶體、io等
2. 功能節點應用執行資訊，其中執行資訊可以包括日誌分析（多是第三方的如nginx、mysql等）或開發者主動埋點（嵌入sdk）

 下圖是平臺大概的一個資源從屬概念

 現在自下而上說說這些資源應該監控的範疇：
1.物理資源、虛擬機器資源、caas平臺上的容器資源：這些資源，從在邏輯上為我們提供了計算能力，在監控的範疇上是大致相同的，但是雖然在採集時指標是相同的，但是在分析時還要區分對待。總的來說，計算資源需要考慮:

• 程序（程序虛擬記憶體大小、程序常駐記憶體大小，程序頁故障數，每分鐘程序頁故障數，程序CPU系統、使用者時間，程序每分鐘CPU系統、使用者時間、程序持續時間、程序CPU總時間，程序每分鐘CPU總時間，程序CPU使用量
• 網路使用：可用性，傳輸、接收包數量，每分鐘傳輸、接收包數量，傳輸、接收的位元組數、每分鐘傳輸、接收位元組數
• 硬碟使用：可用性，讀寫數量，每分鐘讀寫量，讀寫位元組數，每分鐘讀寫位元組數
• CPU：CPU使用，等待，CPU每分鐘使用、等待
• 記憶體：內出共享數，最大、小記憶體使用，記憶體大小，記憶體互動區，記憶體共享區，活躍記憶體，記憶體開銷

2.功能性節點及支撐軟體:是指監控支撐IaaS服務的關鍵應用的執行狀況，目前來看，主要有域名服務（nginx）、資料庫服務（mysql）、甚至是底層的kvm等軟體。至於監控指標，這是和業務相關的，需要分析每個服務的日誌可能會報哪些錯誤，通過指令碼將這些錯誤傳送給平臺。

3.其他應用，這些應用資料大都是和業務相關。比如CaaS，PaaS，樂志等，需要監控的，一方面是開發者整合進sdk的認為有價值的點，另一方面是部署的開源軟體（k8s、hadoop、hbase）的一些關鍵資訊，當然這些都是和業務緊密相關的。

監控體系與實現的步驟：

 目前來看監控體系可以分為以下幾個步驟實現：

1. 目前平臺的已經有的監控體系

 目前來說，平臺大多數應用都有了監控。在資料採集、儲存和甚至是呈現層面，都已經有所涉及了。下面講講按照緊急程度的來分析還需要做哪些工作。

2.資料分析模組

 目前，是沒有資料分析模組，資料分析模組主要是對歷史資料進行分析，算是整個系統中昇華的一個部分，因此，在整個採集、儲存鏈都有了的情況下可以把優先順序放到對資料的分析挖掘上。

3.資料採集和資料儲存的解耦和

 目前，除了使用python指令碼採集的方式用到了轉發模組，其餘平臺均是將資料直接傳送到了儲存模組（樂志）。轉發模組主要完成兩個任務:其一是降低流量的壓力，其二是對監控資料分別發往告警和儲存模組(當我們將告警和儲存分離後才有用),方便控制哪些資料發往告警模組，哪些不傳送。基於目前平臺collector+kafka的架構,我認為這一塊兒的改造應該拆分一下：
1. 對於降低流量壓力的需求，仍然是對要傳送大量監控的業務專門設定轉發模組（如iaas的監控，caas容器的監控（目前沒有做）），對於樂志sdk，目前已經有客戶端將多條訊息合併傳送的功能（sdk提供的功能）
2. 對於分發告警和儲存模組，日後在kafka新增訊息訂閱者，實現告警訊息的選擇性發送。

4.告警模組和儲存模組的分離

 目前，告警模組是基於儲存模組來進行資料分析的，實時性會有損失。在這一階段，應該使告警模組和儲存模組分離。具體的，就是轉發模組，根據上層下發的規則，將部分監控資訊直接傳送給告警模組。

5.告警模組的完善

 目前，告警模組僅支援某一時間點資料的正則分析，這一階段，可以考慮針對資料做一個趨勢分析，預測等更多功能。