提到監(jian)測，有很(hen)多成(cheng)熟的(de)(de)(de)解決方(fang)案，似(si)乎已(yi)經沒(mei)有再(zai)討論的(de)(de)(de)必(bi)要(yao)，但(dan)隨著計算(suan)機技術(shu)的(de)(de)(de)發展，越來(lai)越多的(de)(de)(de)場景(jing)開始(shi)需(xu)要(yao)監(jian)測，它會向著更(geng)深(shen)更(geng)廣的(de)(de)(de)方(fang)向發展。從業務(wu)領域來(lai)看，運(yun)維、電力(li)、交通、工控(kong)、煤炭、油氣(qi)、科研等，所有具(ju)有量化(hua)監(jian)測指標的(de)(de)(de)產業，都(dou)需(xu)要(yao)數據的(de)(de)(de)采集、存儲、分析、可(ke)視化(hua)。但(dan)具(ju)體到不同業務(wu)，其監(jian)測的(de)(de)(de)重點卻可(ke)以差別很(hen)大。

運維監測系統概述

本文將業務領域局限在IT運(yun)維監測(ce)方向，談談這(zhe)里面需要關注的(de)一(yi)些事情(qing)。IT運(yun)維監測(ce)數據通常(chang)都(dou)是(shi)對時(shi)間特性比較敏感的(de)數據，例如

• 系統資源指標：CPU、內存、IO、帶寬等
• 軟件系統指標：存活狀態、連接數目、請求數目、超時數目、錯誤數目、響應時間、服務類型及其他與業務有關的指標

這些數(shu)據的(de)來源很豐富。可以來自(zi)操作系(xi)(xi)統自(zi)帶命(ming)令，如(ru)free、vmstat、sar、iostat等。如(ru)果程序(xu)部署在Tomcat、WebLogic、IIS、JBoss等容器(qi)上(shang)(shang)，則由(you)這些容器(qi)對外提供(gong)采集接(jie)口。但真(zhen)正對軟件系(xi)(xi)統起作用(yong)的(de)，業務(wu)(wu)上(shang)(shang)真(zhen)正關注(zhu)的(de)指標，主要(yao)來自(zi)于數(shu)據埋(mai)點(dian)。埋(mai)點(dian)的(de)事情有很多，前(qian)后端都可能有，通常都是(shi)業務(wu)(wu)上(shang)(shang)的(de)行(xing)為，但是(shi)如(ru)何存儲與分析埋(mai)點(dian)后的(de)數(shu)據，是(shi)監測系(xi)(xi)統的(de)一個重要(yao)問題。通過以上(shang)(shang)實(shi)時采集的(de)數(shu)據，主要(yao)目標是(shi)獲得如(ru)下信息

• 宿主機的健康狀態
• 軟件是否處于正常運行狀態，系統穩定性如何
• 軟件負載情況，是否能夠滿足線上性能要求，是否需要增加實例，性能的瓶頸在哪里，如何提高性能
• 用戶行為分析、用戶畫像

運維監測系統的組成

一個典型的(de)監測系統，通常(chang)分為(wei)數(shu)(shu)據(ju)采集、數(shu)(shu)據(ju)傳輸、數(shu)(shu)據(ju)存儲、數(shu)(shu)據(ju)統計分析、數(shu)(shu)據(ju)可視化五個模塊，分析結果最(zui)終會反(fan)饋到(dao)產品經(jing)理或者軟(ruan)件研發人員，以確保線上軟(ruan)件穩定運(yun)行，并進一步提供改進軟(ruan)件的(de)關鍵信(xin)息。

1.數據采集模塊

數(shu)據采(cai)集是(shi)(shi)監測系統(tong)的(de)第一步，采(cai)集信息是(shi)(shi)否(fou)豐富、是(shi)(shi)否(fou)足(zu)夠準確、是(shi)(shi)否(fou)存夠實時，直接影響到了監測系統(tong)的(de)應(ying)用(yong)效(xiao)果。

如果是(shi)(shi)對主機狀態、軟件(jian)(jian)基本運(yun)行情況進行數據(ju)采集，最簡單易(yi)用的是(shi)(shi)Telegraf，它是(shi)(shi)一個(ge)插件(jian)(jian)驅動的服務器(qi)代(dai)理程序，可直接從其運(yun)行的容(rong)器(qi)和(he)系(xi)統中(zhong)提取(qu)各種指(zhi)標，事件(jian)(jian)和(he)日志，從第三方API提取(qu)指(zhi)標。Telegraf還具有輸出插件(jian)(jian)，可將指(zhi)標發送到各種其他數據(ju)存儲，服務和(he)消息隊列，包括InfluxDB、OpenTSDB、TDengine、NSQ等等。

