銀行一體化監(jiān)控平臺建設最佳實踐

1、 銀行一體化監(jiān)控平臺建設最佳實踐 目前很多銀行針對各類設備、業(yè)務系統(tǒng)構(gòu)建了各種監(jiān)控，然而各個廠商、不同類別的監(jiān)控系統(tǒng)就像一座座孤島占滿了監(jiān)控大屏，各種監(jiān)控各管一段，有些復雜的故障問題或性能問題的定位就變的尤其復雜，影響了問題的快速定位和故障處置。因此，如何構(gòu)建一個一體化監(jiān)控體系（或者統(tǒng)一監(jiān)控體系），成為一個愈來愈緊迫的問題?！締栴}1】銀行建設統(tǒng)一/一體化監(jiān)控平臺的主要原因？從需求角度分析原因：從技術發(fā)展上，目前很多銀行目前已經(jīng)上了新核心，用到了云，容器，微服務等新技術。從業(yè)務要求上，業(yè)務對穩(wěn)定性要求越來越高，要求故障出現(xiàn)后更加及時的恢復，避免帶來業(yè)務的損失。一方面，目前無論是大型、中型還是小型

2、銀行都有統(tǒng)一監(jiān)控平臺的需求，不僅僅因為事件需要集中，為實現(xiàn)業(yè)務系統(tǒng)端到端的監(jiān)控，必然需要多樣的監(jiān)控手段和技術去支撐，帶來監(jiān)控源的多樣化，必然也需要統(tǒng)一的運維數(shù)據(jù)分析平臺去揉合這些監(jiān)控數(shù)據(jù)，輔助運維人員定位根因，甚至結(jié)合歷史處理方式，直接定位故障根因和處理方法。另一方面，統(tǒng)一監(jiān)控平臺是應用穩(wěn)定運行保障的基石（參考谷歌SRE）,一體化的監(jiān)控平臺解決應用、業(yè)務、用戶視角的監(jiān)控，幫助用戶實現(xiàn)根因分析，根因定位，容量預測等等。是企業(yè)數(shù)字化轉(zhuǎn)型的必備工具。從技術角度分析原因：監(jiān)控方式、技術和類型過多，需要一個統(tǒng)一的事件平臺來集中豐富、處理和分析不同監(jiān)控源的告警事件；還需要一個統(tǒng)一的數(shù)據(jù)接入平臺（運維大數(shù)據(jù)

3、）來對不同監(jiān)控源性能數(shù)據(jù)、日志和告警數(shù)據(jù)進行整合、分析、統(tǒng)計，借助AI的能力，智能輔助運維快速定位和根因分析；倘若銀行企業(yè)端到端的監(jiān)控源都比較完善（BPM、NPM、基礎監(jiān)控、APM、TPM等），可以進一步結(jié)合IT架構(gòu)可視化系統(tǒng)，深化統(tǒng)一監(jiān)控平臺項目建設，通過將IT架構(gòu)與多類數(shù)據(jù)源結(jié)合的方式，讓架構(gòu)圖更加生動，運維人員在統(tǒng)一的可視化架構(gòu)下，更為精準的定位故障。沒有做到集中、統(tǒng)一監(jiān)控、統(tǒng)一分析，那么各個系統(tǒng)是一套套毫無關聯(lián)散沙，告警風暴來臨時，多個告警平臺同時告警，事件豐富的方式、聯(lián)系人員也不同，運維人員像沒頭蒼蠅，不僅無法快速判斷故障根源，還可能會因多套監(jiān)控平臺的告警事件擾亂故障定位。【問題2】

4、銀行信息系統(tǒng)監(jiān)控領域產(chǎn)品類型有哪些？每類產(chǎn)品主要技術路線有哪些？整理了一張表格簡要介紹下信息系統(tǒng)監(jiān)控領域的產(chǎn)品類型和主要技術路線（點擊可放大）：【問題3】銀行信息系統(tǒng)監(jiān)控體系整體架構(gòu)層次和關系是怎樣的？這里有三張圖，供大家參考。第一張圖是整體監(jiān)控、運維體系架構(gòu)圖，其中統(tǒng)一CMDB為所有系統(tǒng)和平臺提供統(tǒng)一的配置基準數(shù)據(jù)，提升聯(lián)動的數(shù)據(jù)質(zhì)量和效果；自動化運維平臺自動采集和發(fā)現(xiàn)價值數(shù)據(jù)和數(shù)據(jù)關聯(lián)，供其他系統(tǒng)和平臺使用，和各項資源建立自動化關聯(lián)關系，提供不同自動化運維場景調(diào)用API，供其他系統(tǒng)和平臺調(diào)用；集中監(jiān)控平臺對接所有監(jiān)控系統(tǒng)和平臺，實時收集所有事件和告警，結(jié)合CMDB配置數(shù)據(jù)，第一時間匹配和豐

