現代告警平臺的設計是模塊化的

不少人在搞ELK，不少人也在搞STORM。更多人在用傳統的Nagios，Zabbix等監控工具。Jason Dixon在2012就意識到這些工具的問題是每一個人都想作到大而全，實際上咱們更須要的是一對小二精的組件拼裝成一個個性化的解決方案。推薦你們去看一下他的演講視頻：https://speakerdeck.com/obfuscurity/the-state-of-open-source-monitorin...

這是Jason Dixon所構想一個組件圖。他認爲不一樣的開源方案應該專一於提供好這些組件。
Caskey Dickson 也有一樣的設想，而且提出目前的不少組件仍然是缺少好的提供者的（好比海量metric存儲和任意維度聚合）：https://www.usenix.org/conference/lisa13/working-theory-monitoring

這是他在ppt裏畫的一個組件圖，而且評價了一下主流的開源組件。

受到前輩們的影響，這個是我廠的一個告警平臺的數據流圖。下面按照順序解釋一下這個流程圖中的各類組件：

1. 採集/收集：數據可能來自於業務的db，可能來自於日誌文件，多是由業務程序內置上報的。經過各類手段採集收集到「原數據庫」裏。什麼是「原數據庫」？好比kafka隊列。好比logstash上報前把數據彙總到的redis數據庫。「原數據庫」的存在是爲了把分散的數據彙總到一處，方便後續的處理。
2. 索引：索引主要是爲了日誌存在的。爲了讓日誌能夠檢索，須要把日誌數據進行切分，提取出字段和關鍵字錄入到「檢索庫」裏。這就是著名的ELK最擅長的事情。Logstash負責索引操做，Elasticsearch充當檢索庫的角色。
3. 統計：指標庫最多見的就是給每一個ip存放一份cpu使用率的時間序列。對於這種狀況，原數據採集了以後直接錄入指標庫就好了。另一種好比是nginx的access log，採集到以後須要通過統計才能得出某某url在5分鐘內被訪問了xx次的數據。統計最簡單的形式好比statsd，複雜的能夠用storm寫自定義的流式計算任務，更復雜的甚至涉及機器學習，好比summo logic。指標庫通常使用的是opentsdb等時間序列數據庫，可是我強烈推薦Elasticsearch：http://taowen.gitbooks.io/tsdb/content/
4. 異常檢測：傳統的告警就是比對一個靜態的閾值。對於錯誤率，訪問延遲等指標用靜態閾值確實是沒有問題的。可是對於5分鐘內的收入，訪問人數等綜合的業務指標很難用靜態閾值去作檢測異常。複雜的異常檢測會利用曲線的時間週期性，和相關曲線之間的相關性去定義動態的閾值。etsy的skyline是開源組件裏比較著名的一個。
5. 告警：告警和異常檢測是兩個過程。不是每一個異常都值得通知運維跟進處理（起碼能夠作一個頻率收斂），也不是把原始異常以xx小於xx這樣的形式告訴給運維就能夠了（能夠把告警相關的故障一塊兒通知了）。這裏個從異常到告警的過程須要作到確認這個異常是一個值得通知的告警，而且可以作一個初步的故障定位。最簡單的定位的手段是就把其餘部門的告警（好比網絡部門的網絡質量告警，安所有門的DDoS告警），以及流程單據（發佈單）作爲事件歸入事件庫。經過查詢事件庫定位緣由。

在這樣的一個提下下，不少零散的工具作的事情被整合在了一塊兒：

• 撥測：定時curl一下某個url，有問題就告警。這個是走 原數據=>直接錄入爲異常=>告警
• 日誌集中檢索：ELK的經典用法。走 原數據=>檢索庫
• 日誌告警：5分鐘Error大於xxx次告警。走 原數據=>實時統計出指標=>檢測異常=>告警
• 指標告警：cpu使用率大於xxx告警。走 原數據=>錄入到指標庫=>檢測異常=>告警

把不一樣的告警和監控策略整合到同一個數據管線的好處是簡化了總體的架構，剔除了重複的模塊（好比上報和原數據彙總等模塊）。並且有利於各司其職，專業化縱深發展。目前開源組件還比較缺少的有這麼幾塊：

• 指標庫須要海量存儲海量聚合能力，開源的有 Druid.io Elasticsearch Crate.io 等
• 異常檢測，缺少真正實用的。算法其實不用很複雜
• 故障定位和收斂，缺少真正實用的。Flapjack的實現太簡單了，Riemann又過小衆了
• 實時統計，缺少成熟的解決方案。Storm就是一個底層的執行引擎，而Spark還缺乏時間窗口等抽象。
• 日誌自動分類，尚未開源工具能夠作到 summo logic 那樣的效果
• 自定義曲線和儀表盤：相似kibana的工具仍是太少

我廠的監控告警平臺固然是把這些都實現了。不少創業公司（好比剛冒出來的jut.io）也整合出了不錯的徹底解決方案。可是更多的小廠仍是在用Nagios和Zabbix等傳統的工具，再加上個ELK看日誌。開源社區在方面仍是大有可爲的。說實話，這個東西賣錢很差賣。更多的公司仍是會選擇拿開源工具本身搭一個湊合用的。