原文地址：https://www.infoq.cn/article/TvHZGbm4EToxCb98PO0r?utm_source=related_read_bottom&utm_medium=article

光大銀行統一監控平臺，定位是服務全行科技條線的 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 等常見的開源軟體。另外也有國產的網路流量採集和分析的產品。對於存量的國外商業套件，我們已經制定了替換的計劃，預計會逐步下線。

在資料處理、資料儲存、前端展示以及開發部署各個層面，也就是平臺層的產品則基本都是開源的產品和技術。

上面是對我行監控系統整體的功能和架構進行了簡要介紹。

三、監控管理平臺建設實踐分享

前面介紹了光大銀行總體監控體系，在本章節我來介紹一下監控體系中的監控管理子系統。

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： 指標是一個抽象概念，跟具體的實現解耦。指標只包含名稱、單位、資料型別等關鍵屬性。

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 的，網路裝置發現和配置採集是自研的。

A： cmdb 實現虛擬化 OS 和物理裝置的收集彙總和關聯關係的建立。監控同步 cmdb 的資料獲取相關的關係。

Q21：咱們機器學習演算法也是在分散式記憶體庫內做嗎？

A： 不是，是在我們的大資料平臺做的。

Q22：請教一下，告警收斂怎麼實現？

A： 在報警處理層面，透過預置場景，比如伺服器宕機、交易繁忙等關聯規則，實現報警關聯和抑制。在通知層面，對於報警狀態未發生變化的情況，不會重複傳送報警，且會對通知簡訊進行壓縮處理。

Q23：咱們有服務撥測相關的監控功能嗎？可以介紹一下嗎？

A： 我們採購了網際網路廠商的服務，從全國各運營商對我行外網應用進行撥測，包括 App 和 Web 服務，監控資料實時同步到行內監控系統。在內網建設了私有化的撥測平臺和探點，通過錄制指令碼和定期回放的方式監控重點應用。

Q24：告警關聯是如何實現的？可否舉個例子呢？

A： 空間上，透過告警物件的關聯關係，比如同一個應用系統下，如果資料庫發生告警，那麼依賴他的所有中介軟體、應用都會產生告警；時間上，透過時間窗，比如某個告警發生的前後幾分鐘之內的所有告警。規則引擎會根據上述條件對報警進行實時分析，同時在這兩個維度有關聯的，才會進行告警的關聯。

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

A： 目前採用了分散式記憶體資料庫和分散式併發處理，完全可以應付告警風暴；根因分析是根據預置場景規則進行報警的關聯和壓制。

Q26：請問老師可以分享一下指標的標準化體系建設嗎？

A： 監控指標體系最初建立是多年監控系統執行經驗的積累。現階段由監控團隊負責監控指標的維護和管理，定期由專業團隊和各領域專家進行重檢。