5、富事件告警內(nèi)容，以豐富的通知手段和詳盡真實的告警詳情告知相關負責人；運維大數(shù)據(jù)通過多樣化、不同通道的方式，集成各系統(tǒng)和平臺的實時或歷史的結(jié)構(gòu)化、非結(jié)構(gòu)化數(shù)據(jù)，并進行過濾、清洗、加工、整合、分析、輸出和數(shù)據(jù)持久化；IT架構(gòu)可視化系統(tǒng)通過業(yè)務系統(tǒng)部署架構(gòu)圖、業(yè)務邏輯架構(gòu)圖、業(yè)務網(wǎng)絡拓撲圖三類架構(gòu)圖的方式，結(jié)合運維大數(shù)據(jù)中，不同數(shù)據(jù)源的數(shù)據(jù)，包括智能運維產(chǎn)出的建議，進行實時的展示，讓數(shù)據(jù)和圖聯(lián)動，更為直觀的展示業(yè)務系統(tǒng)整體運行狀況。運維以IT架構(gòu)可視化為主，智能運維為輔，強調(diào)人在運維中不可替代性。第二張圖是網(wǎng)絡性能管理（NPM）、運維大數(shù)據(jù)平臺及與現(xiàn)有的基礎監(jiān)控和集中事件平臺聯(lián)動的整體功能邏輯架構(gòu)圖

6、。網(wǎng)絡流量報文通過TAP設備發(fā)送至NPM服務器和BPC服務器的采集口；NPM系統(tǒng)和BPC系統(tǒng)實時解碼模塊，對網(wǎng)絡原始比特流進行解析，輸出網(wǎng)絡層指標和業(yè)務應用層指標；業(yè)務層和網(wǎng)絡層 數(shù)據(jù)分析模塊實時分析性能指標：交易量、成功率、交易渠道、交易類型、金額、TCP連接狀態(tài)、丟包狀態(tài)、網(wǎng)絡時延等等指標；前臺展示模塊從運維角度，可以實時的展示每一個節(jié)點的業(yè)務層和網(wǎng)絡層指標情況，并配置實時告警，做到快速發(fā)現(xiàn)、快速定位、快速恢復；前臺展示模塊從業(yè)務運營角度，可以對全行交易情況進行實時大屏展示，對業(yè)務 交易渠道、交易機構(gòu)、 交易金額、交易量 、 自定義的統(tǒng)計維度 等進行實時分類統(tǒng)計分析；業(yè)務性能監(jiān)控系統(tǒng)對外的

7、接口包括數(shù)據(jù)輸出接口、交易明細輸出、告警接口：數(shù)據(jù)輸出接口可將業(yè)務監(jiān)控系統(tǒng)統(tǒng)計的交易性能數(shù)據(jù)和交易明細數(shù)據(jù)按JSON、CSV、xml等方式實時輸出，提供給第三方系統(tǒng)。或者第三方系統(tǒng)可以通過RestfulAPI的方式來查詢所產(chǎn)生的統(tǒng)計數(shù)據(jù)、告警數(shù)據(jù)、明細報文數(shù)據(jù)等。告警信息可通過syslog、socket等方式發(fā)送到第三方事件管理平臺進行集成，統(tǒng)一進行匯總處理。本次實時解析的各系統(tǒng)性能數(shù)據(jù)，業(yè)務交易字段等實時推送給運維大數(shù)據(jù)平臺，為實時運維大數(shù)據(jù)分析提供真實可信的數(shù)據(jù)源；業(yè)務交易及網(wǎng)絡性能監(jiān)控產(chǎn)生的告警事件，實時推送到現(xiàn)有集中事件平臺 ；運維大數(shù)據(jù)平臺產(chǎn)生的告警事件，實時推送到現(xiàn)有集中事件平臺；

