光大銀行監(jiān)控平臺實踐，含詳細工具及架構(gòu)選型思路

大家好，我今天分享的主題是光大銀行統(tǒng)一監(jiān)控平臺建設(shè)實踐。

光大銀行統(tǒng)一監(jiān)控平臺，定位是服務(wù)全行科技條線的IT監(jiān)控系統(tǒng)，是運維之眼。該平臺體系比較龐大，今天主要介紹偏向于監(jiān)控管理和報警管理的相關(guān)功能。這部分功能是我行根據(jù)多年的經(jīng)驗自主研發(fā)實現(xiàn)的，里面蘊含著監(jiān)控管理方面的理念和思路，希望此次分享能給大家?guī)硪恍﹨⒖己蛦l(fā)。

金融科技是一個炙手可熱的話題，通過互聯(lián)網(wǎng)、大數(shù)據(jù)、云計算、人工智能、區(qū)塊連等新技術(shù)的應(yīng)用，支持和引領(lǐng)著業(yè)務(wù)的快速發(fā)展。

這個過程中，對銀行科技運維和運營都帶來了很大的挑戰(zhàn)，主要表現(xiàn)在：

為了提升整體的IT運營和運維能力，銀行業(yè)的數(shù)據(jù)中心較早引入了ITIL管理理念，建立流程管理的模式，形成運維管理工作的流程化和標(biāo)準(zhǔn)化模式。

隨著云計算、大數(shù)據(jù)和人工智能的發(fā)展，在原有的ITIL的基礎(chǔ)上引入了DevOps和AIOps理念的相關(guān)技術(shù)，逐步轉(zhuǎn)向為數(shù)據(jù)和業(yè)務(wù)價值驅(qū)動，向著IT運營和數(shù)字化運營的目標(biāo)轉(zhuǎn)型。

從我們光大銀行的角度，科技部運維中心提出了BCDT的理念，作為運維相關(guān)工作的總體指導(dǎo)思想和理念。從監(jiān)控系統(tǒng)建設(shè)的角度，主要的內(nèi)容就是：

光大銀行監(jiān)控體系經(jīng)過了多年的建設(shè)，歷經(jīng)了幾個主要階段，通過分析可以看到主要的趨勢是朝著集中化、平臺化和數(shù)字化的發(fā)展方向。

1）2005年開始配置獨立的監(jiān)控工具。

2）2011年開始進入平臺化建設(shè)，報警統(tǒng)一。

3）2014年開始全面監(jiān)控，實現(xiàn)應(yīng)用交易監(jiān)控，搭建了大數(shù)據(jù)平臺的框架。

4）2018年新一代的監(jiān)控管理平臺上線運行，這是我行自主研發(fā)的平臺，在報警管理、標(biāo)準(zhǔn)化和自動化能力上的提升明顯。

5）2019年科技運營數(shù)據(jù)平臺投產(chǎn)，這個系統(tǒng)通過產(chǎn)學(xué)研合作的方式落地 AI分析處理能力，監(jiān)控系統(tǒng)向著數(shù)字化轉(zhuǎn)型。

在我行監(jiān)控管理系統(tǒng)持續(xù)演進的過程中，我們也在思考和總結(jié)，哪些是不變的，哪些是頻繁變化的。

相對穩(wěn)定不變的內(nèi)容包括：

變化的內(nèi)容就比較多了，比如：

我們回顧和總結(jié)這個變化，對我們監(jiān)控系統(tǒng)建設(shè)有很強的指導(dǎo)作用。不變的點更多是管理相關(guān)的能力和要求，這在市場上沒有完全滿足我們要求的產(chǎn)品，于是我們選擇了自主進行研發(fā)，最終形成了監(jiān)控管理平臺。

而對于更多變化的內(nèi)容，我們的策略是快速引入專業(yè)領(lǐng)域的監(jiān)控工具納入到我行監(jiān)控體系中使用，對接到管理平臺進行統(tǒng)一管理。發(fā)展趨勢中，大數(shù)據(jù)平臺的作用和價值凸顯，我們也以此作為監(jiān)控乃至IT運營的轉(zhuǎn)型的方向，基于開源的產(chǎn)品重點建設(shè)和優(yōu)化。

在重點介紹監(jiān)控管理平臺之前，有必要讓大家對光大銀行監(jiān)控體系的總體架構(gòu)和功能有個了解。

光大銀行監(jiān)控系統(tǒng)的定位是面向全行科技部門的IT監(jiān)控系統(tǒng)。從功能層面分為3層，分別是監(jiān)控工具層、平臺層和統(tǒng)一展示層。

1）監(jiān)控工具層，包含各類開源或者商業(yè)的專業(yè)領(lǐng)域的監(jiān)控工具，他們實現(xiàn)對各類監(jiān)控工具的實時的數(shù)據(jù)采集。常見的比如Zabbix、Nagios、Prometheus、BPC、Tivoli等等，都定位在監(jiān)控工具層。監(jiān)控工具會把報警數(shù)據(jù)、性能數(shù)據(jù)、日志數(shù)據(jù)，上送到平臺層。

