全面解析 Elastic APM Go Agent：效能優化的祕密武器！

Elastic 技術專欄技術專欄 2025 年 5 月 7 日 最後更新時間 : 2025 年 10 月 14 日

前陣子，我們在 Elastic APM 中引入了對 Go 應用程式效能監控的 Beta 支援。

而在這篇部落格文章中，我們將深入探討該代理程式的一些細節。我們將涵蓋的部分內容與即將推出的「正式版」（GA）代理程式的代碼分支相關，該版本採用了修訂後的接收協議和數據模型。

您可以在這裡閱讀更多關於新接收協議的資訊：Increasing Memory Efficiency with an Improved Elastic APM Internal Intake Protocol

在深入探討內部運作之前，讓我們先簡單聊聊這個代理程式的功能。

APM Agent 的一天

從最高層次來看，代理程式的目的在於測量並回報您的 Go 應用程式的響應時間效能，那麼，它是如何做到的呢？

為了測量應用程式的響應時間，您可以使用代理程式的 API 來為應用程式代碼進行檢測。

在每次您的應用程式/服務接收到的請求或所發起的操作中，記錄一筆交易（transaction）。一個交易描述了該操作所花費的整體時間，以及一些相關細節（稱為其「上下文」），以及結果（比如 HTTP 狀態碼）。在交易內，您還可以記錄更細粒度的細節，這些被稱為 span。

以上描述的即是代理程式的追蹤 API（很快將變為分布式追蹤 API）。

Elastic APM 還涵蓋了異常/錯誤報告；未來的版本將包括應用程式的指標功能以及更多特性。

該代理程式會將這些資料回報至 Elastic APM Server，並處理所有細節，包括取樣、緩衝、編碼、壓縮、連線管理等。只需對應用程式代碼進行檢測，並將代理程式指向 APM Server，資料就會被索引至 Elasticsearch，隨時可在 APM 的 UI 中進行視覺化展示！

最小化負擔

Go 開發者對於效能通常有著極高的期望，因此我們非常關注檢測帶來的額外負擔。

幸運的是，大部分工作已經有現成的工具處理！

Go 工具鏈內建了一些出色的性能分析工具，例如：pprof 和內建的基準測試功能。此外，標準庫在許多地方都經過精心設計，提供了選項來最小化內存分配的額外負擔。

我們需要做的，就是根據我們的特定限制，將這些元素整合起來。

那麼，這些限制是什麼？我們在設計所有代理程式時的一貫目標，就是避免對應用程式代碼造成任何干擾。

這可能以多種形式呈現，但特別重要的是，我們必須避免讓應用程式代碼被任意時間的阻塞，或者占用大量資源——特別是 CPU 和內存。

為了避免干擾您的應用程式，我們確保代理程式將大部分工作移至主代碼路徑之外。從實踐的角度來看，這意味着檢測代碼會收集有關交易的一些數據，然後將這些數據交由後台的 goroutine 處理，最終傳輸到 APM Server。

聽起來很簡單，但實際上這其中包含了一些細微的差異。

設計應對失敗

當背景 goroutine 無法跟上從檢測收集數據的輸入速率時會發生什麼？

阻塞應用程式不是一個可行的選項，因為這會影響原本要監控的效能。我們可以選擇丟棄數據，但這將影響通過 UI 報告的統計結果。

目前，Go agent 使用一個帶緩衝的 channel 將檢測到的應用程式代碼數據傳遞給背景 goroutine，而背景 goroutine 會儘可能快地從 channel 中取出條目進行進一步處理。

如果 channel 滿了，檢測代碼就會丟棄數據。每次發生這類數據丟棄事件時，計數器會自動增加，而這些統計數據會定期發送到伺服器。

目前，我們尚未利用這些數據，但未來我們將利用這些資訊來建議更改取樣配置。

那麼，如果 APM Server 無法訪問會發生什麼？無論是由於錯誤還是偶然事故，失敗總是會發生，因此我們必須針對這些情況設計系統，以確保其可靠性。

當 APM Server 無法連接時，我們會對數據進行緩衝，緩衝數據意味著會消耗內存資源，從而減少了我們正在監控的應用程式的資源可用量。

因此，我們會對所存儲的數據量設置限制。

在有限的緩衝空間內，我們需要決定哪些數據應保留，哪些數據應丟棄，何時進行這些操作。我們必須考慮丟棄數據對統計結果的影響，以及如何高效地完成這一切。

對於 Go agent，我們實現了一個v環形緩衝區來存儲經過編碼的事件。

每個編碼事件由一種類型和一段字節序列構成。當緩衝區滿時，該緩衝區中最舊的條目會被淘汰。

每個條目前有一個包含類型和條目大小（以字節為單位）的標頭。

通過在緩衝區內存儲事件類型，我們可以在統計數據中計入由於緩衝區淘汰而丟棄的事件。

設計加速

Go agent 的額外負擔已經降到幾乎最低。

以 net/http 檢測為例，在一台普通的開發者筆記型電腦上測得的時間負擔約為 1.5 微秒。整體上的效能調整關鍵歸結於一點：最小化分配。我們來看看幾項主要的優化措施。

第一項是使用對象池，特別是 sync.Pool。

每當一個 transaction 或 span 開始時，我們會從 sync.Pool 中獲取對象。當 agent 完成事件的編碼——或者事件被丟棄時——就會將它歸還到對象池內。

透過這種方式，我們不僅可以避免分配操作，還可以保留相關的記憶體對象（例如，重置 slice 的長度，但保留其容量）。

需要注意的是，這一點必須融入 API 的設計中：為了啟用對象池，我們要求調用者在結束 transaction 或 span 後不得再引用它們。

下一個主要的優化是我們如何實現 JSON 編碼。

Go 標準庫提供了一個非常友好且易用的 JSON 編碼與解碼工具包：encoding/json。

Elastic APM Go agent 的初始實現就使用了這個工具包（我們始終相信應先讓程式能運行，繼而讓它正確，最後才追求速度），但很快發現編碼是導致資源消耗的主要原因之一。

這有幾個原因：encoding/json 嚴重依賴反射（reflection），其 API 的部分設計還會強制執行分配操作（理論上 encoder/json.Encoder.Encode 可以避免分配，但實際執行中並未如此）。

市場上已存在多種替代的 JSON 編碼器，例如 easyjson、ffjson、go-codec 等。

然而，它們的性能都無法完全滿足我們的特定限制，但我們從中汲取了靈感。

最終，我們實現了一種零拷貝、零分配的 JSON 編碼器，這並未依賴 sync.Pool，而是直接編碼到一個可重用的緩衝區中。與上述工具包類似，我們的實現依賴於通過解析結構體定義來生成代碼。

$ go test -benchmem -bench=. -run=NONE github.com/elastic/apm-agent-go/model
goos: linux
goarch: amd64
pkg: github.com/elastic/apm-agent-go/model
BenchmarkMarshalTransactionFastJSON-8 1000000 1418 ns/op 585.70 MB/s 0 B/op 0 allocs/op
BenchmarkMarshalTransactionStdlib-8 200000 9303 ns/op 127.91 MB/s 1088 B/op 23 allocs/op
PASS
ok github.com/elastic/apm-agent-go/model 3.403

目前，fastjson 編碼器位於 Go agent 的內部套件目錄中，但我們計劃在不久的將來將其移至一個獨立的儲存庫，以便其他人也能使用它。