APM 工具怎麼選：鏈路、保存與排障成本一起看

一個請求變慢，服務拓樸通常能指出它經過哪裡，卻未必能解釋時間花在哪裡。程式執行、下游等待和主機資源競爭可能出現在同一段鏈路。排障人員還要找到相關日誌、容器指標或使用者工作階段；資料分散在不同系統，時間範圍和請求識別碼就得逐一對齊。

選 APM 工具時，我會沿著這條調查路徑往下看：應用程式留下什麼記錄，哪些被採樣掉，保存多久，值班人員能繼續查到哪裡。既有 SkyWalking、Jaeger 或雲端服務已能回答的問題，無須為了統一品牌再搬一次。值得花錢改變的，是經常缺少的上下文，以及團隊不想繼續承擔的後端維運。

觀測雲編輯部 · 2026 年 10 月 28 日。本文依據官方文件比較技術機制與維運責任，觀測雲也是候選方案；未執行相同負載的效能測試或客戶成本測試。

先找出缺少的 Span 在哪裡中斷

分散式追蹤把已插樁的操作記成 Span，再透過上下文傳播連起請求。APM 在這些記錄與其他遙測之上提供請求量、錯誤、延遲與相依關係分析。服務出現在拓樸上，不代表每次呼叫都留下完整、可回查的 Trace。概念說明可參考 APM 是什麼，這裡關心調查實際需要的資料。

同步 HTTP 只是其中一種路徑。呼叫端要注入上下文，閘道要保留傳播標頭，下游要將它取出；佇列與執行緒切換也需要對應的插樁或明確傳遞。W3C Trace Context 的 traceparent 帶有 trace ID 與父 Span 等資訊。兩端填入相同 service.name，無法代替這段因果關係。OpenTelemetry 上下文傳播

自動插樁能減少支援框架、函式庫和執行環境的採集工作。業務自訂步驟仍可能要補 Span 或屬性；eBPF 的覆蓋範圍也取決於核心、協定與實作。看到網路連線，還不足以說明付款為什麼重試三次。程式碼效能剖析則提供執行熱點，要另看語言支援、採集路徑和產品範圍。

先修好傳播或採集的缺口，再決定是否換後端。把相同的不完整記錄送到另一個平台，失去的操作並不會回來。

採樣改變留下的證據，也改變成本減少的位置

頭部採樣在請求早期做決定，成本較低，但不知道後面是否出錯。尾部採樣可以根據已收到的 Span，判斷錯誤、耗時或屬性；代價是先接收資料，維持狀態並處理延遲到達的 Span。OpenTelemetry Collector 的 tail sampling processor 要求同一 Trace 的 Span 到達同一採樣實例；任意分散到多個副本，會拆開判斷依據。採樣機制 · Collector 尾部採樣

假設每秒固定 100 個請求，每個恰好產生 20 個 Span，以 Trace 為單位採用一致的 10% 機率，暫不考慮重試、遺失與遲到：

採樣前：100 × 20 × 86,400 = 172,800,000 Span / 天
採樣後期望值：172,800,000 × 10% = 17,280,000 Span / 天

這是固定負載的算例，不是正式環境量測或帳單測試。Span 的屬性與事件會改變大小，數量不能直接換成 GB，尖峰容量也要另外估算。若應用程式先捨棄 90%，尾部採樣器只能從收到的剩餘資料選擇，無法保證留下所有失敗請求。若全部先送到遠端才篩選，前面的傳送與接收已經發生。

錯誤率的分母也需要一起保留。在採樣前由 SDK 或 Agent 產生的請求指標，與從已採樣 Span 產生的指標，可能來自不同母體。遷移後錯誤數變少，應先查採樣與指標產生的位置。Datadog 的 OTel 文件按接入方式說明 Trace Metrics 的來源，某種 Agent 路徑的全流量保證不能直接套用到所有 OTLP 接入。Datadog OTel 相容範圍

保留既有插樁，再看後端接手哪些工作

OpenTelemetry 讓應用程式與傳輸層較容易換目的端，但各家後端的彙總、效能剖析、服務發現和權限模型仍然不同。先釐清每條路線可以沿用什麼，再安排剩下的工作：

觀測雲 DataKit 的 OTel 文件把差別落在具體端點：gRPC 預設監聽 127.0.0.1:4317，HTTP/Protobuf 的 Trace 路徑預設是 :9529/otel/v1/traces。應用程式的協定和位址要與 DataKit 實際監聽設定一致。Java Agent 2.x 預設使用 HTTP/Protobuf，不能直接套用只設定 gRPC 的位址。既有 SkyWalking、Jaeger 或 Zipkin 採集，也要依對應協定和版本接入，再遷移查詢、告警與採樣規則。

