vivo 服務端監控架構設計與實踐
一、業務背景
當今時代處在信息大爆發的時代，信息藉助互聯網的潮流在全球自由的流動，產生了各式各樣的平台系統和軟件系統，越來越多的業務也會導致系統的複雜性。
當核心業務出現了問題影響用戶體驗，開發人員沒有及時發現，發現問題時已經為時已晚，又或者當服務器的CPU持續增高，磁盤空間被打滿等，需要運維人員及時發現並處理，這就需要一套有效的監控系統對其進行監控和預警。
如何對這些業務和服務器進行監控和維護是我們開發人員和運維人員不可忽視的重要一環，這篇文章全篇大約5000多字，我將對vivo服務端監控的原理和架構演進之路做一次系統性整理，以便大家做監控技術選型時參考。
vivo服務端監控旨在為服務端應用提供包括系統監控、JVM監控以及自定義業務指標監控在內的一站式數據監控，並配套實時、多維度、多渠道的告警服務，幫助用戶及時掌握應用多方面狀態，事前及時預警發現故障，事後提供詳實的數據用於追查定位問題，提升服務可用性。目前vivo服務端監控累計接入業務方數量達到200+，本文介紹的是服務端監控，我司還有其他類型的優秀監控包括通用監控、調用鏈監控和客戶端監控等。
1.1 監控系統的基本流程
無論是開源的監控系統還是自研的監控系統，整體流程都大同小異。
1）數據採集：可以包括JVM監控數據如GC次數，線程數量，老年代和新生代區域大小；系統監控數據如磁盤使用使用率，磁盤讀寫的吞吐量，網絡的出口流量和入口流量，TCP連接數；業務監控數據如錯誤日誌，訪問日誌，視頻播放量，PV，UV等。
2）數據傳輸：將採集的數據以消息形式或者 HTTP 協議的形式等上報給監控系統。
3）數據存儲：有使用 MySQL、Oracle 等 RDBMS 存儲的，也有使用時序數據庫OpenTSDB、InfluxDB 存儲的，還有使用 HBase 直接存儲的。
4）數據可視化：數據指標的圖形化展示，可以是折線圖，柱狀圖，餅圖等。
5）監控告警：靈活的告警設置，以及支持郵件、短訊、IM 等多種通知通道。
1.2 如何規範的使用監控系統
在使用監控系統之前，我們需要了解監控對象的基本工作原理，例如JVM監控，我們需要清楚JVM的內存結構組成和常見的垃圾回收機制；其次需要確定如何去描述和定義監控對象的狀態，例如監控某個業務功能的接口性能，可以監控該接口的請求量，耗時情況，錯誤量等；在確定了如何監控對象的狀態之後，需要定義合理的告警閾值和告警類型，當收到告警提醒時，幫助開發人員及時發現故障；最後建立完善的故障處理體系，收到告警時迅速響應，及時處理線上故障。
二、vivo服務端監控系統架構及演進之路
在介紹vivo服務端監控系統架構之前，先帶大家了解一下OpenTSDB時序數據庫，在了解之前說明下為什麼我們會選擇OpenTSDB，原因有以下幾點：
1） 監控數據採集指標在某一時間點具有唯一值，沒有複雜的結構及關係。
2）監控數據的指標具有隨着時間不斷變化的特點。
3）基於HBase分佈式、可伸縮的時間序列數據庫，存儲層不需要過多投入精力，具有HBase的高吞吐，良好的伸縮性等特點。
4）開源，Java實現，並且提供基於HTTP的應用程序編程接口，問題排查快可修改。
2.1 OpenTSDB簡介
1）基於HBase的分佈式的，可伸縮的時間序列數據庫，主要用途就是做監控系統。譬如收集大規模集群（包括網絡設備、操作系統、應用程序）的監控數據並進行存儲和查詢，支持秒級數據採集，支持永久存儲，可以做容量規劃，並很容易地接入到現有的監控系統里，OpenTSDB的系統架構圖如下：
（來自官方文檔）
存儲結構單元為Data Point，即某個Metric在某個時間點的數值。Data Point包括以下部分：
-
Metric，監控指標名稱；
-
Tags，Metric的標籤，用來標註類似機器名稱等信息，包括TagKey和TagValue；
-
Value，Metric對應的實際數值，整數或小數；
-
Timestamp，時間戳。
核心存儲兩張表：tsdb和tsdb-uid。表tsdb用來存儲監控數據，如下圖：
（圖片出處：//www.jianshu.com）
Row Key為Metric+Timestamp的小時整點+TagKey+TagValue，取相應的位元組映射組合起來；列族t下的Qualifier為Timestamp的小時整點余出的秒數，對應的值即為Value。
表tsdb-uid用來存儲剛才提到的位元組映射，如下圖：
（圖片出處：//www.jianshu.com）
圖中的「001」表示tagk=hots或者tagv=static，提供正反查詢。
2）OpenTSDB使用策略說明：
-
不使用OpenTSDB提供的rest接口，通過client與HBase直連；
-
工程端禁用compact動作的Thrd線程；
-
間隔10秒獲取Redis緩衝數據批量寫入OpenTSDB。
2.2 OpenTSDB在實踐中需要關注的點
1）精確性問題
String value = "0.51";
float f = Float.parseFloat(value);
int raw = Float.floatToRawIntBits(f);
byte[] float_bytes = Bytes.fromInt(raw);
int raw_back = Bytes.getInt(float_bytes, 0);
double decode = Float.intBitsToFloat(raw_back);
/**
* 打印結果：
* Parsed Float: 0.51
* Encode Raw: 1057132380
* Encode Bytes: 3F028F5C
* Decode Raw: 1057132380
* Decoded Float: 0.5099999904632568
*/
System.out.println("Parsed Float: " + f);
System.out.println("Encode Raw: " + raw);
System.out.println("Encode Bytes: " + UniqueId.uidToString(float_bytes));
System.out.println("Decode Raw: " + raw_back);
System.out.println("Decoded Float: " + decode);
如上代碼，OpenTSDB在存儲浮點型數據時，無法知悉存儲意圖，在轉化時會遇到精確性問題，即存儲”0.51″，取出為”0.5099999904632568″。
2）聚合函數問題
OpenTSDB的大部分聚合函數，包括sum、avg、max、min都是LERP（linear interpolation）的插值方式，即所獲取的值存在被補缺的現象，對於有空值需求的使用很不友好。詳細原理參見OpenTSDB關於interpolation的文檔。
目前vmonitor服務端監控使用的OpenTSDB是我們改造後的源碼，新增了nimavg函數，配合自帶的zimsum函數滿足空值插入需求。
2.3 vivo服務端監控採集器原理
1）定時器
內含3種採集器：OS採集器、JVM採集器和業務指標採集器，其中OS及JVM每分鐘執行採集和匯聚，業務指標採集器會實時採集並在1分鐘的時間點完成匯聚重置，3份採集器的數據打包上報至RabbitMQ，上報動作異步超時。
2）業務指標採集器
業務指標採集方式有2種：日誌輸出過濾和工具類代碼上報(侵入式)，日誌輸出過濾是通過繼承log4j的Filter，從而獲取指標配置中指定的Appender輸出的renderedMessage，並根據指標配置的關鍵詞、聚合方式等信息進行同步監聽採集；代碼上報根據代碼中指定的指標code進行message信息上報，屬於侵入式的採集方式，通過調用監控提供的Util實現。業務指標配置每隔5分鐘會從CDN刷新，內置多種聚合器供聚合使用，包括count計數、 sum求和、average平均、max最大值和min最小值統計。
2.4 vivo服務端監控老版本架構設計
1）數據採集及上報：需求方應用接入的監控採集器vmonitor-agent根據監控指標配置採集相應數據，每分鐘上報1次數據至RabbitMQ，所採用的指標配置每5分鐘從CDN下載更新，CDN內容由監控後台上傳。
2）計算及存儲：監控後台接收RabbitMQ的數據，拆解後存儲至OpenTSDB，供可視化圖表調用，監控項目、應用、指標和告警等配置存儲於MySQL；通過Zookeeper和Redis實現分佈式任務分發模塊，實現多台監控服務協調配合運作，供分佈式計算使用。
3）告警檢測：從OpenTSDB獲取監控指標數據，根據告警配置檢測異常，並將異常通過第三方依賴自研消息、短訊發送，告警檢測通過分佈式任務分發模塊完成分佈式計算。
2.5 vivo服務端監控老版本部署架構
1）自建機房A：部署架構以國內為例，監控工程部署在自建機房A，監聽本機房的RabbitMQ消息，依賴的Redis、OpenTSDB、MySQL、Zookeeper等均在同機房，需要上傳的監控指標配置由文件服務上傳至CDN，供監控需求應用設備調用。
2）雲機房：雲機房的監控需求應用設備將監控數據上報至雲機房本地的RabbitMQ，雲機房的RabbitMQ將指定隊列通過路由的方式轉發至自建機房A的RabbitMQ，雲機房的監控配置通過CDN拉取。
2.6 vivo服務端監控新版本架構設計
1）採集（接入方）：業務方接入vmonitor-collector，並在相應環境的監控後台配置相關監控項即完成接入，vmonitor- collector將定時拉取監控項配置，採集服務數據並每分鐘上報。
2）數據聚合：老版本支持的是RabbitMQ將採集到的數據，路由至監控機房的RabbitMQ（同機房則不發生該行為），由監控後台服務消費；CDN負責承載各應用的配置供應用定時拉取。新版本vmonitor-gateway作為監控數據網關，採用http方式上報監控數據以及拉取指標配置，拋棄了之前使用的RabbitMQ上報以及CDN同步配置的途徑，避免兩者故障時對監控上報的影響。
3）可視化並且支持告警與配置（監控後台vmonitor）：負責前台的數據多元化展示（包括業務指標數據，分機房匯總數據，單台服務器數據，以及業務指標複合運算呈現），數據聚合，告警（目前包括短訊及自研消息）等。
4）數據存儲：存儲使用HBASE集群和開源的OpenTSDB作為聚合的中介，原始數據上報之後通過OpenTSDB持久化到HBase集群，Redis作為分佈式數據存儲調度任務分配、告警狀態等信息，後台涉及的指標和告警配置存儲於MySQL。
三、監控採集上報和存儲監控數據策略
為降低監控接入成本以及避免RabbitMQ上報故障和CDN同步配置故障對監控體系帶來的影響，將由採集層通過HTTP直接上報至代理層，並通過採集層和數據代理層的隊列實現災時數據最大程度的挽救。
詳細流程說明如下：
1）採集器（vmonitor-collector）根據監控配置每分鐘採集數據並壓縮，存儲於本地隊列（最大長度100，即最大存儲100分鐘數據），通知可進行HTTP上報，將數據上報至網關。
2）網關（vmonitor-gateway）接收到上報的數據後鑒權，認定非法即丟棄；同時判斷當前是否下層異常熔斷，如果發生則通知採集層重置數據退回隊列。
** 3）網關校驗**上報時帶來的監控配置版本號，過期則在結果返回時將最新監控配置一併返回要求採集層更新配置。
4）網關將上報的數據存儲於該應用對應的Redis隊列中（單個應用緩存隊列key最大長度1w）；存儲隊列完成後立即返回HTTP上報，表明網關已接受到數據，採集層可移除該條數據。
5）網關對Redis隊列數據進行解壓以及數據聚合；如果熔斷器異常則暫停前一行為；完成後通過HTTP存儲至OpenTSDB；如果存儲行為大量異常則觸發熔斷器。
四、核心指標
4.1 系統監控告警和業務監控告警
將採集到的數據通過OpenTSDB存放到HBase中後，通過分佈式任務分發模塊完成分佈式計算。如果符合業務方配置的告警規則，則觸發相應的告警，對告警信息進行分組並且路由到正確的通知方。可以通過短訊自研消息進行告警發送，可通過名字、工號、拼音查詢錄入需要接收告警的人員，當接收到大量重複告警時能夠消除重複的告警信息，所有的告警信息可以通過MySQL表進行記錄方便後續查詢和統計，告警的目的不僅僅是幫助開發人員及時發現故障建立故障應急機制，同時也可以結合業務特點的監控項和告警梳理服務，借鑒行業最佳監控實踐。告警流程圖如下：
4.2 支持的告警類型以及計算公式
1）最大值：當指定字段超過該值時觸發報警（報警閾值單位：number）。
2）最小值：當指定字段低於該值時觸發報警（報警閾值單位：number）。
3）波動量：取當前時間到前15分鐘這段時間內的最大值或者最小值與這15分鐘內的平均值做浮動百分比報警，波動量需要配置波動基線，標識超過該基線數值時才做「報警閥值」判定，低於該基線數值則不觸發報警（報警閾值單位：percent）。
計算公式：
波動量-向上波動計算公式：float rate = (float) (max – avg) / (float) avg;
波動量-向下波動計算公式：float rate = (float) (avg – min) / (float) avg;
波動量-區間波動計算公式：float rate = (float) (max – min) / (float) max;
4）日環比：取當前時間與昨天同一時刻的值做浮動百分比報警（報警閾值單位：percent）。
計算公式：float rate = （當前值 – 上一周期值）/上一周期值
5）周環比：取當前時間與上周同一天的同一時刻的值做浮動百分比報警（報警閾值單位：percent）。
計算公式：float rate = （當前值 – 上一周期值）/上一周期值
6）小時日環比：取當前時間到前一小時內的數據值總和與昨天同一時刻的前一小時內的數據值總和做浮動百分比報警（報警閾值單位：percent）。
計算公式：float rate = (float) (anHourTodaySum – anHourYesterdaySum) / (float) anHourYesterdaySum。
五、演示效果
5.1 業務指標數據查詢
1）查詢條件欄「指標」可選擇指定指標。
2）雙擊圖表上指標名稱可展示大圖，底部是根據起始時間的指標域合計值。
3）滾輪可以縮放圖表。
5.2 系統監控&JVM監控指標數據查詢
1）每分鐘頁面自動刷新。
2）如果某行，即某台機器整行顯示紅色，則代表該機器已逾半小時未上報數據，如機器是非正常下線就要注意排查了。
3）點擊詳情按鈕，可以對系統&JVM監控數據進行明細查詢。
5.3 業務指標配置
單個監控指標(普通)可以針對單個指定Appender的日誌文件進行數據採集。
【必填】【指標類型】為「普通」、「複合」兩種，複合是將多個普通指標二次聚合，所以正常情況下需要先新增普通指標。
【必填】【圖表順序】正序排列，控制指標圖表在數據頁面上的展示順序。
【必填】【指標代碼】默認自動生成UUID短碼。
【可選】【Appender】為log4j日誌文件的appender名稱，要求該appender必須被logger的ref引用；如果使用侵入式採集數據則無需指定。
【可選】【關鍵字】為過濾日誌文件行的關鍵詞。
【可選】【分隔符】是指單行日誌列分割的符號，一般為”,”英文逗號或其它符號。
六、主流監控對比
6.1 Zabbix
Zabbix 於 1998 年誕生，核心組件採用 C 語言開發，Web 端採用 PHP 開發，它屬於老牌監控系統中的優秀代表，能夠監控網絡參數，服務器健康和軟件完整性，使用也很廣泛。
Zabbix採用MySQL 進行數據存儲，所有沒有OpenTSDB支持 Tag的特性，因此沒法按多維度進行聚合統計和告警配置，使用起來不靈活。Zabbix 沒有提供對應的 SDK，應用層監控支持有限，也沒有我們自研的監控提供了侵入式的埋點和採集功能。
總體而言Zabbix 的成熟度更高，高集成度導致靈活性較差，在監控複雜度增加後，定製難度會升高，而且使用的MySQL關係型數據庫，對於大規模的監控數據插入和查詢是個問題。
6.2 Open-Falcon
OpenFalcon 是一款企業級、高可用、可擴展的開源監控解決方案，提供實時報警、數據監控等功能，採用 Go 和 Python 語言開發，由小米公司開源。使用 Falcon 可以非常容易的監控整個服務器的狀態，比如磁盤空間，端口存活，網絡流量等等。基於 Proxy-gateway，很容易通過自主埋點實現應用層的監控（比如監控接口的訪問量和耗時）和其他個性化監控需求，集成方便。
官方的架構圖如下：
6.3 Prometheus（普羅米修斯）
Prometheus是由SoundCloud開發的開源監控報警系統和時序列數據庫(TSDB)，Prometheus使用Go語言開發，是Google BorgMon監控系統的開源版本。
和小米的Open-Falcon一樣，借鑒 OpenTSDB，數據模型中引入了 Tag，這樣能支持多維度的聚合統計以及告警規則設置，大大提高了使用效率。監控數據直接存儲在 Prometheus Server 本地的時序數據庫中，單個實例可以處理數百萬的 Metrics，架構簡單，不依賴外部存儲，單個服務器節點可直接工作。
官方的架構圖如下：
6.4 vivo服務端監控vmonitor
vmonitor作為監控後台管理系統，可以進行可視化查看，告警的配置，業務指標的配置等，具備JVM監控、系統監控和業務監控的功能。通過採集層（vmonitor-collector採集器）和數據代理層（vmonitor-gateway網關）的隊列實現災時數據最大程度的挽救。
提供了SDK方便業務方集成，支持日誌輸出過濾和侵入式代碼上報數據等應用層監控統計，基於OpenTSDB時序開源數據庫，對其源碼進行了改造，新增了nimavg函數，配合自帶的zimsum函數滿足空值插入需求，具有強大的數據聚合能力，可以提供實時、多維度、多渠道的告警服務。
七、總結
本文主要介紹了vivo服務端監控架構的設計與演進之路，是基於java技術棧做的一套實時監控系統，同時也簡單列舉了行業內主流的幾種類型的監控系統，希望有助於大家對監控系統的認識，以及在技術選型時做出更合適的選擇。
監控體系裏面涉及到的面很廣，是一個龐大複雜的體系，本文只是介紹了服務端監控里的JVM監控，系統監控以及業務監控（包含日誌監控和工具類代碼侵入式上報），未涉及到客戶端監控和全鏈路監控等，如果想理解透徹，必須理論結合實踐再做深入。
作者：vivo互聯網服務器團隊-Deng Haibo