2）平臺層，包含兩大部分功能：一是由監(jiān)控報警處理、監(jiān)控標(biāo)準(zhǔn)化和自服務(wù)等功能模塊組成的管理平臺；二是基于大數(shù)據(jù)架構(gòu)的科技運營數(shù)據(jù)平臺，包括大數(shù)據(jù)處理、存儲、AI分析以及數(shù)據(jù)服務(wù)接口等子系統(tǒng)。在平臺層，還實現(xiàn)了和行內(nèi)其他運維系統(tǒng)的對接。

3）統(tǒng)一展示層，根據(jù)不同用戶的角色和場景，提供PC、大屏和手機端展示。

總的來說，平臺層的建設(shè)思路是開源+自研，是整個體系的核心；工具層的建設(shè)思路是專業(yè)+敏捷+統(tǒng)一管理。

通過多年的建設(shè)，監(jiān)控系統(tǒng)的指標(biāo)覆蓋從底層的機房設(shè)施到最上層的應(yīng)用交易，實現(xiàn)了指標(biāo)全覆蓋。借助多種監(jiān)控工具的部署，對監(jiān)控指標(biāo)的實現(xiàn)，一般都具備多種監(jiān)控手段。

我們內(nèi)部有個原則：對于關(guān)鍵指標(biāo)，要有兩種的工具能夠覆蓋。這樣做有兩個好處：一是能夠確保監(jiān)控策略有冗余，二是確保當(dāng)我們識別出一個新的指標(biāo)要納入監(jiān)控時，我們一定有工具能快速實現(xiàn)監(jiān)控部署。 

交易監(jiān)控，一直是所有監(jiān)控系統(tǒng)建設(shè)的重點功能。我們通過多種手段，實現(xiàn)端到端的交易全方位監(jiān)控：

1）采用了網(wǎng)絡(luò)旁路抓包、流水表鏡像和交易日志分析等多種方式監(jiān)控交易成功率、響應(yīng)率、響應(yīng)時間等指標(biāo)，實現(xiàn)了對應(yīng)用無侵入的、實時的監(jiān)控。

2）TCP網(wǎng)絡(luò)層監(jiān)控，通過旁路方式對應(yīng)用的全鏈路“通訊對”進行監(jiān)控和分析，能夠快速發(fā)現(xiàn)網(wǎng)絡(luò)的異常，也能從網(wǎng)絡(luò)層面對應(yīng)用故障進行協(xié)助定位和分析。

3）模擬監(jiān)控，從互聯(lián)網(wǎng)以及內(nèi)網(wǎng)探點模擬訪問應(yīng)用系統(tǒng)，主動獲取可用性和性能數(shù)據(jù)，并接入到監(jiān)控平臺進行集中處理和分析。

4）通過網(wǎng)絡(luò)抓包和日志Api的方式進行端到端追蹤系統(tǒng)應(yīng)用間和應(yīng)用系統(tǒng)內(nèi)部的交易路徑。這個功能目前在部分新架構(gòu)下的應(yīng)用系統(tǒng)已經(jīng)實現(xiàn)，更多傳統(tǒng)的應(yīng)用系統(tǒng)正在改造過程中。

大數(shù)據(jù)和智能算法，是我們現(xiàn)在的工作重心。2019年我們的科技運營數(shù)據(jù)平臺完成上線投產(chǎn)，這個平臺綜合運用了多種算法，實現(xiàn)了指標(biāo)異常檢測、多維檢測、批處理異常檢測等多種功能。

對銀行業(yè)最重要的就是聯(lián)機交易和批量執(zhí)行，智能監(jiān)控為傳統(tǒng)監(jiān)控提供了重要的補充手段：

一個場景是交易監(jiān)控，綜合節(jié)假日、促銷等各種因素實現(xiàn)動態(tài)的異常交易檢測和告警，可以細化到每一只交易單獨進行監(jiān)控，相比于傳統(tǒng)的固定閾值監(jiān)控能提前3-5分鐘進行提示。  

第二個場景，是對批量任務(wù)時長的智能分析，相比于傳統(tǒng)的固定批量執(zhí)行時長的監(jiān)控，智能分析的結(jié)果能夠做到提前預(yù)警，為夜間故障處置贏得了時間。

在數(shù)據(jù)展示方面，我們建設(shè)了統(tǒng)一視圖系統(tǒng)。支持移動端、大屏端、PC端實時數(shù)據(jù)展示。根據(jù)業(yè)務(wù)場景，定制了日常運維視圖、 應(yīng)急保障視圖、和重保運營視圖。

按照用戶角色的使用需求，對各類視圖進行分類，如一線偏重于故障發(fā)現(xiàn)、和按照預(yù)案處置以及事后的驗證；二線偏重于故障的解決以及趨勢分析和隱患排查。

