本文由 dbaplus 社羣授權轉載。
大家好，我今天分享的主題是光大銀行統一監控平臺建設實踐。
光大銀行統一監控平臺，定位是服務全行科技條線的IT監控系統，是運維之眼。該平臺體系比較龐大，今天主要介紹偏向於監控管理和報警管理的相關功能。這部分功能是我行根據多年的經驗自主研發實現的，裏面蘊含着監控管理方面的理念和思路，希望此次分享能給大家帶來一些參考和啓發。
一、監控系統發展現狀分析
1、發展背景
金融科技是一個炙手可熱的話題，通過互聯網、大數據、雲計算、人工智能、區塊連等新技術的應用，支持和引領着業務的快速發展。
這個過程中，對銀行科技運維和運營都帶來了很大的挑戰，主要表現在：
- 業務對服務的穩定性、可靠性要求越來越高；
- 業務對IT支撐能力的依賴性越來越強；
- IT架構本身的複雜度越來越高。
爲了提升整體的IT運營和運維能力，銀行業的數據中心較早引入了ITIL管理理念，建立流程管理的模式，形成運維管理工作的流程化和標準化模式。
隨着雲計算、大數據和人工智能的發展，在原有的ITIL的基礎上引入了DevOps和AIOps理念的相關技術，逐步轉向爲數據和業務價值驅動，向着IT運營和數字化運營的目標轉型。
從我們光大銀行的角度，科技部運維中心提出了BCDT的理念，作爲運維相關工作的總體指導思想和理念。從監控系統建設的角度，主要的內容就是：
- 底線思維：不漏報、不誤報、全覆蓋，監控系統自身高可用，安全可靠；
- 閉環思維：監控能力建設要向開發、測試前移，監控策略的部署、故障處置、定位和後分析，要形成閉環持續優化；
- 發展思維：是研究和引入新的監控手段和管理方法，適應和滿足新的管理要求；
- 技術思維：強調技術是核心驅動力，通過技術帶動監控能力的提升。
2、建設歷程
光大銀行監控體系經過了多年的建設，歷經了幾個主要階段，通過分析可以看到主要的趨勢是朝着集中化、平臺化和數字化的發展方向。
1）2005年開始配置獨立的監控工具。
2）2011年開始進入平臺化建設，報警統一。
3）2014年開始全面監控，實現應用交易監控，搭建了大數據平臺的框架。
4）2018年新一代的監控管理平臺上線運行，這是我行自主研發的平臺，在報警管理、標準化和自動化能力上的提升明顯。
5）2019年科技運營數據平臺投產，這個系統通過產學研合作的方式落地 AI分析處理能力，監控系統向着數字化轉型。
3、思考總結
在我行監控管理系統持續演進的過程中，我們也在思考和總結，哪些是不變的，哪些是頻繁變化的。
相對穩定不變的內容包括：
- 平臺職能目標： 保障IT系統穩定運行，不變。運維中心對監控系統設定的主動發現率這個KPI指標，一直沒有變；
- 報警管理的目標： 事前預警、事中發現和定位、事後分析，這個工作方法沒有變。
- 監控管理的模型： 監控管理作爲業務去分析，它包含的監控對象、監控指標、監控策略，這個管理模型沒有變。
變化的內容就比較多了，比如：
- 監控對象更復雜；
- 監控技術和工具日新月異；
- 監控範圍涵蓋指標、日誌、Tracing等；
- 更加認識到數據的價值；
- 引入很多智能算法；
- 運維和開發更加緊密合作等等。
我們回顧和總結這個變化，對我們監控系統建設有很強的指導作用。不變的點更多是管理相關的能力和要求，這在市場上沒有完全滿足我們要求的產品，於是我們選擇了自主進行研發，最終形成了監控管理平臺。
而對於更多變化的內容，我們的策略是快速引入專業領域的監控工具納入到我行監控體系中使用，對接到管理平臺進行統一管理。發展趨勢中，大數據平臺的作用和價值凸顯，我們也以此作爲監控乃至IT運營的轉型的方向，基於開源的產品重點建設和優化。
二、光大銀行監控體系總體介紹
1、總體架構
在重點介紹監控管理平臺之前，有必要讓大家對光大銀行監控體系的總體架構和功能有個瞭解。
光大銀行監控系統的定位是面向全行科技部門的IT監控系統。從功能層面分爲3層，分別是監控工具層、平臺層和統一展示層。
1）監控工具層 ，包含各類開源或者商業的專業領域的監控工具，他們實現對各類監控工具的實時的數據採集。常見的比如Zabbix、Nagios、Prometheus、BPC、Tivoli等等，都定位在監控工具層。監控工具會把報警數據、性能數據、日誌數據，上送到平臺層。
2）平臺層 ，包含兩大部分功能：一是由監控報警處理、監控標準化和自服務等功能模塊組成的管理平臺；二是基於大數據架構的科技運營數據平臺，包括大數據處理、存儲、AI分析以及數據服務接口等子系統。在平臺層，還實現了和行內其他運維繫統的對接。
3）統一展示層 ，根據不同用戶的角色和場景，提供PC、大屏和手機端展示。
總的來說，平臺層的建設思路是開源+自研，是整個體系的核心；工具層的建設思路是專業+敏捷+統一管理。
通過多年的建設，監控系統的指標覆蓋從底層的機房設施到最上層的應用交易，實現了指標全覆蓋。藉助多種監控工具的部署，對監控指標的實現，一般都具備多種監控手段。
我們內部有個原則：對於關鍵指標，要有兩種的工具能夠覆蓋。這樣做有兩個好處：一是能夠確保監控策略有冗餘，二是確保當我們識別出一個新的指標要納入監控時，我們一定有工具能快速實現監控部署。
2、交易監控
交易監控，一直是所有監控系統建設的重點功能。我們通過多種手段，實現端到端的交易全方位監控：
1）採用了網絡旁路抓包、流水錶鏡像和交易日誌分析等多種方式監控交易成功率、響應率、響應時間等指標，實現了對應用無侵入的、實時的監控。
2）TCP網絡層監控，通過旁路方式對應用的全鏈路“通訊對”進行監控和分析，能夠快速發現網絡的異常，也能從網絡層面對應用故障進行協助定位和分析。
3）模擬監控，從互聯網以及內網探點模擬訪問應用系統，主動獲取可用性和性能數據，並接入到監控平臺進行集中處理和分析。
4）通過網絡抓包和日誌Api的方式進行端到端追蹤系統應用間和應用系統內部的交易路徑。這個功能目前在部分新架構下的應用系統已經實現，更多傳統的應用系統正在改造過程中。
3、大數據和智能化
大數據和智能算法，是我們現在的工作重心。2019年我們的科技運營數據平臺完成上線投產，這個平臺綜合運用了多種算法，實現了指標異常檢測、多維檢測、批處理異常檢測等多種功能。
對銀行業最重要的就是聯機交易和批量執行，智能監控爲傳統監控提供了重要的補充手段：
一個場景是交易監控，綜合節假日、促銷等各種因素實現動態的異常交易檢測和告警，可以細化到每一隻交易單獨進行監控，相比於傳統的固定閾值監控能提前3-5分鐘進行提示。
第二個場景，是對批量任務時長的智能分析，相比於傳統的固定批量執行時長的監控，智能分析的結果能夠做到提前預警，爲夜間故障處置贏得了時間。
在數據展示方面，我們建設了統一視圖系統。支持移動端、大屏端、PC端實時數據展示。根據業務場景，定製了日常運維視圖、 應急保障視圖、和重保運營視圖。
按照用戶角色的使用需求，對各類視圖進行分類，如一線偏重於故障發現、和按照預案處置以及事後的驗證；二線偏重於故障的解決以及趨勢分析和隱患排查。
4、技術棧
對於監控系統的建設，我們的原則是以開源爲主，自主可控。
在數據採集層面，我們使用了zabbix、nagios、prometheus 等常見的開源軟件。另外也有國產的網絡流量採集和分析的產品。對於存量的國外商業套件，我們已經制定了替換的計劃，預計會逐步下線。
需要特別提到的是，我們正在實施部署的統一採控Agent子系統，採用自研方式建設，目標是能夠成爲一個採集腳本編寫和管理的基礎平臺，提供通用的Agent驅動能力，獨立實現服務器上所有數據的實時採集，成爲大數據平臺最穩定可靠的數據來源。
在數據處理、數據存儲、前端展示以及開發部署各個層面，也就是平臺層的產品則基本都是開源的產品和技術。
上面是對我行監控系統整體的功能和架構進行了簡要介紹。
三、監控管理平臺建設實踐分享
前面介紹了光大銀行總體監控體系，在本章節我來介紹一下監控體系中的監控管理子系統。
1、管理平臺功能架構
這是監控管理平臺的總體功能架構圖：
主要是兩大部分，第一個是左半部分，從下到上包括報警採集、預處理和處理，構成了報警處理引擎子系統，其中還包括了報警通知和維護期管理的功能。
第二是右半部分從上到下，監控標準化管理子系統，包含監控對象、策略、指標和規則等標準化管理功能，以及監控配置自動化、監控評價等功能。
通俗的說，左面部分解決的是報警來了怎麼處理的問題， 右面部分解決的是報警如何配置，怎麼產生的問題。
2、監控報警引擎
下面分別介紹一下報警處理引擎和監控標準化管理兩大部分功能。報警處理引擎，是光大銀行自主研發實現的核心組件，所以這個部分是本次分享的重點內容。
首先，我們先來分析報警管理的技術和業務特點：
- 在事件採集層 ，數據源豐富、報文格式多種多樣，並且期望的採集延遲在毫秒級；
- 在報警處理層 ，特點包括報警量大、可能存在報警風暴、報警之間相關性高、處理邏輯複雜，要考慮擴展性並且還要合理繼承原有的規則，處理延遲要求在秒級完成；
- 在展示和處置層 ，要求的是展現形式多種多樣，前端頁面能夠高頻刷新或主動的接收服務器推送的報警，保證時效性。
基於上述報警管理的特點，我們制定了報警處理引擎的選型和開發的目標：
1）事件採集和處理要解耦，這樣能夠保證採集器的採集時效性。
2）事件處理集中化，規則、外部對象資源都要加載，通過集中處理可以更加充分的利用資源，一次加載重複使用。
3）事件處理分佈式，處理集中之後就要有分佈式處理可水平擴展的能力。
4）分佈式內存數據庫，針對報警反覆讀寫數據庫的情況，這是從性能角度考慮。
5）對SQL的支持好，數據庫的訪問就能非常靈活和簡潔，監控報警規則就更容易實現。
6）去商業化，自主構建。基於開源軟件構建，能夠最大程度滿足管理要求。
上述幾點是我們最初選擇報警處理引擎的一些考量或者是目標。這和我們之前用的產品也有一定關係，我們之前採用的是IBM Omnibus產品，到現在也有很多金融機構在使用該產品，它是一個基於內存的支持SQL的報警處理引擎，它的最大問題就是單節點、單進程運行，所以對於大數據量的處理存在瓶頸。
所以我們開發的新報警引擎一方面要解決處理能力的瓶頸，另一方面要能夠完全兼容原平臺的處理邏輯和規則。這是我們在技術選型前的另外一個約束。
在產品選型的過程中，我們主要考慮的是兩部分，一是數據庫，二是分佈式開發的框架。
在數據庫選型中，我們選擇了Apache Ignite作爲分佈式數據庫。和其他數據庫的對比，比如Oracle、MySQL、Eedis、Geode、ES，主要考量幾個特徵是內存關係數據庫、支持SQL、支持持久化等。
第二個選型，是分佈式開發框架，因爲框架主要用於引擎內各個組件的高性能交互，所以我們選擇了Dubbo框架，相對更輕量和小巧。
關於 Apache Ignite，是基於Java語言開發的，可以用作一個分佈式的緩存，也是一個分佈式內存數據庫，可以作爲關係數據庫使用。它的數據儲存在堆外內存的，不受GC影響，性能更好。作爲內存數據庫，它還能將數據持久化到磁盤，保證數據不丟失。另外一些特點比如支持事務、可配置爲CP或者AP使用，支持SQL函數擴展以及內置消息訂閱發佈模型。
作爲報警引擎來講，我們更加關注分佈式緩存、分佈式數據庫、和持久化。
下面是報警處理引擎的功能架構圖，包括接入層、處理層、APP管理層、數據管理層和接口層。
其中的重點是處理層，分爲兩大類的處理功能，下層是報警流處理，上層是報警的批處理。這些處理功能模塊是動態加載和可擴展的，是在App管理層採用應用商店的模式，進行發佈和編排的App。在我們的報警引擎中，將每個處理功能都作爲一個App來管理。通過這樣的靈活管理和部署的架構，滿足報警處理的各種需求。
從技術產品框架的視角看，最下層是自主開發的事件採集器 使用了spring boot + akka。應用層採用Dubbo的分佈式處理集羣，集羣內運行多個事件處理節點，事件處理節點使用的技術包括：ANTLR 語法分析、java 動態編譯tools 以及Java RMI。使用zookeeper作爲服務發佈和訂閱的管理，ignite是報警存儲庫。最上層是報警視圖的前後端服務。
一個事件處理節點內部的邏輯架構和數據的流向圖如下：
主要內容包括：
1）數據處理流程是報警從採集器來，送到流處理模塊後通過ignite客戶端節點入庫。批處理模塊負責把報警取出來進行二次分析，增刪改的動作還會送到流處理模塊進行處理後入庫。
2）在ignite庫中分爲實時庫和歷史庫，保存所有的報警信息。引擎通過報警跟蹤的模塊，把所有的報警變化記錄同步到kafka，供第三方消費。批處理分配模塊則實現了批任務的分佈式處理調度的工作。
3）控制檯提供用戶交互接口，管理流處理和批處理中運行的處理功能App。節點間管理信息的同步則通過RMI通訊模塊完成。
報警處理功能，是處理引擎的核心功能。什麼是處理功能？比如一個報警發生了，要不要進維護期，那這就是一個報警處理功能。那維護期的判斷，一定是在報警通知之前執行。那這就是功能間的編排。
我們的報警處理引擎，是以應用商店App的模式對報警處理功能進行封裝和管理編排，定義了多種App類型，支持處理功能的定製開發。也就是說報警功能可以不斷的擴充的。
App的類型，包括：
- 最普通的流App和批量App；
- 廣播型的App本質是爲分佈式批量；
- 訂閱型批量是和上述類型App組合使用的，用於數據的彙總和再處理；
- Restful App 可以動態的生成訪問App內部數據的接口，可以對App運行情況進行監控。
在我行報警處理引擎正在運行的處理功能，包括一些基本的處理功能，比如報警豐富、報警壓縮 、恢復關聯、自動升降級、維護期等。在智能化報警方面，主要的處理功能用於報警的根因和影響分析，實現了根因升級和受影響報警的自動降級，場景包括如服務器宕機、應用服務擁堵、DWDM中斷等異常場景。我們正在做的優化工作，包括基於算法的報警和基於cmdb規則的排障樹等功能。
總結一下報警處理引擎的特性：
特性包括：分佈式處理、高可用；完全兼容之前IBM omnibus的處理規則，可以平滑過渡；支持App熱部署熱插拔；App可編排、調度和協作；擴展性強，支持自定義App開發和部署以及SQL函數擴展；高併發、高性能；支持告警鏈路追蹤和處理性能統計；支持全備+增量的備份方式；支持多數據中心主備模式部署。
3、監控標準化
前面講了監控管理平臺的報警引擎，下面要再來分享標準化管理的內容。
在前面介紹監控系統演進過程時我們講到過，監控管理的模型到目前爲止還是依然適用的：
其中涉及監控對象、監控工具、監控策略、監控指標 ，比較核心的幾個概念和關係：
- 監控指標 是針對每一類對象要監控什麼，是對象的一組動態屬性，比如CPU使用率就是一個指標；
- 監控策略 是如何進行度量指標，比如 CPU使用率大於80%，持續3分鐘，報一個警告;
- 關係是： 監控對象關聯了監控指標，監控策略實現了監控指標，並且在特定的監控工具上運行，完成對監控對象的監控;
- 監控標準 ，就是哪些對象用哪些策略覆蓋哪些指標。把這些規則彙總和發佈出來，就是我們企業級的監控標準。
在實際運行中，監控對象、指標、策略和工具自身的內容，都在發生變化，比如我們引入了交易量動態基線的監控，實際上就是用一種新的工具和策略，去檢查我們原有的監控對象和指標。
在我行監控系統實現時的一些要點總結如下：
1）在監控對象管理的方面 ，支持對象全覆蓋、對象類別和屬性擴充、對象關聯關係管理。錄入對象時，物理的屬性是系統自動發現和採集；管理屬性優先是從外部的cmdb進行同步。支持批量導入。這部分的管理功能可以套用cmdb的管理。
2）指標方面 ，需要支持虛擬指標和工具指標的定義和關聯。
3）策略方面 ，要支持通用的公式編輯器，利用指標生成策略。對於一些單向支持的工具，支持策略從工具進行抽取。
4、監控自動化和自服務
前面標準化模型的內容都準備好之後，就具備了監控自動化和自服務部署策略的前提。
自動化分爲兩個層次：
- 自動化，就是監控的實施人員進行的自動化部署；
- 自服務，這個是面向專業團隊運維人員的操作。自服務是自動化的更高階的階段，需要系統提供面向業務場景的、更加易用的交互界面。
實現過程中的技術要點，就是通過監控工具驅動程序的開發，實現平臺對底層監控工具的變更操作，而且能夠屏蔽工具的差異性，快速接入各類工具。根據工具接口的完備度，有全驅動和半驅動之分，全驅動就是所有的操作都能在平臺層完成，半驅動就是常見的標準化策略部署，在平臺完成，一些特殊策略部署還需要到工具手工完成。
正是有了驅動能力的不同，所以對於半驅動來說，我們還需要一個策略採集器，確保管理平臺有完整的工具策略。
對於監控自服務管理的執行，那我們有一個原則：專業團隊的管理員的自助式的配置，是在監控標準下的自服務。
典型場景是操作人員錄入設備信息，自動發現或者同步資源的信息，然後補充必要的對象信息，預覽自動匹配到的監控策略，進行確認後，下發生效。
在這個流程中，策略的匹配和綁定是基於監控規則的，監控規則是企業級定義和發佈的監控標準，所以大家在進行自服務的時候，還是要以規則爲準。
對於個性化策略的部署，技術上是可以支持的。目前在我們的實際使用中是要走ITSM流程審批過後，由監控管理員去執行非標策略或個性化策略部署的。而且這種非標的策略部署過後，我們是有評價機制來跟蹤的。
5、監控評價
監控評價模塊，用於事後量化評價每個應用系統的監控情況。
評價主要是3個指標，監控覆蓋率、監控標準化率、超額布控率，這三個指標在設計的時候，從管理上要求是逐級升高的：
1）監控覆蓋率 ，是說需要有監控，這是最基本的要求。計算公式是基於監控指標進行的。
2）監控標準化率 ，是說除了有監控，還應該按照行裏的標準策略進行監控，比如標準的閾值是90%，如果某個服務器需要改爲80%的閾值，那這就是不遵從標準了。所以監控標準化率指標是基於監控策略進行計算的。
3）超額布控率 ，就是說前面的標準動作都做完了，如果管理員責任心強，又提了額外的監控策略，那就是超額布控率，也是基於指標計算的。
通過這樣三個指標，可以對我們的應用系統的監控完備度進行一個量化的評價和排名。有了這個排名後，那我們的管理機制就能夠發揮作用了。
監控評價的目標是以評促改。基於評價的結果，我們或者進一步去完善監控標準，或者對於一些非標的特例就要促進相應的應用系統進行整改，進一步符合監控的規範。這樣一個持續改進的閉環就形成了。
6、監控自動化和自服務
管理平臺還有一個比較重要的功能，維護期管理。這和報警管理以及標準化管理都有一些關係。這個是個常用的功能，技術上並不複雜，但也非常容易出問題。它直接影響了報警的有效性，管理的不好很容易出現漏報警或者誤報警。
關於維護期使用，我們在多年的監控運行中，吃了一些虧得到一些教訓，這會促進我們不斷優化相關的功能。以下經驗和大家分享：
1）維護期最多設置30天，單次超過24小時，就要進行二次確認，避免出現誤操作。
2）非週期的維護期內發生的高級別報警，也要通知到管理員，避免把維護期報警和故障報警進行混淆。
3）出維護期前，管理員要去檢查維護期內報警的狀態，避免出現誤報警。
4）出維護期後，如果報警還沒有恢復，那就要重新進入處置流程，避免遺漏報警。
此外，我們還定期導出報表，進行維護期的重檢，確認維護期的有效性。
7、監控管理的整體評價
作爲監控管理平臺，如何對我們整個監控體系的運行效果進行評價，最直接的指標，是發現率和有效率。
目前運維中心設定的KPI指標是監控發現率，就是監控系統發現的故障佔總體故障的百分比。我們的監控主動發現率基本能保持在98%以上，對於監控未主動發現的故障，有相當大比例會引起業務影響，這也從側面也證明了監控的重要性。
前面講的偏向於工具功能以及技術實現，在這我還想強調一下體系的作用，體系包括人員的參與和管理流程：
1）人員各司其職很重要，一線人員、二線人員、專家、運維質量管理人員、監控管理的人員還有監控系統建設的人員，都參與到系統運行中，而且通過二線應用管理人員，開發項目組的人員也間接參與到整個監控體系運轉中，盡職盡責。
2）我們做了很多基礎的管理工作和數據分析工作，通過監控報表、事件報表，每天、每週、每月、每年的事件會，對報警相關的事件進行分析，持續的反饋和優化監控標準、補充策略。過去10年間，運維中心的領導能夠親身參與到這些工作中。堅持，所以才能讓我們的監控系統持續優化。
對於有效率指標，從真實有效的角度去度量，那我行監控系統誤報很少，都能如實反應生產的情況。如果站在一個更高的要求去理解這個指標，有效率表示的是事件的數量和報警的比值，提升有效率能夠減少無效報警的干擾，提升故障處置的效率。我們目前正在做的優化是基於規則和場景，按照報警的根因和業務影響的分析，這兩個視角進行報警的合併和關聯，減少孤立報警的數量，提升報警的有效率。
四、未來發展方向展望
最後我們對監控系統的未來發展，做個展望。總體的方向，我們認爲是向數字化運營的轉變。
目標是提升對數字化運行態的洞察力和智能分析能力。這裏面有4個方面：
1）數字化的思維的建立和數字化的監控轉型。
2）基於這些大數據，進一步豐富完善算法，推廣智能算法的應用場景。
3）監控管理和服務的融合，在強化監控標準化管理的基礎上，還要更加快速的納管新的技術工具，提升自服務的應用範圍和場景。
4）監控雲和雲監控。監控雲是以雲原生方式構建監控系統，提升彈性和敏捷的能力，加強工具整合；雲監控則是提升容器、k8s、分佈式應用的監控能力，通過監控API的部署和使用，把運維和開發部門進行打通，提升雲應用自身的主動監控能力。
Q&A
Q1：咱們有用到規則引擎嗎？
A： 用到了Spring SpEL，正在研究Drools。
Q2：請問Ignite持久化到RDMS有使用嗎？
A： 沒有使用Ignite自身的機制持久化到RDMS，我們做了IDUC模塊將所有告警的變更操作都同步到了RDMS，這個比Ignite本身持久化到RDMS更細緻。
Q3：請問實時流事件處理是基於Ignite嗎？
A： 不是，Ignite只是用來做存儲，實時流處理是我們自己開發的模塊。
Q4：請問咱們Ignite可以支持多大的告警量？
A： 支持千萬級的實時告警量，支持億級的歷史告警量。
Q5: 監控的指標會有相應的區分嗎？比如根據採集的手段：遠程或者本地？
A： 指標是一個抽象概念，跟具體的實現解耦。指標只包含名稱、單位、數據類型等關鍵屬性。
Q6：您好，想了解這裏介紹的各個功能，是基本都已經實現的還是規劃爲主呢？
A： 大部分已經實現。有一些功能還在推廣過程中，如監控自服務和監控評價功能，還在持續提升工具的覆蓋範圍。
Q7：請問現在智能化監控落地的場景能講一下嗎？
A： 交易基線分析、批量運行時長分析、交易異常點定位。
Q8：請問目前光大銀行的自動化運維達到什麼程度了呢？
A： 和監控相關的自動化主要是監控策略自動部署，以及報警產生後推送到自動化運維平臺和運維工具箱進行自動匹配。
Q9：請問表鏡像用的是什麼技術和工具？
A： 使用Oracle Golden Gate實現Oracle數據庫之間以及Oracle數據庫到Kafka的實時數據同步。
Q10：可以談一談監控和CMDB，流程平臺的關聯關係嗎？
A： 監控對象的全集來自CMDB，目前是每天自動同步；和流程平臺，目前已經實現了變更流程的維護期自動設置，還有報警轉事件工單流程。
Q11：請問目前每天數據量有多少？
A： 存量活動告警2萬以內，歷史告警新增記錄數每天10w+。
Q12：晚上批處理監控有沒有比較好的方法呢？特別是關鍵路徑上的批處理時間的監控
A： 我們是根據批量運行的歷史數據計算批量運行時長的基線，再根據基線進行報警。
Q13：TCP鏈路追蹤是指在網卡層進行分佈式鏈路採集嗎？
A： 我行的TCP鏈路監控是通過網絡交換機旁路抓包的方式對TCP報文進行分析和監控。
Q14：這個監控平臺都是自己開發的嗎？沒有引入一些開源的監控工具嗎？
A： 基於開源工具進行自主開發的，具體的開源工具正文有介紹。
Q15：想了解下在存儲方面如何做統一監控呢？
A： 統一監控平臺通過接收存儲設備推送的trap報警實現故障監控。獨立運行的存儲管理平臺實現存儲設備及SAN交換機的性能監控。
Q16：請問做自研的監控平臺，從哪方面入手更好？比如先做好數據採集？用哪些開源技術棧比較好？
A： 需要看具體的需求和資源投入了，最好還是做好提前規劃設計。最大化利用開源工具的能力，比如Prometheus、Zabbix。
Q17：請問監控數據在問題故障根因定位等方面是如何使用，在哪些方面或環節必須基於監控數據？
A： 根因定位一般需要告警數據和配置數據兩類數據，告警數據指告警記錄本身，配置數據指描述對象的資源數據、描述業務的業務數據等等元描述數據。
Q18：請問應用的監控數據採集是通過什麼方式？
A： 應用監控數據採集方式主要包括：本地代理實時採集；外部服務探測；旁路網絡抓包；數據庫流水錶同步鏡像等方式。
Q19：請問自動發現引擎用的是Zabbix還是自研呢？
A： 服務器相關的自動發現是基於Zabbix的，網絡設備發現和配置採集是自研的。
Q20：請問帶外硬件設備的監控，和帶內系統監控，關聯關係建立方面，有相關經驗可以分享嗎？謝謝。
A： cmdb實現虛擬化OS和物理設備的收集彙總和關聯關係的建立。監控同步cmdb的數據獲取相關的關係。
Q21：咱們機器學習算法也是在分佈式內存庫內做嗎？
A： 不是，是在我們的大數據平臺做的。
Q22：請教一下，告警收斂怎麼實現？
A： 在報警處理層面，通過預置場景，比如服務器宕機、交易繁忙等關聯規則，實現報警關聯和抑制。在通知層面，對於報警狀態未發生變化的情況，不會重複發送報警，且會對通知短信進行壓縮處理。
Q23：咱們有服務撥測相關的監控功能嗎？可以介紹一下嗎？
A： 我們採購了互聯網廠商的服務，從全國各運營商對我行外網應用進行撥測，包括App和Web服務，監控數據實時同步到行內監控系統。在內網建設了私有化的撥測平臺和探點，通過錄制腳本和定期回放的方式監控重點應用。
Q24：告警關聯是如何實現的？可否舉個例子呢？
A： 空間上，通過告警對象的關聯關係，比如同一個應用系統下，如果數據庫發生告警，那麼依賴他的所有中間件、應用都會產生告警；時間上，通過時間窗，比如某個告警發生的前後幾分鐘之內的所有告警。規則引擎會根據上述條件對報警進行實時分析，同時在這兩個維度有關聯的，纔會進行告警的關聯。
Q25：請問告警風暴和根因分析這塊兒，可以分享一下嗎？
A： 目前採用了分佈式內存數據庫和分佈式併發處理，完全可以應付告警風暴；根因分析是根據預置場景規則進行報警的關聯和壓制。
Q26：請問老師可以分享一下指標的標準化體系建設嗎？
A： 監控指標體系最初建立是多年監控系統運行經驗的積累。現階段由監控團隊負責監控指標的維護和管理，定期由專業團隊和各領域專家進行重檢。
作者介紹：
胖亞鵬
光大銀行科技部系統架構師
- 光大銀行科技部系統架構師、技術專家，具有十餘年監控系統建設的項目實施經驗。目前主要負責光大銀行統一監控管理平臺的總體架構規劃和欄目內部研發管理等工作。
- 對監控系統的管理模型優化、監控服務化的實現以及分佈式監控等領域有較深入的研究和理解。對於將AI技術運用到監控領域有濃厚興趣。
原文鏈接：