張曉強(qiáng)

中國(guó)聯(lián)通軟件研究院濟(jì)南分院，山東濟(jì)南，250000

0 引言

相較于主機(jī)、容器、中間件等通用性的監(jiān)控對(duì)象，業(yè)務(wù)系統(tǒng)監(jiān)控具有更大的挑戰(zhàn)性。首先，對(duì)于主機(jī)、容器、中間件等，Prometheus社區(qū)有很多通用指標(biāo)采集器、監(jiān)控指標(biāo)規(guī)范等可以借鑒，采集周期多為固定時(shí)長(zhǎng)，指標(biāo)數(shù)據(jù)相對(duì)簡(jiǎn)單、規(guī)整。但是業(yè)務(wù)監(jiān)控不同：業(yè)務(wù)指標(biāo)相對(duì)來(lái)說(shuō)較為復(fù)雜，不同的業(yè)務(wù)系統(tǒng)會(huì)有不同的指標(biāo)體系，對(duì)于具體的業(yè)務(wù)指標(biāo)，需要單獨(dú)開發(fā)指標(biāo)采集器；告警規(guī)則不同，業(yè)務(wù)指標(biāo)之間有時(shí)會(huì)產(chǎn)生一定的關(guān)聯(lián)性，需要關(guān)聯(lián)判斷；采集周期不確定，一般分為固定時(shí)間點(diǎn)和固定時(shí)間周期兩種。在長(zhǎng)期的業(yè)務(wù)系統(tǒng)監(jiān)控實(shí)踐中，我們根據(jù)Prometheus生態(tài)體系，結(jié)合實(shí)際的業(yè)務(wù)情況，摸索出一套現(xiàn)實(shí)可行的業(yè)務(wù)監(jiān)控系統(tǒng)[1]。

1 系統(tǒng)架構(gòu)

系統(tǒng)分為數(shù)據(jù)采集層、監(jiān)控與告警組件、用戶交互三層（如圖1所示）。數(shù)據(jù)采集層采用自研指標(biāo)統(tǒng)一采集框架，在Prometheus原有采集功能上擴(kuò)充指標(biāo)數(shù)據(jù)超時(shí)及指標(biāo)基線功能。監(jiān)控組件采用Prometheus+Alertmanager，Prometheus采用主備部署模式，用于拉取并存儲(chǔ)時(shí)間序列數(shù)據(jù)以及計(jì)算、配置告警規(guī)則，Alertmanager采用三節(jié)點(diǎn)集群部署模式，用于進(jìn)行告警的管理及將告警發(fā)送到對(duì)應(yīng)的webhook，在webhook中根據(jù)配置的告警策略通過(guò)通知中心發(fā)送給用戶。用戶交互層通過(guò)自研的釘釘移動(dòng)端，包含監(jiān)控視圖、運(yùn)維操作、數(shù)據(jù)可視化、通知中心等功能[2]。

1.1 指標(biāo)采集

業(yè)務(wù)數(shù)據(jù)采集沒有現(xiàn)成的指標(biāo)采集器可以使用，需要自己去開發(fā)。采集器主要分為兩種模式，標(biāo)準(zhǔn)模式和自定義采集模式。標(biāo)準(zhǔn)模式將指標(biāo)數(shù)據(jù)刷新到緩存中，Prometheus調(diào)取接口獲取緩存中數(shù)據(jù)，采集效率高，但數(shù)據(jù)會(huì)有延遲。自定義采集模式為Prometheus調(diào)用采集器接口時(shí)，采集器才會(huì)去業(yè)務(wù)系統(tǒng)獲取對(duì)應(yīng)的指標(biāo)，并把指標(biāo)返回給Prometheus，數(shù)據(jù)延遲低，但采集性能差。在實(shí)際的業(yè)務(wù)監(jiān)控中，對(duì)于及時(shí)性要求不高或者獲取業(yè)務(wù)數(shù)據(jù)時(shí)間耗時(shí)長(zhǎng)的指標(biāo)，我們采用標(biāo)準(zhǔn)模式以降低Prometheus采集的性能消耗，對(duì)于及時(shí)性要求很高且指標(biāo)數(shù)量少、數(shù)據(jù)獲取時(shí)間短的指標(biāo)我們采用自定義采集的模式以降低指標(biāo)數(shù)據(jù)延遲。Prometheus提供拉取+推送（實(shí)際是pushgateway提供中間數(shù)據(jù)緩存，實(shí)際仍為拉取方式）兩種采集方式。對(duì)于固定周期數(shù)據(jù)使用拉取方式實(shí)現(xiàn)，對(duì)于固定時(shí)間點(diǎn)（如每月、每周固定時(shí)間點(diǎn)產(chǎn)生）或隨機(jī)產(chǎn)生指標(biāo)適用于推送方式實(shí)現(xiàn)。

