概述

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

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

數(shù)據(jù)結(jié)構(gòu)的選擇

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

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

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

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

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

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

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

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

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

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

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

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

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

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

架構(gòu)的變化

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

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

模塊的角色功能

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

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

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

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

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

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

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

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

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

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

總結(jié)

數(shù)據(jù)的采集是起點(diǎn)而非終點(diǎn)，如何對(duì)采集到的數(shù)據(jù)進(jìn)一步加工處理，并且能夠幫助我們改善工作和生活才是最終目標(biāo)，我們堅(jiān)信，數(shù)據(jù)改變?nèi)藗兊臎Q策方式，數(shù)據(jù)改善人類自身和環(huán)境。