喬叔的 Elastic Stack 專業教育訓練
  • 喬叔的 Elastic Stack 專業教育訓練
  • 🧑關於喬叔 (Joe Wu)
  • Elastic 課程公開班
    • 🎯Elasticsearch 基礎實務班
      • 💯學員課後回饋
    • 🆕Elasticsearch 進階運維班
      • 💯學員課後回饋
    • Elasticsearch 進階開發班
    • Elastic Stack 基礎實務班
    • Elastic Observability 基礎實務班
    • 📩課程許願池
  • 技術分享
    • 📗喬叔帶你上手 Elastic Stack
      • 前言
      • Elastic Cloud 如何建立 Deployment
        • ES Node 的種類
        • 配置的選擇
      • Index 建立前你該知道的
        • ES Index 如何被建立
        • ES 的超前佈署 - Dynamic Mapping
        • ES 的超前佈署 - Index Template
        • ES Index 的別名 (Alias)
        • 管理你的 Index - Kibana Index
      • 管理 Index 的 Best Practices
        • Shard 的數量與 Rollover & Shrink API
        • 三溫暖架構 - Hot Warm Cold Architecture
        • Index Lifecycle Management (ILM)
        • Rollup
        • Transform
        • Snapshot Lifecycle Management (SLM)
        • 總結
      • Elastic Cloud 比免費版還多的功能
        • Elastic Stack 的方案比較與銷售方式
        • Centralized Beats Management
        • Centralized Pipeline Management
        • Watcher
        • Elasticsearch Token Service
        • Multi-stack monitoring & Automatic stack issue alerts
      • 向 App Search 學習怎麼用 Elasticsearch
        • 揭開 App Search 的面紗
        • Engine 的 Index Settings 篇
        • Engine 的 Mapping 篇
        • Engine 的 Search 基礎剖析篇
        • Engine 的 Search 進階剖析篇
      • Elasticsearch 的優化技巧
        • Indexing 索引效能優化
        • Searching 搜尋效能優化
        • Index 的儲存空間最佳化
        • Shard 的最佳化管理
      • 完賽心得
    • 📘喬叔帶你上手 Elastic Stack - 探索與實踐 Observability 系列
      • 前言 & 淺談 Observability
      • Elastic 的 Observability 解決方案
      • Uptime - 掌握系統的生命徵象
        • 我們要觀測的生命徵象是什麼?
        • 使用 Heartbeat 收集系統生命徵象數據
        • 透過 Kibana 觀看心電圖及設定警報
        • 使用合成監控 (Synthetics Monitor) 從使用者情境驗證服務的運作狀態
      • Metrics - 觀察系統的健康指標
        • Metrics 與 Metricbeat 的基本介紹
        • 使用 Metricbeat 掌握 Elastic Stack 的健康狀態
        • 使用 Metricbeat 掌握 Infrastructure 的健康狀態 Host 篇
        • 使用 Metricbeat 掌握 Infrastructure 的健康狀態 Docker 篇
        • 使用 Metricbeat 掌握 Infrastructure 的健康狀態 Kubernetes 篇
        • 使用 Metricbeat 掌握 Infrastructure 的健康狀態 AWS 篇
      • Logs - 挖掘系統內部發生的狀況
        • Logs 與 Filebeat 的基本介紹
        • 使用 Filebeat 應該要了解的設計細節與原理
        • 透過 Filebeat 收集 Elastic Stack 中各種服務的細節資訊
        • 透過 Filebeat 收集 Infrastructure 中各種服務的細節資訊
      • Traces - 觀察應用程式的效能瓶頸
        • Elastic APM 基本介紹
        • 使用 APM-Integratoin-Testing 建立 Elastic APM 的模擬環境
        • 如何在 Kibana 使用 APM UI
        • 使用 APM Server 來收集 APM 數據
        • 透過 APM Agents 收集並傳送後端服務運作的記錄
        • 透過真實使用者監控 (RUM, Real User Monitoring) 來改善使用者體驗
      • 建立結構化的 Log
        • Elastic Common Schema 結構化 Log 的規範
        • Elasticsearch Ingest Pipeline 資料 Index 前的轉換好幫手
          • 基本介紹
          • 各種常用的 Processor
          • Enrich 資料與例外處理
      • 有效的使用 Observability 的資料
        • 透過 Machine Learning 發現異常的問題
        • 使用 Kibana Alerts 主動通知異常狀況
        • 資料的生命週期管理
        • 使用 Elastic Observability 追縱及觀察問題的心得
      • 完賽心得
    • 😀Elasticsearch 技術分享小品
      • 🤖Elastic 與 AI
        • Elasticsearch Inference API 讓我們直接在 ES 裡運用 OpenAI Completion API
    • 🎥線上分享
      • 喬叔 Elasticsearch Index 管理與效能優化技巧
      • Elastic Certification 認證經驗分享
    • 🛠️workshop
      • 如何在 Elasticsearch 實現敏捷的資料建模與管理 @ DevOpsDays 2023
        • 工作坊實作內容
      • Elastic Observability 實作體驗坊 @ DevOpsDays 2022
        • 行前準備
        • 工作坊實作內容
      • 當 Elasticsearch 搜尋引擎遇上 AI @ HelloWordDevConference 2024
        • 投影片
        • Elasticsearch 環境準備
        • Google Colab 環境準備
        • 工作坊操作說明
        • ElasticSearch Relevance Engine (ESRE)
    • ⬆️Elastic Stack 版本升級記錄
      • 🔍Elasticsearch
  • 其他專業服務
    • 👩‍🎓企業包班 | 企業內訓
    • 👨‍💼顧問服務
    • 🈺專案合作
    • 🧩Elastic 授權代理
  • 相關連結
    • Facebook 粉絲頁
