前言

以組件監(jiān)控為例，介紹監(jiān)控產(chǎn)品的路線圖

運(yùn)維監(jiān)控系統(tǒng)的作用不言而喻，貫穿運(yùn)維的5項(xiàng)職能：發(fā)布、變更、故障處理、體驗(yàn)優(yōu)化、日常需求，保障上述職能的服務(wù)可用性。

從大數(shù)據(jù)的特性(數(shù)據(jù)量大、多維度、完備性)[1]來看，運(yùn)維監(jiān)控系統(tǒng)的建設(shè)可以分為2個(gè)階段：多維度監(jiān)控（積累數(shù)據(jù)） 和 智能監(jiān)控(使用數(shù)據(jù)），通過多維度監(jiān)控實(shí)現(xiàn)出了故障能看、能查，智能監(jiān)控提前發(fā)現(xiàn)風(fēng)險(xiǎn)、找出故障根源。

組件監(jiān)控是多維度監(jiān)控體系的第3層，主要對常見開源組件、中間件的性能指標(biāo)做監(jiān)控，比如 Nginx 的性能指標(biāo)有Active Connections（當(dāng)前客戶端連接數(shù)）、Waiting（等待中的連接數(shù)）等，Oracle的性能指標(biāo)有 SQL硬解析率、表空間使用率等。

通過采集組件的關(guān)鍵性能指標(biāo)，實(shí)時(shí)獲悉組件的運(yùn)行狀況，提前發(fā)現(xiàn)問題，而不是僅監(jiān)控進(jìn)程或端口是否存活（進(jìn)程或端口都正常時(shí)，不代表可以提供服務(wù)）。

本文以建設(shè)組件監(jiān)控為例，從多維度監(jiān)控的組成、監(jiān)控產(chǎn)品要解決的3個(gè)問題、組件監(jiān)控的技術(shù)選型、云端下發(fā)采集器配置、社區(qū)的開放能力來介紹監(jiān)控產(chǎn)品設(shè)計(jì)路線圖。

1. 多維度監(jiān)控的組成

從用戶訪問鏈路的角度，將監(jiān)控指標(biāo)的維度分為用戶層、應(yīng)用層、組件層、主機(jī)層、網(wǎng)絡(luò)層。

用戶層，通過服務(wù)撥測等方式模擬用戶的訪問行為，不用等用戶投訴上門；應(yīng)用層，通過調(diào)用鏈等方式追蹤應(yīng)用的調(diào)用狀態(tài)；其他三層較為容易理解就不做介紹了。

通過這5層+其他關(guān)鍵指標(biāo)（如日志、業(yè)務(wù)KPI曲線等），構(gòu)筑監(jiān)控系統(tǒng)的多維度監(jiān)控能力，為第二階段的智能監(jiān)控提供數(shù)據(jù)支撐。

2. 監(jiān)控產(chǎn)品要解決的3個(gè)問題

除了獲取關(guān)鍵的性能指標(biāo)外，監(jiān)控產(chǎn)品還需要解決3個(gè)問題， 退可做故障關(guān)聯(lián)分析，進(jìn)可建設(shè)運(yùn)維的智能化場景。

2.1 對IT系統(tǒng)的自主掌控能力

由于對IT系統(tǒng)自主掌控能力的缺乏，"正在更換IT系統(tǒng)" 和 "走向更換IT系統(tǒng)的路上，是部分中、大型企業(yè)在"互聯(lián)網(wǎng)+"浪潮下積極擁抱互聯(lián)網(wǎng)的現(xiàn)狀。

鑒于這種情況，部分行業(yè)已明確已表明[2][3]，必須加大對IT系統(tǒng)自主掌控的能力。

于是，產(chǎn)品設(shè)計(jì)時(shí)，需考慮能讓監(jiān)控系統(tǒng)的使用者可以參與到監(jiān)控系統(tǒng)的開發(fā)或部分開發(fā).

2.2 拒絕再造一個(gè)煙囪

豎井式的結(jié)構(gòu)估計(jì)是大部分企業(yè)構(gòu)建IT系統(tǒng)的現(xiàn)狀，每個(gè)系統(tǒng)間毫無關(guān)聯(lián)，每買一套系統(tǒng)等于多構(gòu)建一個(gè)信息孤島，附加值極低。

如果想實(shí)現(xiàn)退可做故障關(guān)聯(lián)分析，進(jìn)可建設(shè)運(yùn)維的智能化場景，可在基于PaaS的運(yùn)維平臺(tái)上建設(shè)[4]，通過iPaaS打通企業(yè)內(nèi)部的各個(gè)IT運(yùn)營系統(tǒng)。

2.3 組件繁多，完全自研不太現(xiàn)實(shí)

行業(yè)中應(yīng)用的組件種類繁多，從數(shù)據(jù)庫、存儲(chǔ)、HTTP服務(wù)到消息隊(duì)列等共100+，完全自研肯定不現(xiàn)實(shí)。

好的辦法是自研核心、行業(yè)支撐不好的組件，剩下的借助行業(yè)多年積累的能力，少造一點(diǎn)輪子，為社會(huì)省點(diǎn)電。

3. 組件監(jiān)控的技術(shù)選型

在2.3中提到自研 + 第3方開源采集器的思路，這里以開源采集器Prometheus Exporter為例。

Prometheus Exporter的社區(qū)很活躍[5]，支持100+ 常見開源組件，部分大廠甚至專門編寫對應(yīng)的Prometheus Exporter，比如Oracle編寫的Weblogic Exporter，IBM編寫的IBM MQ exporter，k8s、etcd甚至內(nèi)置基于Exporter規(guī)范的metrics。

按照這種方案，只需要做一個(gè)協(xié)議轉(zhuǎn)換即可把指標(biāo)入庫

4. 體驗(yàn)優(yōu)化：云端下發(fā)采集器配置

解決基礎(chǔ)需求后，需要馬上來優(yōu)化下體驗(yàn)。

把采集器或配置下發(fā)至被監(jiān)控的主機(jī)上，一般需要手動(dòng)部署或使用第三方的工具（如Ansible）。

切換多個(gè)系統(tǒng)來完成一件事情，體驗(yàn)非常不好。

有一個(gè)優(yōu)化方案，通過iPaaS使用管控平臺(tái)層的文件分發(fā)和命令執(zhí)行能力[4]，讓用戶在一個(gè)頁面完成配置流程，提升效率。

5. 社區(qū)的開放能力

在滿足基礎(chǔ)功能和優(yōu)化產(chǎn)品體驗(yàn)后，接下來考慮產(chǎn)品的可擴(kuò)展性。

先解決用戶一鍵導(dǎo)入自研組件的便利性，接下來提供一個(gè)交流平臺(tái)讓社區(qū)用戶可以自由分享。

在獲得社區(qū)開源能力的同時(shí)，也需要反哺社區(qū)。

6. 結(jié)尾

屬于基礎(chǔ)監(jiān)控范圍的多維度監(jiān)控相對智能監(jiān)控來說，不太光鮮，但它是智能監(jiān)控的數(shù)據(jù)基礎(chǔ)，沒有多維度監(jiān)控提供的數(shù)據(jù)，無法落地故障預(yù)測、故障根因分析等智能監(jiān)控場景。

傳統(tǒng)企業(yè)或互聯(lián)網(wǎng)企業(yè)在擁抱互聯(lián)網(wǎng)變革時(shí)，需冷靜思考，按照路線圖逐步實(shí)現(xiàn)。

7. 參考文獻(xiàn)

[1] 吳軍. 智能時(shí)代：大數(shù)據(jù)與智能革命重新定義未來 [M]. 北京：中信出版集團(tuán)，2016-8.

[2] 中國人民銀行. （中國金融業(yè)信息技術(shù)“十三五” 發(fā)展規(guī)劃：http://images.mofcom.gov.cn/coi/201706/20170629110047159.pdf）[EB/OL]. 2017.06

[3] 中國銀監(jiān)會(huì).（中國銀行業(yè)信息科技“十三五”發(fā)展規(guī)劃監(jiān)管指導(dǎo)意見（征求意見稿）：http://www.cbrc.gov.cn/chinese/home/docView/1940BD4B2D7740CC90F4FE4C6B3CD316.html）[EB/OL]. 2016.07.15

[4] 中國通信標(biāo)準(zhǔn)化協(xié)會(huì).（云計(jì)算運(yùn)維平臺(tái)參考框架及技術(shù)要求：http://v2.opensourcecloud.cn/article/2）[EB/OL]. 2017.11.16

[5] Prometheus. （EXPORTERS AND INTEGRATIONS：https://prometheus.io/docs/instrumenting/exporters/） [EB/OL].

藍(lán)鯨智云

本文由騰訊藍(lán)鯨智云編輯發(fā)布，騰訊藍(lán)鯨智云（簡稱藍(lán)鯨）軟件體系是一套基于PaaS的技術(shù)解決方案，致力于打造行業(yè)領(lǐng)先的一站式自動(dòng)化運(yùn)維平臺(tái)。目前已經(jīng)推出社區(qū)版、企業(yè)版，歡迎體驗(yàn)。

- 官網(wǎng)：https://bk.tencent.com/

- 下載鏈接：https://bk.tencent.com/download/

- 社區(qū)：https://bk.tencent.com/s-mart/community/question