商業產品也需要按路徑比較。Datadog 列出廠商 SDK、OTel SDK、Collector 與直接 OTLP 接入的功能差異；New Relic 有原生 OTLP 接收端點；Dynatrace 的 Full-Stack 與獨立遙測接入有不同範圍和計量。這些平台能接收其他插樁來源，成功收到資料也不代表所有進階功能相同。

自託管產品同樣各有範圍。SkyWalking已包含多種觀測與分析功能；Jaeger 和 Tempo 的鏈路後端需要各自支援的儲存，並連接團隊所需的其他訊號。Thanos、Cortex 處理指標，不能當成通用 Trace 儲存。既有軟體功能無須重新開發，正式部署和復原責任則必須有人承擔。

雲端原生服務也可以保留。阿里雲 ARMS、AWS 與 Azure 應分別核對執行環境和產品範圍。Azure Application Insights 有支援的 OTel 接入，跨雲是否接得上取決於傳播與採集。AWS 建議將 X-Ray SDK 與 daemon 的插樁遷到 OpenTelemetry，這是採集元件的維護變化，並不代表 X-Ray 服務整體停止。AWS 支援時程

從 Trace 到日誌與使用者請求，保留同一次操作

從慢請求開啟相關日誌，比重新搜尋服務名稱省事。觀測雲鏈路詳情按 trace_id 關聯日誌，再依 service、env、version 等欄位對應日誌索引。主機、容器與 Pod 視圖還需要資源識別資訊和已採集資料。這些業務設定完成後，託管平台提供查詢與相關視圖，團隊可以少維護一套關聯後端。鏈路詳情與關聯分析

假設日誌保存 30 天、Trace 保存 7 天，第八天仍能讀到日誌裡的 trace ID，原本的 Trace 卻可能已經不存在。這只是保存期差異的例子，並非產品預設值。經常一起調查的訊號，應涵蓋需要的時間範圍；權限或索引不同，也會讓有效連結查不到記錄。

瀏覽器還多了一段傳播。觀測雲 Web SDK 用 allowedTracingUrls 選擇注入 Trace Header 的請求，用 traceType 選擇格式。後端要繼續這段上下文，跨來源 API 也要以 CORS 允許相關標頭。RUM 工作階段與後端 Trace 的採樣，分別影響記錄是否存在。allowTraceHeaderWithoutSession 可以在未採到一般工作階段時繼續傳送標頭，但不會建立那次工作階段的 RUM 記錄。Web SDK 鏈路設定

服務命名、上下文傳播與業務欄位仍是應用團隊的工作，平台接手後端維運和已有分析功能。AI 可以協助閱讀既有證據；不存在或已到期的 Span 不會因為一段說明而恢復。

把留下的資料與維運責任一起計價

同一個應用程式，在不同 APM 工具裡會形成不同帳單。Datadog 的主機型 APM 還要分開看攝入 GB、索引 Span、相關功能和超額；Dynatrace Full-Stack 的公開單位是記憶體 GiB-hour，日誌、RUM 與額外遙測依對應功能核算。New Relic 有資料加使用者方案，也有符合條件的 Full Consumption，額外計算功能會影響總額。Datadog 價格 · Dynatrace 價格 · New Relic 價格

Grafana Cloud 的單純 Trace 服務與 Application Observability 也有區別：後者計量 host-hours 與相應資料條件，不能只用 Tempo 資料量估價。Elastic 則要先分清 Serverless、Hosted 與自託管；接收端及處理路徑也會影響 APM 視圖。Grafana 應用觀測計費 · Elastic OTel 架構

觀測雲企業版依壓縮後位元組計算寫入流量，依涉及的原始流量計算資料處理，另計實際儲存、任務和選用算力。Span 數可以描述採集規模，無法代替整張帳單。商業版、企業版與私有部署也要分別取得同範圍報價。企業版計費

先對齊請求量、Span 分布、採樣位置、保存期與所需日誌/RUM，再分列服務費、客戶端採集資源和持續維護投入。一次性遷移與並行運行另外計算，不要把已發生的建設費再算成未來支出。只改一個 exporter 目的端通常是切換；同時送到兩端，還需要採集路徑支援的複製方式，並處理額外負載與費用。

資料存放也取決於實際部署。SaaS 站點、私有部署、遠端存取和外部處理形成不同資料流，供應商國籍無法代替對設定和契約的判斷。

既有鏈路已能支撐日常調查，就先保留，補好傳播和關聯缺口。 希望減少跨訊號排障與後端維運的團隊，再比較觀測雲等託管平台能接手的工作；已有成熟平台團隊、需要掌握底層資源，則可繼續自託管。依留下的調查能力、能停用的舊元件和持續費用，決定真正需要採購的範圍。