大資料系統之監控系統（一）

標籤：

一個穩定可靠的系統離不開監控，我們不僅監控服務是否存活，還要監控系統的健全狀態。健全狀態主要是對這些組件的核心metrics採集、抓取、分析和警示。

一、 監控 的資料

監控的日誌資料一般包括：

v APP、PC、Web 等系統運行Log：採用Flume-NG搜集

v 使用者日誌 : 採用Flume-NG搜集

v 後端Server（SOA）日誌：採用Flume-NG搜集

v 巨量資料元件的Metrics:JMX和HTTP

v MYSQL等資料庫日誌：CANAL

不同公司有不同的設計要求，這方面都不多說了。

二、組件運行時監控

• 採集agent : Flume-NG
• 訊息系統 : Kafka
• 資料庫訊息系統：MQ
• 即時資料流處理 : Storm
• 分布式日誌儲存：hbase
• 分布式搜尋 : Elasticsearch

這也是很多互連網日誌解決方案的通用選型。但是，這些組件自身提供的監控方案以及他們支援的第三方監控工具，卻各不相同：

• Flume-NG : 支援http/jmx metrics，支援的監控工具：Ganglia
• Kafka : 支援jmx metrics，支援的監控工具：Yahoo!
• Storm : 支援jmx metrics，內建Storm UI
• Elasticsearch : 支援http形式的status請求

從上面的結果來看，這顯然不符合我們的期望，我們的幾個關注點：

• 監控統一化，或者說去異構化
• 配置方便，隨著系統穩定後，能夠自由配置我們認為非常重要的監控指標
• 統一的可視化，能在一個管控台上一目瞭然地看到我們希望看到的監控指標

總結一下，如上的這些組件在被監控能力上雖然各有差異，不過還是有一些共同點，那就是：

• Jmx
• http

這兩種協議的metrics請求，各個組件都至少支援其中的一個，這也是很多互連網日誌解決方案的通用選型。

三、中繼資料存放區與設計

為了達到資料擷取通用性和擴充性，讓定時資料擷取任務具有更好的適應性和自動化。這就需要對採集的資料正常化，需要進行中繼資料的設計和管理。

我們設計了一個層次化的組織圖，他們從上到下依次是：

v Meta Category

v Meta Type

v Meta Source

v Job Metadata

v Job Scheduler

　　上面的這些資料都提供了在管控台進行組態管理的功能。為了提升定時任務的可擴充性和自管理性。我們選擇用Zookeeper來儲存任務的拓撲以及中繼資料資訊。Zookeeper除了是很好的中繼資料管理工具，還是很主流的分布式協同工具。它的Event機制，使得我們對Job生命週期的自動化管理成為可能。我們通過對各個ZNode的children ZNode進行監聽，來動態感知Job的變化，感知到節點的變化之後，我們就可以動態建立或者刪除某個job。

大資料系統之監控系統（一）