對于監(jiān)控系統(tǒng)的建設(shè)，我們的原則是以開源為主，自主可控。

在數(shù)據(jù)采集層面，我們使用了zabbix、nagios、prometheus 等常見的開源軟件。另外也有國產(chǎn)的網(wǎng)絡(luò)流量采集和分析的產(chǎn)品。對于存量的國外商業(yè)套件，我們已經(jīng)制定了替換的計劃，預(yù)計會逐步下線。

需要特別提到的是，我們正在實施部署的統(tǒng)一采控Agent子系統(tǒng)，采用自研方式建設(shè)，目標(biāo)是能夠成為一個采集腳本編寫和管理的基礎(chǔ)平臺，提供通用的Agent驅(qū)動能力，獨立實現(xiàn)服務(wù)器上所有數(shù)據(jù)的實時采集，成為大數(shù)據(jù)平臺最穩(wěn)定可靠的數(shù)據(jù)來源。

在數(shù)據(jù)處理、數(shù)據(jù)存儲、前端展示以及開發(fā)部署各個層面，也就是平臺層的產(chǎn)品則基本都是開源的產(chǎn)品和技術(shù)。

上面是對我行監(jiān)控系統(tǒng)整體的功能和架構(gòu)進行了簡要介紹。

前面介紹了光大銀行總體監(jiān)控體系，在本章節(jié)我來介紹一下監(jiān)控體系中的監(jiān)控管理子系統(tǒng)。

這是監(jiān)控管理平臺的總體功能架構(gòu)圖：

主要是兩大部分，第一個是左半部分，從下到上包括報警采集、預(yù)處理和處理，構(gòu)成了報警處理引擎子系統(tǒng)，其中還包括了報警通知和維護期管理的功能。 

第二是右半部分從上到下，監(jiān)控標(biāo)準(zhǔn)化管理子系統(tǒng)，包含監(jiān)控對象、策略、指標(biāo)和規(guī)則等標(biāo)準(zhǔn)化管理功能，以及監(jiān)控配置自動化、監(jiān)控評價等功能。

通俗的說，左面部分解決的是報警來了怎么處理的問題， 右面部分解決的是報警如何配置，怎么產(chǎn)生的問題。

下面分別介紹一下報警處理引擎和監(jiān)控標(biāo)準(zhǔn)化管理兩大部分功能。報警處理引擎，是光大銀行自主研發(fā)實現(xiàn)的核心組件，所以這個部分是本次分享的重點內(nèi)容。

首先，我們先來分析報警管理的技術(shù)和業(yè)務(wù)特點：

基于上述報警管理的特點，我們制定了報警處理引擎的選型和開發(fā)的目標(biāo)：

2）事件處理集中化，規(guī)則、外部對象資源都要加載，通過集中處理可以更加充分的利用資源，一次加載重復(fù)使用。

3）事件處理分布式，處理集中之后就要有分布式處理可水平擴展的能力。

4）分布式內(nèi)存數(shù)據(jù)庫，針對報警反復(fù)讀寫數(shù)據(jù)庫的情況，這是從性能角度考慮。

5）對SQL的支持好，數(shù)據(jù)庫的訪問就能非常靈活和簡潔，監(jiān)控報警規(guī)則就更容易實現(xiàn)。

6）去商業(yè)化，自主構(gòu)建?；陂_源軟件構(gòu)建，能夠最大程度滿足管理要求。

上述幾點是我們最初選擇報警處理引擎的一些考量或者是目標(biāo)。這和我們之前用的產(chǎn)品也有一定關(guān)系，我們之前采用的是IBM Omnibus產(chǎn)品，到現(xiàn)在也有很多金融機構(gòu)在使用該產(chǎn)品，它是一個基于內(nèi)存的支持SQL的報警處理引擎，它的最大問題就是單節(jié)點、單進程運行，所以對于大數(shù)據(jù)量的處理存在瓶頸。

所以我們開發(fā)的新報警引擎一方面要解決處理能力的瓶頸，另一方面要能夠完全兼容原平臺的處理邏輯和規(guī)則。這是我們在技術(shù)選型前的另外一個約束。

在產(chǎn)品選型的過程中，我們主要考慮的是兩部分，一是數(shù)據(jù)庫，二是分布式開發(fā)的框架。

在數(shù)據(jù)庫選型中，我們選擇了Apache Ignite作為分布式數(shù)據(jù)庫。和其他數(shù)據(jù)庫的對比，比如Oracle、MySQL、Eedis、Geode、ES，主要考量幾個特征是內(nèi)存關(guān)系數(shù)據(jù)庫、支持SQL、支持持久化等。

第二個選型，是分布式開發(fā)框架，因為框架主要用于引擎內(nèi)各個組件的高性能交互，所以我們選擇了Dubbo框架，相對更輕量和小巧。

