APM 應用程式效能監控完整指南：從 Trace 到告警

APM(Application Performance Monitoring,應用程式效能監控)是以分散式追蹤(distributed tracing)為核心,持續量度應用程式回應時間、錯誤率與吞吐量的監控方法。 它回答的問題不是「伺服器是否運作」,而是「這單交易為何慢了 800ms、卡在哪一個服務、哪一行 SQL」。導入順序應依現有調查缺口決定，並沒有適用於所有香港企業的固定次序。

APM 與傳統監控有什麼分別

基建監控常從 CPU、磁碟、網絡及程序狀態切入；APM 則以應用請求、依賴關係和執行路徑為調查入口。兩者都能協助調查已知或未預期的問題，不能用「已知／未知故障」劃分。一次請求跨越多少服務取決於架構；即使主機指標正常，應用仍可能因查詢、鎖或下游依賴而變慢。

APM 提供應用層的調查證據，但仍須結合日誌、變更和重現來驗證原因。

APM 監控的三大功能

1. Distributed tracing(分散式追蹤)。 已埋點的請求透過上下文傳播連接 trace ID，各受支援操作記錄為 span（含耗時、狀態及 metadata）。只有成功採集並保留的 span 才能組成可查詢的路徑；未埋點、採樣及傳送失敗都可能造成缺口。

2. Metrics(指標)。 業界通用 RED 三指標:

3. 關聯分析(correlation)。 Trace 與日誌(logs)、基建指標、RUM(Real User Monitoring,真實用戶監控)互相關聯:由用戶瀏覽器的一次點擊,直達後端某條慢查詢(slow query)。

核心概念速查表

點樣揀 APM 工具:五個評估維度

1. Instrumentation 成本。 是否支援自動注入(Java agent、auto-instrumentation)?是否相容 OpenTelemetry(OTel)?OTel 相容方案有助提升資料可移植性，但遷移仍需核對訊號支援、屬性映射、看板、告警、採樣及保留政策，並非只改 export 目的地——我們在 Datadog 遷移至 OpenTelemetry 指南示範過雙寫(dual-write)做法。
2. 採樣策略。 高流量系統應比較全量保留、head、tail 或混合採樣的成本與證據需求。Tail sampling 可優先保留已收到的錯誤或慢請求，但需要緩衝、穩定路由和容量，不能保證不丟失資料。
3. 收費模式。 以相同工作負載比較 host、攝取量、保留、用戶與計算等適用單位,再加入尖峰、承諾用量及超額條款;不能單憑計量單位判斷哪種較便宜。詳見下節。
4. 數據位置(data residency)。 若 trace 或 RUM 含個人資料,應核對實際儲存、處理、備份位置、跨境資料路徑、保留和存取控制,再按適用要求審查合同。亞太區節點或自託管本身都不能證明合規。
5. 部署形態。 SaaS、自託管和專屬部署的實際接入時間、權限、資料路徑與責任範圍需分別核對；行業名稱本身不足以決定部署形態。

收費模式與成本預算

業界 APM 主要有三種計費方式:

• 主機或主機時數：Datadog 有獨立 APM 及搭配 Infrastructure 的方案，不是所有 APM 都必須先購 Infrastructure。Grafana Application Observability 也有主機時數計費，不能把整個平台都視為只按 GB 收費。
• 資料與其他用量：寫入、索引、保留、運算及使用者權限可能各有單位。New Relic 同時提供不同用量與使用者方案，需按實際版本核對。
• 按資料類型計費：觀測雲不同訊號各有計量方式與保留設定，不能把所有費用都換算成相同的 trace/span 單位。合約承諾、固定費及其他訊號也會影響帳單，不應假定請求量下降時總價必然同步下降。

預算時的常見陷阱:估算 trace 量切勿用「請求數」直接推算,要先乘以採樣率,再計每條 trace 的平均 span 數與大小。例如每秒 3,000 個入口請求、10% 採樣且連續運行 30 日，假設一個入口請求對應一條 trace，可估得約 7.776 億條保留 trace；位元組數還需要每條 trace 的 span 數、序列化大小及計費口徑。未指定這些值及同範圍價格前，不能判定是 TB 級或相差數倍。

四星期試點範例（並非完成時間保證）

第 1 週:選 1–2 條核心交易鏈路,以 OpenTelemetry auto-instrumentation 接入,驗證 trace 完整性。
第 2 週:定義 RED 指標基線與首張 service dashboard,設定 p99 延遲與錯誤率告警。
第 3 週:擴展至其餘關鍵服務,加入 RUM 與日誌關聯,試行一次事故演練(game day)。
第 4 週:檢討採樣率與數據保留期,鎖定月度成本預算,完成 runbook。

想逐步照做的工程師,可參考英文版 APM Monitoring Guide 的評估方法；實際安裝應以對應語言和平台的官方文件為準;概念背景可先讀 什麼是可觀測性。

常見問題

Q. APM 與 observability platform(可觀測性平台)有什麼分別?
APM 專注應用效能與追蹤;observability platform 再整合基建監控、日誌、RUM、合成監控(synthetics)等。中型團隊通常由 APM 入手,再按需要擴展,或直接選用一體化平台減少工具數量。

Q. 我們已用 Prometheus + Grafana,還需要 APM 嗎?
視乎調查缺口。Prometheus 主要處理指標；如需查看個別請求跨服務的路徑，可補充追蹤系統或 APM。兩者能互補，但是否需要新增產品，應由現有工具和問題決定。

Q. 引入 APM 會拖慢應用程式嗎?
沒有可套用至所有應用的固定百分比。語言、框架、訊號、堆疊取樣、批次導出及採樣規則都會改變 CPU、記憶體與延遲；應在代表性負載下量度接入前後差異，並監控收集管線的丟棄與重試。

Q. 香港公司選 APM,數據要放在哪裏?
視乎數據是否含個人資料及行業規管。不能僅憑「亞太節點」判定已符合要求。應確認實際儲存與處理地點、跨境存取、分包處理者、保留與刪除條款、安全措施及適用行業要求，再按合約與法律意見決定。

Q. APM 可以幫手慳雲成本嗎?
APM 配合資源與成本資料，可以幫助找出重複查詢或容量配置的改善機會；是否節省費用，要比較調整前後的相同工作量、服務水準及監控自身成本。本稿沒有可支持「首季節省一至兩成」的實測資料，因此不作該承諾。

下一步

• APM Monitoring Guide(英文技術版)— 採樣策略、告警門檻與工具對照表
• 什麼是可觀測性?— 概念上游
• Datadog 替代方案(東南亞/香港適用)— Datadog 與 Guance 的區域、部署與遷移條件比較

官方資料與技術覆核

2026 年 10 月 27 日對照公開文件覆核；本文沒有執行效能基準測試。

• OpenTelemetry 自動埋點與採樣
• Apdex 技術規格
• Datadog 收費、New Relic 收費、Grafana Cloud 收費及觀測雲計費明細
• 香港個人資料私隱專員公署：雲端運算指引