宜信智慧監控平臺建設實踐|分享實錄
摘要：介紹宜信智慧運維平臺UAVStack的設計思想、技術架構和核心功能，及落地實踐經驗。
內容來源：宜信技術學院第6期技術沙龍-線上直播|宜信智慧監控平臺建設實踐
主講人：宜信高階架構師 & 智慧監控平臺負責人謝知求
一、UAVStack平臺的產生背景
目前業界常用的監控軟體有很多，主流產品或以監控深度見長、或以監控廣度見長。
- 關注監控廣度的代表產品是Prometheus，其特點是生態圈活躍，針對常見的網際網路中介軟體（如MySQL、Redis、Kafka、RocketMQ、MongoDB、ElasticSearch等）均提供了現成的指標採集外掛來進行監控。類似產品還有Zabbix、Nagios和Open-Falcon。
- 關注監控深度的產品也有很多，如聽雲、OneAPM、PinPoint、SkyWalking。這類軟體一般是探針型的，在應用效能監控方面提供了更深入的監控能力。
這些產品各有優勢，也存在不足之處：
- 無法兼顧監控的廣度和深度；
- 無法同時支援實時指標、呼叫鏈和日誌三類類資料的採集，未考慮這三類功能的整合連通性，無法解決資料的時效、品控、對齊等問題。
為了克服上述不足，同時滿足公司多樣化和智慧化的監控需求、降低二研的成本和難度，我們自主研發了全維監控與智慧運維基礎平臺（UAVStack）。
作為智慧監控平臺，監控僅僅是智慧化運維的第一環。我們認為，智慧運維(AIOps)可以分三步走：全維監控、全維關聯和全維智慧。
- 第一步：全維監控，通過統一的採集體系，採集全維度的監控資料，包括系統、應用和服務的畫像資料、實時指標資料、呼叫鏈資料和日誌資料。
- 第二步：全維關聯，獲取全維度的監控資料後，需要進一步建立資料之間的關聯關係。這種關聯關係可以是通過畫像、服務流圖譜或呼叫鏈資料建立的強關聯關係，也可以是通過機器學習演算法建立的關聯關係。通過全維關聯，可以在監控資料之間建立實時關聯關係；有了關聯關係，我們就可以做根因分析了。
- 第三步：全維智慧，通過引入包括異常檢測、根因分析、智慧降噪及任務機器人等AI服務，用機器取代人進行一些決策，從而持續提升公司智慧化運維的水平。
二、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，獲得隨時隨地的運維體驗。
健康管理服務也是採用微服務架構構建的，包括多個微服務，支援叢集部署和擴容。
三、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 智慧運維：根因分析，告警收斂與智慧降噪
有了關聯關係，就可以做根因分析了。我們可以收集各個渠道的告警，先通過告警過濾將其中重複的告警和不重要的告警過濾掉，再根據關聯分析建立同一時間視窗內不同型別告警之間的關聯，可以按畫像建立關聯，也可以按呼叫鏈路建立關聯。然後是權重計算，根據預先設定的各類告警的權重，計算成為根源告警的可能性。最後將權重最大的告警標記為根源告警。此外，還可以根據歷史告警處理知識庫，找到類似根源告警的推薦解決方案。
在根因分析和定位的過程中，順帶實現了告警收斂和智慧降噪。比如我們對重複告警、非根源的一般告警、同一條鏈路的其它告警進行了壓制。
四、總結
上圖為線上實際的宜信核心業務線呼叫關係的圖譜。UAV作為宜信的公司級智慧監控標準軟體，已持續覆蓋到宜信所有關鍵業務系統，支援公司超過300個業務線。越來越多的同事可以熟練地使用UAV，將UAV應用於日常運維、事前預警、事中問題診斷和事後覆盤分析等各個方面。
使用UAV，可以獲得隨時隨地的運維體驗。目前UAVStack監控部分已在GitHub上開源，可以登入檢視更多詳細介紹。
- 官方網站：https://uavorg.github.io/main/
- 開源地址：https://github.com/uavorg