融數數據CTO王東：6步建立一個基於微服務的APM平台！

最新 02-05

本篇活動家為大家分享融數數據北京研發中心 CTO 王東的在又拍雲 Open Talk 聯合 Spring Cloud 中國社區舉辦的「進擊的微服務實戰派北京站」上分享的主題《微服務下的APM全鏈路監控》。

分享分為五個部分，從性能管理一直到現在的 microservice 對 APM 的大影響，然後自然去構建適合微服務的 APM 平台。王東認為：因為監控不是目的，目的也不是告警，目的是發現問題，所以本次分享，王東主要講解了講如何打造監控告警和保障的閉環，以及我們現在的產品對未來的一些商業層面上的思考。

以下是分享詳情：

什麼是APM

APM (ApplicationPerformance Management) 即應用性能管理，屬於IT運維管理（（ITOM）)範疇。主要是針對企業關鍵業務的IT應用性能和用戶體驗的監測、優化，提高企業IT應用的可靠性和質量，保證用戶得到良好的服務，降低IT總擁有成本（(TCO))。

APM主要特徵有三個特徵

多級應用性能監控：覆蓋通訊協議1-7層，通過事務處理過程監控、模擬等手段實現端到端應用監測。

應用性能故障快速定位：對應用系統各個組件進行監測，迅速定位系統故障，並進行修復或提出修復建議。

應用性能全面優化：精確分析各組件佔用系統資源的情況，並根據應用系統性能要求給出專家建議

APM的發展歷程

APM的發展主要經歷了三個階段：

第一階段：以網路監控基礎設施為主，主要監控主機的CPU 使用率、I/O、內存資源、網速等，主要以各類網路管理系統（NMS）和各種系統監控工具為代表。

第二階段：以監控各種基礎組件為主，隨著互聯網的快速發展，為了降低應用開發難度，各種基礎組件（如資料庫、中間件等）開始大量湧現，所以這個時期應用性能管理主要是監控和管理各種基礎組件的性能。

第三階段：以監控應用本身的性能為主, IT 運維管理的複雜度開始出現爆炸性的增長，應用性能管理的重點也開始聚焦於應用本身的性能與管理上。

第四節階段屬於我們的思考：雲計算方興未艾，而DevOps以及微服務的興起對傳統APM產生了很大的衝擊，傳統廠商也在做一些革新，也做一些微服務方面的嘗試和雲計算方面的嘗試。隨著Machine Learning、AI的技術的興起，對定位故障、定位問題，也會起到一些幫助，基於大數據的分析的手段也會有一些幫助，在融數的產品裡面也希望有所體現，當然我們還是在初步的嘗試階段。

2016年Gartner對APM的定義分為三個維度

1、DEM-Digital experience monitoring：數字體驗監控，瀏覽器及移動設備用戶體驗監控及利用主動撥測的實現的業務可用性及性能監控。

2、ADTD-Application discovery, tracing and diagnostics：應用自動發現、追蹤和故障診斷，自動發現應用之間的邏輯關係，自動建模、應用組件的深入監控及性能關聯分析。

3、AA-Application analytics：應用分析，通過機器學習，進行針對JAVA及.NET應用的根源分析。

服務開發架構的發展歷程

微服務帶來的挑戰主要有六點：依賴關係無比複雜，持續交付，容器化環境，服務註冊、發現和可靠性，一切皆服務（Everything-as-a-Service) ，DevOps。

微服務對APM的影響主要分為三種

微服務的規模和動態性使得數據收集的成本大幅度提高，例如（CPUcpu、內存和網路傳輸的開銷；）

大量的監控數據對後台數據處理分析的產生影響，服務的體量非常大的情況下，出現了問題之後，如何快速定位到發生問題的根本原因上，這需要大量的模型建立和機器學習；

對於可視化和關聯分析的要求方面，傳統APM缺少好的手段。

建立一個基於微服務的APM平台和建立一個APM平台所面臨的問題差不多，區別就在於平台的架構和是基於容器還是基於VM。這裡要強調一點：監控和告警不以業務為目標就是耍流氓。

APM的核心能力

基於微服務的端到端的監控是比較複雜的，下圖中是包括整體機房裡全部內容，包括路由器、防護牆、交換機等，以及依賴的三方服務，和對外的服務的依賴和提供。

基於微服務的應用程序端到端監控

以下兩張圖分別是APM探針的基本原理及融數數據APM探針的基本原理。

APM探針的基本原理

融數數據 APM 探針的基本原理 (Java探針結構)

融數數據經常讓客戶看我們的成本，性能開銷大概在3%到5%，收益就可以看到很多，包括改進，防止SQL注入，安全攻擊，代碼漏洞的定位，包括平均響應Apdex。

分散式追蹤可以有效的將瀏覽器的監控、APM的監控、日誌、移動端的監控全部串通，有些功能是沒有完全實現的。最終目的就是追蹤一切，也就是說從業務服務一直到微服務，或者是傳統的中間件的JAVA代碼，以及到主機容器和中間鍵的層級，每一個層級都會有追蹤，然後通過流失數據處理做數據的收取和健康的檢查。

分散式追蹤 – Google Dapper

分散式追蹤 – OpenTracing

追蹤過程中可以做一些檢測，比如說異常檢測告警等等，通過數據的計算和分析，比如說通過拓撲，依賴的檢查、關聯分析、性能指標分析，以及實時計算，可以做數據的分析和計算。

追蹤一切

服務所依賴的環境信息，比如它在哪個域裡面，它依賴的是在容器上跑，在VM上跑，物理機上跑，還是說在物理機的其他數據，比如說業務的劃分，區域的劃分，都是通過環境信息在CD中獲取的。

下圖是融數數據APM的總體架構，我們把所有的JAVA技能叫中間件，agent是埋在中間件上，實的箭頭是數據攝取的數據流。

APM總體架構

下圖是融數數據的整個的APM的核心的能力，包括瀏覽器，融數現在瀏覽器也是有探針的，可以做到首屏、白屏時間，資源載入完成時間，到解析時間，用戶IP、請求重定向時間，以及使用者使用什麼設備來訪問網頁等等都有。應用伺服器有比較多了，包括服務動態發現，IO異常，性能指數等等。

APM核心能力

構建「開發+部署+監控+告警+報障」閉環，在運行環境下，拿到統一監控，一旦有問題會直接到輪值報障系統里，輪值報障會把它放到運維的資料庫里，進到專業運營的分析報表裡面去分析，然後來做一些改進。同時希望建成的一個理念，誰構建誰運維。

構建「開發+部署+監控+告警+報障」閉環

1. 告警平台

下圖是融數數據告警平台的架構圖，告警數據源有APM、業務數據、日誌和ITIM。

有些指標不需要自動的故障檢測，有些指標通過簡單數學的演算法就可以，有些是有季節和周期性變化的，還有些是一個趨勢，這時就需要自己來設置規則。

告警最糟糕的是漏告，一定要用演算法去解決漏告問題。這裡就涉及到告警歸併和分發的問題。

告警歸併：把多條類型相同的告警總結成一條告警

分發：每一類型的告警會有一個告警流水線，系統會根據告警的配置，發送到不同的流水線里，分散式的去處理這些告警。

2. 報障平台

報障平台很簡單，首先把業務監控、系統監控和業務人員的報障通過我們的工單系統收進來，然後建造問題分類服務的分類樹CTI，之後通過OnCall系統通知值班人員。通過故障分類系統、支持組，快速將接入的各監控系統報障通知給相應維護人員，並通過配置的SLA及組織架構，對未及時響應的報障進行上告處理，以達到卓越運維的目的。