Prometheus本身不提供指標(biāo)基線功能，只要是指標(biāo)采集器返回的數(shù)據(jù)照單全收，對(duì)于指標(biāo)缺失是沒有感知的。但是對(duì)于指標(biāo)缺失的情況，所有的告警規(guī)則計(jì)算結(jié)果都會(huì)為空，這樣就會(huì)產(chǎn)生一定的風(fēng)險(xiǎn)。對(duì)此我們進(jìn)行了改造，首先在主應(yīng)用側(cè)維護(hù)所有的指標(biāo)基線，在不同的指標(biāo)采集器側(cè)維護(hù)同步接口，定時(shí)從主應(yīng)用同步所有的指標(biāo)基線存儲(chǔ)到本地Redis中，且為每條指標(biāo)增加當(dāng)前時(shí)間戳字段表示數(shù)據(jù)時(shí)間，同時(shí)對(duì)于不同的指標(biāo)設(shè)置不同的超時(shí)時(shí)間。指標(biāo)采集器進(jìn)行Redis中指標(biāo)取值刷新時(shí)，會(huì)判斷該條指標(biāo)是否在指標(biāo)基線中，若存在則賦值并刷新時(shí)間戳，否則則忽略。在Prometheus拉取指標(biāo)時(shí)，直接取出Redis中所有的指標(biāo)進(jìn)行返回，采集器會(huì)判斷Redis中指標(biāo)基線取值是否已超過(guò)超時(shí)時(shí)間，若超過(guò)則將指標(biāo)取值打?yàn)?9999.99等特殊數(shù)值，在Prometheus中配置告警規(guī)則判斷是否有-9999.99的取值來(lái)判斷是否有指標(biāo)缺失，若存在則告警通知用戶[3]。如圖2所示。

1.2 指標(biāo)體系

Prometheus指標(biāo)分為三部分。①指標(biāo)名和標(biāo)簽（metric）：在內(nèi)部存儲(chǔ)上指標(biāo)名也作為名為__name__的特殊標(biāo)簽與其他標(biāo)簽共同唯一標(biāo)識(shí)每條指標(biāo)；②時(shí)間戳（timestamp）：指標(biāo)數(shù)據(jù)采集的時(shí)間，精確到毫秒；③樣本值（value）：表示當(dāng)前樣本的值，folat64類型。

在系統(tǒng)中采用Prometheus默認(rèn)時(shí)序數(shù)據(jù)庫(kù)進(jìn)行指標(biāo)存儲(chǔ)。Prometheus會(huì)將所有采集到的樣本數(shù)據(jù)以時(shí)間序列（time-series）的方式保存在內(nèi)存數(shù)據(jù)庫(kù)中，并且定時(shí)保存到時(shí)序庫(kù)中。時(shí)間序列中縱軸為所有的標(biāo)簽，橫軸為時(shí)間戳，這樣所有的標(biāo)簽只需要存儲(chǔ)一次，每次采集指標(biāo)只需要存儲(chǔ)時(shí)間戳和取值即可，大大地提升了存儲(chǔ)性能。

Prometheus支持四種類型的指標(biāo)，包括Counter（只增不減）、Gauge（可增可減）、Summary（數(shù)據(jù)集的不同分位數(shù)）、Histogram（數(shù)據(jù)集的不同區(qū)間的指標(biāo)數(shù)量）。在實(shí)際的業(yè)務(wù)系統(tǒng)監(jiān)控中，我們采用Gauge的指標(biāo)類型，基于其可增加可減少，也可以直接賦值的特性，可以很好地滿足業(yè)務(wù)監(jiān)控需求。