關(guān)于 Apache Ignite，是基于Java語言開發(fā)的，可以用作一個分布式的緩存，也是一個分布式內(nèi)存數(shù)據(jù)庫，可以作為關(guān)系數(shù)據(jù)庫使用。它的數(shù)據(jù)儲存在堆外內(nèi)存的，不受GC影響，性能更好。作為內(nèi)存數(shù)據(jù)庫，它還能將數(shù)據(jù)持久化到磁盤，保證數(shù)據(jù)不丟失。另外一些特點比如支持事務(wù)、可配置為CP或者AP使用，支持SQL函數(shù)擴展以及內(nèi)置消息訂閱發(fā)布模型。

作為報警引擎來講，我們更加關(guān)注分布式緩存、分布式數(shù)據(jù)庫、和持久化。

下面是報警處理引擎的功能架構(gòu)圖，包括接入層、處理層、APP管理層、數(shù)據(jù)管理層和接口層。

其中的重點是處理層，分為兩大類的處理功能，下層是報警流處理，上層是報警的批處理。這些處理功能模塊是動態(tài)加載和可擴展的，是在App管理層采用應(yīng)用商店的模式，進行發(fā)布和編排的App。在我們的報警引擎中，將每個處理功能都作為一個App來管理。通過這樣的靈活管理和部署的架構(gòu)，滿足報警處理的各種需求。

從技術(shù)產(chǎn)品框架的視角看，最下層是自主開發(fā)的事件采集器 使用了spring boot + akka。應(yīng)用層采用Dubbo的分布式處理集群，集群內(nèi)運行多個事件處理節(jié)點，事件處理節(jié)點使用的技術(shù)包括：ANTLR 語法分析、java 動態(tài)編譯tools 以及Java RMI。使用zookeeper作為服務(wù)發(fā)布和訂閱的管理，ignite是報警存儲庫。最上層是報警視圖的前后端服務(wù)。

一個事件處理節(jié)點內(nèi)部的邏輯架構(gòu)和數(shù)據(jù)的流向圖如下：

主要內(nèi)容包括：

1）數(shù)據(jù)處理流程是報警從采集器來，送到流處理模塊后通過ignite客戶端節(jié)點入庫。批處理模塊負責(zé)把報警取出來進行二次分析，增刪改的動作還會送到流處理模塊進行處理后入庫。

2）在ignite庫中分為實時庫和歷史庫，保存所有的報警信息。引擎通過報警跟蹤的模塊，把所有的報警變化記錄同步到kafka，供第三方消費。批處理分配模塊則實現(xiàn)了批任務(wù)的分布式處理調(diào)度的工作。

3）控制臺提供用戶交互接口，管理流處理和批處理中運行的處理功能App。節(jié)點間管理信息的同步則通過RMI通訊模塊完成。

報警處理功能，是處理引擎的核心功能。什么是處理功能？比如一個報警發(fā)生了，要不要進維護期，那這就是一個報警處理功能。那維護期的判斷，一定是在報警通知之前執(zhí)行。那這就是功能間的編排。

我們的報警處理引擎，是以應(yīng)用商店App的模式對報警處理功能進行封裝和管理編排，定義了多種App類型，支持處理功能的定制開發(fā)。也就是說報警功能可以不斷的擴充的。

App的類型，包括：

在我行報警處理引擎正在運行的處理功能，包括一些基本的處理功能，比如報警豐富、報警壓縮 、恢復(fù)關(guān)聯(lián)、自動升降級、維護期等。在智能化報警方面，主要的處理功能用于報警的根因和影響分析，實現(xiàn)了根因升級和受影響報警的自動降級，場景包括如服務(wù)器宕機、應(yīng)用服務(wù)擁堵、DWDM中斷等異常場景。我們正在做的優(yōu)化工作，包括基于算法的報警和基于cmdb規(guī)則的排障樹等功能。 

總結(jié)一下報警處理引擎的特性：

特性包括：分布式處理、高可用；完全兼容之前IBM omnibus的處理規(guī)則，可以平滑過渡；支持App熱部署熱插拔；App可編排、調(diào)度和協(xié)作；擴展性強，支持自定義App開發(fā)和部署以及SQL函數(shù)擴展；高并發(fā)、高性能；支持告警鏈路追蹤和處理性能統(tǒng)計；支持全備+增量的備份方式；支持多數(shù)據(jù)中心主備模式部署。

前面講了監(jiān)控管理平臺的報警引擎，下面要再來分享標(biāo)準(zhǔn)化管理的內(nèi)容。

在前面介紹監(jiān)控系統(tǒng)演進過程時我們講到過，監(jiān)控管理的模型到目前為止還是依然適用的：

其中涉及監(jiān)控對象、監(jiān)控工具、監(jiān)控策略、監(jiān)控指標(biāo) ，比較核心的幾個概念和關(guān)系：

