宜信智能監控平臺建設實踐|分享實錄

時間 2019-11-22

標籤智能監控平臺建設實踐分享實錄欄目快樂工作简体版

原文原文鏈接

摘要：介紹宜信智能運維平臺UAVStack的設計思想、技術架構和核心功能，及落地實踐經驗。前端

內容來源：宜信技術學院第6期技術沙龍-線上直播|宜信智能監控平臺建設實踐ios

主講人：宜信高級架構師 & 智能監控平臺負責人謝知求git

1、UAVStack平臺的產生背景

目前業界經常使用的監控軟件有不少，主流產品或以監控深度見長、或以監控廣度見長。github

關注監控廣度的表明產品是Prometheus，其特色是生態圈活躍，針對常見的互聯網中間件（如MySQL、Redis、Kafka、RocketMQ、MongoDB、ElasticSearch等）均提供了現成的指標採集插件來進行監控。相似產品還有Zabbix、Nagios和Open-Falcon。
關注監控深度的產品也有不少，如聽雲、OneAPM、PinPoint、SkyWalking。這類軟件通常是探針型的，在應用性能監控方面提供了更深刻的監控能力。

這些產品各有優點，也存在不足之處：web

沒法兼顧監控的廣度和深度；
沒法同時支持實時指標、調用鏈和日誌三類類數據的採集，未考慮這三類功能的集成連通性，沒法解決數據的時效、品控、對齊等問題。

爲了克服上述不足，同時知足公司多樣化和智能化的監控需求、下降二研的成本和難度，咱們自主研發了全維監控與智能運維基礎平臺（UAVStack）。算法

做爲智能監控平臺，監控僅僅是智能化運維的第一環。咱們認爲，智能運維(AIOps)能夠分三步走：全維監控、全維關聯和全維智能。數據庫

第一步：全維監控，經過統一的採集體系，採集全維度的監控數據，包括系統、應用和服務的畫像數據、實時指標數據、調用鏈數據和日誌數據。
第二步：全維關聯，獲取全維度的監控數據後，須要進一步創建數據之間的關聯關係。這種關聯關係能夠是經過畫像、服務流圖譜或調用鏈數據創建的強關聯關係，也能夠是經過機器學習算法創建的關聯關係。經過全維關聯，能夠在監控數據之間創建實時關聯關係；有了關聯關係，咱們就能夠作根因分析了。
第三步：全維智能，經過引入包括異常檢測、根因分析、智能降噪及任務機器人等AI服務，用機器取代人進行一些決策，從而持續提高公司智能化運維的水平。

2、UAVStack平臺的整體技術架構

2.1 全維度監控+應用運維解決方案

使用UAV的全維監控和應用性能管理工具集能夠搭建一站式全維度監控+應用運維解決方案。瀏覽器

首先，UAV在每一個物理機、虛擬機以及容器上部署一個監控代理程序（MonitorAgent，MA）。MA其實是部署在宿主機上的獨立JVM進程。緩存

其次，在每一個JEE中間件、JSE應用或其餘JVM語言應用中，可經過Java Agent的形式植入監控探針，監控探針會與應用在同一個JVM進程中一塊兒啓動。安全

監控探針啓動時，會自動對應用進行畫像和監控。應用畫像包括服務組件、客戶端組件和日誌組件的畫像。

服務組件是應用對外暴露服務能力的接口，如服務URL；
客戶端組件是應用訪問的其它服務或第三方數據源（如MySQL,、Oracle、 Redis、MQ等）客戶端；
日誌組件是應用輸出的日誌。

除對以上三類組件進行自動畫像和實時數據採集外，監控探針也會記錄每一個請求/響應生成端到端的調用鏈路，繪製各個應用/服務之間的調用關係，並生成服務圖譜。

監控代理程序（MA進程）會定時拉取監控探針採集的數據，同時也會採集應用環境的性能指標（如CPU、內存、磁盤IO等）。此外，MA還提供了插件機制，支持個性化指標的採集。

最終，咱們採集到了包括指標Metrics、調用鏈Tracing及日誌Logging的全維度監控數據。其中：

Metrics數據包括：業務自定義指標、應用環境性能指標、應用集羣/實例性能指標、服務組件/客戶端組件/URL性能指標。
Tracing數據包括調用鏈指標、客戶端體驗（UEM）數據。
Logging數據包括日誌、線程棧（Thread）數據。