為了應(yīng)對(duì)業(yè)務(wù)的復(fù)雜程度，指標(biāo)體系中統(tǒng)一添加了模塊和租戶標(biāo)簽，以區(qū)分不同業(yè)務(wù)模塊的指標(biāo)。對(duì)于所有的指標(biāo)體系進(jìn)行統(tǒng)一編碼，統(tǒng)一管理，每條指標(biāo)明細(xì)配置唯一ID和CMDB實(shí)例名稱，告警發(fā)生后以便定位具體的告警指標(biāo)和CMDB實(shí)例，方便進(jìn)行告警分析。指標(biāo)基線由CMDB統(tǒng)一管理，配置指標(biāo)無(wú)數(shù)據(jù)告警，保證數(shù)據(jù)可靠性。

1.3 告警處理

告警規(guī)則配置在Consul中，通過(guò)Consul Template同步到Prometheus配置文件中，不同的業(yè)務(wù)模塊使用不同的配置文件。告警規(guī)則結(jié)合業(yè)務(wù)經(jīng)驗(yàn)進(jìn)行配置，一般為固定閾值，對(duì)于閾值隨時(shí)間變化的監(jiān)控點(diǎn)，需要按照需求定時(shí)去刷新Consul中規(guī)則配置文件，除了閾值外，還應(yīng)配置閾值持續(xù)時(shí)間，即超過(guò)閾值多長(zhǎng)時(shí)間才算告警，避免一些瞬時(shí)超過(guò)閾值造成誤告警或者告警閃斷。告警規(guī)則分為一般告警及嚴(yán)重告警，不同的告警等級(jí)對(duì)應(yīng)不同的告警通知方式以及告警恢復(fù)的緊急程度。

Prometheus負(fù)責(zé)告警規(guī)則計(jì)算，告警觸發(fā)后，將告警信息發(fā)送到Alertmanager，Alertmanager負(fù)責(zé)接收Prometheus等發(fā)送的告警。Alertmanager具有告警分組、告警靜默、告警抑制功能；告警分組是在告警第一次發(fā)生后，等待一段時(shí)間再進(jìn)行發(fā)送，若在等待期間有同組的告警觸發(fā)，則會(huì)加入分組中一塊發(fā)送給用戶，以防發(fā)生告警風(fēng)暴；告警抑制是告警之間往往有一定的關(guān)聯(lián)程度，具有因果關(guān)系的告警不應(yīng)該重復(fù)發(fā)送給用戶，例如進(jìn)程停止后往往會(huì)造成進(jìn)程積壓，進(jìn)程狀態(tài)發(fā)生告警后，進(jìn)程積壓不應(yīng)該再發(fā)給用戶；告警靜默是告警發(fā)生后，用戶可以手動(dòng)觸發(fā)靜默，使告警不再發(fā)送給用戶，給用戶足夠的解決問題的時(shí)間。Alertmanager接收告警后通過(guò)配置的告警路由將告警路由到正確的webhook接口，通過(guò)自定義webhook接口對(duì)告警信息、告警策略進(jìn)行個(gè)性化定制，例如采用不同的告警方式、根據(jù)值班表發(fā)送給不同的值班人員等[4]。

1.4 用戶交互

用戶交互采用自研釘釘移動(dòng)端平臺(tái)的方式，前臺(tái)采用React框架，后臺(tái)采用SpringCloud微服務(wù)框架。平臺(tái)區(qū)分多租戶，不同租戶之間提供租戶服務(wù)、配置信息、存儲(chǔ)資源隔離，保證租戶之間互不影響、互不干涉。平臺(tái)提供多種監(jiān)控視圖，針對(duì)不同業(yè)務(wù)模塊、不同監(jiān)控對(duì)象為用戶提供多維度多樣式的監(jiān)控視圖。同時(shí)平臺(tái)提供相關(guān)的運(yùn)維操作功能及數(shù)據(jù)展示功能，實(shí)現(xiàn)告警、監(jiān)控、運(yùn)維操作一體化[5]。

