微服务下的APM全链路监控
https://opentalk.upyun.com/333.html
2017 年 10 月 29 日，又拍云 Open Talk 聯合 Spring Cloud 中國社區成功舉辦了“進擊的微服務實戰派北京站”。融數數據北京研發中心 CTO 王東作了題為《微服務下的APM全鏈路監控》。分享分為五個部分，從性能管理一直到現在的 microservice 對 APM 的大影響，然后自然去構建適合微服務的 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應用的根源分析。
二、微服務對APM的大影響
服務開發架構的發展歷程
微服務帶來的挑戰主要有六點：依賴關系無比復雜，持續交付，容器化環境，服務注冊、發現和可靠性，一切皆服務（Everything-as-a-Service) ，DevOps。
微服務對APM的影響主要分為三種
- 微服務的規模和動態性使得數據收集的成本大幅度提高，例如（CPUcpu、內存和網絡傳輸的開銷；）
- 大量的監控數據對后臺數據處理分析的產生影響，服務的體量非常大的情況下，出現了問題之后，如何快速定位到發生問題的根本原因上，這需要大量的模型建立和機器學習；
- 對于可視化和關聯分析的要求方面，傳統APM缺少好的手段。
三、如何構建適于微服務的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及組織架構，對未及時響應的報障進行上告處理，以達到卓越運維的目的。
五、未來的思考和展望
大數據能力的充分釋放-自動異常點檢測
- 不同服務有不同的特點，避免修改每個服務的閾值。
- 在服務負載發生變化時，避免手工調整每個服務的閾值。
- 避免靜態閾值造成的誤報
- 在不生成報警的的情況下預測 不正常的指標，用于診斷問題
轉載于:https://www.cnblogs.com/davidwang456/articles/9269835.html
總結
以上是生活随笔為你收集整理的微服务下的APM全链路监控的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 使用Skywalking实现全链路监控
- 下一篇： 服务容错模式