如果(guo)是對軟(ruan)件系統產生(sheng)的(de)(de)(de)日(ri)(ri)(ri)志(zhi)(zhi)數據做數據采(cai)集，則(ze)需要該軟(ruan)件系統的(de)(de)(de)開發(fa)人(ren)(ren)員來完(wan)(wan)成。日(ri)(ri)(ri)志(zhi)(zhi)數據可分(fen)(fen)為結(jie)(jie)構(gou)化(hua)日(ri)(ri)(ri)志(zhi)(zhi)和(he)非(fei)(fei)結(jie)(jie)構(gou)化(hua)日(ri)(ri)(ri)志(zhi)(zhi)兩類，對業務分(fen)(fen)析(xi)有益的(de)(de)(de)數據，通常是結(jie)(jie)構(gou)化(hua)的(de)(de)(de)，只是采(cai)用(yong)非(fei)(fei)結(jie)(jie)構(gou)化(hua)的(de)(de)(de)文本(ben)進行了(le)表示而已。很(hen)多軟(ruan)件開發(fa)人(ren)(ren)員因為偷懶，但更多的(de)(de)(de)是沒有這方面(mian)的(de)(de)(de)意識，隨意的(de)(de)(de)編寫記錄日(ri)(ri)(ri)志(zhi)(zhi)的(de)(de)(de)程序(xu)。這些日(ri)(ri)(ri)志(zhi)(zhi)因而格式(shi)變化(hua)較大，壓(ya)縮(suo)比(bi)很(hen)差，等于(yu)將數據存儲成本(ben)和(he)數據分(fen)(fen)析(xi)的(de)(de)(de)工(gong)作量完(wan)(wan)全推給了(le)下(xia)游的(de)(de)(de)數據分(fen)(fen)析(xi)人(ren)(ren)員，而分(fen)(fen)析(xi)人(ren)(ren)員受限于(yu)采(cai)用(yong)的(de)(de)(de)開發(fa)工(gong)具(ju)，基本(ben)上無法(fa)準確(que)、實時的(de)(de)(de)給出分(fen)(fen)析(xi)結(jie)(jie)果(guo)。恰巧(qiao)，軟(ruan)件系統中最容易更改(gai)且影(ying)響面(mian)最小的(de)(de)(de)就是日(ri)(ri)(ri)志(zhi)(zhi)模塊(kuai)，所以，把日(ri)(ri)(ri)志(zhi)(zhi)模塊(kuai)抽象、改(gai)進、使得日(ri)(ri)(ri)志(zhi)(zhi)結(jie)(jie)構(gou)化(hua)，這是比(bi)較重要且簡(jian)單的(de)(de)(de)工(gong)作。

2.數據傳輸模塊

網(wang)絡環境不(bu)會是監控系統要考(kao)慮的主要問題，但是考(kao)慮到(dao)監控數據(ju)的大小和實時性(xing)要求，可以將日志區分慢(man)日志和快(kuai)日志。

對快(kuai)日(ri)志(zhi)(zhi)，比(bi)較流(liu)行的(de)傳輸方式采用(yong)(yong)RESTFul接口(kou)，不同點在于選擇Pull還是(shi)Push。如果是(shi)與業務關聯(lian)比(bi)較多的(de)，建議采用(yong)(yong)Push方式，保證實時性的(de)同時，也(ye)不需(xu)(xu)要(yao)(yao)緩存數據。Pull方式則比(bi)較簡單，一般只需(xu)(xu)要(yao)(yao)被監控的(de)軟件系統(tong)提(ti)供(gong)(gong)Http接口(kou)即可，適用(yong)(yong)于拉(la)取一些簡單數值，例如系統(tong)狀態(tai)、訪問數量(liang)、訪問時間等。快(kuai)日(ri)志(zhi)(zhi)一般需(xu)(xu)要(yao)(yao)存儲(chu)到實時分析(xi)系統(tong)，以(yi)生成實時報表為(wei)主要(yao)(yao)目(mu)標(biao)。TDengine提(ti)供(gong)(gong)的(de)RESTFul接口(kou)，可以(yi)快(kuai)速(su)處理(li)(li)Push過來的(de)Http請求，實時處理(li)(li)快(kuai)日(ri)志(zhi)(zhi)。

慢日志通(tong)常記到(dao)日志文件，然后再(zai)單獨做一個(ge)通(tong)用的日志收集(ji)程序，將日志寫入(ru)到(dao)Kafka中，再(zai)分(fen)流出(chu)去。之后，由日志機(ji)消費(fei)這些(xie)數(shu)據，進入(ru)到(dao)數(shu)據存儲模塊(kuai)中。

