企業(yè)數(shù)字化使得運維智能化轉型成為必然，宜信積極推動 AIOps 在科技金融企業(yè)的落地實踐。本文探索 AIOps 落地的一種形式：通過行為采集、仿真模擬、主動感知等手段，從用戶側真實系統(tǒng)使用體驗出發(fā)，結合全維監(jiān)控數(shù)據(jù)，更加有效的實現(xiàn)智能異常檢測和根因分析。

一、運維的發(fā)展

1.1 運維的價值

早期的運維工作比較簡單，一般是先由系統(tǒng)集成工程師及研發(fā)工程師研發(fā)完項目后交付出來，再由負責運維工作的人員從后臺做一些操作，保證系統(tǒng)正常運行。

隨著軟件研發(fā)行業(yè)和技術的發(fā)展，運維的工作也變得越來越豐富。現(xiàn)階段運維的工作與價值主要集中在三個方面：

1）效率

大量業(yè)務上線，運維人員需要保障快速高效地為系統(tǒng)提供資源、應對業(yè)務變更、響應操作請求。

2）質量

運維的目標是保障質量及系統(tǒng)的穩(wěn)定性。也就是說，要保障業(yè)務和系統(tǒng)7*24小時在線上穩(wěn)定運行，為用戶提供流暢舒適的體驗。為實現(xiàn)這個目標，運維的相關工作包括：

• 故障預測：沒出現(xiàn)問題之前預測到故障發(fā)生的可能。 

• 異常檢測：出現(xiàn)問題時很快檢測并定位到異常點。 

• 根因分析：分析問題的誘因，找出真正導致問題的根本原因。 

• 動態(tài)擴容：問題處理的過程中可能受到復雜因素的影響，需要對系統(tǒng)進行動態(tài)擴容。 

• 服務降級：不影響核心業(yè)務的邊緣業(yè)務可能需要做服務降級處理。

3）成本

隨著公司規(guī)模的不斷壯大，投入產(chǎn)出比也越來越被重視。運維的另外一個價值在于降低成本。主要體現(xiàn)為：

• 容量規(guī)劃：規(guī)劃每年在IT運維層面投入多少人員和資源。 

• 彈性調(diào)度：如何調(diào)度和分配資源，實現(xiàn)資源的充分利用。 

• 利用率分析：利用率分析包括動態(tài)和靜態(tài)兩個方面。 

• 趨勢分析：比如今年花了多少錢在IT運維層面，明年要花多少錢在這個方面，這是一個趨勢分析。 

• 成本分析：成本分析包括今年有多少業(yè)務、每個業(yè)務用了多少錢、多少IT技術設施、多少人員。

1.2 運維的困境

如圖所示，橫坐標代表服務規(guī)模。公司業(yè)務不斷增長，服務規(guī)模也相應增長，此處我們簡單理解為這是一個線性的變化，不考慮業(yè)務的暴增。

然而，業(yè)務規(guī)模增長反映到運維的復雜度增長上最少體現(xiàn)在三個層面：

• 服務規(guī)模的增長直接導致服務器量及網(wǎng)絡量的增長，隨之而來的是網(wǎng)絡拓撲的增長。 

• 業(yè)務增長，服務的技術棧也是增長的。以前可能前邊跑一個服務，后邊跑一個數(shù)據(jù)庫就可以了，現(xiàn)在隨著服務規(guī)模的不斷增長，引入不同服務形式，可能就有了隊列、緩存等，相應的，技術棧也不斷增加。 

• 服務拓撲不斷增長。以前可能一個煙囪型的服務就可以了，而現(xiàn)在隨著微服務的應用，服務之間的調(diào)度非常多，需要增長服務拓撲來滿足需求。

隨著服務規(guī)模的增長，運維復雜度呈現(xiàn)指數(shù)級增長，那運維人員是否也隨著增長了呢？縱觀各司，答案是否定的。出于節(jié)約成本的考慮，各司各崗位人員并不會隨著服務復雜度增加而擴張，反而是越來越趨于平穩(wěn)?；谶@個比例，相當于運維復雜度越來越高的情況下，運維人員越來越少了。