Powered by GitBook
On this page
  • 本篇學習重點
  • APM Agents 要解決的問題
  • 傳統收集 Performance Metrics 的問題
  • 傳統收集 Error 的問題
  • APM Agents 的功能介紹
  • Framework Integration (框架整合)
  • Instrumentation (檢測)
  • Background Collection (背景收集)
  • APM Agents 支援的語言
  • APM Agents 使用方式簡介
  • 使用 APM Agents 時要注意的事項
  • 對於原本服務的影響?
  • Sample Rate (取樣率)
  • 減少 APM Agents 處理的資料量
  • 參考資料
  1. 技術分享
  2. 喬叔帶你上手 Elastic Stack - 探索與實踐 Observability 系列
  3. Traces - 觀察應用程式的效能瓶頸

透過 APM Agents 收集並傳送後端服務運作的記錄

本篇學習重點

  • APM Agents 要解決的問題是什麼?

  • APM Agents 提供什麼功能?

  • 如何使用 APM Agents 的簡介

  • 使用 APM Agents 要注意的事項。

APM Agents 要解決的問題

Elastic APM Agents 的任務主要有兩件事:

  • 協助『應用程式』或『服務』收集 Performance (效能) 相關的 Metrics,傳送給 APM Server。

  • 當 『應用程式』或『服務』 發生 Error (錯誤) 時,收集 Error Logs,傳送給 APM Server。

要做到以上的兩件事,代表我們需要程式運作時,收集這兩種的資訊,以下分別針對這兩種情境來說明一般的做法。

傳統收集 Performance Metrics 的問題

