【最佳實踐】阿裡雲Elasticsearch應用性能監控分析（APM）

通過阿裡雲托管的Elasticsearch 應用性能監控（APM）服務，您可以結合阿裡雲Elasticsearch實作系統可觀測性能力搭建。本文介紹了阿裡雲Elasticseasrch APM服務概念架構及功能，以及如何快速接入并使用。

申請APM首月100元試用：

https://survey.aliyun.com/apps/zhiliao/j_9SKp6x_ 了解阿裡雲Elasticsearch 應用性能監控（APM）詳情： https://help.aliyun.com/document_detail/326325.html

一 背景資訊

可觀測性的本質是度量您的基礎設施、平台和應用程式，以了解它是如何運作的。與傳統監控運維相比，目前主流的監控更加注重發現與預警問題，而可觀測性的終極目标是為一個複雜分布式系統所發生的一切給出合了解釋。監控更注重軟體的傳遞過程中以及傳遞後的服務狀态，而可觀測性則要為全研發與運維的生命周期負責。

日志、基礎架構名額以及APM應用程式性能監測構成了可觀測性的三要素。其中，APM彌補了名額和日志之間的差距。雖然日志和名額往往更具交叉性，涉及基礎架構群組件，但APM更側重于應用程式，允許IT和開發人員監測其堆棧的應用層，包括最終的使用者體驗。

将APM添加到系統監測中，您可以：

• 了解服務的時間花在什麼上，以及它崩潰的原因。
• 了解服務如何互相互動，以及它的可視化瓶頸。
• 主動發現并修複性能瓶頸和錯誤。
• 提高開發團隊的生産力。
• 在浏覽器中跟蹤終端使用者體驗。

APM通常被應用于以下場景：

• 使用者體驗監控：通過監控使用者的行為提升使用者體驗。例如監控使用者和Web界面或用戶端的互動，并記錄互動事件的時間。
• 運作時應用程式架構：了解服務間的依賴關系、架構中應用程式互動的網絡拓撲。
• 業務事務（Business transaction）：産生有意義的SLA報告，并從業務角度提供有關應用程式性能的趨勢資訊。
• 元件監控（Deep dive component monitoring）：通常需要安裝Agent并且主要針對中間層，包括Web伺服器、應用和消息伺服器等。健壯的監控應該能顯示代碼執行的清晰路徑，因為這一次元和上述第二個次元緊密相關，APM産品通常會将這兩個次元合并作為一個功能。
• 分析或報告（Analytics/Reporting）：将從應用程式中收集的一系列名額資料，标準化地展現成應用性能資料的通用視圖。

阿裡雲托管的

Elastic APM

和目前比較流行的開源APM系統

Apache SkyWalking

的能力對比情況請參見

能力對比

。

二 架構及資料模型

阿裡雲Elasticsearch應用性能監控分析服務，支援基于開源Elastic APM建構雲上一鍵托管的APM Server服務，并靈活對接阿裡雲Elasticsearch服務，能夠為您提供高效的應用程式性能優化與監控能力。整體功能子產品架構如下。

Elastic APM由四個子產品組成，詳細資訊請參見

應用性能監控分析服務介紹

。其中APM Agent采集器從其監測的應用程式中收集不同類型的資訊和資料，這些被稱為事件。采集器收集資料後将這些事件流式傳輸到APM Server，由Server驗證并處理事件。事件支援的類型包括Spans、Transaction、Errors和Metrics：

• Spans：範圍事件類型。包含有關已執行的特定代碼路徑的資訊。它們從活動的開始到結束進行度量，可以與其他Span具有父或子關系。
• Transaction：事務事件類型。是一種特殊的Span（沒有父Span，隻能從中派生出子Span，可以了解為“樹”這種資料結構的根節點），具有與之關聯的額外中繼資料。你可以将Transactions視為您在服務中衡量的最進階别的工作，例如服務中的請求、提供的HTTP請求或運作的特定的背景作業等。
• Errors：錯誤事件類型。包含相關的原始異常資訊，或發生異常時建立的日志資訊。
• Metrics：名額事件類型。APM Agent自動擷取基本的主機級别名額，包含系統和程序級别的CPU和記憶體名額。除此之外還可擷取特定于代理的名額，例如Java Agent中的JVM名額和Go代理中的Go運作時名額。

三 前提條件

建立阿裡雲Elasticsearch 7.10版本執行個體，建議選擇日志增強版，以滿足應用性能監控場景下低成本海量資料寫入及存儲的需求。

四 使用限制

阿裡雲APM Server僅支援與阿裡雲Elasticsearch 7.10版本內建。

五 操作流程

步驟一：建立APM Server執行個體

1. 登入 阿裡雲Elasticsearch控制台
2. 進入APM應用性能監控控制台。

1. 1. 在頂部菜單欄處，選擇地域。
   2. 在左側導航欄，單擊APM應用性能監控。