3.數據存儲模塊

數據存儲選型在監測系統中至關重要，可供選擇的大數據引擎很多。針對時序數據做了優化的，例如Prometheus、InfluxDB、TDengine、ClickHouse、OpenTSDB、Graphite等時序數據庫；通用(yong)分析型(xing)(xing)的，例如Hadoop體系及其上的流式(shi)計算(suan)引擎。具體怎么選？還是要(yao)從(cong)記錄的數據類型(xing)(xing)來看，關注的指標可以從(cong)寫入(ru)速(su)度、采集頻率、數據壓(ya)縮比、查詢分析速(su)度方面著手。

如(ru)(ru)果和時間(jian)關聯不大(da)，采(cai)用Hadoop處理這類問(wen)題較(jiao)好。如(ru)(ru)果確(que)實(shi)是時序(xu)(xu)數(shu)據的，則采(cai)用時序(xu)(xu)數(shu)據庫(ku)比(bi)較(jiao)好。在時序(xu)(xu)數(shu)據庫(ku)上，如(ru)(ru)果為(wei)(wei)非結構化數(shu)據的，可以采(cai)用InfluxDB、OpenTSDB、Cassendra、MongoDB，如(ru)(ru)果為(wei)(wei)結構化數(shu)據的，可以采(cai)用Prometheus、ClickHouse、TDengine。后面這三種(zhong)，Prometheus受限(xian)于設(she)計，需要(yao)在水平擴展(zhan)的問(wen)題上妥善(shan)考慮；ClickHouse偏重(zhong)于分析，實(shi)時數(shu)據的處理能力(li)稍差；TDengine推出時間(jian)較(jiao)短，但在寫入速(su)度、查詢速(su)度、壓縮(suo)比(bi)等方面都有突(tu)出的性能表現(xian)。

4.數據統計分析模塊

統計分(fen)(fen)析(xi)的(de)目(mu)標，不(bu)應該被選(xuan)擇的(de)存(cun)儲引擎限制(zhi)了想象力。但是通常來說，監控數據的(de)統計分(fen)(fen)析(xi)也都是與時(shi)間序列(lie)(lie)有關的(de)一系列(lie)(lie)分(fen)(fen)析(xi)，可以分(fen)(fen)為兩類

• 實時分析：最新值、實時曲線、流式計算、滑動窗口、歷史截面等
• 非實時分析：年報、月報、日報、分組、聚合等

這些指標的查詢性(xing)能(neng)，是選擇數(shu)據存儲引擎的關(guan)鍵因素(su)。TDengine查詢性(xing)能(neng)非(fei)常好，能(neng)夠(gou)將絕大多數(shu)傳統思(si)維(wei)下的非(fei)實(shi)時分析(xi)，轉變為(wei)實(shi)時分析(xi)，充(chong)分利用這個特(te)點，可以為(wei)用戶提供新功能(neng)，進一步(bu)拓(tuo)展新業務。

5.數據可視化模塊

數據可視(shi)化方面(mian)，除了Grafana之外，并(bing)沒有太多可供選擇的(de)開源可視(shi)化軟件。如(ru)果部門內部使用，是(shi)(shi)足(zu)夠的(de)；如(ru)果是(shi)(shi)對外的(de)項目，或者需要跨部門提供數據，就需要自己編(bian)寫更(geng)加易(yi)用、查詢條件更(geng)豐富的(de)界面(mian)，展示實時或者定時任務(wu)的(de)計算結果，以期(qi)得(de)到(dao)更(geng)好的(de)反(fan)饋。

基于TDengine Database的運維監測系統的快速搭建

參(can)照TDengine Database的白皮書(shu)，它(ta)創(chuang)新性的定義了時序數(shu)(shu)(shu)據的存(cun)儲結構，而且具備安裝使用方便(bian)、壓縮比(bi)高、查詢性能(neng)(neng)好等特(te)點，特(te)別適用于處理實時監測(ce)(ce)類數(shu)(shu)(shu)據。與具體業務上(shang)有關(guan)的監測(ce)(ce)邏輯(ji)，不(bu)容易舉例說明。但由于TDengine能(neng)(neng)夠與開源數(shu)(shu)(shu)據采集(ji)系(xi)統Telegraf和(he)開源數(shu)(shu)(shu)據可視化系(xi)統Grafana快(kuai)(kuai)速集(ji)成，所以本節參(can)照以上(shang)各(ge)系(xi)統的用戶(hu)手冊(ce)，快(kuai)(kuai)速搭建運維數(shu)(shu)(shu)據監測(ce)(ce)系(xi)統，整個(ge)過程無需任(ren)何(he)代(dai)碼開發。