8、運維大數(shù)據(jù)平臺可根據(jù)故障發(fā)生時間點，復原系統(tǒng)的性能、日志、網(wǎng)絡報文等信息，輔助故障分析和快速解決 ；在集中了性能、配置、日志、事件等運維數(shù)據(jù)的基礎上， 以運維大數(shù)據(jù)平臺為核心， 開展智能運維在監(jiān)控方面的建設，如單、多指標預測和分析、建議，告警事件自動關聯(lián)知識庫，指導運維人員快速解決問題，結(jié)合多類監(jiān)控數(shù)據(jù)，進行可能的根因分析，輔助運維人員快速定位故障源，并在告警日志上下文歷史挖掘分析、同類告警周期性規(guī)律分析、告警成對成組出現(xiàn)分析、告警相關與因果分析等等方面，進行智能分析，推進運維工作自動化和智能化 ；在各數(shù)據(jù)源數(shù)據(jù)統(tǒng)一接入運維大數(shù)據(jù)平臺后，可為不同的用戶的行為進行畫像，供以后的精準營銷或者風控項

9、目消費，進一步指導業(yè)務的運營和管理等。第三張圖是運維大數(shù)據(jù)平臺的整體架構(gòu)圖， 自下而上，最下面一層是數(shù)據(jù)源層，提供各種運維數(shù)據(jù)庫包括結(jié)構(gòu)化數(shù)據(jù)如關系型數(shù)據(jù)庫以及非結(jié)構(gòu)化數(shù)據(jù)例如各種系統(tǒng)日志，這些數(shù)據(jù)可以通過代理采集方式獲取；另外一部分數(shù)據(jù)來源是現(xiàn)有系統(tǒng)，例如監(jiān)控平臺、網(wǎng)管、APM等工具，這些平臺本身已經(jīng)提供了各自該平臺的事件或者性能數(shù)據(jù)，可以通過API的方式進行數(shù)據(jù)采集或者推送；數(shù)據(jù)源之上是運維管理總線，運維管理總線提供數(shù)據(jù)的接入、緩存、預處理，以及各個系統(tǒng)之間的消息傳遞、API調(diào)用。這一層通過搭建異步消息總線例如kafka集群來實現(xiàn)消息交互；第三層是數(shù)據(jù)處理層，包括兩個方面，首先是大數(shù)據(jù)平臺

10、，大數(shù)據(jù)平臺提供的是數(shù)據(jù)流式解析（例如數(shù)據(jù)加工、實時告警），數(shù)據(jù)計算以及存儲能力；另外一部分是智能算法層，主要提供、訓練各種智能算法模型；數(shù)據(jù)處理層之上是接口層，接口層是為了根據(jù)不同的智能化運維場景提供接口調(diào)用，包括服務總線，主要提供API的注冊、接口網(wǎng)關、狀態(tài)、調(diào)用的管理，數(shù)據(jù)網(wǎng)關主要提供數(shù)據(jù)的查詢，數(shù)據(jù)網(wǎng)關等功能；采用的架構(gòu)為微服務架構(gòu)和總線架構(gòu)：微服務架構(gòu)可以將運維子系統(tǒng)的所有功能、操作、指令全部轉(zhuǎn)變?yōu)樵硬僮?，接受AIOPS的總體調(diào)度。運維總線架構(gòu)可以將各類系統(tǒng)的相互通訊模式由網(wǎng)狀變?yōu)樾切?，降低關聯(lián)耦合度，提高通訊的速度、穩(wěn)定性、可用性、可擴展性，使得大數(shù)據(jù)通訊不再成為瓶頸；最上面一層

11、是AIOps場景層，該層次是通過調(diào)用API層提供的各種能力來實現(xiàn)智能化場景。場景層的設置是根據(jù)事件的生命周期進行設置的，例如在發(fā)現(xiàn)問題階段通過自動基線、通過日志分類來判斷異常，發(fā)現(xiàn)問題；到通過關聯(lián)分析、日志深度檢查、應用全鏈路監(jiān)控等來分析問題；通過匹配知識庫，調(diào)用運維調(diào)度平臺來定位問題；最后通過智能預測來預測容量、故障的發(fā)生。另外提供了為領導層提供輔助決策的功能，例如系統(tǒng)畫像、用戶工單、請求分析等?！締栴}4】 銀行信息系統(tǒng)監(jiān)控涉及的系統(tǒng)、網(wǎng)絡、應用等軟硬件種類繁雜，如何進行有效的監(jiān)控整合，避免各個監(jiān)控系統(tǒng)之間的數(shù)據(jù)孤島？監(jiān)控系統(tǒng)之間目前確實很容易存在數(shù)據(jù)孤島的問題，比如基礎監(jiān)控和業(yè)務監(jiān)控，和網(wǎng)