1. 在APM Server管理頁面，參見 建立APM Server執行個體 ，建立APM Server執行個體。其中專有網絡需要與待監控的用戶端服務（APM Agent）所在的專有網絡保持一緻。執行個體建立成功後，您可以單擊對應執行個體右側的執行個體管理，檢視執行個體的通路位址等基本資訊。

步驟二：配置APM Agent

1. 在APM Server管理頁面，單擊APM資料采集。
2. 在Agent資料采集對話框中，單擊與您用戶端相同語言的頁簽，根據提示配置資料采集。

配置完成後，代理程式會結合應用程式收集性能名額和錯誤，最終将收集到的所有資料發送至Server端。以Java為例，配置方法如下：

1. 1. 參見 High Level REST Client（7.x） ，配置應用程式通路阿裡雲Elasticsearch，在pom依賴中添加APM Agent依賴。

<dependency>
  <groupId>co.elastic.apm</groupId>
  <artifactId>elastic-apm-agent</artifactId>
  <version>1.27.0</version>
</dependency>      

b. 在

Maven Central

中下載下傳應用相容的代理檔案。

c. 設定啟動參數，并使用javaagent參數啟動應用。

java -javaagent:/root/elastic-apm-agent-1.27.0.jar \
     -Delastic.apm.service_name=my-application \
     -Delastic.apm.server_urls=http://apm-cn-tl32fxqq****.apm.elasticsearch.aliyuncs.com::8200 \
     -Delastic.apm.secret_token= \
     -Delastic.apm.application_packages=org.example \
     -jar elastic.jar      

• • • apm-agent-java-0.1.2.jar：需要替換為您上一步下載下傳的代理檔案的名稱，包含檔案類型字尾（.jar）。
    • Delastic.apm.server_urls：将該參數值替換為您APM Server執行個體的通路位址。執行個體建立成功後，單擊對應執行個體右側的執行個體管理，即可擷取執行個體的通路位址。

步驟三：在Kibana中進行應用性能分析

1. 時，所關聯的Elasticsearch執行個體的Kibana控制台。登入Kibana控制台的具體操作，請參見 登入Kibana控制台
2. 根據頁面提示進入Kibana首頁，單擊右上角的Dev tools。

1. 在Console頁簽，運作以下腳本，開啟自動建立APM onboarding索引。

PUT _cluster/settings
{
  "persistent": {
    "action.auto_create_index":"+.*,+apm-7.10.2-onboarding-*,-*"
  }
}      

1. 檢視APM中包含的所有服務。

1. 1. 在頁面左上角單擊

      

      圖示，展開左側導航欄。
   2. 在左側導航欄，單擊Observability下的APM。
   3. 在Services頁簽下檢視APM的所有服務。

1. 單擊對應服務，檢視服務的具體資訊。以petclinic-spring服務為例，服務資訊如下圖（每項服務都具有類似的布局）。

• • 左上角顯示了響應時間的平均值、p95和p99值，以顯示發生異常的具體時間。同時您可以在圖表上隐藏不關注的數值曲線，以便更好地了解異常值對整個服務影響。将滑鼠移到任何一個圖表上時，可以得到一個彈出視窗顯示當時的具體摘要。從圖中可以看出，響應時長的突增沒有導緻任何伺服器發生500響應錯誤。
  • 通過檢視下方請求明細，您可以看到應用程式中每個請求都來自不同的節點，您可以通過使用 各種代理API 來擴充預設節點。支援按列标題、響應時長和影響列排序，影響列考慮了對應請求的延遲和熱度資料。以影響最高的getOwners請求為例 ，它的平均延遲并不高，為96毫秒。單擊該請求名稱，可以看到對應請求的詳細資訊，圖中反應最慢的請求也不到一秒鐘。

• • 向下滾動，可以看到該請求處理的操作瀑布視圖。其中有很多SELECT語句正在進行，使用APM能夠看到正在執行的實際查詢。

圖 1. 請求處理的操作瀑布視圖

圖 2. 正在執行的實際查詢

• • 由于該應用程式中的多層微服務均安裝了APM Agent，您可以單擊View full trace，檢視該請求的詳細資訊并顯示全鍊路中參與處理的所有元件，進而可以實作一個從浏覽器層開始的請求的分布式追蹤。

圖 3. 請求的詳細資訊

圖 4. 全鍊路中的所有元件

• • 真實使用者監測：為了從分布式跟蹤中獲得最大價值，您需要盡可能多地監測元件和服務，包括使用 真實使用者監測RUM（Real User Monitoring） 。快速的服務響應時間并不意味着請求在浏覽器中很快就能完成， APM能夠幫助業務衡量最終使用者在浏覽器中的終端體驗。下圖的分布式跟蹤顯示了四種不同的服務，包含了網絡浏覽器等多項。

掃碼加入技術交流群

參與技術讨論學習