中間的差距如何來彌補呢？這就需要運用到運維手段了。即上圖所示的：運維質量=運維人員 X 運維手段。運維人員要通過各種運維手段來解決運維困境，進而推動運維的發(fā)展。

1.3 運維的發(fā)展

如圖所示，運維的發(fā)展大致分為四個階段：

1）手工階段

手工階段比較好理解，研發(fā)人員交付一個系統(tǒng)，運維人員通過手工執(zhí)行操作保障這個系統(tǒng)正常運行。此階段的運維工作沒有什么標準可言。

2）標準化階段

隨著企業(yè)IT系統(tǒng)越來越多地引入運維，且所有業(yè)務都變成系統(tǒng)形式在線上運行，運維工作的重要性越來越高，但同時帶來的是運維和研發(fā)、業(yè)務人員工作中的溝通壁壘。這時就衍生出了一些標準，其中最主要的是ITSM（IT Service Management，IT服務管理）。ITSM的目標是把日常所有的運維工作，包括流程、信息管理、風險控制等，通過系統(tǒng)建設和標準化固定下來，像流水線一樣，人員只需要按照標準參與即可。

3）自動化階段

隨著互聯(lián)網(wǎng)大爆發(fā)，服務交付模型越來越多，用戶對互聯(lián)網(wǎng)和IT的要求越來越高，ITSM的缺點也越來越明顯，主要表現(xiàn)為時間過長、成本過高，不能適應快速多變的需求。于是從工程或運維的角度自發(fā)出現(xiàn)了一種文化：DevOps，DevOps強調(diào)運維、研發(fā)及QA工程師工作的高度融合，要求運維從工程交付的角度不斷迭代。

同時從企業(yè)IT管理或運營訴求出發(fā)也要解決快速演進的問題，于是演化出了標準ITOM。ITOM和ITSM很像，區(qū)別是把“S”改成“O”，即把Operation本身及其帶來的各種自動化工具納入模型中，包括主機、運營、發(fā)布系統(tǒng)等等。

• DevOps不斷發(fā)展演變成現(xiàn)在的ChatOps，ChatOps的目標是將研發(fā)、運維、QA融合起來，以說話（Chat）的方式進行交流，但 ChatOps 只考慮了交流的形式，并沒有就如何實現(xiàn)基于 Chat 方式的整體解決方案，ChatOps 并沒有很好的解決 DevOps 的困境。 

• ITOM把所有的Operation線上化、自動化后，發(fā)現(xiàn)IT運維所產(chǎn)生的大量數(shù)據(jù)是非常有意義的，特別是對于企業(yè)數(shù)字化而言，這些數(shù)據(jù)經(jīng)過加工分析，可以對日常業(yè)務產(chǎn)生價值。于是Gartner提出了一個新的標準“ITOA”。ITOA強調(diào)IT數(shù)據(jù)的價值，提出對IT運維分析的訴求，但沒說明這個數(shù)據(jù)能干什么。很快Gartner就將ITOA演化成“AIOps”。這時AIOps中的“AI”是指“Algorithm（算法）”，強調(diào)的是數(shù)據(jù)分析本身產(chǎn)生的價值，包括通過算法來解決線上故障發(fā)現(xiàn)、日常交互等運維問題。

4）智能化階段

隨著行業(yè)對IT運維要求的不斷提高，無論是AIOps還是ChatOps，都面臨一個嚴重的問題：人處理不過來了。從工程角度來看，運維面臨的現(xiàn)狀是異構性非常強，需要引入三方應用和各種各樣的設備，交付模式也越來越多，運維復雜度出現(xiàn)指數(shù)級增長。

為解決上述問題，Gartner適時提出了“AIOps”的概念，這里的“AI”代表的是人工智能，通過機器人的參與將人工智能技術體系帶入到運維的各個環(huán)節(jié)，幫助解決運維問題，運維發(fā)展也由此進入智能化階段。

二、什么是智能運維

2.1 什么是智能運維（AIOps）？

BMC給了AIOps定義是：

