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

APM(Application Performance Monitoring,應用程式效能監控)是以分散式追蹤(distributed tracing)為核心,持續量度應用程式回應時間、錯誤率與吞吐量的監控方法。 它回答的問題不是「伺服器是否運作」,而是「這單交易為何慢了 800ms、卡在哪一個服務、哪一行 SQL」。對香港企業而言,APM 通常是可觀測性(observability)建設中,繼基建監控之後的第二步。

APM 與傳統監控有什麼分別

傳統監控(monitoring)看的是「已知故障」:CPU 是否過高、磁碟是否滿、服務是否回應。APM 看的是「未知故障」:微服務架構下一個 API 請求會穿過 5 至 10 個服務,任何一環慢了,用戶體驗就受損,但每台伺服器的指標可能全部正常。

一句話總結:監控告訴你系統「有沒有事」,APM 告訴你「事在哪裏、為什麼」。

APM 監控的三大功能

1. Distributed tracing(分散式追蹤)。 每個請求獲派一個 trace ID,穿過各服務時逐段記錄為 span(含耗時、狀態、metadata)。所有 span 串連成 waterfall 圖,一眼看出慢在哪一段。

延伸閱讀什麼是分散式追蹤？從 Trace 到落地方案

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

指標	全寫	回答的問題
Rate	Requests per second	流量有幾多?
Errors	Error rate	有幾多請求失敗?
Duration	Latency (p50/p95/p99)	回應有幾快?

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

核心概念速查表

術語	繁中釋義
Trace	一個請求橫跨多個服務的完整旅程
Span	Trace 中的一段操作,例如一次 SQL 查詢
Sampling(採樣)	只記錄部分 trace 以控制成本;head-based 在起點決定,tail-based 在終點按錯誤/延遲決定
Apdex	以 SLA 門檻換算的用戶滿意度分數(0–1)
Service map	由 trace 自動生成的服務依賴拓撲圖
Instrumentation	在程式碼中加入量度點的動作,分手工 SDK 與自動 agent 兩類

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

Instrumentation 成本。 是否支援自動注入(Java agent、auto-instrumentation)?是否相容 OpenTelemetry(OTel)?選 OTel 相容方案可避免日後被單一供應商鎖定(vendor lock-in),遷移時只需改 export 目的地——我們在 Datadog 遷移至 OpenTelemetry 指南示範過雙寫(dual-write)做法。
採樣策略。 高流量系統必需 tail-based sampling,否則要麼成本失控,要麼關鍵錯誤 trace 被丟掉。
收費模式。 按 host 計費對常駐服務友善;按數據量(GB ingest)計費對流量波動大的系統風險較高。詳見下節。
數據位置(data residency)。 香港企業受《個人資料(私隱)條例》(PDPO)規範,若 trace 或 RUM 數據含個人資料,宜選擇提供亞太區節點或可自託管(self-hosted)的方案,具體合規責任請諮詢法律顧問。
部署形態。 純 SaaS 上手最快;金融、政府機構常要求私有化或專屬節點部署。

收費模式與成本預算

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

延伸閱讀Datadog 替代方案 7 選（2026）：成本、功能與選型比較

按 host/agent 月費:例如 Datadog APM 每 host US$31 起(年繳價,且需先購 Infrastructure Pro,實際起步價約每 host US$46,以官網當日價為準);
按數據量:例如 New Relic 按每 GB 數據寫入計費,另加用戶席位費;
用量制(usage-based):按實際 trace/span 數據量逐日結算,流量低谷時成本自然回落——Guance(观测云)採用此模式,香港及亞太區節點可供選擇(覆蓋範圍以官網為準)。

預算時的常見陷阱:估算 trace 量切勿用「請求數」直接推算,要先乘以採樣率,再計每條 trace 的平均 span 數與大小。一個 100 host、每秒 3,000 請求、10% 採樣的系統,trace 數據量每月可達 TB 級,按 GB 計費與按 host 計費的差價可達數倍。

實施路線圖(四星期可完成)

第 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 處理指標(metrics),不處理分散式追蹤。兩者互補:Prometheus 告訴你 p99 變差,APM/trace 告訴你變差的是哪個服務哪段程式。

Q. 引入 APM 會拖慢應用程式嗎?
現代 agent 與 OTel SDK 的開銷一般在 1–5% 之間(因語言與採樣設定而異);採樣率與非同步批次上報(asynchronous batch export)可把影響再壓低。建議先在 staging 環境做負載測試。

Q. 香港公司選 APM,數據要放在哪裏?
視乎數據是否含個人資料及行業規管。一般商業系統選亞太 SaaS 節點已足夠;銀行、保險、政府相關系統宜評估專屬節點或私有化部署,並在合約寫明數據位置與保留政策,具體請諮詢法律顧問。

Q. APM 可以幫手慳雲成本嗎?
可以。Trace 與指標能指出閒置服務、過度配置(over-provisioned)的實例與 N+1 查詢,不少團隊在上線 APM 後首季已能縮減一至兩成運算資源(屬經驗值,因系統而異)。

下一步

APM Monitoring Guide(英文技術版)— 採樣策略、告警門檻與工具對照表
什麼是可觀測性?— 概念上游
Datadog 替代方案(東南亞/香港適用)— 七款工具同工作量成本對照