大數據系統之監控系統(一)

一個穩定可靠的系統離不開監控,咱們不只監控服務是否存活,還要監控系統的運行情況。運行情況主要是對這些組件的核心metrics採集、抓取、分析和報警。數據庫

1、監控的數據

監控的日誌數據通常包括:後端

v APP、PC、Web 等系統運行Log:採用Flume-NG蒐集分佈式

v 用戶日誌 : 採用Flume-NG蒐集工具

v 後端Server(SOA)日誌:採用Flume-NG蒐集大數據

v 大數據組件的Metrics:JMX和HTTP設計

v MYSQL等數據庫日誌:CANAL日誌

不一樣公司有不一樣的設計要求,這方面都很少說了。orm

2、組件運行時監控

  • 採集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請求,各個組件都至少支持其中的一個,這也是不少互聯網日誌解決方案的通用選型。

3、元數據存儲與設計

爲了達到數據採集通用性和擴展性,讓定時數據採集任務具備更好的適應性和自動化。這就須要對採集的數據規範化,須要進行元數據的設計和管理。

咱們設計了一個層次化的組織結構,他們從上到下依次是:

v Meta Category

v Meta Type

v Meta Source

v Job Metadata

v Job Scheduler

  上面的這些數據都提供了在管控臺進行配置管理的功能。爲了提高定時任務的可擴展性和自管理性。咱們選擇用Zookeeper來存儲任務的拓撲以及元數據信息。Zookeeper除了是很好的元數據管理工具,仍是很主流的分佈式協同工具。它的Event機制,使得咱們對Job生命週期的自動化管理成爲可能。咱們經過對各個ZNode的children ZNode進行監聽,來動態感知Job的變化,感知到節點的變化以後,咱們就能夠動態建立或者刪除某個job。

相關文章
相關標籤/搜索