概述

監(jiān)控系統(tǒng)是整個IT架構中的重中之重，小到故障排查、問題定位，大到業(yè)務預測、運營管理，都離不開監(jiān)控系統(tǒng)，可以說一個穩(wěn)定、健康的IT架構中必然會有一個可信賴的監(jiān)控系統(tǒng)，而一個監(jiān)控系統(tǒng)的基石則是一個穩(wěn)定而健壯的數(shù)據(jù)采集系統(tǒng)。

定義采集數(shù)據(jù)

數(shù)據(jù)結構的選擇

監(jiān)控數(shù)據(jù)是標準的時間序列數(shù)據(jù)，傳統(tǒng)的監(jiān)控系統(tǒng)中，一條監(jiān)控數(shù)據(jù)一般是由監(jiān)控指標、時間戳和值組成，比如有10臺服務器的內存使用率需要監(jiān)控，一個時間周期內映射到系統(tǒng)中可能就是10條mem.userd.percent 時間 值 這種格式的數(shù)據(jù)，然后分別和對應的主機關聯(lián)。

這樣做的缺點是，如果某一時刻想統(tǒng)計某個產(chǎn)品線、業(yè)務系統(tǒng)、集群、數(shù)據(jù)中心的某些監(jiān)控指標的使用情況，可能就不太好實現(xiàn)。所以我們需要在傳統(tǒng)的數(shù)據(jù)結構基礎上增加一個字段，用來存儲我們自定義的數(shù)據(jù)標簽。為此，我們調研了當前主流的時序數(shù)據(jù)庫，如RRDtool、Graphite、InfluxDB、openTSDB等，其中RRDtool和Graphite 只能支能持時間維度和值維度，Cacti和Zabbix就是基于RRDtool來繪圖展示的。而InfluxDB和openTSDB都能滿足我們的需求：其中InfluxDB版本比較低，而且每次更新變動都比較大;而openTSDB則在企業(yè)中有大量的成功案例。所以在數(shù)據(jù)結構的定義上，我們借鑒了openTSDB的數(shù)據(jù)結構，每條數(shù)據(jù)由metric、timestamp、value、tags組成，用tags鍵值對來標識不同的屬性。比如網(wǎng)卡發(fā)送數(shù)據(jù)包數(shù)目為例，其數(shù)據(jù)結構如下：

Metric是一個可測量的單位的標稱。metric不包括一個數(shù)值或一個時間，其僅僅是一個標簽，包含數(shù)值和時間的叫datapoints，metric是用逗號連接的不允許有空格，例如：cpu.idle，app.latency等。

Tags：一個metric應該描述什么東西被測量，其不應該定義的太簡單。通常，更好的做法是用Tags來描述具有相同維度的metric。Tags由tagk和tagv組成，前者表示一個分組，后者表示一個特定的項

Timestamp。一個絕對時間，用來描述一個數(shù)值或者一個給定的metric是在什么時候定義的。

Value。一個Value表示一個metric的實際數(shù)值。

這樣對于相同的metric數(shù)據(jù)，我們可以自由的通過tag的組合來獲取我們真正需要的數(shù)據(jù)。

三種數(shù)據(jù)類型

既然有了上面的數(shù)據(jù)結構的定義，當然就會有數(shù)據(jù)類型，不同的數(shù)據(jù)可能代表的意義都不一樣，OWL中采用了RRDtool中比較常用的三種數(shù)據(jù)類型，分別為GAUGE、COUNTER、DRIVER。

GAUGE類型是一個計量器，可以理解最終存儲的數(shù)據(jù)就是采集到的數(shù)據(jù)，比如服務器上的磁盤使用率，內存使用率，cpu使用率，硬件的溫度，風扇的轉速，業(yè)務系統(tǒng)中的訪問時間等等，這種數(shù)據(jù)會隨時間的變化而變化，并且沒有什么規(guī)律可言。

