大數據下的技術運營（一）——監控系統概覽篇

技術運營團隊的由來

在運維更名為技術運營的兩年內，我們對這個團隊的工作目標產生了新的理解，工作內容也逐漸從傳統的維護往nDevOps方向轉化。技術運營，簡單地講就是利用技術手段，降低資源消耗，提高基礎資源的運行效率，提高整個軟體生命周期運行的效率。這意味著對團隊內n的每個工程師都提出了更高的要求：一方面我們要支持目前的系統運行；同時也要針對目前的業務流程去開發自己的工具，讓整個基礎資源和能力工具化，把經驗和自己對流程的理解變成Web化的工具，提供給程序員使用。

為什麼必須自主研發監控系統

目前在TalkingData的Developer除了負責代碼的編寫，還要負責生產系統自己程序的性能指標提供監控介面，以及生產環境程序bug的處理。Developer能夠一定程度的獲取生產許可權，方便常規的維護和簡單故障的處理。這樣一來，技術運營的挑戰就來了：許可權的管理、性能指標的監控、日誌的管理以及資源的隔離，都需要有成熟的工具去支撐。目n前市面上有很多開源的軟體可以實現這樣的功能，但是在不同程度上存在各種各樣的問題。以監控為例，開源的監控很多，Zabbix、Nagios、nCacti，都是不錯的監控軟體，但是首先它們並不能滿足大數據場景下的數據存儲；其次，如果監控項和主機數量過多，數據查詢時會出現速度慢等一系列問n題。所以技術運營首先選擇在監控上做了全新的設計和開發，新監控命名為OWL（貓頭鷹），意思就是在技術人員睡覺的時候提供值班服務。

自研監控系統的三大技術要點

傳統的監控很多還是在停留在設備、網路、系統相關的監控上，重視數據的採集，但是在數據演算法和Role上比較傳統。對監控系統簡化抽象下，傳統監控可以大致分為三個過程：數據採集、數據存儲、響應處理。OWL監控在傳統監控基礎上，增加了Algorithm模塊，支持複雜的演算法規則報警，如下圖所示：

1. 監控數據採集

Data Collection 就是數據採集，這裡指的數據不光是基礎硬體的指標，也可以是業務指標。下面介紹兩個實例。

第一個例子是主機硬碟狀態的採集：

下n面的數據採集中第一列是硬碟設備標號，第二列是硬碟的狀態，在監控的這個層面，一切都是metric，不同的層級可以抽象到不同的metric，結合 nmetric timestamp tagk1 tagv1… tagkN ntagvN，這樣針對相同的metric去加tag，用來標示數據，方便後期的查詢。

{n "0_1_12": 0, n "0_1_13": 0, n "0_1_10": 0, n "0_1_11": 0, n "0_1_4": 0, n "0_1_5": 0, n "0_1_6": 0, n "0_1_7": 0, n "0_1_0": 0, n "0_1_1": 0, n "0_1_2": 0, n "0_1_3": 0, n "0_1_8": 0, n "0_1_9": 0n}n

第二個例子是Nginx 的訪問狀態的數據採集：

第一列是http請求的狀態，第二列是計數器

{n "200": 29312, n "404": 0, n "499": 60, n "412": 0, n "400": 114, n "502": 0, n "408": 179n}n

2. 監控數據存儲

監控數據的存儲也是一個很有意思的話題，監控數據在數據結構上是很有特色的。仔細觀察發現監控數據基本上都是和時間維度相關的，以metric ＋timestamp的組合形式的數據佔了所有監控數據量的大部分，相比而言，多維度的監控數據比較少；如果出現了多維度的監控數據，也可以通過其他的方式繞開處理。RDBMSn由於要考慮數據的關聯，所以它在整體數據存儲設計上充分考慮了數據的完整性和關係型，同時在 nschema設計上還要遵守資料庫的幾大範式。傳統的監控大多數還是使用了RDBMS，但是這造成了性能上和擴展性上的局限性。針對監控數據這樣簡單的數n據結構，卻採用了一套複雜的存儲格式。隨著近些年各種各樣的垂直的

技術領域對數據的存儲不同要求的演變，如Graph ndatabase，Time Series nDatabases等資料庫得到了不斷發展；監控數據在存儲上有了更多的選擇，InfluxDB，OpenTSDB，KairosDB都是不錯的選擇，最n後我們選擇了OpenTSDB，這主要是因為TalkingData的大數據基因，Hadoop和HBase在我們的業務系統中大規模使用。從現有的數據n體量上，OpenTSDB能夠滿足現在的業務要求。簡單的總結了一下OpenTSDB的優點：