1.架構圖

2.TDengine的安裝與配置

• 下載tdengine-1.6.0.0.tar.gz，地址//yakult-sh.com.cn/downloads/
• 安裝TDengine，解壓后運行install.sh進行安裝
• 啟動TDengine，運行sudo systemctl start taosd
• 測試是否安裝成功，運行TDengine的shell命令行程序taos，可以看到如下類似信息

Welcome to the TDengine shell, server version:1.6.0  client version:1.6.0
Copyright (c) 2017 by TAOS Data, Inc. All rights reserved.

taos> 

3.Telegraf的安裝與配置

• 下載telegraf_1.7.4-1_amd64.deb，地址//portal.influxdata.com/downloads/
• 安裝telegraf，sudo dpkg -i telegraf_1.7.4-1_amd64.deb
• 配置telegraf，修改Telegraf配置文件/etc/telegraf/telegraf.conf中與TDengine有關的配置項

在output plugins部分，修改[[outputs.http]]配(pei)置項

url：//ip:6020/telegraf/udb，其中ip為TDengine集群的中任意一臺服務器的IP地址，6020為TDengine RESTful接口的端口號，telegraf為固定關鍵字，udb為用于存儲采集數據的數據庫名稱，可預先創建
method: "POST" 
username: 登錄TDengine的用戶名
password: 登錄TDengine的密碼
data_format: "json"
json_timestamp_units: "1ms"

例如

[[outputs.http]]
   url = "//127.0.0.1:6020/telegraf/udb"
   method = "POST"
   username = "root"
   password = "taosdata"
   data_format = "json"
   json_timestamp_units = "1ms"

在agent部分(fen)，修改如(ru)下配置項

hostname: 區分不同采集設備的機器名稱，需確保其唯一性
metric_batch_size: 30，允許Telegraf每批次寫入記錄最大數量，增大其數量可以降低Telegraf的請求發送頻率，但對于TDegine，該數值不能超過50

例如

[agent]
   hostname = "gsl"
   metric_batch_size = 30
   interval = "10s"
   debug = true
   omit_hostname = false

• 啟動telegraf，sudo systemctl start telegraf
• 測試是否接收到Telegraf的數據
  • 在shell中輸入show databases語句，應該看到名為udb的數據庫
  • 運行use udb語句
  • 運行show stables語句，可以看到cpu等超級表
  • 運行show stables語句，可以看到cpu_gsl_cpu0等普通數據表

3.Grafana的安裝與配置

• 下載grafana_6.2.5_amd64.deb，地址//grafana.com/grafana/download
• 安裝Grafana，sudo dpkg -i grafana_6.2.5_amd64.deb
• 配置Grafana，TDengine 的 Grafana 插件 /usr/local/taos/connector/grafana 目錄下，將之拷貝到/var/lib/grafana/plugins 目錄
• 啟動Grafana，sudo systemctl start taosd
• 用戶可以直接通過localhost:3000的網址，登錄Grafana服務器(用戶名/密碼:admin/admin)，配置TDengine數據源，此時可以在數據源列表中看到TDengine數據源類型

• 在Host文本框中輸入//localhost:6020并保存

• 然后，就可以在Grafana的數據源列表中看到剛創建好的TDengine的數據源

• 創建Dashboard的時候使用TDengine數據源

• 點擊Add Query按鈕增加三個新查詢，在INPUT SQL輸入框中輸入查詢SQL語句，該SQL語句的結果集應為兩行多列的曲線數據，例如

select avg(f_usage_idle) from udb.cpu WHERE ts>=$from and ts<$to interval($interval)

其中，$from、$to和$interval為TDengine插件的內置變量，表示從Grafana插件面板獲取的查詢范圍和時間間隔
點擊GENERATE SQL按鈕可以看到Grafana發給TDengine的SQL語句。

select avg(f_usage_idle) from udb.cpu WHERE ts>='2019-07-04T01:23:44.509Z' and ts<'2019-07-04T07:23:44.511Z' interval(20000a)

總結

監測(ce)系統可以采用的技術方案有很多，如(ru)果(guo)僅僅是(shi)做(zuo)一個(ge)玩具，選擇(ze)面是(shi)很大的。但若(ruo)監測(ce)的數據量很大，對于寫入(ru)尤其是(shi)分(fen)析性能(neng)要求很高的場景，不妨試(shi)試(shi)TDengine Database。

本文(wen)只是(shi)簡單(dan)對TDengine使(shi)用做(zuo)了初步探討(tao)，要想真正了解它超強的讀寫(xie)能力(li)，還(huan)需要進一步構造(zao)大規(gui)模的測試數據集。