2.2 監控探針架構

UAV採集側主要包括監控Agent和監控探針兩部分。

監控探針負責應用層面的監控。
監控Agent負責應用環境層面的監控，同時會定時拉取監控探針的數據並上送給UAV服務端。

上圖所示是監控探針的架構圖。隨着UAV功能的加強，探針已不只僅用於監控目的，如今已經更名爲中間件加強框架。

上圖左邊能夠看到，中間件加強框架位於應用服務器和應用之間，採用了中間件劫持技術，對應用服務器的代碼進行了類加載劫持和字節碼改寫，對上層應用代碼無侵入。

右邊是監控探針放大以後的架構圖，最底層是應用服務器適配層，對互聯網經常使用的開源中間件（如Tomcat、Jetty、SpringBoot）提供了適配支持，對其它服務器能夠相應地擴展一個Adapter適配器來進行支持。

在適配層之上，首先提供了一系列通用的擴展點SPI，再基於這些SPI，擴展出了與監控相關的畫像收集和指標採集功能；與問題診斷分析工具相關的調用鏈跟蹤、瀏覽器跟蹤、JVM線程分析、堆內存dump執行等功能；與服務治理相關的服務限流/降級以及服務安全管控等功能。此外，還提供了這些功能對Docker和K8s容器環境的適配。

最上層提供了應用對接API以及數據發佈API，支持經過HTTP和JMX兩種方式來獲取探針上的監控數據。

2.3 數據捕獲架構

接下來將介紹UAV數據捕獲和傳輸的架構。

從上圖能夠看到，監控代理程序Agent數據傳輸採用了雙通道+雙心跳的方式：

1）雙通道是指HTTP心跳和MQ傳輸這兩條通道：

Http心跳傳輸通道，用來傳輸應用環境相關的監控數據，主要包括：容器/節點畫像數據和實時監控數據；
MQ傳輸通道，用來傳輸應用相關的監控數據，主要包括：應用實時數據，畫像數據，日誌數據，以及調用鏈和JVM線程棧等APM數據。MQ數據傳輸通道上的數據格式採用了統一的Schema，方便後期對數據的轉換和處理。

2）雙心跳是指無論來自Http通道仍是MQ通道的數據，實際上既能夠當作監控數據，也能夠當作心跳數據。來自每一個通道的數據都會到UAV監控後臺服務「簽到」。兩種通訊方式意味着更高的可靠性。

Agent經過雙通道的方式，將數據傳輸到UAV監控後臺，咱們稱之爲健康管理服務。

健康管理服務會根據數據類型對監控數據進行解析處理，並分別持久化到合適的數據源，好比OpenTSDB存儲時序指標數據；ES存儲日誌、調用鏈、JVM線程分析等APM數據。

AppHub是UAV的統一門戶，提供了監控數據的集中展現及用戶權限的管理功能。用戶能夠在PC端和移動端登陸UAV，得到隨時隨地的運維體驗。

健康管理服務也是採用微服務架構構建的，包括多個微服務，支持集羣部署和擴容。

3、UAVStack平臺的核心功能及其原理（附案例）

3.1 UAVStack核心功能

上圖展現了目前UAVStack的核心功能，主要包括：應用監控、應用環境監控、服務流、調用鏈、JVM監控、數據庫監控、日誌監控、性能告警、瀏覽器跟蹤、配置中心、時空沙盤、上帝羅盤、服務治理、容器生態支持、業務監控、智能運維（AIOps）等。其中：

瀏覽器監控：用來監控前端Web頁面的性能數據；
時空沙盤：提供了對歷史監控數據的查詢；
上帝羅盤：提供了監控大屏的展現；
智能運維（AIOps）包括：異常檢測、根因分析、告警收斂和智能降噪、任務機器人四個方面的能力。

此外，還包括圖上未列出的一些運營支持的相關工具，如UAV統一升級中心；UAV監控日報、週報、月報；UAV使用狀況統計等。本次分享將重點介紹上圖中白色字樣的功能。

3.2 應用監控

首先介紹UAV應用監控的核心原理。

3.2.1 核心原理：對應用代碼無侵入技術

UAV應用監控的核心原理是：對應用代碼無侵入技術。