通知中心提供短信通知、釘釘通知及電話外呼功能。針對(duì)一般告警，通常只需要進(jìn)行釘釘通知。釘釘通知分為工作通知、群機(jī)器人等方式。在用戶權(quán)限允許范圍內(nèi)，用戶可自行訂閱告警通知以及告警通知接收時(shí)間等，通知接收后用戶可在釘釘平臺(tái)中進(jìn)行告警確認(rèn)、告警靜默等操作。對(duì)于嚴(yán)重的告警，需要通過(guò)電話外呼的形式發(fā)送給用戶，電話外呼采用逐層上報(bào)告警策略，結(jié)合值班表會(huì)對(duì)值班人員進(jìn)行多次通知，若用戶沒有響應(yīng)，則會(huì)向上反映，直到告警接收為止，確保嚴(yán)重告警發(fā)生后，保證值班人員能夠接收到告警信息。對(duì)于可預(yù)見性的告警提供生產(chǎn)聯(lián)動(dòng)功能，在正常生產(chǎn)操作發(fā)生時(shí)靜默告警點(diǎn)，防止產(chǎn)生誤告警。

2 業(yè)務(wù)流程監(jiān)控

在系統(tǒng)建設(shè)過(guò)程中，指標(biāo)接入工作一直以監(jiān)控點(diǎn)作為單位進(jìn)行，對(duì)于系統(tǒng)中一些關(guān)鍵的業(yè)務(wù)流程是否覆蓋全面、是否能夠有效地監(jiān)控?zé)o法進(jìn)行有效的分析。為了增加監(jiān)控系統(tǒng)的可靠性、全面性，針對(duì)關(guān)鍵的業(yè)務(wù)流程進(jìn)行重點(diǎn)監(jiān)控，我們引入了業(yè)務(wù)流程監(jiān)控。使用CMDB和圖數(shù)據(jù)庫(kù)，構(gòu)建業(yè)務(wù)流程圖，每個(gè)節(jié)點(diǎn)對(duì)應(yīng)一部分實(shí)際存在的進(jìn)程、數(shù)據(jù)庫(kù)、中間件、主機(jī)、容器等組件，針對(duì)具體的實(shí)例節(jié)點(diǎn)定制監(jiān)控點(diǎn)規(guī)范、稽核實(shí)例節(jié)點(diǎn)是否監(jiān)控全面、是否監(jiān)控有效。同時(shí)針對(duì)具體的應(yīng)用構(gòu)建應(yīng)用拓?fù)?，告警發(fā)生時(shí)，根據(jù)業(yè)務(wù)拓?fù)浞治龈婢a(chǎn)生的根本原因或產(chǎn)生的范圍影響[6]。

3 結(jié)論與展望

業(yè)務(wù)監(jiān)控復(fù)雜程度高，對(duì)于一些業(yè)務(wù)指標(biāo)設(shè)置固定的告警規(guī)則會(huì)造成很多的誤告警，需要結(jié)合AiOps技術(shù)實(shí)現(xiàn)單指標(biāo)閾值監(jiān)控及多指標(biāo)閾值自動(dòng)判斷。平臺(tái)缺乏監(jiān)控自助接入功能，目前監(jiān)控接入依賴維護(hù)人員人工配置，效率低。同時(shí)，當(dāng)前告警處理自動(dòng)化程度低，無(wú)法實(shí)現(xiàn)告警自動(dòng)恢復(fù)、處理等功能。平臺(tái)接入指標(biāo)后，缺乏可靠的告警全面性、有效性分析標(biāo)準(zhǔn)，對(duì)于缺失的監(jiān)控?zé)o法有效識(shí)別。在后續(xù)建設(shè)工作中，需要擴(kuò)充告警分析模塊，對(duì)產(chǎn)生的告警進(jìn)行影響范圍分析、根因分析、智能告警收斂等，進(jìn)一步提升告警的價(jià)值，減少業(yè)務(wù)人員處理的告警數(shù)量；完善告警自助接入功能，將接入功能全面下放；對(duì)接告警自動(dòng)及手動(dòng)處理模塊，實(shí)現(xiàn)告警閉環(huán)，同時(shí)建立完善的有效性、全面性分析機(jī)制，進(jìn)一步提升監(jiān)控系統(tǒng)可用性、可靠性。