AIOps refers to multi-layered technology platforms that automate and enhance IT operations by 1) using analytics and machine learning to analyze big data collected from various IT operations tools and devices, in order to 2) automatically spot and react to issues in real time.

簡單來說，就是引入多層平臺，使用大數(shù)據(jù)分析和機器學習等方法，加強IT運維自動化的能力。

上圖底部三張小圖分別表示2016、2017、2018年的AIOps架構演進，都是圍繞Machine Learning和Big Data來建設的。

2.2 技術、場景與算法

AIOps涉及的技術、場景和算法如圖所示。

1）技術層面

• 大數(shù)據(jù)分析：主要關注點在分析的部分，包括基于海量數(shù)據(jù)的分析。 

• 機器學習：數(shù)據(jù)量太大，人工的簡單分析遠遠不夠，需要它自己產(chǎn)生智能，這是機器學習的價值。 

• 知識圖譜：日常運維會產(chǎn)生各種經(jīng)驗數(shù)據(jù)，這些數(shù)據(jù)如何反過來對運維工作產(chǎn)生真正的價值，這就涉及到知識圖譜。 

• 自然語言處理：自然語言處理是ChatOps能引入到AIOps這個領域的原因，我們希望能夠找到一個相對簡單且容易接受的交互界面，最好的就是聊天平臺Chat，這就需要使用自然語言處理的方式，理解人的語言并反饋給人，并理解相關的執(zhí)行動作。

2）涉及場景

• 單指標異常檢測：比如想要知道一個實時數(shù)據(jù)的指標是否出現(xiàn)異常，我們可以對它進行檢測，如有異常就反饋出來。 

• 多維指標異常檢測：指標和指標之前是有關系的，通過比如聚類的一些操作能夠檢查出更多異常。 

• 趨勢預測：主要體現(xiàn)在成本部分，能夠通過人工智能的方式預測出未來的增長和變化，更好地指導決策。 

• 日志異常檢測：檢測日志是否出現(xiàn)異常。 

• 根因分析：出現(xiàn)故障時，能夠從時間維度和空間維度找到導致故障出現(xiàn)的原因。 

• 智能問答：以前每次變更操作都需要向運維提出要求，現(xiàn)在這些職能全部被承接下來變成一個智能平臺，日常運維的工作可以通過智能平臺或機器人直接完成。 

• 智能執(zhí)行：這是我們期待的最好的方式，通過聊天窗口能夠實時感知線上業(yè)務發(fā)生的變化，需求提交給平臺后平臺會自動執(zhí)行。

3）算法層面

• 規(guī)則 

• 統(tǒng)計 

• 機器學習 

1.  變分自編碼器、GBRT、EMA、極限理論 
2.  Pearson 相關系數(shù)、DBScan 算法 
3.  FP-Tree 
4.  Path Ranking

2.3 AIOps平臺架構

上圖所示是一個比較典型的AIOps平臺架構。

底層是所有數(shù)據(jù)的來源，我們把大量數(shù)據(jù)收集起來，通過實時分析交付到算法平臺。算法平臺包括三部分，首先是基于規(guī)則和模式進行簡單的分類，然后通過域算法，最后通過機器學習和AI的方式影響Operation，讓自動化運行起來。

如果大家了解AI，就會發(fā)現(xiàn)這其實就是一個AI智能體，包括從Sensing到Thinking到Acting，即感知到思考到執(zhí)行的過程。

三、宜信智能運維實踐

3.1 宜信IT運營架構

宜信正在落地“中臺化戰(zhàn)略”，將可復用的技術集中到技術中臺、數(shù)據(jù)/智能中臺、運維中臺，統(tǒng)一提供服務，節(jié)約了人力和資源，提高需求響應速度。

宜信的IT運營架構分為四部分：

• 居于中心的是技術中臺，真正承載業(yè)務。技術中臺沿用了云平臺的概念，從底層的物理環(huán)境開始，包括IaaS、PaaS、saas，這里的saas實際上是一種中臺的概念，將通用性的系統(tǒng)軟件沉淀到中臺上，統(tǒng)一為業(yè)務系統(tǒng)提供服務。 

