大數據作為趨勢是任何一個企業都逃脫不了的宿命。大數據架構和傳統架構有著天壤之別。對于運維人員來說，大數據時代的運維應該從傳統運維轉變到業務運維中去。然而對業務指標的監控也區別于對機器的監控，對業務的監控和告警方式也千差萬別。企業運維人員該如何應對呢？

在WOT2016互聯網運維與開發者大會現場，51CTO記者獨家專訪到極光推送高級Hadoop工程師許俊。讓我們通過本文一起了解，他是如何基于業務運維的思維導向，構建極光推送大數據架構下的運維監控告警系統的；在許俊眼中，業務運維與傳統運維的理念和實現上又存在著哪些差異。

嘉賓簡介

[[165331]]

許俊，高級Hadoop工程師，大數據平臺負責人。極光推送首位大數據工程師，見證并負責整個極光推送大數據平臺的演進，目前負責Hadoop平臺，流計算系統、圖數據庫服務、spark算法平臺等基礎數據平臺。在Hadoop運維開發，大規模分布式計算平臺領域有著豐富經驗。

可視化的智能運維監控系統

極光推送的大數據平臺基于Hadoop集群實現。開始時由于部署在集群上的業務少、數據少，只采用了Zabbix對機器的基本指標進行監控，往往要到第二天接到業務部門的反饋才知道集群出現了問題。

隨著業務程序越來越多，越來越復雜，對于指標的監控要求也越來越高。發展到現在，簡單的指標監控已經不能滿足要求，出現了越來越多的類似 “平均值”、“***值”、“求和” 等更靈活多樣的需求。目前，極光推送采用的Grafana+Graphite+Statsd+Cabot這四個組件，構建一套更通用并且功能更豐富的監控系統。Graphite作為整個架構的核心，提供源數據的接收、數據的存儲和數據展示功能；Statsd是作為數據的收集和數據的聚合，以及部分的數據負載均衡的操作；Cabot是作為整個系統的告警部分，來對接到極光推送自己的告警系統;Grafana是作為監控系統UI這一層的方案。

問題的監控告警及風險預估

日志收集方面，極光推送主要是用Flume。許俊談到，Flume除了能把原始的日志收集到ES外，還能將一些不是原始文件的日志對接到Kafka數據中心。另外，通過與Elasticsearch的配合，Flume能非常容易地把數據拉到想要的目的地，而不需要像使用ES時那樣，做一些具體的分析和挖掘，非常便于問題的發現。

對于如何進一步挖掘這些日志數據的價值，許俊談到，他們希望通過對業務指標的監控，及時地發現并處理問題，甚至是對風險進行預盼，這也是做監控和告警的目的。實現這項工作，就需要更加詳盡地獲取或提供這些業務方面的指標，并將其對接到監控系統里，并通過一些基本功能，讓業務方更加直觀、方便地掌據自身業務各方面的具體情況，從而有針對性地進行一些優化和改進，比如及時進行擴容、負載均衡等。

以Redis內存為例。傳統運維可能更加關注Redis使用內存有沒有達到預設值，但通過現在這樣的系統，業務方就能夠非常輕松地觀察到在整個歷史時間內，Redis實際占用內存的增長速度和比例。這樣系統就能在它達到設置的預值之前發出預警，提前進行擴容方面的工作，而不是等到問題發生的那個時間點，為業務發展起到有力的支撐。

談及結合業務發展的需求對極光推送大數據架構運維的優化方向，許俊分享到，要整合大數據各組件的通用監控告警系統，實現與調度等系統的結合，從監控、警告的階段演進為回復和預警。通用監控告警系統就像JVM對于Java一樣，可以讓業務方基于一些通用的標準或者協議，把資料統一寫好，定制好，然后直接與監控系統對接，來減少對各組件運維的重復勞動。

業務運維是對傳統運維的有效補充

在采訪***，許俊再次強調，對大數據業務的監控與傳統的機器和集群監控一個顯著的區別是，運維關注的層面更高，關注點更超前，強調在問題出現之前，就去根據一些變化趨勢去發現問題，某種意義上來講，也是對傳統運維的一個有效的補充。

建議大家選用一些常見的、通用的運維監控方案，比如基于運維人員非常熟悉的Python語言設計出的一些方案。因為Python的生態圈非常發達，這樣一方面可以以非常低的成本去維護和定制我們需要的組件，另外一方面也能夠讓我們非常容易的找到相應的組件，來滿足我們的需求。