UAV對應用代碼無侵入，應用無需任何改造。
UAV不須要應用使用統一的開發框架。

UAV的代號是「無人機」的縮寫，寓意：無人機翱翔藍天，智能地、透明地完成任務。

其中用到的核心技術主要包括：

中間件劫持技術，含Java Agent探針和字節碼改寫；
應用/服務畫像與監控技術。

3.2.2 無侵入技術：應用/服務畫像

監控探針經過中間件劫持技術實現對應用/服務的自動畫像和監控。

中間件劫持就是將咱們本身的代碼植入到中間件的各類行爲中。
中間件劫持的核心是：掌控類加載樹，獲取優先加載權，植入咱們本身的代碼。

以應用/服務畫像爲例：

當Web容器中Standard Context這個類加載時，經過字節碼改寫植入了相關的畫像代碼。JEE應用啓動時會執行植入的代碼，生成應用畫像和服務畫像；
應用畫像主要包括：應用標示、應用名稱、應用的URI：http(s)://<本地IP>:<端口>/、應用的類庫信息（從加載應用的webapp class loader中獲取）；
服務畫像是按照JEE技術規範進行掃描的，經過掃描註解和部署描述符，提取了服務註冊相關的信息，從而生成了服務畫像。

3.2.3 無侵入技術：應用/服務監控

與應用/服務畫像相似，應用/服務監控也是在加載服務器相關類時，經過字節碼改寫植入相應的監控代碼。

以Tomcat爲例：

CoyoteAdapter負責整個Tomcat的服務請求；StandardWrapper負責全部Servlet的服務請求。
加載這兩個類時，UAV會經過字節碼改寫植入監控代碼。當有實際請求發生時，會調用植入的請求攔截代碼和響應回覆攔截代碼，進行性能指標的採集。
採集到的性能統計指標會緩存到全局計數器中，後續由監控Agent集中採走。

上圖所示是應用監控的一個實際展現界面。

能夠從應用集羣的展現界面，鑽取到應用實例的監控展現界面，再鑽取到自動畫像出來的服務組件/客戶端組件和日誌組件的展現界面，最後再鑽取到服務組件/客戶端組件的每一個URI的監控指標界面以及日誌展現界面。能夠從全局鑽取到細節，獲取想看的監控數據。

此外，咱們還提供了服務URL監控報表和客戶端URL監控報表。

以服務URL監控報表爲例：

能夠直觀地看到該應用中全部服務URL的訪問計數、平均響應時間、累計訪問計數、累計錯誤計數、成功率等指標在選定時間區間內的統計數據。
時間區間支持最近10分鐘、最近3小時、今天、昨天、最近7天以及自定義的任意時間區間。

如上圖，點擊查看某個URL的詳情，能夠查看該URL在不一樣時間區間的詳細報表。

3.3 應用/服務拓撲：服務流

接下來介紹服務流相關的功能。基於應用/服務畫像和監控數據，UAV提供了服務流的功能。服務流涵蓋了應用拓撲的內容，但提供了比應用拓撲更豐富的運行時狀態的展現。

從上圖能夠看到，當前服務位於中間位置，左邊是調用當前服務的服務，右邊是當前服務調用的其它第三方服務。

在服務流圖上，連線的粗細表示調用量；連線的顏色表明健康情況，以響應時間和錯誤數爲參考：綠色表明健康、黃色表明警告、紅色表明嚴重。好比當連線爲粗紅線時，表明着有大量請求發生了錯誤。

如圖，咱們能夠從全局的服務流鑽取到某個業務線的服務流，再鑽取到該業務線下某個應用集羣/實例的服務流，進行全局範圍的性能追蹤。

3.4 調用鏈

3.4.1 調用鏈：全鏈追蹤

調用鏈分爲輕調用鏈、重調用鏈和方法級調用鏈。

輕調用鏈也叫基本調用鏈。應用無需任何改造，能夠運行時啓動和中止。獲取的數據包括服務/請求URL、服務類+方法、調用類+方法、耗時、結果狀態+異常、應用特徵、技術棧特徵等，性能開銷能夠忽略；
重調用鏈是在輕調用鏈的基礎上增長了對請求/響應數據報文的獲取，性能開銷稍大，依據報文數據量通常會有5%的性能降低；
方法級調用鏈：若是不開啓方法級調用鏈，則僅在服務的入口和出口生成調用鏈節點。若是想要在應用內部也生成調用鏈節點，可使用方法級調用鏈。能夠經過AppHub界面配置須要跟蹤的類和方法。方法級調用鏈的性能開銷較小，具體消耗取決於報文數據量。