• 數(shù)據(jù)/智能中臺，為其他業(yè)務和平臺提供統(tǒng)一的可復用的數(shù)據(jù)和智能服務。 

• 運維中臺，積極響應研發(fā)、業(yè)務發(fā)起的請求，維護線上業(yè)務系統(tǒng)。運維方面采用傳統(tǒng)運營的方式和互聯(lián)網(wǎng)快速迭代共同交互的方式，在監(jiān)控、信息、自動化等垂直領域建立所有套件。

運維如何使用數(shù)據(jù)/智能中臺的數(shù)據(jù)和應用呢？我們建立一個通用的管道，把運維產(chǎn)生的有價值的數(shù)據(jù)傳輸?shù)綌?shù)據(jù)/智能中臺，數(shù)據(jù)/智能中臺通過對這些數(shù)據(jù)進行分析，并基于運維需要的場景反饋智能應用。

3.2 運維管理

上圖所示是運維管理架構。

從左到右是從運營到運維，也可以說是從運營到DevOps，左邊更偏向于ITSM的概念，右邊更偏向于DevOps的概念。從上到下是從入口到執(zhí)行。大家可能更熟悉DevOps，以這部分為例介紹上圖所示架構。

我們的建設方式是從自服務入口，它被對接到持續(xù)集成和持續(xù)發(fā)布平臺，持續(xù)集成和持續(xù)發(fā)布平臺會利用所有的自動化建設，包括主機、域名、數(shù)據(jù)庫、負載均衡及其他組件，實現(xiàn)自動化，最終我們會把線上的系統(tǒng)數(shù)據(jù)收集起來，包括指標、跟蹤、日志等，這就是監(jiān)控的部分。

上述DevOps部分的運維管理架構對于交付2C產(chǎn)品是非常適合的，但對于像宜信這樣，有大量系統(tǒng)是面向內(nèi)部人員的，要求能夠快速響應用戶的問題，并且能快速沉淀更有價值的運維請求和數(shù)據(jù)，單一的運維管理架構不足以滿足上述要求。

因此我們也會建設ITSM部分，即偏運營、偏管理、偏審核的部分。ITSM部分以服務臺為入口，涉及的內(nèi)部管理包括請求管理、事件管理、問題管理、變更管理、需求管理和編排管理等，涉及的信息管理包括資產(chǎn)管理和CMDB。 

下面我們通過一個實例來看ITSM的價值點。

系統(tǒng)出現(xiàn)一個故障：業(yè)務人員在提交一個用戶的手機號時報錯，提示系統(tǒng)出現(xiàn)故障請聯(lián)系開發(fā)人員。如果是在DevOps領域處理這個問題就很簡單，把故障報給研發(fā)，研發(fā)就給解決了。但這樣處理，下次可能還會出現(xiàn)同樣的問題。

如果將故障放到ITSM部分進行分析，就能讓問題得到更根本的解決。發(fā)現(xiàn)故障后，通過請求管理把這件事告訴后臺人員，后臺人員看到請求后將故障升級為“事件”并提交給研發(fā)人員，研發(fā)人員分析得知引發(fā)故障的原因是手機號觸發(fā)了風險控制平臺，而風險控制平臺由于剛剛上線所以狀態(tài)碼的解釋并不充分，研發(fā)人員將平臺關閉，故障處理完成，同時將該“事件”升級成“問題”。研發(fā)和產(chǎn)品人員對該問題分析后認為需要變更相關服務，提供更細的狀態(tài)碼和更清晰的錯誤提示，于是將“問題”提交成“需求”。最終“需求”完成，“問題”解決，之后類似的情況也不會再發(fā)生。

3.3 采集和處理

前文提到運維中臺和數(shù)據(jù)/智能中臺之間有一個通用管道，運維中臺負責采集所有數(shù)據(jù)，進行簡單加工，并傳輸給數(shù)據(jù)/智能中臺，智能中臺分析處理數(shù)據(jù)并反饋數(shù)據(jù)及智能應用給運維中臺。