要分析某段程式運作效能時,最簡單與古老的做法,就是在程式開始時,先記錄當下的時間,在程式結束之後,記錄結束的時間,也因為這種需求太普遍,各種語言當中的 Framework 或 Library 也都有支援這種計算 time elapsed 的工具,不過當記錄這些 Performance Metrics 時,常會有以下的問題:

  • 『只有有埋 time elapsed 的地方,才收集得到數據』,但是要埋的地方可能有非常多,一開始不會都埋好,實務上常常會變成『發生問題時,才改 code 來埋 log、重新出 build、deploy、想辦法讓問題再次發生時,取得 log 』,這樣會變成是背動的狀況,甚至遇到不容易 reproduce (重製) 的例外狀況時,也會很不容易收集到能協助判斷及解決問題的資訊。

  • 收集到的資訊不足,在不同的情境下,會需要收集的資訊會不同,例如 Database 存取時的執行速度太慢,這時要能進一步盤查原因,可能會需要執行當下的 SQL statement 並且包含執行時帶入的參數,也可能會需要知道是哪一個請求,才產生出這個 DB 的 query,資訊不足時要花更多的時間才能推測與盤查。

傳統收集 Error 的問題

使用例如 try catch 等 Error handling 的方法,並且在錯誤發生時寫 Logs,而這樣的做法常會遇到:

  • Logs 沒有結構化的格式,都只純文字的方式在解讀,有時要找尋相關的 Logs 時,只能用 grap 的方式去篩選,但複雜的條件要處理會很花時間。

  • 沒有抓到的錯誤,被丟出時,記錄到的資訊也不足,可能只有 stack trace,但是缺少能更進一步判斷的商業資訊,例如使用者 ID、訂單編號…等。

  • 收到的 Error,不容易與前、後發生的處理所產生的 Logs 串連在一起,在分析問題的原因時,不容易掌握整體處理流程發生狀況的全貌。

APM Agents 的功能介紹

Elastic APM Agent 在協助收集 Performance Metrics 時,提供幾種的方式:

Framework Integration (框架整合)

也可以稱為 Build-in Instrumentation (內建檢測),不論是哪種程式語言,在開發的時候常會使用各種 Framework,並且在 Framework 透過已經建立好的一些機制,例如:HTTP 請求的處理、Database 的存取,Logging 的機制、Scheduling (排程) 的功能…等。

APM Agents 在各種語言的支援上,都有盡量整合最熱門的一些 Framework,讓使用者簡單的設定後就能直接使用,自動依照 Framework 的功能,收集相關的資訊,並且以結構化的方式,將收集到的數據的格式定義在 Elastic Common Schema 之中。

Instrumentation (檢測)

在沒有使用支援的 Framework 的時候,APM Agents 也有提供 Instrument (檢測) 資料收集的工具,讓使用者能很簡單的將自己程式中要觀察的某個處理行為,能包裝成為 Transaction 或 Span,並且透過已經定義好的架構與提供的 Utility,能輕易的收集 Performance 相關的 Metrics 並且加上要額外記錄的資訊,並且由 APM 幫我們將這收集到的事件,與其他前後的事件連結在一起。

Background Collection (背景收集)

APM Agents 在運作時,會在背景定期的收集系統的 Metrics,能夠配合我們所收集的 Transaction 或 Span 的資訊,來協助掌握某個要觀察的時間點,系統整體的狀況。

APM Agents 支援的語言

目前有支援的語言,後端相關的如下:

  • Golang

  • Java

  • .Net

  • Node.js

  • PHP

  • Python

  • Ruby

前端相關的有兩個

  • iOS

  • RUM (Real Time Monitoring) Javascript

APM Agents 使用方式簡介

以下使用 Golang 為例:

  1. 安裝 Elastic APM 套件

go get -u go.elastic.co/apm
  1. 使用在 Build-in framework 或 Library,例如 Gin Web Framework:

import (
	"go.elastic.co/apm/module/apmgin"
)

func main() {
	engine := gin.New()
	engine.Use(apmgin.Middleware(engine))
	...
}
  1. 透過 Environment Variable 定義相關的設定

  • ELASTIC_APM_SERVER_URL:APM Server 的位置

  • ELASTIC_APM_SERVICE_NAME:目前的服務名稱,這個會是之後在 APM UI 中用來識別服務的重要設定。

  • ELASTIC_APM_ENVIRONMENT:目前的 Environment,這也是在 Kibana APM UI 中篩選的主要功能之一。

  • ELASTIC_APM_GLOBAL_LABELS:有一些自訂的 Labes 是屬於全域型的,也就是在這個服務裡全都要加上的,可以定在這裡。

  1. 指定自定義的 Instrument

