監(jiān)控系統(tǒng)的設(shè)計(jì)指導(dǎo)與框架模型
監(jiān)控設(shè)計(jì)指導(dǎo)
為了能夠清楚意識(shí)到任何微小的延遲都可能預(yù)示著明天的局部停機(jī)或者系統(tǒng)癱瘓，遵循通用監(jiān)控系統(tǒng)設(shè)計(jì)的指導(dǎo)思想，需要進(jìn)行對(duì)業(yè)務(wù)系統(tǒng)的劃分：
面向IaaS平臺(tái)：包括但不限于硬件底層、操作系統(tǒng)主機(jī)、數(shù)據(jù)庫(kù)、網(wǎng)絡(luò)等;
面向PaaS平臺(tái)：如SOA公共框架(SOA框架、Dubbo服務(wù)等)、公共組件(緩存Redis組件、消息隊(duì)列RabbitMQ組件等)，公共服務(wù)子系統(tǒng)或公共服務(wù)平臺(tái)等;
面向SAAS服務(wù)：如提供業(yè)務(wù)服務(wù)的HTTP、API、SDK、APP、SOCKET等;
遵循分層的設(shè)計(jì)原則，企業(yè)級(jí)監(jiān)控系統(tǒng)的采集周期(頻次)必須能夠細(xì)化到秒級(jí)甚至毫秒級(jí)別，監(jiān)控?cái)?shù)據(jù)必須完整覆蓋天、周、月、年的單位，歷史監(jiān)控?cái)?shù)據(jù)必須完整存儲(chǔ)超過(guò)3年以上的時(shí)間，這也是對(duì)重要監(jiān)控系統(tǒng)最基本的需求。其中，所設(shè)計(jì)的監(jiān)控系統(tǒng)要面向的目標(biāo)對(duì)象(Goal Object)必須能夠準(zhǔn)確反映出可用性狀況、性能瓶頸指標(biāo)、對(duì)外提供服務(wù)的SLA指標(biāo)(ART&EST)等，如果是面向應(yīng)用型監(jiān)控系統(tǒng)，不僅僅能夠完整的顯示出應(yīng)用中間件或容器的JVM等各類指標(biāo)，包括但不限于GRP:GlobalRequestProcessor，BusyThread，JCA:JavaConnectionAvailable，MaxReuqestTime，AverageResponeTime等)，而且可以捕捉到WebServer在運(yùn)行過(guò)程中，應(yīng)用系統(tǒng)中各方法類的性能開銷狀態(tài)，出現(xiàn)故障如果可以進(jìn)行做追述和定位的時(shí)候，還能細(xì)化到開銷方法的全棧追蹤到每個(gè)數(shù)值，那這樣的業(yè)務(wù)應(yīng)用監(jiān)控架構(gòu)的設(shè)計(jì)就非常的完整，即通常我們所描述的監(jiān)控系統(tǒng)的顆粒細(xì)度以及能夠?qū)χ匾南到y(tǒng)、業(yè)務(wù)、安全等指標(biāo)進(jìn)入預(yù)測(cè)分析。
圖二：通用監(jiān)控系統(tǒng)設(shè)計(jì)指導(dǎo)思想
企業(yè)監(jiān)控框架
對(duì)于企業(yè)內(nèi)部趨向于成熟的監(jiān)控框架通常會(huì)來(lái)行業(yè)通用的結(jié)構(gòu)來(lái)部署，這個(gè)結(jié)構(gòu)需要將監(jiān)控、分析與控制完成三位一體的無(wú)縫融合。本人的切身感受而言，一個(gè)好的監(jiān)控架構(gòu)不僅僅能夠建設(shè)基于現(xiàn)狀及未來(lái)發(fā)展提供有效的監(jiān)控預(yù)警支撐，而且可以通過(guò)平臺(tái)內(nèi)實(shí)時(shí)或積累的系統(tǒng)或業(yè)務(wù)監(jiān)測(cè)數(shù)據(jù)進(jìn)行聯(lián)動(dòng)分析，找出問(wèn)題的瓶頸點(diǎn)或未來(lái)的增長(zhǎng)點(diǎn)，提供系統(tǒng)成長(zhǎng)重要的數(shù)據(jù)決策支撐。
簡(jiǎn)單來(lái)說(shuō)，監(jiān)控系統(tǒng)框架分為如下三個(gè)部分：
統(tǒng)一監(jiān)控：
1)基礎(chǔ)層面的監(jiān)控：通過(guò)選取開源或主流的監(jiān)控系統(tǒng)，完成公共設(shè)施或系統(tǒng)運(yùn)維方面的有效監(jiān)控，如OpenNMS-Cacti聚焦網(wǎng)絡(luò)層面; Zabbix/Hyerpic HQ聚焦IaaS公共層面;監(jiān)控寶聚焦網(wǎng)站、API等。無(wú)論何種監(jiān)控系統(tǒng)只是一種實(shí)現(xiàn)系統(tǒng)生命周期的有效運(yùn)維工具，對(duì)工具本身的熱愛(ài)及對(duì)工具所涉及的技術(shù)選型最好的依據(jù)主要是能夠融會(huì)貫通，舉一反三。因?yàn)闆](méi)有任何一款監(jiān)控工具都適用于所有公司的監(jiān)控需求，基于量體裁衣以及在主流被廣泛使用的系統(tǒng)，同時(shí)兼顧了為日后統(tǒng)一監(jiān)控中心的數(shù)據(jù)融合所準(zhǔn)備的，能夠通過(guò)DevOps結(jié)合的監(jiān)控系統(tǒng)才是最適合自己的。
2)有效的應(yīng)用性能監(jiān)控：除了WebServer的各層基礎(chǔ)運(yùn)行指標(biāo)，因代碼BUG或者程序設(shè)計(jì)不當(dāng)所引發(fā)的各種級(jí)別故障越來(lái)越多，對(duì)于企業(yè)來(lái)講，業(yè)務(wù)代碼的變更需經(jīng)過(guò)嚴(yán)格的覆蓋測(cè)試，甚至?xí)趯?duì)外發(fā)布后進(jìn)行全回歸覆蓋測(cè)試及在必要的時(shí)候進(jìn)行性能壓力測(cè)試，但漏網(wǎng)之魚依然存在，而且企業(yè)通常很難做到7*24小時(shí)的實(shí)時(shí)業(yè)務(wù)性能檢測(cè)分析，特別是在多業(yè)務(wù)復(fù)用的情況下，具體引發(fā)的問(wèn)題根源無(wú)法在短時(shí)間內(nèi)被快速定位和追蹤到，這也是過(guò)往業(yè)務(wù)監(jiān)控的一個(gè)短板，如何準(zhǔn)確定位到業(yè)務(wù)代碼級(jí)別的故障和異常，捕捉的信息能夠直接為開發(fā)工程師提供第一手的信息反饋，確保業(yè)務(wù)高峰來(lái)臨前能夠被準(zhǔn)確的發(fā)現(xiàn)修復(fù)，我將在下文通過(guò)透視寶的實(shí)踐操作來(lái)加深這方面的介紹。
3)統(tǒng)一的業(yè)務(wù)日志平臺(tái)：ELK(Elastic+Logfluent+Kibana)已然成為行業(yè)的標(biāo)桿或首選，盡管市面上有很多主流的商業(yè)化產(chǎn)品，但對(duì)本人而言，更加青睞自身DevOps研發(fā)建設(shè)出一套大數(shù)據(jù)如日志監(jiān)控系統(tǒng)，因?yàn)檫@也是作為一家互聯(lián)網(wǎng)科技公司的技術(shù)標(biāo)配，這樣不僅能夠個(gè)性化定制和配置，還能無(wú)縫對(duì)接集團(tuán)或公司業(yè)務(wù)的特殊監(jiān)控訴求。
4)開放的API監(jiān)控：能夠完成如業(yè)務(wù)API的有效性監(jiān)控，做到接口數(shù)據(jù)相關(guān)的故障分析，實(shí)現(xiàn)對(duì)系統(tǒng)的彈性預(yù)測(cè)、耗損/過(guò)期分析、顆粒細(xì)度的定位等。
