微服務時代,你還不懂APM?

愛生活,愛編碼,微信搜一搜【架構技術專欄】關注這個喜歡分享的地方。
本文 架構技術專欄 已收錄,有各類視頻、資料以及技術文章。

1. APM?

APM (Application Performance Management) 即應用性能管理(應用性能監控)git

APM主要是針對企業 關鍵業務的IT應用性能和用戶體驗的監測、優化,提升企業IT應用的可靠性和質量。
旨在確保最終用戶得到高質量的體驗,下降IT總擁有成本(TCO)數據庫

TCO (Total Cost of Ownership ),即總擁有成本,包括產品採購到後期使用、維護的成本。 這是一種公司常常採用的技術評價標準。後端

2 .簡介

目前市面的系統基本都是參考 Google 的 Dapper(大規模分佈式系統的跟蹤系統)來作的。
跟蹤業務請求的處理過程,完成對應用系統在先後端處理、服務端調用的性能消耗跟蹤,提供可視化的界面來展現對跟蹤數據的分析。
經過匯聚業務系統各處理環節的實時數據,分析業務系統各事務處理的交易路徑和處理時間,實現對應用的全鏈路性能監測。瀏覽器

APM工具與傳統的性能監控工具的區別在於,不只僅提供一些零散的資源監控點和指標,其主要關注在系統內部執行、系統間調用的性能瓶頸分析,這樣更有利於定位到問題的具體緣由。
APM致力於檢測和診斷應用性能問題,從而能提供應用預期的服務水平。微信

2.1 三大特徵

  • 多級應用性能監控:覆蓋通信協議1-7層,經過事務處理過程監控、模擬等手段實現端到端應用監測。
  • 應用性能故障快速定位:對應用系統各個組件進行監測,迅速定位系統故障,並進行修復或提出修復建議。
  • 應用性能全面優化:精確分析各組件佔用系統資源的狀況,並根據應用系統性能要求給出專家建議。

2.2 發展歷程

目前APM的發展主要經歷了前面的三個階段:
第一階段:以網絡監控基礎設施爲主,主要監控主機 的CPU 使用率、I/O、內存資源、網速等,主要以各種網絡管理系統(NMS)和各類系統監控工具爲表明。網絡

第二階段:以監控各類基礎組件爲主,隨着互聯網的快速發展,爲了下降應用開發難度,各類基礎組件(如數據庫、中間件等)開始大量涌現,因此這個時期應用性能管理主要是監控和管理各類基礎組件的性能。架構

第三階段:以監控應用自己的性能爲主, IT 運維管理的複雜度開始出現爆炸性的增加,應用性能管理的重點也開始聚焦於應用自己的性能與管理上。app

第四節階段屬於正在發展的階段:
雲計算方興未艾,而DevOps以及微服務的興起對傳統APM產生了很大的衝擊,傳統廠商也在作一些革新,也作一些微服務方面的嘗試和雲計算方面的嘗試。
隨着Machine Learning、AI的技術的興起,對定位故障、定位問題,也會起到一些幫助,基於大數據的分析的手段也會有一些幫助,目前市場上正在初步嘗試階段。運維

2016年Gartner對APM的定義分爲三個維度機器學習

  • DEM-Digital experience monitoring:數字體驗監控,瀏覽器及移動設備用戶體驗監控及利用主動撥測的實現的業務可用性及性能監控。
  • ADTD-Application discovery, tracing and diagnostics:應用自動發現、追蹤和故障診斷,自動發現應用之間的邏輯關係,自動建模、應用組件的深刻監控及性能關聯分析。
  • AA-Application analytics:應用分析,經過機器學習,進行鍼對JAVA及.NET等應用的根源分析。

2.3 DevOps

DevOps(Development和Operations的組合詞)是一種重視「軟件開發人員(Dev)」和「IT運維技術人員(Ops)」之間溝通合做的文化、運動或慣例。
DevOps能夠簡潔的理解爲「開發團隊與運營團隊之間更具協做性、更高效的關係」。
是兩個相關趨勢碰撞中出現的新術語
更多信息見:https://zh.wikipedia.org/wiki...

2.4 APM 的核心思想

在應用服務各節點相互調用的時候,從中記錄並傳遞一個應用級別的標記,這個標記能夠用來關聯各個服務節點之間的關係。
好比兩個應用服務節點之間使用 HTTP 做爲傳輸協議的話,那麼這些標記就會被加入到 HTTP 頭中。
可見如何傳遞這些標記是與應用服務節點之間使用的通信協議有關的,經常使用的協議就相對容易加入這些內容,一些按需定製的可能就相對困難些,這一點也直接決定了實現分佈式追蹤系統的難度。

2.5 爲何要使用APM

隨着公司業務的與日俱增,各個系統也愈來愈複雜,服務間的調用,服務的依賴,以及分析服務的性能問題也越棘手,所以引入服務追蹤系統尤其重要。
現有的APM,基本都是參考Google的Dapper的體系來作的。經過跟蹤請求的處理過程,來對應用系統在先後端處理、服務端調用的性能消耗進行跟蹤(每一個請求的完整調用鏈路,收集調用鏈路上每一個服務的性能數據),方便工程師可以快速定位問題。

2.6 好的APM應知足的條件

總的來講,一個優秀的APM系統應該知足如下五個條件

  • 低消耗,高效率:被跟蹤的系統爲跟蹤所付出的系統資源代價要儘可能小,如今主流的APM對於系統資源的消耗在2.5%-5%左右,可是這個數值應該越小越好,由於在大規模的分佈式系統下,一個單節點的資源是沒法把控的,多是超強配置,也多是老爺機,只跑幾個小服務,可是自己性能已經十分吃緊了,若是這時候跟蹤應用再一跑,極可能這個節點就掛掉了,得不償失。
  • 低侵入性,足夠透明:做爲跟蹤系統,侵入性是不可能不存在的,關鍵這種侵入性要在哪一個層面,如何在越底層的層面上侵入,對於開發者的感知和須要配合跟蹤系統的工做就越少,若是在代碼層面就須要進行侵入,那對於自己業務就比較複雜的應用來講,代碼就更加冗餘複雜了,也不利於開發者快節奏的開發。
  • 靈活的延展性:不能隨着微服務和集羣規模的擴大而使分佈式跟蹤系統癱瘓,要可以充分考慮到將來分佈式服務的規模,跟蹤系統至少要在將來幾年內徹底吃得消。
  • 跟蹤數據可視化和迅速反饋:要有可視化的監控界面,從跟蹤數據收集、處理到結果的展示儘可能作到快速,就能夠對系統的異常情況做出快速的反應
  • 持續的監控: 要求分佈式跟蹤系統必須是7x24小時工做的,不然將難以定位到系統偶爾抖動的行爲
愛生活,愛編碼,微信搜一搜【架構技術專欄】關注這個喜歡分享的地方。
本文 架構技術專欄 已收錄,有各類視頻、資料以及技術文章。
相關文章
相關標籤/搜索