• 監(jiān)控指標(biāo)是針對每一類對象要監(jiān)控什么，是對象的一組動態(tài)屬性，比如CPU使用率就是一個指標(biāo)；

• 監(jiān)控策略是如何進行度量指標(biāo)，比如 CPU使用率大于80%，持續(xù)3分鐘，報一個警告; 

• 關(guān)系是：監(jiān)控對象關(guān)聯(lián)了監(jiān)控指標(biāo)，監(jiān)控策略實現(xiàn)了監(jiān)控指標(biāo)，并且在特定的監(jiān)控工具上運行，完成對監(jiān)控對象的監(jiān)控;

• 監(jiān)控標(biāo)準(zhǔn)，就是哪些對象用哪些策略覆蓋哪些指標(biāo)。把這些規(guī)則匯總和發(fā)布出來，就是我們企業(yè)級的監(jiān)控標(biāo)準(zhǔn)。

在實際運行中，監(jiān)控對象、指標(biāo)、策略和工具自身的內(nèi)容，都在發(fā)生變化，比如我們引入了交易量動態(tài)基線的監(jiān)控，實際上就是用一種新的工具和策略，去檢查我們原有的監(jiān)控對象和指標(biāo)。

在我行監(jiān)控系統(tǒng)實現(xiàn)時的一些要點總結(jié)如下：

1）在監(jiān)控對象管理的方面，支持對象全覆蓋、對象類別和屬性擴充、對象關(guān)聯(lián)關(guān)系管理。錄入對象時，物理的屬性是系統(tǒng)自動發(fā)現(xiàn)和采集；管理屬性優(yōu)先是從外部的cmdb進行同步。支持批量導(dǎo)入。這部分的管理功能可以套用cmdb的管理。

2）指標(biāo)方面，需要支持虛擬指標(biāo)和工具指標(biāo)的定義和關(guān)聯(lián)。

3）策略方面，要支持通用的公式編輯器，利用指標(biāo)生成策略。對于一些單向支持的工具，支持策略從工具進行抽取。

前面標(biāo)準(zhǔn)化模型的內(nèi)容都準(zhǔn)備好之后，就具備了監(jiān)控自動化和自服務(wù)部署策略的前提。

自動化分為兩個層次：

實現(xiàn)過程中的技術(shù)要點，就是通過監(jiān)控工具驅(qū)動程序的開發(fā)，實現(xiàn)平臺對底層監(jiān)控工具的變更操作，而且能夠屏蔽工具的差異性，快速接入各類工具。根據(jù)工具接口的完備度，有全驅(qū)動和半驅(qū)動之分，全驅(qū)動就是所有的操作都能在平臺層完成，半驅(qū)動就是常見的標(biāo)準(zhǔn)化策略部署，在平臺完成，一些特殊策略部署還需要到工具手工完成。 

正是有了驅(qū)動能力的不同，所以對于半驅(qū)動來說，我們還需要一個策略采集器，確保管理平臺有完整的工具策略。

對于監(jiān)控自服務(wù)管理的執(zhí)行，那我們有一個原則：專業(yè)團隊的管理員的自助式的配置，是在監(jiān)控標(biāo)準(zhǔn)下的自服務(wù)。

典型場景是操作人員錄入設(shè)備信息，自動發(fā)現(xiàn)或者同步資源的信息，然后補充必要的對象信息，預(yù)覽自動匹配到的監(jiān)控策略，進行確認(rèn)后，下發(fā)生效。

在這個流程中，策略的匹配和綁定是基于監(jiān)控規(guī)則的，監(jiān)控規(guī)則是企業(yè)級定義和發(fā)布的監(jiān)控標(biāo)準(zhǔn)，所以大家在進行自服務(wù)的時候，還是要以規(guī)則為準(zhǔn)。 

對于個性化策略的部署，技術(shù)上是可以支持的。目前在我們的實際使用中是要走ITSM流程審批過后，由監(jiān)控管理員去執(zhí)行非標(biāo)策略或個性化策略部署的。而且這種非標(biāo)的策略部署過后，我們是有評價機制來跟蹤的。

監(jiān)控評價模塊，用于事后量化評價每個應(yīng)用系統(tǒng)的監(jiān)控情況。

評價主要是3個指標(biāo)，監(jiān)控覆蓋率、監(jiān)控標(biāo)準(zhǔn)化率、超額布控率，這三個指標(biāo)在設(shè)計的時候，從管理上要求是逐級升高的：

1）監(jiān)控覆蓋率，是說需要有監(jiān)控，這是最基本的要求。計算公式是基于監(jiān)控指標(biāo)進行的。

2）監(jiān)控標(biāo)準(zhǔn)化率，是說除了有監(jiān)控，還應(yīng)該按照行里的標(biāo)準(zhǔn)策略進行監(jiān)控，比如標(biāo)準(zhǔn)的閾值是90%，如果某個服務(wù)器需要改為80%的閾值，那這就是不遵從標(biāo)準(zhǔn)了。所以監(jiān)控標(biāo)準(zhǔn)化率指標(biāo)是基于監(jiān)控策略進行計算的。

