開場
本次演講將會一步步地，向大家展示我們這個系統架構。
由於時間有限，我不會深入講解技術細節（事實上我一開始做好、發給Sting的ppt有多達40頁現在精簡到20多頁）。
我希望達到的效果是－－
對於有相關項目經驗的開發人員，可以起到一個參考的作用
對於沒有監控項目經驗的人員，也可以讓你對如何實現監控平臺有一個快速的認知
背景介紹
監控系統對於大數據平臺的重要性不言而喻。
那要實現這樣一種系統，我們需要解決哪些問題？
首先我們要知道如何採集監控數據，監控數據主要有三種
-
系統本身的運行狀態，例如CPU、內存、磁盤、網絡的使用情況
各種應用的運行狀況，例如數據庫、容器等
處理網絡上發送過來的數據
有了數據，我們需要採用合適的存儲方案來保存海量的監控數據
然後需要把這些數據在web界面進行展示，把監控指標的變化情況可視化
另外，如果監控系統只能看而不能及時發出告警（以郵件／微信等通知方式），價值也大打折扣
最後，對於這樣的大型架構，我們同樣需要考慮高可用／高併發／可伸縮性
架構設計之路
接下來，我們來初步設計這個架構的實現方案。
根據對現有監控產品的調研，以及我們列出的所需解決的問題，可以發現監控系統的一般套路：採集－存儲－展示－告警，也就是圖上這四個模塊：
爲了實現解耦、異步和對採集器的控制，我們在採集和存儲之間增加一個任務隊列；考慮到可能需要進行接口封裝、統一開放對外接口，我們增加一個API服務模塊。
存儲－OpenTSDB
我們先來看看存儲方面的OpenTSDB。
由於監控數據（例如CPU、內存等）跟時間點密切相關，我們確定了採用時間序列來存儲監控數據。OpenTSDB是一個基於HBase、分佈式、高可用、可伸縮的時間序列數據庫，支持每秒百萬級別的寫入請求，並可以通過增加節點來靈活擴展處理能力。
我們可以把它當作一個HBase的應用，利用它豐富的API和聚合函數來查詢監控數據。
它存儲的數據格式包涵以下四個元素：
Metric：
指標名，比如過去1分鐘的系統負載，可以表示爲proc.loadavg.1m
Timestamp：
Unix時間戳，可以精確到毫秒級別
Value：
指標的數值，整型
Tag：
標籤，指標的過濾條件，作用相當於SQL語句中的Where條件查詢；
每個指標可以有多個標籤
每一條數據由以上4種數值組成，如（telnet端口發送的數據格式）：
[metric] [timestamp] [value] [tags]
一個示例：
proc.loadavg.1m 1234567890 0.42 host=web42 pool=static
這是它的應用場景，中間綠色的就是OpenTSDB（簡稱TSD），上面每個Server的c就是採集器（collector），採集器把數據發送到TSD，TSD再異步寫入到HBase集羣，web UI則可以通過TSD的HTTP API接口來查詢數據和進行展示。
因此，在我們這個系統架構裏，存儲模塊就是OpenTSDB模塊。
採集－Collector
我們的採集器基於開源的TCollector。
TCollector是一個python編寫的、OpenTSDB的採集器客戶端。它提供了一個採集器的框架，讓你只需要編寫簡單的採集腳本，其他諸如網絡連接、性能優化等工作由它處理。
上面是它的工作原理：編寫的採集器腳本，從Linux的/proc目錄下獲取系統相關信息，或者收集其他自定義的指標，輸出到標準輸出，然後有一個核心的採集器管理器統一處理輸出數據，最後發送到TSD。
這個核心管理器，其內部實現也不復雜（源代碼大概1000多行），就是起兩個主循環線程：讀取線程ReaderThread和發送線程SenderThread。ReaderThread從採集器運行實例（也就是腳本輸出）yield一行數據，將數據異步推入ReaderQueue，然後SenderThread從ReaderQueue裏拿到數據，存到SenderQueue，最後發送到TSD。其中還有一些優化工作，ReaderThread負責做一些數據去重，減少一段時間內相同數據的發送次數；SenderThread負責網絡連接的管理，比如與TSD的心跳檢測、黑白名單等。
我們在TCollector的基礎上進行開發，包括：
重構，提高代碼可讀性、解耦模塊和配置
增加實現代理和用戶管理
增加與任務隊列Celery的集成
性能優化
因此，這個系統架構的採集器模塊，也有了實現。
隊列－Celery
Celery是一個快速、靈活、高可用、分佈式的異步任務調度隊列。
集成到我們這個系統裏，其實就是把採集器當成生產者，採集器生產的數據發送到Broker；Broker是消息中間件，我們選用了Redis；Worker就是消費者，消費者行爲就是從Redis中獲取數據，並最終寫入到TSD裏面。
整個流程比起採集器直接發送到TSD會更長，但得益於Redis和Celery的高效，依然保持極佳的性能，且可以通過結合Celery－Flower這種管理界面，對採集行爲進行控制。
因此，任務隊列由Celery實現。
API－Tornado
Tornado是一個高性能的Web服務框架，很適合構建支持高併發的API服務，而且Tornado可以和Celery整合在一起。這個Tornado API服務，我們在系統中主要用它來：
API的封裝，對TSD、Bosun（告警模塊）的API進行二次開發
可以作爲對外接口，接收處理網絡數據
因此，系統架構中API服務的實現也敲定了。
展示－Metrilyx
Metrilyx是基於OpenTSDB的開源可視化界面：
它是基於django開發的，可以很好地利用django生態的工具
數據展示的面板簡單易用
對數據指標更好的查詢操作
更豐富的指標名搜索工具
分佈式、高可用
這是它的數據面板，左邊是指標名搜索欄，右邊每個小面板展示的是監控指標的圖表。
告警－Bosun
最後，告警這個模塊，我們採用了StackOverflow的Bosun。Bosun是一個基於OpenTSDB開源的告警系統：
GO語言和AngularJS開發，性能好且易於部署
通過靈活強大的表達式來定義告警規則
提供HTTP調用的告警方式
架構全景
至此，我們基本看完了整個系統架構的技術面貌。
我們把上面的架構圖再稍微完善一下...
這就是我們系統的整個架構全景。
可以看到，在OpenTSDB節點上，我們增加了一個HAProxy，用於進行負載均衡。
在採集器部分，還增加了一個Proxy代理。因爲在大數據場景下，完全有可能是跨地區的大規模採集，這時候我們需要在不同的地域增加一個代理，用於中轉處理和統一發送數據。
整個架構可以概括爲：採集－隊列－存儲－展示－告警，以及協助提供模塊間通訊的API服務。
現在來看，在這個系統架構裏涉及到的技術選型，Python幾乎佔據了半壁江山，包括採集器TCollector、Celery隊列、django展示界面和Tornado。
所以，正如本次大會的主題所說的，我們看到Python正在大數據領域發揮着重要的作用，也希望更多的Pythoner一起來分享自己的成果，貢獻自己的力量。
推薦閱讀：
