宜信智能監控平臺建設實踐

本文整理自宜信技術學院第6期技術沙龍,宜信智能監控平臺負責人謝知求介紹宜信智能運維平臺UAVStack的設計思想、技術架構和核心功能,及落地實踐經驗。

一、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上開源,可以登錄查看更多詳細介紹。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章