概述

監控系統是整個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讀取數據進行對比，產生的結果返回給控制器處理。整體而言這是一個生產者消費者模型，理論上消費者可用無限擴展。更多報警的具體細節，會在本系列的報警文章中進行詳細的介紹。

總結

數據的采集是起點而非終點，如何對采集到的數據進一步加工處理，并且能夠幫助我們改善工作和生活才是最終目標，我們堅信，數據改變人們的決策方式，數據改善人類自身和環境。