上圖所示為數(shù)據(jù)采集和處理的架構。

采集的數(shù)據(jù)形式包括動態(tài)和靜態(tài)兩種：動態(tài)數(shù)據(jù)包括業(yè)務、應用、鏈路、技術設施、全網(wǎng)、日志數(shù)據(jù)等；靜態(tài)數(shù)據(jù)包括配置、拓撲、工單數(shù)據(jù)等。

我們通過自有系統(tǒng)將所有數(shù)據(jù)收集起來，通過統(tǒng)一管道（統(tǒng)一管道包括kafka、宜信開源的DBus，DBus會對結構化的數(shù)據(jù)進行配置或預處理。）傳送到實時分析平臺，對數(shù)據(jù)進行后期加工，包括相關運算，最終數(shù)據(jù)會分類存儲到數(shù)據(jù)中臺的數(shù)據(jù)庫中，比如關系、指標、文檔/日志型數(shù)據(jù)會存儲在ElasticSearch中、結構化數(shù)據(jù)會存儲在Hive中，其他歷史數(shù)據(jù)會存儲在HDFS中。

3.4 智能場景

運維中的智能場景如上圖所示。

智能中臺根據(jù)運維中臺提供的工單、編排規(guī)則、CMDB、畫像、Tracing、KPIs、Logs等數(shù)據(jù)，通過算法為運維中臺建設一系列模型和應用。

重點介紹一下編排規(guī)則。我們用的編排工具是StackStrom，我們把自動化的每個動作都抽象成一個原子（atom），比如重啟服務、重啟機器、修改配置，這些atom通過StackStrom建立成一個個的工作流，這些工作流是我們有經(jīng)驗的運維專家建立的一個更高級抽象、更語義化的模型。比如我想發(fā)布一個系統(tǒng)，包括擴容機器、無縫切換、涉及前端負載均衡的調(diào)整、后端應用的調(diào)整，這些都會是編排規(guī)則。

智能平臺通過算法，包括NLP分析、根因分析、趨勢預測、異常檢測等，產(chǎn)生兩個模型：知識圖譜和搜索引擎。這兩個模型應用于運維中臺的問答后臺、編排管理和監(jiān)控系統(tǒng)中。

1）智能問答/執(zhí)行

如圖所示是智能問答/執(zhí)行的案例，用戶通過服務臺的會話窗口提出問題，這些問題以請求的方式發(fā)送到問答后臺，后臺利用搜索引擎和知識圖譜的數(shù)據(jù)自動化反饋信息，包括問答、動作執(zhí)行等。

2）故障檢測

目前的AIOps研究最多的是KPIs，將日志等各種數(shù)據(jù)，通過根因分析、趨勢預測、異常檢測等算法，生成對應的算法/模型，將這些算法/模型應用到監(jiān)控系統(tǒng)中，就是監(jiān)控報警部分。監(jiān)控報警結果會展示到展板上，通知用戶。

四、如何實現(xiàn)主動感知

4.1 痛點

我們的業(yè)務運行在IT環(huán)境中，這個IT環(huán)境就是承載業(yè)務的IT，包括數(shù)據(jù)中心、服務器、各種系統(tǒng)、三方應用、網(wǎng)絡用戶的設備等。而隨著云平臺的建設和微服務的發(fā)展，很多部分運維人員觀察不到，再加上出于投入產(chǎn)出比的考慮，一些部分我們不會去觀察，因此，實際上運維人員能夠觀察到的IT遠遠小于真正承載業(yè)務的IT。

在運維可觀察的IT環(huán)境中，真實觀察到的IT數(shù)據(jù)往往僅包括交換機的流量包、進程的運行狀態(tài)、網(wǎng)卡流量、CPU使用率、請求數(shù)等數(shù)據(jù)。如果要建設AIOps，數(shù)據(jù)的完整是非常重要的，觀察的IT環(huán)境越多，獲取的數(shù)據(jù)越完整，越有利于AIOps的建設，這時就需要用到主動感知。

4.2 主動感知定義

Wikipedia對主動感知的定義如下：