1. 使用HBase存儲，不存在單點故障。
2. 使用HBase存儲，存儲空間幾乎無限。支持永久存儲，可以做容量規劃。
3. 易於定製圖形
4. 能擴展採集數據點到100億級。
5. 能擴展metrics數量到K級別（比如CPU的使用情況，可以算作一個metric，即metric就是1個監控項）
6. 支持秒級別的數據。

此外，OpenTSDB支持API查詢，可以輕鬆地和其他系統進行數據對接，也方便其他系統抽取監控相關的數據。 並且，查詢方式靈活：查詢數據可以使用query介面，它既可以使用get的query string方式，也可以使用post方式以JSON格式指定查詢條件。

3. 監控的報警演算法

Algorithm這塊是傳統監控系統所欠缺的，基本上都是單個指標的大於，小於這樣的演算法，但是遇到集群或者複雜的指標，就需要自己去增加一些演算法，比如多個指標的加和，平均值，top10，歷史相似度等。這些演算法的引入，可以增加報警的準確度，有效的減少報警數量，讓報警變得人性化。 關於報警的演算法會在本系列的後續文章進行詳細介紹。

自研監控系統一覽

簡單的介紹一下OWL的整體架構，下面目前的架構是第四個大版本。在研發的過程中，我們也嘗試了很多的開源技術，如RRDtools、Graphlite，也踩了很多的技術坑，最後我們整體選擇了OpenTSDB，在這個技術棧下面演進了兩個版本：

方案特點一：語言棧統一為Go

2015n年的版本，由於技術人員的稀缺，我們採用了一部分Python一部分Golang的系統，在開源推廣中帶來了很多問題，主要是部署難度增加。2016年即n將發布的版本中，metric ncollection模塊、Controller模塊、Inspector模塊全部採用Golang開發，簡單摘錄一下Golang的優點：

1. 部署簡單。Go 編譯生成的是一個靜態可執行文件，除了 glibc 外沒有其他外部依賴。這讓部署變得異常方便：目標機器上只需要一個基礎系統和必要的管理、監控工具，完全不需要操心應用所需的各種包、庫的依賴關係，大大減輕了維護的負擔。這是與Python 的巨大區別。
2. 並發性好。goroutine 和 channel 使得編寫高並發的服務端軟體變得相當容易，很多情況下完全不需要考慮鎖機制以及由此帶來的各種問題。單個 Go 應用也能有效的利用多個 CPU 核，並行執行的性能好。
3. 良好的語言設計。
4. 執行性能好。雖然不如 C 和 Java，但通常比原生 Python 應用還是高一個數量級的，適合編寫一些瓶頸業務。內存佔用也非常節省。

我們也同樣意識到這樣的問題，所以在OWL V4.0 的版本中，全部統一了語言棧，降低了大家的使用難度，和後期技術棧的維護難度。

方案特點二：定製化自己的圖表

上面的架構圖中，大家不難發現，整個OWL 的設計核心是Custom Report。將整個系統從以工具為核心，轉向以數據和用戶為核心，OWL的好處是首先使用者會自己定義感興趣的數據指標；其次在指標上添加rule，用戶可以更專註數據；隨後可以做一些簡單的數據處理，一些數據加和等這樣的簡單運算；並且定製不同樣式的圖表，餅圖、柱狀圖、線圖。

在整個監控上形成一個立體的結構，不同層面的工程師可以在同一個層面上工作。

有了好的工具支持，才能讓工程師DevOps起來。OWL 新版本中也將會支持Docker的支持，這塊目前採用的主要是google 開源的cAdvisor作為數據採集的，通過二次開發將cAdvisor變成plugin集成進入OWL。

方案特點三：報警模塊的劃分

關n於報警方式，目前沒有放置在OWL中。在TalkingData，所有的報警採用Message center的方式，Message ncenter有獨立的Web，支持基礎的信息查詢，信息的發送對外採用 restful nAPI暴露給其他的系統，信息的傳送方式上，按照消息的優先順序程度，採用不同的下行方式，高＝簡訊＋企業微信＋email；中＝企業微信＋email；n低＝email，目前正在考慮加入商業化的呼轉服務。 具體詳情參見本系列的後續文章：《報警系統的設計與實現》。

總結

OWL 只是TalkingData在DevOps嘗試的其中一個平台。如果從長期的角度去考慮，企業構建自己的運維平台，應該按照雲平台的思路去建設，將工程師定義為整個平台的使用者，要簡化工程師在基礎資源上消耗的時間，降低資源使用的時間成本，這樣才會在DevOps的路上越走越好。

via: InfoQ