12、絡監(jiān)控等，這些監(jiān)控到的東西，無法形成統(tǒng)一的整體，割裂開來，造成網(wǎng)絡做網(wǎng)絡的監(jiān)控、應用做業(yè)務的監(jiān)控、系統(tǒng)做系統(tǒng)的基礎監(jiān)控，大家都是孤立的個體，最多通過統(tǒng)一的事件平臺來展示和告警而已。這種現(xiàn)狀，顯然已經(jīng)無法滿足企業(yè)，尤其是銀行企業(yè)的實際運維監(jiān)控需求，因此如何把這些孤立的數(shù)據(jù)，協(xié)同、統(tǒng)一起來，變得十分的重要。有兩種思路供大家參考：第一種是：運維大數(shù)據(jù)，通過對多運維數(shù)據(jù)源的匯總，分析，歸納，統(tǒng)計，形成一個統(tǒng)一的可視化運維分析平臺，出現(xiàn)故障，不再是割裂的，而是統(tǒng)一的各類信息的整合， 實現(xiàn)統(tǒng)一分析，如根因定位，告警的影響性分析，應用容量分析和預測等等。另外運維大數(shù)據(jù)更重要的是多類監(jiān)控數(shù)據(jù)源的數(shù)據(jù)，有結(jié)構(gòu)化

13、的、非結(jié)構(gòu)化的數(shù)據(jù)，不斷學習，做深入挖掘，幫助運維人員找出可能的根因。第二種是：IT架構(gòu)可視化，在統(tǒng)一的網(wǎng)絡架構(gòu)、業(yè)務邏輯架構(gòu)、應用部署架構(gòu)下，展示所有的運維數(shù)據(jù)，有實時的基礎監(jiān)控數(shù)據(jù)、業(yè)務性能數(shù)據(jù)（BPC）、網(wǎng)絡性能數(shù)據(jù)（NPM）、運維大數(shù)據(jù)分析后的數(shù)據(jù)（ITOA）、APP終端性能數(shù)據(jù)（TPM）、流程數(shù)據(jù)（ITSM）等等，整個統(tǒng)一架構(gòu)下的，不同數(shù)據(jù)源的整合，讓運維人員，可視化的發(fā)現(xiàn)可能的根因。利用“IT架構(gòu)圖”與數(shù)據(jù)相互結(jié)合的方式，圖可以分三類，一類是業(yè)務系統(tǒng)所在的網(wǎng)絡架構(gòu)，結(jié)合NPM的數(shù)據(jù)和流程數(shù)據(jù)，網(wǎng)絡架構(gòu)中的節(jié)點，可以關聯(lián)CMDB的數(shù)據(jù)和NPM性能數(shù)據(jù)和告警數(shù)據(jù)等；二類是業(yè)務系統(tǒng)的業(yè)務

14、邏輯架構(gòu)，也就是該業(yè)務系統(tǒng)和其他系統(tǒng)的關聯(lián)關系，這張圖上的業(yè)務節(jié)點，可以關聯(lián)業(yè)務性能指標和流程數(shù)據(jù)，清晰的知道該業(yè)務系統(tǒng)的健康狀態(tài)，如業(yè)務量，業(yè)務成功率和系統(tǒng)響應率，和告警，或者近期有沒有流程變更等；三類是業(yè)務系統(tǒng)的部署架構(gòu)圖，其中的各類組件，比如WEB、中間件、數(shù)據(jù)庫、應用負載、非通用設備等，關聯(lián)的數(shù)據(jù)是基礎性能數(shù)據(jù)和流程等。有了這樣一套IT可視化系統(tǒng)，各類運維人員，無論是網(wǎng)絡、系統(tǒng)還是應用運維人員都可以很清晰的知曉哪里有問題，哪里是關鍵節(jié)點，幫助迅速定位可能的原因。而不是每個運維人員心中一張圖，各自定位，信息孤島，排查問題低效。【問題5】一體化監(jiān)控技術選型方案？一體化系統(tǒng)監(jiān)控包含哪些系統(tǒng)的