Active Perception is where an agents' behaviors are selected in order to increase the information content derived from the flow of sensor data obtained by those behaviors in the environment in question. ——Wikipedia

通俗來說，主動感知其實是賦予每個參與者一個身份，這個參與者會主動獲取環(huán)境中的數(shù)據(jù)，同時會根據(jù)從環(huán)境中獲取的數(shù)據(jù)主動進行進一步的發(fā)現(xiàn)并獲取新的數(shù)據(jù)，目的是增加獲得數(shù)據(jù)的信息量、信息價值。

上圖展示了一個比較典型的主動感知流程，重點來看感知部分。感知器從環(huán)境中通過情景感知、情景理解和預見的方式去感知環(huán)境，產(chǎn)生一個決策，決策產(chǎn)生一個動作，動作反饋到感知。

4.3 主動感知領域

• 主動感知在人工智能領域并不是一個陌生的名詞，它已經(jīng)有大量的應用，包括：

• 機器人，機器人怎么觀察環(huán)境、怎么查看邊緣信息、怎么識別物體。 

• 自動駕駛，如果將現(xiàn)實中獲取的所有圖像數(shù)據(jù)都交給一個中心去處理，這個信息量和計算量是非常大的，目前的芯片還不能滿足這樣的體量處理。我們的方式是在探知環(huán)境數(shù)據(jù)的時候感知變化，獲取變化數(shù)據(jù)。 

• 智能手機，主要體現(xiàn)在手機的GPS、攝像頭，可以感知環(huán)境變化。直接作用并影響到人。 

• 路網(wǎng)監(jiān)控，路網(wǎng)識別，包括主動感知車速變化，判斷行駛的車輛是否超速。

4.4 分布式主動感知

AIOps引入分布式主動感知：

通過對真實 IT 環(huán)境的參與者建立模型，有目的的獲取相關 IT 數(shù)據(jù)，并基于獲取到的數(shù)據(jù)持續(xù)優(yōu)化獲取的數(shù)據(jù)和方法，以實現(xiàn)對真實 IT 實時完整的監(jiān)控。

傳統(tǒng)的監(jiān)控方式是被動的，通過被動采集是不可能采集到所有數(shù)據(jù)的，無法保證數(shù)據(jù)的真實完整。如果能夠對所有的IT參與者進行建模，通過模型去感知真正參與者的身份什么樣的、有哪些數(shù)據(jù)，就可以采集到更加實時和完整的數(shù)據(jù)。

1）主動感知建模

主動感知的建模涉及到本地建模和全局建模。本地建模只需要關注IT參與者是什么，比如一個職場、一個主機；全局建模需要考慮全國有多少個職場、都分布在哪里、如何將它們聯(lián)動起來。

2）主動感知的動作

主動感知的動作包括兩個方面：有主動篩選的被動感知和有主動行為的主動感知。

• 有主動篩選的被動感知，比如網(wǎng)卡流量數(shù)據(jù)都是實時監(jiān)控的，但我并不會把所有數(shù)據(jù)都收集起來，只有在數(shù)據(jù)陡增或出現(xiàn)異常時才會收集，這就是主動篩選。 

• 有主動行為的主動感知，在真正獲取環(huán)境數(shù)據(jù)時，只是粗略獲得一些內(nèi)網(wǎng)中機器的端口，如果發(fā)現(xiàn)有端口是危險的，就會對這些端口進行細致的探測，包括發(fā)一些協(xié)議請求去模擬這些行為，這就是有主動行為的主動感知。

3）主動感知的方法

主動感知的方法有兩種：基于規(guī)則和基于智能算法（比如貝葉斯決策樹）?；谝?guī)則的方法是目前使用最多的。

4）主動感知的數(shù)據(jù)類型

主動感知的數(shù)據(jù)類型包括畫像數(shù)據(jù)、參與者與參與者之間的關聯(lián)關系、主動篩選和主動行為的細節(jié)捕捉、定位跟蹤等。

5）主動感知系統(tǒng)