建立自己定義的 Transaction:

tx := apm.DefaultTracer.StartTransaction("GET /api/v1", "request")
defer tx.End()
...
tx.Result = "HTTP 2xx"
tx.Context.SetLabel("region", "us-east-1")

在 Transaction 當中加上 Span:

span, ctx := apm.StartSpan(ctx, "SELECT FROM foo", "db.mysql.query")
defer span.End()

使用 APM Agents 時要注意的事項

對於原本服務的影響?

APM Agents 在運作時,一定會佔用到原本服務需使用的系統資源,這些處理會使用到:

  • CPU

  • Memory

  • 頻寬

另外再從兩個部份來分析:

  • Latency (延遲):APM Agents 收集資訊對於原本服務的 latency 影響程度非常的小,一般只有個位數的微秒 (microseconds),所以單純是考量 Latency 的部份的話,埋的量不是非常多的話,其實不會有太大的影響。

  • Background tasks (背景處理):APM 在收集到 Instrument 資訊之後,會需要序列化 (serialize) 以及壓縮 (gzipping) 的處理,這部份會佔用到 CPU 的運算,如果服務本身是使用 CPU 為主的服務 (CPU bound),這部份會影響到原本的性能,但如果不是 CPU bound 的話,影響會較少。

另外 APM Server 如果無法正常接受 APM Agents 所傳送的資料時,APM Agents 最終會選擇放棄傳送,設計上也是以不影響原本服務執行為主。

特別注意:先前專案的團隊實際在使用 PHP 版本的 APM Agents 時,在壓測時有明確的因為加上 APM Agents 後,原本服務的 QPS 下降將近一半,猜測和 PHP 的實作版本沒有實作 async call 可能有關,若有使用 PHP 版本的話會需要特別留意。

Sample Rate (取樣率)

既然使用 APM Agents 收集 Instruments 數據時,一定會佔用到系統的資源,也就是多少都會影響到原本服務的效能,這時候 Sample Rate (取樣率) 就是一個很重要的設定,不過這個值沒有一定的標準,但是在量級非常大的系統之中,1 ~ 3% 的取樣率一般已經足夠有一定的代表性,也就是若是有問題發生時,一般都會能取得到樣本,當然這個設定值還是會依照使用的情境與硬體的規格需進行壓測及調整。

減少 APM Agents 處理的資料量

  • 如果某些資料沒有必要都要收集,例如 capture_header 、 capture_body ,這個在 Sample Rate 較高、量級較大的環境之中,應該考慮關掉 capture_body ,這個會於效能會有明顯的影響。

  • 如果一個 Transaction 中包含了過多個 Span,這也會讓整包處理的量非常的大,例如有寫了個跑非常多次的迴圈,裡面產生非常多的 span,這種情況應該設定好 transaction_max_span 來避免這種意外發生。

  • 另外 APM Agents 會將收集到的 Instruments 資料分批的往 Elasticsearch 傳送,這個每次處理的量也會佔用到系統的效能,如果記憶體佔用太多,應該要嘗試調整傳送的間隔 api_request_time 、或是每批的大小 api_request_size。

參考資料

Previous使用 APM Server 來收集 APM 數據Next透過真實使用者監控 (RUM, Real User Monitoring) 來改善使用者體驗

Last updated 2 years ago

...其它可參考 。

由於每一種語言實作的方式都會有些不同,每一種 Framework 的行為有不同時,支援的方式也會有所差異,以上只是最簡短介紹 APM Agents 的使用方式,讓大家有個感覺,詳細的使用方式,請參考 [1] 每個語言的版本。

📘
官方文件 - APM Go Agents - Configuration
官方文件 - APM Agents
官方文件 - APM Agents