3.4.2 調用鏈：實現原理

上圖展現的是一個調用鏈具體的生成流程。調用鏈節點主要是在服務接口代碼處和客戶端調用代碼處生成。若是開啓了方法級調用鏈，也會在過程方法代碼處生成調用鏈節點。

此外，介紹一下關於調用鏈上下文的傳遞。

服務內上下文的傳遞：同線程的狀況下使用了基本ThreadLocal；跨線程（池）的狀況下使用了可傳遞ThreadLocal（TTL）。

服務間上下文的傳遞：經過客戶端劫持（client hook)對原協議（如HTTP，RPC，MQ）進行適配，並在協議頭注入調用鏈上下文的元數據。傳輸到下一個服務接口的時候，會由下一個服務解析協議頭裏的調用鏈上下文元數據，從新構建調用鏈上下文，而後再繼續往下傳遞。

3.4.3 調用鏈：關鍵技術

調用鏈的實現主要使用了4個關鍵技術。

服務內上下文的傳遞。主要基於原threadlocal實現了支持父子線程之間值傳遞的threadlocal。
服務間上下文的傳遞。經過客戶端劫持（client hook），對原協議進行適配，並在協議內注入調用鏈上下文元數據。
報文體內容提取。重調用鏈提取請求/響應數據報文體內容時，爲把對應用的影響降到最低，使用了servlet wrapper機制在用戶讀取報文體時進行數據轉存（利用string池的屬性最小佔用內存）。
調用鏈數據的收集和處理。經過agent對調用鏈數據進行抓取，HM端進行數據解析入庫並提供查詢接口，使用極簡數據格式最小化佔用帶寬。

3.4.4 調用鏈展現：可視化，可關聯日誌，快速定位問題

這是調用鏈的實際展現界面。在調用鏈列表上，

能夠一鍵獲取最近1分鐘、最近12小時前100及最近1小時最慢的調用鏈。
能夠根據應用服務的特徵，按照時間區間或業務關鍵詞自定義搜索相關的調用鏈。
在調用鏈的任何環節，均可以查看整個端到端的完整的調用鏈。
經過端到端完整的調用鏈的展現，能夠快速發現調用緩慢的瓶頸或出錯的節點。
可從調用鏈的任意節點跳轉到日誌界面，查看該調用鏈環節對應的日誌。
能夠從日誌界面跳轉到該日誌對應的調用鏈，查看該日誌位於完整調用鏈路的哪一環，從而幫助咱們快速排查和定位問題。

3.4.5 調用鏈展現：查看請求/響應報文

開啓了重調用鏈的狀況下，咱們能夠查看請求/響應報文的詳細數據。

上圖中能夠看到，開啓了重調用鏈的狀況下，咱們能夠獲取到請求頭信息、請求內容、響應頭信息、響應內容等詳細數據。

3.5 日誌監控/管理

3.5.1 日誌捕獲架構

上圖所示是UAV日誌功能的架構圖。UAV日誌功能採用了日誌管理系統流行的EKK架構，包括日誌的採集、上送Kafka、ES存儲/查詢、RAID歷史備份/下載以及基於異常/關鍵字和時間的統計和告警功能。

應用服務器上的Agent採集、讀取日誌，並把讀取到的數據發送到Kafka集羣上。

對於需熱查詢的日誌，由logging-store程序從Kafka讀取日誌並保存到ElasticSearch集羣中；
對於需冷備份的日誌，由logging-raid程序從Kafka讀取日誌，先存到本地磁盤，天天凌晨會將本地日誌按天壓縮，備份到RAID集羣中。

日誌的統計和告警功能：由logging-statistics程序從Kafka讀取異常、關鍵字、Nginx日誌，並以分鐘爲單位統計數量，保存到Redis中，供後續統計展現和告警。

具體日誌展現界面在介紹調用鏈關聯到日誌部分已出現過了，這裏就不贅述了。

3.6 性能告警