15、監(jiān)控，如何進行技術選型，采用何種研發(fā)方式，自研還是外采？監(jiān)控是個體系化工程，在這個體系內(nèi)有基礎監(jiān)控部分，包括網(wǎng)絡基礎監(jiān)控、動力環(huán)境監(jiān)控、數(shù)據(jù)庫監(jiān)控、中間件監(jiān)控、操作系統(tǒng)監(jiān)控和硬件監(jiān)控等等，還有業(yè)務性能監(jiān)控（以業(yè)務為中心的性能監(jiān)控），應用性能監(jiān)控（以應用軟件為中心的性能監(jiān)控），網(wǎng)絡性能監(jiān)控（以網(wǎng)絡為中心的性能監(jiān)控），還有終端體驗監(jiān)控，包括APP SDK或者客戶端等終端的監(jiān)控，應用撥測等等。最后需要一個統(tǒng)一的事件平臺來整合管控所有告警事件；需要一個運維方向上的大數(shù)據(jù)平臺，來接入所有監(jiān)控源數(shù)據(jù),包括基礎監(jiān)控，APM，BPM，NPM，TPM，撥測數(shù)據(jù)，實現(xiàn)歷史數(shù)據(jù)分析和挖掘,實時監(jiān)控數(shù)據(jù)整合，通過AI

16、技術實現(xiàn)智能運維；需要一個架構(gòu)可視化平臺，以架構(gòu)為圖，圖上的各元素接入運維大數(shù)據(jù)平臺的各監(jiān)控數(shù)據(jù)源的數(shù)據(jù)，來集中展現(xiàn)。像我們中小金融機構(gòu)，一般采用外采的較多，自研還是偏向基礎監(jiān)控的多些，畢竟基礎監(jiān)控的門檻不是高，腳本開發(fā)也是不難，這類可以自研。但一些專業(yè)度較高的，業(yè)務和網(wǎng)絡性能監(jiān)控，一般通過網(wǎng)絡旁路鏡像的方式采集數(shù)據(jù)，報文解碼能力要求很高，很難自研，市面上的成熟產(chǎn)品也很多，案例也是非常多，可以直接外采。應用監(jiān)控的話，看應用是外采還是自研的了，如果是自研的話，也可以順帶開發(fā)個監(jiān)控系統(tǒng)，也未嘗不可，若是外采開發(fā)的話，通常還是用成熟的應用監(jiān)控系統(tǒng)，通過收集日志來監(jiān)控也可以?！締栴}6】進行一體化監(jiān)控項

17、目建設，CMDB系統(tǒng)如何建設及建設的范圍？監(jiān)控和CMDB系統(tǒng)屬于不同的領域，因此都有不同的建設思路，在監(jiān)控選型的時候，不建議選擇在監(jiān)控系統(tǒng)中內(nèi)置配置管理的工具，而是考慮CMDB和監(jiān)控分開建設，然后考慮兩個系統(tǒng)的集成。一體化監(jiān)控所需要的配置信息都納入到CMDB中進行對接，或者監(jiān)控自己的CMDB和外部CMDB系統(tǒng)進行數(shù)據(jù)同步。倘若每個運維監(jiān)控系統(tǒng)都自己弄一套CMDB，那信息完全紊亂，匹配。全行級CMDB還是必須的，不能單獨放到某一個運維系統(tǒng)中去做。需要考慮的集成的地方有以下幾個方面：1、監(jiān)控的標準化依賴CMDB，如每種類型對象他的監(jiān)控指標要標準化，監(jiān)控的自動化可以和CMDB集成，如監(jiān)控對象入網(wǎng)后，

18、可以自動化的實現(xiàn)監(jiān)控，監(jiān)控的覆蓋率和CMDB也有依賴。2、告警事件的豐富和收斂可以和CMDB緊密結(jié)合。3、CMDB可以提供應用視角的拓撲（Service Map），和告警事件進行關聯(lián)，實現(xiàn)應用視角的監(jiān)控和告警分析。4、CMDB建設容易，但如何持續(xù)更新完善數(shù)據(jù)是關鍵，有些數(shù)據(jù)可以通過系統(tǒng)采集，有些數(shù)據(jù)只能人為錄入。因此建立一套符合運維和監(jiān)控體系的CMDB錄入和采集標準和流程是非常有必要的。【問題7】如何看待監(jiān)控中的LessAgent和Agent監(jiān)控方式的問題？兩種方式各有利弊， 對于安裝Agent， 這種方式獲取的數(shù)據(jù)相對來說豐富，配置性也較好，其數(shù)據(jù)抓取能力是非常強的，僅僅消耗一部分的CPU和