3）超額布控率，就是說前面的標(biāo)準(zhǔn)動作都做完了，如果管理員責(zé)任心強，又提了額外的監(jiān)控策略，那就是超額布控率，也是基于指標(biāo)計算的。

通過這樣三個指標(biāo)，可以對我們的應(yīng)用系統(tǒng)的監(jiān)控完備度進行一個量化的評價和排名。有了這個排名后，那我們的管理機制就能夠發(fā)揮作用了。

監(jiān)控評價的目標(biāo)是以評促改?；谠u價的結(jié)果，我們或者進一步去完善監(jiān)控標(biāo)準(zhǔn)，或者對于一些非標(biāo)的特例就要促進相應(yīng)的應(yīng)用系統(tǒng)進行整改，進一步符合監(jiān)控的規(guī)范。這樣一個持續(xù)改進的閉環(huán)就形成了。

管理平臺還有一個比較重要的功能，維護期管理。這和報警管理以及標(biāo)準(zhǔn)化管理都有一些關(guān)系。這個是個常用的功能，技術(shù)上并不復(fù)雜，但也非常容易出問題。它直接影響了報警的有效性，管理的不好很容易出現(xiàn)漏報警或者誤報警。

關(guān)于維護期使用，我們在多年的監(jiān)控運行中，吃了一些虧得到一些教訓(xùn)，這會促進我們不斷優(yōu)化相關(guān)的功能。以下經(jīng)驗和大家分享：

1）維護期最多設(shè)置30天，單次超過24小時，就要進行二次確認(rèn)，避免出現(xiàn)誤操作。

2）非周期的維護期內(nèi)發(fā)生的高級別報警，也要通知到管理員，避免把維護期報警和故障報警進行混淆。

3）出維護期前，管理員要去檢查維護期內(nèi)報警的狀態(tài)，避免出現(xiàn)誤報警。

4）出維護期后，如果報警還沒有恢復(fù)，那就要重新進入處置流程，避免遺漏報警。

此外，我們還定期導(dǎo)出報表，進行維護期的重檢，確認(rèn)維護期的有效性。

作為監(jiān)控管理平臺，如何對我們整個監(jiān)控體系的運行效果進行評價，最直接的指標(biāo)，是發(fā)現(xiàn)率和有效率。

目前運維中心設(shè)定的KPI指標(biāo)是監(jiān)控發(fā)現(xiàn)率，就是監(jiān)控系統(tǒng)發(fā)現(xiàn)的故障占總體故障的百分比。我們的監(jiān)控主動發(fā)現(xiàn)率基本能保持在98%以上，對于監(jiān)控未主動發(fā)現(xiàn)的故障，有相當(dāng)大比例會引起業(yè)務(wù)影響，這也從側(cè)面也證明了監(jiān)控的重要性。

前面講的偏向于工具功能以及技術(shù)實現(xiàn)，在這我還想強調(diào)一下體系的作用，體系包括人員的參與和管理流程：

1）人員各司其職很重要，一線人員、二線人員、專家、運維質(zhì)量管理人員、監(jiān)控管理的人員還有監(jiān)控系統(tǒng)建設(shè)的人員，都參與到系統(tǒng)運行中，而且通過二線應(yīng)用管理人員，開發(fā)項目組的人員也間接參與到整個監(jiān)控體系運轉(zhuǎn)中，盡職盡責(zé)。

2）我們做了很多基礎(chǔ)的管理工作和數(shù)據(jù)分析工作，通過監(jiān)控報表、事件報表，每天、每周、每月、每年的事件會，對報警相關(guān)的事件進行分析，持續(xù)的反饋和優(yōu)化監(jiān)控標(biāo)準(zhǔn)、補充策略。過去10年間，運維中心的領(lǐng)導(dǎo)能夠親身參與到這些工作中。堅持，所以才能讓我們的監(jiān)控系統(tǒng)持續(xù)優(yōu)化。

對于有效率指標(biāo)，從真實有效的角度去度量，那我行監(jiān)控系統(tǒng)誤報很少，都能如實反應(yīng)生產(chǎn)的情況。如果站在一個更高的要求去理解這個指標(biāo)，有效率表示的是事件的數(shù)量和報警的比值，提升有效率能夠減少無效報警的干擾，提升故障處置的效率。我們目前正在做的優(yōu)化是基于規(guī)則和場景，按照報警的根因和業(yè)務(wù)影響的分析，這兩個視角進行報警的合并和關(guān)聯(lián)，減少孤立報警的數(shù)量，提升報警的有效率。

最后我們對監(jiān)控系統(tǒng)的未來發(fā)展，做個展望?？傮w的方向，我們認(rèn)為是向數(shù)字化運營的轉(zhuǎn)變。