3.6.1 性能告警：多指標聯合表達式，流式/同比/環比，雙收斂，反饋動做

UAV獲取到全維度的服務端指標集、客戶端指標集、日誌指標集和自定義指標以後，能夠設置多指標聯合告警條件，這些條件包括流式/同比/環比的條件（「同比」好比今天10點和昨天10點的對比；「環比」好比最近5分鐘和上一個5分鐘的對比），能夠混合使用構成聯合表達式。

爲避免告警轟炸，UAV提供了2種告警收斂策略：時間冷卻收斂和梯度收斂。梯度收斂策略上，咱們配置了「1」「5」「10」，即第1次、第5次、第10次知足告警條件時纔會發送告警提醒，其餘時間則進行壓制處理，不發送告警提醒。

告警可經過短信、郵件、微信及移動App推送通知到人，也能夠經過HTTP方式通知其餘系統。

3.6.2 性能告警：預警策略模板、靈活的策略編輯、多種通知

建立預警策略時，可使用預警策略模板。上圖是系統裏的預警策略模板截圖。

選定策略類型以後，預警策略的規則和條件會根據咱們缺省推薦的套餐自動設置，用戶只要配置須要報警的目標範圍和通知方式，直接保存就能夠了。也能夠調整模板套餐裏的閾值和報警表達式。此外，告警也支持運行時動態啓用和禁用。

3.7 JVM監控分析

3.7.1 JVM監控分析工具：總體架構

JVM監控分析工具基於UAVStack已有總體架構，如上圖所示。總體分爲前端、後臺及探針MOF部分。

前端負責數據展現以及向後臺發送用戶的執行指令。
後臺負責將指令下發到具體節點及結果的歸集和處理。
監控探針MOF負責接收後臺下發的指令，執行指令返回結果。

其中在探針部分：

JVM實時監控數據，如堆內存大小、Minor GC和Full GC的狀況，都是經過JMX提供的接口來獲取。
JVM堆內存採樣分析數據和CPU採樣分析數據，則經過JDK提供的Java Attach API進行獲取。

3.7.2 JVM監控分析工具：監控功能展現

上圖是JVM監控分析工具的監控功能展現頁面。JVM監控分析工具的功能主要包括：

基本信息Tab顯示JVM基本信息，包括JVM版本、啓動時間、JVM參數、系統屬性等。
監控Tab提供JVM實時監控指標展現，包括CPU、線程、內存、GC統計等。用戶能夠切換時間/區間，好比最近10分鐘、最近3小時、今天、昨天、最近七天或自定義的時間/區間，查看不一樣時間/區間內的JVM監控數據。
線程分析和內存Dump Tab提供了JVM線程分析與JVM堆內存Dump在線工具。
CPU採樣和內存採樣Tab提供了JVM堆內存採樣分析和CPU採樣分析工具。

3.7.3 JVM監控分析工具：堆內存採樣和CPU採樣分析

堆內存採樣分析可實時採樣JVM的堆內存分配、每一個類實例對象的數量以及這些實例所佔用的內存大小，從而輔助定位內存泄露的根源。
CPU採樣分析可實時採樣JVM每一個方法的CPU執行時間，可輔助定位熱點方法。好比CPU達到100%時，能夠定位哪些方法佔用CPU比例較高。

3.8 數據庫監控

3.8.1 數據庫監控：核心功能

區別於傳統的數據庫端的監控，UAV的數據庫監控採用新的視角，從應用端切入分析，彌補了現有數據庫端監控的不足，增長了數據庫-應用的關聯分析能力。

數據庫監控目前已實現的功能包括：數據庫鏈接池監控、SQL分類統計、慢SQL統計、慢SQL耗時分佈統計、慢SQL追蹤以及與調用鏈/日誌關聯。

慢SQL的監控功能主要包括慢SQL統計+慢SQL追蹤。對慢SQL的監控，能夠自主設定閾值，界定多慢纔算是慢SQL。用戶能夠按具體應用和它操做的數據庫實例來設置，高於設置閾值的SQL操做才計入慢SQL。

在開啓調用鏈/日誌歸集的狀況下, 慢SQL操做可關聯至對應的調用鏈以及日誌，幫助咱們診斷和定位問題。