19、內(nèi)存，即使主控服務器掛掉，仍然可以在恢復后，再次獲得數(shù)據(jù)。LessAgent的監(jiān)控方式，則較為依賴網(wǎng)絡，如果監(jiān)控端口出現(xiàn)故障，或者主控服務器出現(xiàn)故障，則監(jiān)控數(shù)據(jù)在一段時間內(nèi)將是空白，而且對于SSH，WMI等監(jiān)控方式，頻繁的訪問仍然會加重系統(tǒng)負擔，但是好在不會讓系統(tǒng)有除業(yè)務應用之外的進程，而且頻繁的增加Agent會導致系統(tǒng)的進程越來越多， 增加了系統(tǒng)端的壓力，并且增加了處理問題的復雜性。隨著技術的發(fā)展，現(xiàn)在的流行趨勢是將業(yè)務邏輯之外的所有基礎技術進一步下沉，很多之前分散的基礎技術都可以封裝在一起，或者說通過AGENT代理去實現(xiàn)，監(jiān)控也不例外。而通過SSH或者WMI等通訊協(xié)議去做這種基礎技術的統(tǒng)一

20、管控根本沒辦法做全做好。所以目前還是偏向于Agent的方式去做更復雜的事情，用Lessagent的方式去做更簡單的事情而又不會對增加系統(tǒng)額外開銷。【問題8】 目前很多銀行部署了私有云或容器，在面對云與傳統(tǒng)結(jié)構(gòu)融合的環(huán)境，應該如何部署監(jiān)控系統(tǒng)，更快速，更準確的發(fā)現(xiàn)問題。監(jiān)控是屬于右側(cè)運維管理體系中的一個非常重要的工具。方案一：使用私有云和容器自帶的監(jiān)控工具，進行日常的監(jiān)控，缺點是監(jiān)控分散，無法站在應用視角進行監(jiān)控；方案二：部署統(tǒng)一的監(jiān)控系統(tǒng)，通過統(tǒng)一的監(jiān)控系統(tǒng)監(jiān)控私有云，容器以及網(wǎng)絡，數(shù)據(jù)庫，應用等，從而實現(xiàn)更快速更準確的發(fā)現(xiàn)問題?！締栴}9】銀行監(jiān)控一體化后，海量監(jiān)控數(shù)據(jù)如何深度挖掘利用，價值最

21、大化？海量監(jiān)控數(shù)據(jù)的挖掘利用是需要結(jié)合實際運用場景才能實現(xiàn)價值最大化的，這里有一張我們運維大數(shù)據(jù)平臺的整體框架圖，最底層是海量運維數(shù)據(jù)接入層，包括各類指標型、日志型、配置型和流程型數(shù)據(jù)，第二層是數(shù)據(jù)采集組件層，通過代理及無代理兩種方式進行接入數(shù)據(jù)的采集，第三層是數(shù)據(jù)總線和分析層，最上層是運維大數(shù)據(jù)的各類運用場景，主要包含兩大塊運用場景，一個是數(shù)據(jù)的應用場景，包括儀表盤、報表、實時檢索分析、數(shù)據(jù)資產(chǎn)地圖、數(shù)據(jù)的導出和共享等等。另一個是智能應用場景，包括智能監(jiān)控、系統(tǒng)畫像、智能預警、知識庫等等場景。具體包括六大智能場景，見下表格，包括應用系統(tǒng)交易智能分析、 企業(yè)級系統(tǒng)智能感知、 企業(yè)級數(shù)據(jù)庫智能洞察、 企業(yè)安全及網(wǎng)絡智能防御、 企業(yè)級運維智能提升、 企業(yè)級存儲智能評估。這些場景，目前部分已經(jīng)實現(xiàn)落地，另一些還在積極摸索實現(xiàn)。產(chǎn)品組件場景價值AI算法模型用戶應用系統(tǒng)交易智能分析可視化交易鏈路上數(shù)字化表現(xiàn)，并直觀的深入分析運行狀態(tài)下應用系統(tǒng)平臺的動態(tài)交易量異常評估、預警和深層次故障定位故障樹AI模型 動態(tài)閥值模型 系統(tǒng)知識圖譜，單KPI異常檢測，多KPI聯(lián)合異常檢測 多KPI異常機器和軟件模塊定位 調(diào)用鏈分析應用支撐企業(yè)級系統(tǒng)智能感知結(jié)合Aix,Linux,Windows，HP等操作系統(tǒng)特點，