一個穩定可靠的系統離不開監控，我們不僅監控服務是否存活，還要監控系統的運行狀況。運行狀況主要是對這些組件的核心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。