主動感知系統(tǒng)包括全網(wǎng)Agent、業(yè)務Agent、網(wǎng)絡Agent、應用Agent，這些都是我們的感知器。

4.5 全網(wǎng)感知模型

用一個例子來細化什么是分布式主動感知。

全網(wǎng)感知的背景：宜信在全國各地有很多職場，這些職場都是重要的參與者，每個職場里有很多業(yè)務人員在使用業(yè)務系統(tǒng)，需要對這些職場進行監(jiān)控。

我們用分布式主動感知的方法，首先建立模型，即職場網(wǎng)絡。在職場放一個Agent，因為職場分布在全國各地，本身是全網(wǎng)的，因此稱之為全網(wǎng)Agent。感知的內(nèi)容包括出口有哪些；網(wǎng)絡、身份識別；這個網(wǎng)絡有多大；邊緣探測；還包括內(nèi)部一系列的統(tǒng)計數(shù)據(jù)，同時還會做內(nèi)部內(nèi)網(wǎng)的風險監(jiān)測，甚至會通過模擬數(shù)據(jù)、誘導攻擊來發(fā)現(xiàn)內(nèi)網(wǎng)是否存在安全隱患。

4.6 全網(wǎng)感知應用

• 全網(wǎng)Agent獲取當?shù)芈殘鲂畔?，包括出口、網(wǎng)段、地理位置和運營商信息，并反饋到拓撲和圖譜中，同時ITSM會管理所有的組織和職場信息，這些職場身份信息和主動感知的Agent反饋的信息結合，繪制出一個準確而詳細的拓撲/圖譜。 

• 全網(wǎng)Agent從網(wǎng)絡中獲取并反饋所有職場設備及其分布情況。 

• 全網(wǎng)Agent會嗅探風險端口、掃描攻擊，并反饋風險的細節(jié)掃描數(shù)據(jù)。 

• 全網(wǎng)Agent會將網(wǎng)絡統(tǒng)計數(shù)據(jù)反饋到系統(tǒng)中，幫助完善拓撲和監(jiān)控。 

• 我們可以通過網(wǎng)格數(shù)據(jù)加上職場身份給不同 Agent加上不同的監(jiān)測模擬配置，由Agent發(fā)起模擬監(jiān)測的數(shù)據(jù)。當發(fā)現(xiàn)異常時，可以從全網(wǎng)獲取更詳細的拓撲網(wǎng)絡監(jiān)測和密集系統(tǒng)檢測數(shù)據(jù)。

上圖展示的是我們?nèi)W(wǎng)感知的一些示例，包括職場信息、組織信息、模擬監(jiān)控數(shù)據(jù)、動態(tài)監(jiān)測配置，不展開細述。

4.7 網(wǎng)絡感知模型

上圖展示的是網(wǎng)絡感知模型，我們首先進行建模，建模的點，也就是網(wǎng)絡的參與者，即每個交換機，并實時監(jiān)測和掃描網(wǎng)絡內(nèi)部所有服務器。通過這個模型可以直觀且實時看到異常細節(jié)數(shù)據(jù)，保證網(wǎng)絡質量。

上圖展示了網(wǎng)絡感知的示例。

4.8 主機/應用/業(yè)務感知

除了上述應用以外，還有主機/應用/業(yè)務感知等等。

• 主機感知。出現(xiàn)異常時，異常時感知反饋進程、IO、網(wǎng)絡 Dump 細節(jié)信息。 

• 應用感知，根據(jù)運行狀態(tài)動態(tài)調(diào)整采集密度和方法。 

• 應用感知，包括主動業(yè)務異常捕捉和上報。

4.9 收益

分布式主動感知的收益包括：

• 更豐富的畫像和拓撲 

• 更有價值的監(jiān)控數(shù)據(jù) 

• 知識圖譜 

• 根因分析 

• 異常檢測

4.10 問題與前景

分布式主動感知在智能運維中的實踐
網(wǎng)站URL：http://jinyejixie.com/news34/98984.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供響應式網(wǎng)站、網(wǎng)站設計、移動網(wǎng)站建設、全網(wǎng)營銷推廣、電子商務、云服務器

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)