監控系統是整個IT架構中的重中之重，小到故障排查、問題定位，大到業務預測、運營管理，都離不開監控系統，可以說一個穩定、健康的IT架構中必然會有一個可信賴的監控系統，而一個監控系統的基石則是一個穩定而健壯的數據採集系統。
定義採集數據
數據結構的選擇
監控數據是標準的時間序列數據，傳統的監控系統中，一條監控數據一般是由監控指標、時間戳和值組成，比如有10臺伺服器的內存使用率需要監控，一個時間周期內映射到系統中可能就是10條mem.userd.percent 時間 值 這種格式的數據，然後分別和對應的主機關聯。
這樣做的缺點是，如果某一時刻想統計某個產品線、業務系統、集群、數據中心的某些監控指標的使用情況，可能就不太好實現。所以我們需要在傳統的數據結構基礎上增加一個欄位，用來存儲我們自定義的數據標籤。為此，我們調研了當前主流的時序資料庫，如RRDtool、Graphite、InfluxDB、openTSDB等，其中RRDtool和Graphite 只能支能持時間維度和值維度，Cacti和Zabbix就是基於RRDtool來繪圖展示的。而InfluxDB和openTSDB都能滿足我們的需求：其中InfluxDB版本比較低，而且每次更新變動都比較大;而openTSDB則在企業中有大量的成功案例。所以在數據結構的定義上，我們借鑑了openTSDB的數據結構，每條數據由metric、timestamp、value、tags組成，用tags鍵值對來標識不同的屬性。比如網卡發送數據包數目為例，其數據結構如下：
Metric是一個可測量的單位的標稱。metric不包括一個數值或一個時間，其僅僅是一個標籤，包含數值和時間的叫datapoints，metric是用逗號連接的不允許有空格，例如：cpu.idle，app.latency等。
Tags：一個metric應該描述什麼東西被測量，其不應該定義的太簡單。通常，更好的做法是用Tags來描述具有相同維度的metric。Tags由tagk和tagv組成，前者表示一個分組，後者表示一個特定的項
Timestamp。一個絕對時間，用來描述一個數值或者一個給定的metric是在什麼時候定義的。
Value。一個Value表示一個metric的實際數值。
這樣對於相同的metric數據，我們可以自由的通過tag的組合來獲取我們真正需要的數據。
三種數據類型
既然有了上面的數據結構的定義，當然就會有數據類型，不同的數據可能代表的意義都不一樣，OWL中採用了RRDtool中比較常用的三種數據類型，分別為GAUGE、COUNTER、DRIVER。
GAUGE類型是一個計量器，可以理解最終存儲的數據就是採集到的數據，比如伺服器上的磁碟使用率，內存使用率，cpu使用率，硬體的溫度，風扇的轉速，業務系統中的訪問時間等等，這種數據會隨時間的變化而變化，並且沒有什麼規律可言。
COUNTER類型是一個計數器，該類型一般用於記錄連續增長的記錄，例如作業系統中的網卡流量，磁碟的io，交換機接口的流量，業務的吞吐量等等，COUNTER類型會假設計數器的值永遠不會減小，除非達到數據類型的最大值產生溢出，OWL客戶端會存儲最近一次的值和上一次的值，每次上報的過程中會取每秒的速率發送到repeater，當計數器溢出，agent會自動對數據進行補值，否則可能會因為溢出產生一個巨大的錯誤值導致錯誤告警。
DRIVER類型用於表示單位時間內的數據變化，簡單來說就是用來表示當前值和上一次值之間的差值，在監控領域中的實際應用場景可能不是很多。
agent每次採集都會判斷數據類型，並應用對應的運算規則。
採集系統的整體架構
架構的變化
相比於上個版本的架構，我們的數據採集系統還是發生了很大的變化，變化主要體現在服務邏輯拆分和重新規劃。
服務端在上個版本中，主要負責agent端配置的維護，監控數據的接收和轉存，網絡設備數據的採集，埠健康狀態監測等功能，當服務端需要進行維護的時候，整個監控服務相當於不可用的。另外也不利於擴展。所以在該版本中對server進行了拆分，分別為cfc、repeater、net-collect，其中cfc主要負責配置維護，repeater負責監控數據接收和轉發，net-collect負責採集網絡設備數據，任何一個組件都可用做到水平擴展，極大的降低了系統的風險。
模塊的角色功能
agent：通過內置metric以及自定義插件方式採集主機硬體、作業系統、中間件、業務系統等數據，並通過tcp長連接異步發送到repeater。
net-collect：負責採集網絡設備各項性能指標，包含各接口接收發送字節數、數據包數、錯誤數等等，監控數據通過tcp長連接發送到repeater中，配置和接口信息發送到cfc中。
cfc：一般部署於數據中心，直連MySQL，負責維護agent或net-collect同步過來的metric信息以及插件的同步等
cfc-proxy：一般部署於分支機構或異地機房，是agent/net-collect和cfc之間的通訊橋梁。
repeater：可任意部署，負責接收時間序列數據並轉發到指定的後端，支持repeater->repeater、repeater->openTSDB、repeater->Redis等。
採集系統如何與應用系統對接
比如我們現在新開發一個應用，那麼我們需要梳理我們需要關心的指標，比如系統的吞吐量、延遲、接口或url訪問量等等，由於OWL不支持主動push數據，所以我們需要將這些數據通過Http REST API 方式暴露出來，然後使用OWL自帶的app_collect插件來定時採集數據，API暴露的數據結構大概如下：
採集系統的上層應用封裝
基於該系統，我們可以在上層構建報警系統，統計分析系統，報表系統等等。大家可以自由去發揮。
其中，報警服務在上個版本中是基於Python 的Celery去實現的，由於依賴眾多模塊，安裝部署複雜，在開源過程中大部分反饋的問題都是在該模塊的部署上。因此，在該版本中我們使用go語言對重構了報警服務，分為控制器和報警邏輯處理模塊：其中控制器負責報警策略生成和報警結果處理;邏輯處理模塊負責從控制器獲取策略並去OpenTSDB讀取數據進行對比，產生的結果返回給控制器處理。整體而言這是一個生產者消費者模型，理論上消費者可用無限擴展。更多報警的具體細節，會在本系列的報警文章中進行詳細的介紹。
總結
數據的採集是起點而非終點，如何對採集到的數據進一步加工處理，並且能夠幫助我們改善工作和生活才是最終目標，我們堅信，數據改變人們的決策方式，數據改善人類自身和環境。
第三十屆CIO班招生 法國布雷斯特商學院碩士班招生 北達軟EXIN網絡空間與IT安全基礎認證培訓 北達軟EXIN DevOps Professional認證培訓責編：pingxiaoli