綜述
日誌和監控開發人員工作中必不可少的兩隻眼睛，日誌是為了快速定位排查故障，監控是為了發現潛在問題並能及時告警，是故障診斷和分析的重要輔助利器，同樣監控系統對大資料平臺重要性不言而喻。在發生事故之前就能預警，最大限度降低系統故障率，是監控的終極目標和價值體現。本文旨在幫助大家瞭解監控系統，並能快速搭建公司的監控平臺。
監控體系
監控粒度、監控指標完整性、監控實時性是評價監控系統的三要素。從分層體系可以把監控系統分為三個層次：
業務層
：業務系統本質目的是為了達成業務目標，因此監控業務系統是否正常最有效的方式是從資料上監控業務目標是否達成。對業務運營資料進行監控，可及時發現程式bug或業務邏輯設計缺陷，比如註冊失敗率、登入失敗率、付款失敗率等。業務系統的多樣性決定了應由各個業務系統實現監控指標開發。
應用層
：對應用的整體執行狀況進行了解、把控，如果將應用當成黑盒子，開發、運維就無從知曉應用當前狀態，不能及時發現潛在故障。應用監控不應侷限於業務系統，還包括各種中介軟體、計算引擎，如Spark、Jstorm、redis、zookeeper、kafka等。常用監控資料：JVM堆記憶體、GC、CPU使用率、執行緒數、TPS、吞吐量等。一般透過抽象出的統一指標收集元件，收集應用級指標，比如不管是支付系統還是交易系統，都要監控jvm記憶體使用。
系統層：
實時掌握伺服器工作狀態，留意效能、記憶體消耗、容量和整體系統健康狀態，保證伺服器穩定執行。監控指標：記憶體、磁碟、CPU、網路流量、系統程序等系統級效能指標
架構設計
工欲善其事必先利其器，根據對現有監控產品的調研，以及我們對監控的分層介紹、所需解決的問題，可以發現監控系統從收集到分析的流程架構：採集－儲存－展示－告警：
Telegraf
：外掛化的指標收集和指標報告服務，能定製化開發並輕鬆新增所需外掛。已經內建了很多常用服務的外掛，這也是我們選擇telegraf的原因之一，不用再重複造輪子
InfluxDB
：高效能的布式時間序列指標資料庫。監控指標收集是非常頻繁的，否則就失去了實時性，高頻收集的結果就是大資料量，也要對時間序列進行分析，InfluxDB就能滿足這種應用場景
Grafana
：時間序列分析和監控的開放平臺，支援多種資料來源（InfluxDB、OpenTSDB時間序列資料庫）、豐富的展現形式、支援email/dingding報警
Telegraf
go語言編寫的外掛化指標收集agent，編譯成一個沒有外部依賴的二進位制檔案，安裝部署很便捷，直接下載、解壓就行，預設配置檔案在$TELEGRAF_HOME/etc/telegraf/telegraf。conf目錄下。telegraf外掛分為兩大類：input、output。
input
：收集inputs配置的所有指標，已內建的input外掛：elasticsearch、redis、jolokia等。也可直接收集執行agent server的各種指標，比如記憶體、cpu、磁碟、磁碟IO、程序、swap等。input配置都很簡明易用，一般只需配置服務IP地址就可以，如redis指標收集配置：
如果沒有內建收集外掛，有兩種實現方案：
開發input外掛，但這需要有GO語言基礎
藉助於httpjson input外掛，該外掛請求http url，返回json格式。url配置為自定義指標收集服務，在指標收集服務內實現指標收集功能，然後指標封裝成json返回或指標資料直接在服務內入庫。我們監控Kettle Carte、spark、jstorm等用的這種實現思路。
output
：將收集到的度量資料序列化儲存，Telegraf指標由四個部分組成：度量、標籤、欄位、時間戳。支援以下儲存結構：InfluxDB、Graphite、JSON，比如度量輸出到InfluxDB的配置：
urls
：InfluxDB埠
database
：儲存的資料庫
retention_policy
：資料保留策略
排程頻率：
所有指標收集頻率是一樣的，在配置檔案agent項下配置：
服務啟動
：
——config：配置檔案
——config-directory：配置檔案目錄，如果有多個配置檔案時使用
InfluxDB
InfluxDB是為時間序列構建的高效能資料儲存，提供類SQL的查詢語言、特定分析時間序列的功能。透過設定資料保留策略，自動從系統中刪除過期資料，釋放儲存空間。社群版只支援單臺伺服器，會有單點故障風險，商業版版支援高可用，對我們來說，單機InfluxDB已經能滿足需求。選擇InfluxDB的原因：
InflluxDB是用GO寫的，編譯後是一個完全無依賴的二進位制檔案，安裝部署非常便捷，解壓縮包即可
高效能時間序列專有資料庫，對時間序列的儲存和查詢都做了最佳化
類SQL查詢語言，降低使用門檻
資料保留策略可以有效的自動清理過期資料
InfluxDB的資料是以shard groups形式儲存，指定時間間隔的資料儲存到一個shard groups裡，這個時間間隔稱為shardGroupDuration。
服務啟動
：
influx進入shell命令列
：
常用命令
：
show databases：檢視所有資料庫
use db_name：進入資料庫
show measurements：顯示資料庫下所有度量
select *from cpu limit 10：查詢一個度量的資料
Telegraf預設是將收集的資料持久化到telegraf這個資料庫下，每個input對應一個度量表，比如zookeeper的指標資料就在zookeeper這個度量下：
查詢資料保留策略：
duration：資料保留時間，0表示無限制，InfluxDB預設30分鐘檢查一次保留策略。ALTER RETENTION語句修改保留7天資料。
replicaN：每個度量在集群裡的副本數，副本保證資料高可用性，社群版（單節點）不支援副本數設定
Java Client
：
Java Client對http api進行了封裝，底層用Retrofit框架進行http請求，是執行緒安全的，只需在一個應用中建立一個InfluxDB Client物件。
client的寫操作支援batch，其實現原理
：
1、建立後臺單執行緒定時排程任務，執行緒每隔一定時間傳送請求：
2、每次writer時，把請求放到BlockingQueue佇列裡，如果佇列大於batch數，就啟動執行緒傳送請求：
Client Api使用例子:
1、建立資料庫連線：
InfluxDB influxDB= InfluxDBFactory。connect（url， user， password）；
url：InfluxDB的地址和埠，比如 http：//localhost：8086
user/password：InfluxDB的使用者名稱/密碼
2、設定訪問的資料庫：
influxDB。setDatabase（database）；
3、資料寫入：
Point。Builder builder = Point。measurement（measurement）；
builder。tag（tags）；
builder。fields（fields）；
influxDB。write（builder。build（））；
Grafana
Grafana是一個指標查詢、視覺化、監控的開源應用，有著非常漂亮的圖表和佈局展示，功能齊全的度量儀表盤和圖形編輯器，支援Graphite、zabbix、InfluxDB、Prometheus和OpenTSDB作為資料來源。
Grafana主要特性
：
靈活豐富的圖形化元件，包括熱力圖、直方圖、地圖等
在同一dashboard內可以混合多種展示元件
開源社群有大量的外掛可供選擇，包括資料來源外掛、圖形外掛、通知外掛
可以在同一個視圖裡使用多個不同資料來源
簡單使用介紹
：
安裝：
下載&解壓二進位制包
配置：
配置檔案：$GRAFANA_HOME$/conf
配置埠號、Email、登入使用者
start：
命令：/opt/grafana/bin/grafana-server start
訪問：
http：//ip：port
連線資料來源、圖表開發、報警設定可參看官方文件
本文為原創，
歡迎分享到朋友圈。