目標(biāo)是提升對數(shù)字化運行態(tài)的洞察力和智能分析能力。這里面有4個方面：

1）數(shù)字化的思維的建立和數(shù)字化的監(jiān)控轉(zhuǎn)型。

2）基于這些大數(shù)據(jù)，進一步豐富完善算法，推廣智能算法的應(yīng)用場景。

3）監(jiān)控管理和服務(wù)的融合，在強化監(jiān)控標(biāo)準(zhǔn)化管理的基礎(chǔ)上，還要更加快速的納管新的技術(shù)工具，提升自服務(wù)的應(yīng)用范圍和場景。

4）監(jiān)控云和云監(jiān)控。監(jiān)控云是以云原生方式構(gòu)建監(jiān)控系統(tǒng)，提升彈性和敏捷的能力，加強工具整合；云監(jiān)控則是提升容器、k8s、分布式應(yīng)用的監(jiān)控能力，通過監(jiān)控API的部署和使用，把運維和開發(fā)部門進行打通，提升云應(yīng)用自身的主動監(jiān)控能力。

Q1：咱們有用到規(guī)則引擎嗎？

A：用到了Spring SpEL，正在研究Drools。

Q2：請問Ignite持久化到RDMS有使用嗎？

A：沒有使用Ignite自身的機制持久化到RDMS，我們做了IDUC模塊將所有告警的變更操作都同步到了RDMS，這個比Ignite本身持久化到RDMS更細致。

Q3：請問實時流事件處理是基于Ignite嗎？

A：不是，Ignite只是用來做存儲，實時流處理是我們自己開發(fā)的模塊。

Q4：請問咱們Ignite可以支持多大的告警量？

A：支持千萬級的實時告警量，支持億級的歷史告警量。

Q5: 監(jiān)控的指標(biāo)會有相應(yīng)的區(qū)分嗎？比如根據(jù)采集的手段：遠程或者本地？

A：指標(biāo)是一個抽象概念，跟具體的實現(xiàn)解耦。指標(biāo)只包含名稱、單位、數(shù)據(jù)類型等關(guān)鍵屬性。

Q6：您好，想了解這里介紹的各個功能，是基本都已經(jīng)實現(xiàn)的還是規(guī)劃為主呢？

A：大部分已經(jīng)實現(xiàn)。有一些功能還在推廣過程中，如監(jiān)控自服務(wù)和監(jiān)控評價功能，還在持續(xù)提升工具的覆蓋范圍。

Q7：請問現(xiàn)在智能化監(jiān)控落地的場景能講一下嗎？

A：交易基線分析、批量運行時長分析、交易異常點定位。

Q8：請問目前光大銀行的自動化運維達到什么程度了呢？

A：和監(jiān)控相關(guān)的自動化主要是監(jiān)控策略自動部署，以及報警產(chǎn)生后推送到自動化運維平臺和運維工具箱進行自動匹配。

Q9：請問表鏡像用的是什么技術(shù)和工具？

A：使用Oracle Golden Gate實現(xiàn)Oracle數(shù)據(jù)庫之間以及Oracle數(shù)據(jù)庫到Kafka的實時數(shù)據(jù)同步。

Q10：可以談一談監(jiān)控和CMDB，流程平臺的關(guān)聯(lián)關(guān)系嗎？

A：監(jiān)控對象的全集來自CMDB，目前是每天自動同步；和流程平臺，目前已經(jīng)實現(xiàn)了變更流程的維護期自動設(shè)置，還有報警轉(zhuǎn)事件工單流程。

Q11：請問目前每天數(shù)據(jù)量有多少？

A：存量活動告警2萬以內(nèi)，歷史告警新增記錄數(shù)每天10w+。

Q12：晚上批處理監(jiān)控有沒有比較好的方法呢？特別是關(guān)鍵路徑上的批處理時間的監(jiān)控

A：我們是根據(jù)批量運行的歷史數(shù)據(jù)計算批量運行時長的基線，再根據(jù)基線進行報警。

Q13：TCP鏈路追蹤是指在網(wǎng)卡層進行分布式鏈路采集嗎？

A：我行的TCP鏈路監(jiān)控是通過網(wǎng)絡(luò)交換機旁路抓包的方式對TCP報文進行分析和監(jiān)控。

Q14：這個監(jiān)控平臺都是自己開發(fā)的嗎？沒有引入一些開源的監(jiān)控工具嗎？

A：基于開源工具進行自主開發(fā)的，具體的開源工具正文有介紹。

Q15：想了解下在存儲方面如何做統(tǒng)一監(jiān)控呢？

A：統(tǒng)一監(jiān)控平臺通過接收存儲設(shè)備推送的trap報警實現(xiàn)故障監(jiān)控。獨立運行的存儲管理平臺實現(xiàn)存儲設(shè)備及SAN交換機的性能監(jiān)控。