上圖是數據庫監控功能的慢SQL統計報表，展現了某段時間以內慢SQL的計數狀況。慢SQL分類統計根據SQL類型，包括I-插入、D-刪除、U-更新、Q-查詢、B-批量操做，對慢SQL進行分類統計。

圖中下方兩個報表中，一個是數據庫鏈接池監控，能夠查看鏈接池總鏈接數、活動鏈接數以及空閒鏈接數；另外一個是SQL分類統計，能夠根據SQL類型來分類統計。

3.8.2 數據庫監控案例：某催收系統

經過某外購催收系統的數據庫監控案例來講明數據庫監控的使用方法。

催收系統在查詢催收歷史時，統計記錄數的count(*)語句，由於執行計劃異常，執行效率低，佔用了大量資源，致使數據庫服務器CPU資源耗盡，進而系統不可用。從圖上能夠看到，故障期間的慢SQL數目明顯變大，慢SQL具體爲count(*)語句。

上圖能夠查看到慢SQL的詳細SQL語句，得知故障期間的鏈接池資源被耗盡，活動鏈接數達到峯值，而空閒鏈接數爲0；SQL分類統計圖表也顯示故障期間查詢錯誤SQL數量明顯變大。

經過慢SQL追蹤界面，能夠查看故障期間的慢SQL列表，發現執行時間長的三條SQL全是count(*)語句。

每一條慢SQL的執行結果及SQL語句均可以與調用鏈關聯。繼續點擊，查看慢SQL詳情及與調用鏈關聯，均顯示了count(*)語句執行時間長，且執行錯誤。經過慢SQL的執行與調用鏈、日誌的關聯，能夠輔助定位和分析故障問題。

3.9 容器生態支持

3.9.1 容器生態支持：基本原理

對容器生態上的支持是指UAV以上全部功能都能在容器雲平臺上無縫遷移和使用。在容器環境下，監控Agent和應用分別在不一樣的容器中，須要作一些適配工做，主要體如今應用畫像/監控數據的採集、進程畫像/監控數據的採集、日誌採集路徑的適配上。

首先，在應用畫像/監控數據的採集上，監控agent容器應容許經過容器的虛擬IP訪問應用的容器，經過http請求獲取應用畫像及實時監控數據。
其次，在進程畫像/監控數據的採集上，監控agent的容器PID namespace須要和宿主機保持一致，從而保證監控agent能夠掃描宿主機的/proc目錄獲取進程信息。
最後，在日誌採集路徑的適配上，監控agent應容許經過API獲取應用和agent自身使用的volume信息。有了雙方的volume信息，agent才能正確地在自身的容器內找到應用輸出的日誌路徑。

3.9.2 容器生態支持：應用環境監控 — Kubernetes

UAV以上全部功能都能在容器雲平臺上的無縫遷移和使用，因此從UI上看不出來和VM有何區別，僅在應用環境監控界面上有些不一樣。上圖截取了Kubernetes環境下的應用環境監控界面，能夠看到一個物理主機上有10個主機進程、17個容器、28個在容器裏的進程。

應用環境監控能夠顯示容器和進程的對應關係。可點擊分別查看容器性能指標和進程性能指標。

在容器或進程的屬性列表裏，新增了K8S相關的屬性展現。這是在容器雲環境下，咱們能夠從應用環境監控UI中看到和VM環境下的些許差別。而對於其它功能（如調用鏈、日誌監控、數據庫監控，等等）而言，界面在容器環境下和VM環境下是沒有任何區別的，用戶感受不到差別。

3.10 Agent插件支持

3.10.1 Agent插件支持：支持Open-Falcon插件與UAV自定義插件

爲了彌補監控廣度上的不足，UAV目前提供了指標採集插件，支持已有的Open-Falcon的指標採集插件（相似Prometheus的exporter），也支持UAV自定義插件，使UAV監控能力可靈活擴展到對幾乎全部經常使用的互聯網中間件的監控，如MySQL、Redis、Kafka、RocketMQ、MongoDB、ElasticSearch等。

上圖展現了UAV對Kafka、RocketMQ、Redis指標的監控曲線。

3.11 業務鏈路監控與告警

3.11.1 業務鏈路監控與告警：解決方案