COUNTER類型是一個計數(shù)器，該類型一般用于記錄連續(xù)增長的記錄，例如操作系統(tǒng)中的網(wǎng)卡流量，磁盤的io，交換機接口的流量，業(yè)務的吞吐量等等，COUNTER類型會假設計數(shù)器的值永遠不會減小，除非達到數(shù)據(jù)類型的最大值產(chǎn)生溢出，OWL客戶端會存儲最近一次的值和上一次的值，每次上報的過程中會取每秒的速率發(fā)送到repeater，當計數(shù)器溢出，agent會自動對數(shù)據(jù)進行補值，否則可能會因為溢出產(chǎn)生一個巨大的錯誤值導致錯誤告警。

DRIVER類型用于表示單位時間內的數(shù)據(jù)變化，簡單來說就是用來表示當前值和上一次值之間的差值，在監(jiān)控領域中的實際應用場景可能不是很多。

agent每次采集都會判斷數(shù)據(jù)類型，并應用對應的運算規(guī)則。

采集系統(tǒng)的整體架構

架構的變化

相比于上個版本的架構，我們的數(shù)據(jù)采集系統(tǒng)還是發(fā)生了很大的變化，變化主要體現(xiàn)在服務邏輯拆分和重新規(guī)劃。

服務端在上個版本中，主要負責agent端配置的維護，監(jiān)控數(shù)據(jù)的接收和轉存，網(wǎng)絡設備數(shù)據(jù)的采集，端口健康狀態(tài)監(jiān)測等功能，當服務端需要進行維護的時候，整個監(jiān)控服務相當于不可用的。另外也不利于擴展。所以在該版本中對server進行了拆分，分別為cfc、repeater、net-collect，其中cfc主要負責配置維護，repeater負責監(jiān)控數(shù)據(jù)接收和轉發(fā)，net-collect負責采集網(wǎng)絡設備數(shù)據(jù)，任何一個組件都可用做到水平擴展，極大的降低了系統(tǒng)的風險。

模塊的角色功能

agent：通過內置metric以及自定義插件方式采集主機硬件、操作系統(tǒng)、中間件、業(yè)務系統(tǒng)等數(shù)據(jù)，并通過tcp長連接異步發(fā)送到repeater。

net-collect：負責采集網(wǎng)絡設備各項性能指標，包含各接口接收發(fā)送字節(jié)數(shù)、數(shù)據(jù)包數(shù)、錯誤數(shù)等等，監(jiān)控數(shù)據(jù)通過tcp長連接發(fā)送到repeater中，配置和接口信息發(fā)送到cfc中。

cfc：一般部署于數(shù)據(jù)中心，直連MySQL，負責維護agent或net-collect同步過來的metric信息以及插件的同步等

cfc-proxy：一般部署于分支機構或異地機房，是agent/net-collect和cfc之間的通訊橋梁。

repeater：可任意部署，負責接收時間序列數(shù)據(jù)并轉發(fā)到指定的后端，支持repeater->repeater、repeater->openTSDB、repeater->Redis等。

采集系統(tǒng)如何與應用系統(tǒng)對接

比如我們現(xiàn)在新開發(fā)一個應用，那么我們需要梳理我們需要關心的指標，比如系統(tǒng)的吞吐量、延遲、接口或url訪問量等等，由于OWL不支持主動push數(shù)據(jù)，所以我們需要將這些數(shù)據(jù)通過Http REST API 方式暴露出來，然后使用OWL自帶的app_collect插件來定時采集數(shù)據(jù)，API暴露的數(shù)據(jù)結構大概如下：

采集系統(tǒng)的上層應用封裝

基于該系統(tǒng)，我們可以在上層構建報警系統(tǒng)，統(tǒng)計分析系統(tǒng)，報表系統(tǒng)等等。大家可以自由去發(fā)揮。

其中，報警服務在上個版本中是基于Python 的Celery去實現(xiàn)的，由于依賴眾多模塊，安裝部署復雜，在開源過程中大部分反饋的問題都是在該模塊的部署上。因此，在該版本中我們使用go語言對重構了報警服務，分為控制器和報警邏輯處理模塊：其中控制器負責報警策略生成和報警結果處理;邏輯處理模塊負責從控制器獲取策略并去OpenTSDB讀取數(shù)據(jù)進行對比，產(chǎn)生的結果返回給控制器處理。整體而言這是一個生產(chǎn)者消費者模型，理論上消費者可用無限擴展。更多報警的具體細節(jié)，會在本系列的報警文章中進行詳細的介紹。

總結

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