Q16：請問做自研的監(jiān)控平臺，從哪方面入手更好？比如先做好數(shù)據(jù)采集？用哪些開源技術(shù)棧比較好？

A：需要看具體的需求和資源投入了，最好還是做好提前規(guī)劃設(shè)計。最大化利用開源工具的能力，比如Prometheus、Zabbix。

Q17：請問監(jiān)控數(shù)據(jù)在問題故障根因定位等方面是如何使用，在哪些方面或環(huán)節(jié)必須基于監(jiān)控數(shù)據(jù)？

A：根因定位一般需要告警數(shù)據(jù)和配置數(shù)據(jù)兩類數(shù)據(jù)，告警數(shù)據(jù)指告警記錄本身，配置數(shù)據(jù)指描述對象的資源數(shù)據(jù)、描述業(yè)務(wù)的業(yè)務(wù)數(shù)據(jù)等等元描述數(shù)據(jù)。

Q18：請問應(yīng)用的監(jiān)控數(shù)據(jù)采集是通過什么方式？

A：應(yīng)用監(jiān)控數(shù)據(jù)采集方式主要包括：本地代理實時采集；外部服務(wù)探測；旁路網(wǎng)絡(luò)抓包；數(shù)據(jù)庫流水表同步鏡像等方式。

Q19：請問自動發(fā)現(xiàn)引擎用的是Zabbix還是自研呢？

A：服務(wù)器相關(guān)的自動發(fā)現(xiàn)是基于Zabbix的，網(wǎng)絡(luò)設(shè)備發(fā)現(xiàn)和配置采集是自研的。

Q20：請問帶外硬件設(shè)備的監(jiān)控，和帶內(nèi)系統(tǒng)監(jiān)控，關(guān)聯(lián)關(guān)系建立方面，有相關(guān)經(jīng)驗可以分享嗎？謝謝。

A：cmdb實現(xiàn)虛擬化OS和物理設(shè)備的收集匯總和關(guān)聯(lián)關(guān)系的建立。監(jiān)控同步cmdb的數(shù)據(jù)獲取相關(guān)的關(guān)系。

Q21：咱們機器學(xué)習(xí)算法也是在分布式內(nèi)存庫內(nèi)做嗎？

A：不是，是在我們的大數(shù)據(jù)平臺做的。

Q22：請教一下，告警收斂怎么實現(xiàn)？

A：在報警處理層面，通過預(yù)置場景，比如服務(wù)器宕機、交易繁忙等關(guān)聯(lián)規(guī)則，實現(xiàn)報警關(guān)聯(lián)和抑制。在通知層面，對于報警狀態(tài)未發(fā)生變化的情況，不會重復(fù)發(fā)送報警，且會對通知短信進行壓縮處理。

Q23：咱們有服務(wù)撥測相關(guān)的監(jiān)控功能嗎？可以介紹一下嗎？

A：我們采購了互聯(lián)網(wǎng)廠商的服務(wù)，從全國各運營商對我行外網(wǎng)應(yīng)用進行撥測，包括App和Web服務(wù)，監(jiān)控數(shù)據(jù)實時同步到行內(nèi)監(jiān)控系統(tǒng)。在內(nèi)網(wǎng)建設(shè)了私有化的撥測平臺和探點，通過錄制腳本和定期回放的方式監(jiān)控重點應(yīng)用。

Q24：告警關(guān)聯(lián)是如何實現(xiàn)的？可否舉個例子呢？

A：空間上，通過告警對象的關(guān)聯(lián)關(guān)系，比如同一個應(yīng)用系統(tǒng)下，如果數(shù)據(jù)庫發(fā)生告警，那么依賴他的所有中間件、應(yīng)用都會產(chǎn)生告警；時間上，通過時間窗，比如某個告警發(fā)生的前后幾分鐘之內(nèi)的所有告警。規(guī)則引擎會根據(jù)上述條件對報警進行實時分析，同時在這兩個維度有關(guān)聯(lián)的，才會進行告警的關(guān)聯(lián)。

Q25：請問告警風(fēng)暴和根因分析這塊兒，可以分享一下嗎？

A：目前采用了分布式內(nèi)存數(shù)據(jù)庫和分布式并發(fā)處理，完全可以應(yīng)付告警風(fēng)暴；根因分析是根據(jù)預(yù)置場景規(guī)則進行報警的關(guān)聯(lián)和壓制。

Q26：請問老師可以分享一下指標(biāo)的標(biāo)準(zhǔn)化體系建設(shè)嗎？

A：監(jiān)控指標(biāo)體系最初建立是多年監(jiān)控系統(tǒng)運行經(jīng)驗的積累?，F(xiàn)階段由監(jiān)控團隊負責(zé)監(jiān)控指標(biāo)的維護和管理，定期由專業(yè)團隊和各領(lǐng)域?qū)＜疫M行重檢。

特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：
長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