宜信公司業務大多跨多個業務線和多個系統，爲在IT層面能夠快速定位問題系統，在業務層面上也能夠給出受影響或波及的具體業務單據和客戶範圍，解決業務/運營人員的痛點，UAV提供了一套通用的業務鏈路監控與告警接入平臺。

如圖所示，該平臺包括異構業務日誌歸集、數據上送、數據切分、過濾、聚合計算等功能，以後能夠將結果持久化，提供業務報表大屏展現，也能夠根據結果告警，生成業務工單。

實施過程當中，各業務組先在應用中埋點具備業務涵義的日誌，而後自助配置和維護對業務日誌的解析邏輯、具體的告警策略和告警消息模板內容，從而能夠快速搭建針對自身業務的鏈路監控系統。

這套業務監控系統的優點在於：

將IT層面的調用鏈與業務事件雙向關聯，給IT層面的調用鏈賦予了業務涵義的同時，將跨系統的調用跟蹤升級爲跨業務領域的跟蹤。
發生問題後，能夠發出具備業務涵義的告警消息，將業務問題直接反饋給業務/運營人員；也能根據調用鏈快速定位到問題節點，從而幫到技術運維人員；此外，技術人員與運營人員也可經過業務ID反查系統鏈路來追溯問題。

3.11.2 業務鏈路監控與告警：業務告警示例

這是一個業務告警的具體例子。

上方是發給業務同事的告警郵件，內容能夠細化到X年X月X日X:X:X，在X個系統的X個業務環節，發生了X問題，影響了X類型的客戶，客戶姓名是X，手機號是X。幫助業務運營人員快速定位問題單據和受影響的客戶。

下方是發給技術運維同事的郵件，在業務同事郵件的基礎上，額外提供了IT調用鏈路，方便技術運維同事快速定位和診斷問題。

3.12 智能運維

目前UAV在AIOps智能運維上的工程實踐主要包括異常檢測，根因分析，告警收斂和智能降噪，以及任務機器人HIT這4個方面。本次分享將重點介紹指標異常檢測和根因分析兩部分。

3.12.1 智能運維：異常檢測框架

上圖是UAV工程實踐中使用的較流行的時間序列異常檢測框架。主要包括離線模型優化、在線模型預測、A/B TEST部分。其中，離線模型優化和在線模型預測造成了指標異常檢測的智能監控閉環。具體流程如圖所示，其中要點包括：

對無標記數據的分析，採用無監督的方法進行異常識別。好比，在進行連續數據的異常檢測時，可選用孤立森林算法，經過多棵iTree樹造成森林來判斷是否異常。
對已標記的數據的分析，採用了監督學習的方法，學習異常和正常羣體的歷史表現。這樣，進行新數據檢測時，能夠經過模型直接決策，輸出異常狀況。
可是採用人工標註樣本，工做量比較大，通常難以知足監督學習方法對數據量級的要求，因此可採用半監督的方法擴充標註的樣本庫。

3.12.2 智能運維：全維度的數據可關聯

按照全維監控->全維關聯->全維智能的技術路線，UAV採集到了多維度的監控數據後，須要創建起這些數據以前的關聯。

這種關聯關係：

能夠是經過畫像創建的強關聯關係，好比宿主機與虛擬機、虛擬機與應用服務器、應用服務器和應用、應用和服務組件之間的關係；
也能夠是經過調用鏈路或服務流圖譜創建的強關聯關係；
也能夠是經過機器學習算法創建的關聯關係，好比同一時間窗口同時變化的指標，可能存在某種關聯。

須要說明的是，金融行業自己的業務特色決定了對第三方存在依賴性，所以告警的隨機性較大，客觀上致使學習樣本的質量不高。所以，UAV目前使用強關聯關係。

3.12.3 智能運維：根因分析，告警收斂與智能降噪

有了關聯關係，就能夠作根因分析了。咱們能夠收集各個渠道的告警，先經過告警過濾將其中重複的告警和不重要的告警過濾掉，再根據關聯分析創建同一時間窗口內不一樣類型告警之間的關聯，能夠按畫像創建關聯，也能夠按調用鏈路創建關聯。而後是權重計算，根據預先設置的各種告警的權重，計算成爲根源告警的可能性。最後將權重最大的告警標記爲根源告警。此外，還能夠根據歷史告警處理知識庫，找到相似根源告警的推薦解決方案。