中國業務的 Datadog 替代方案：八條可觀測平台選型路線

Datadog 的公開產品範圍覆蓋基礎設施、APM、日誌、RUM、告警及相關安全產品。對已經依賴這些集成和工作流的團隊，替換成本不僅是重新接入資料，還包括告警、權限、儀表板和歷史記錄的處理。本文由觀測雲編輯部撰寫，依據官方公開資料比較選型邊界，不是獨立排名或實測報告。

但“成熟”不等於“適合所有團隊”。當業務主要在中國、基礎設施橫跨多雲和 IDC、日誌與鏈路資料量快速增長、採購和合規流程更復雜時，很多團隊會開始搜索 Datadog 替代 或 Datadog alternative。本文由候選供應商編寫，不是第三方排名。我們更關心一個問題：

如果你今天正在評估 Datadog 替代方案，哪一類工具更適合你的團隊、成本結構和故障排查方式？

先按需求縮小選擇範圍

如果你只想快速驗證觀測雲是否適合，不需要先替換 Datadog。更穩妥的方式是用觀測雲免費版接入一條真實業務鏈路，與現有系統並行跑兩到四周，再比較故障定位路徑和成本口徑。

為什麼團隊會尋找 Datadog 替代？

1. 成本不是“單價貴”，而是資料規模變得不可預測

Datadog 的定價頁把不同產品線拆得很清楚，但真實生產環境裏的成本感知往往沒那麼清楚。日誌、APM trace、自定義指標、RUM、Profiling、安全資料、保留週期和用戶席位都會隨着業務增長變化。

團隊最常見的痛點不是“今天某一項價格看不懂”，而是：

• 日誌範圍擴大後，索引和保留成本開始上升；
• Kubernetes、微服務和多租户帶來大量標籤，高基數指標越來越多；
• trace 和 RUM 在故障時很有用，但全量保留成本壓力大；
• 工程團隊希望保留上下文，財務團隊希望賬單可預測；
• 最後只能靠少採、少留、少開功能來控成本。

這也是很多 alternatives 文章都會先講成本的原因。不是因為 Datadog 沒價值，而是可觀測資料天然會膨脹，平台必須幫助團隊做資料治理。

2. 中國區落地會遇到產品之外的問題

國際 SaaS 在功能層面可能很成熟，但中國團隊還要處理採購、發票、付款、法務、安全、資料合規、網絡訪問、本地支持和中文協作成本。

這些問題不會出現在功能矩陣裏，卻會決定項目能不能上線。對很多國內團隊來説，Datadog 替代方案的真正標準不是“誰功能最多”，而是“誰能在中國組織裏更快、更穩地落地”。

3. 多雲和混合雲會放大工具割裂

運行在阿里雲、騰訊雲、IDC 或國內外混合環境的團隊，需要核對跨環境的資料接入與關聯。雲廠工具也可能支持外部資料，但統一服務身份、網絡路徑和查詢範圍仍要設定。國際 SaaS 的採購、訪問和支持條件，同樣應按實際部署驗證。

所以 Datadog 替代方案需要回答一個很具體的問題：當一個請求從前端、網關、微服務、消息隊列、資料庫一路跨過多個雲資源時，平台能不能給出統一上下文？

4. AI 排障開始變成新評估維度，但不能只看“有沒有 MCP”

過去可觀測平台比的是“能不能採、能不能查、能不能畫圖”。現在還要看 AI 能不能進入真實排障流程：

• 告警發生時能否彙總相關指標、日誌、trace 和事件；
• 能否解釋異常而不是隻展示圖表；
• 能否幫助新人理解現場；
• 能否把歷史故障和處理路徑帶出來；
• 能否減少第一輪排查時間。

這裏有一個很容易被寫錯的分界：MCP Server、CLI、OpenAPI 解決的是“AI 能不能呼叫觀測平台的資料和工具”；引入 Agent Team 時，還需要驗證“AI 能不能在企業生產環境裏按權限、按流程、按證據鏈完成診斷、協同和行動”。

換句話説，接入工具只是開始。真正難的是方法論、權限邊界、審計、資料治理、統一服務語義、審批執行、復原驗證和長期運行。AI 不會替你承擔事故責任，也不應該被寫成自動修復一切。它更現實的價值是：在可控邊界內，縮短從“看到異常”到“形成假設、收集證據、給出處置建議”的時間。

我們的評估標準

下面這組標準，比簡單功能清單更適合評估 Datadog 替代方案。

8 個 Datadog 替代方案

1. 觀測雲：評估中國區與多雲的運作條件

**適用團隊：**中國區業務、多雲/混合雲環境、需要本地服務、希望評估成本模型，以及希望把 AI Agent 放進受控排障流程的工程團隊。

觀測雲不是 Datadog 的逐項複製品。它更適合的場景是：中國團隊需要一個能覆蓋日誌、指標、鏈路、RUM、基礎設施、Kubernetes、告警和事件的統一平台，同時希望採購、服務、文件和試用路徑更貼近國內企業。

優勢

• 中國區落地：可評估中文文件、服務渠道及本地化交付；具體支持和合同範圍仍需確認。
• 雲中立：適合同時看阿里雲、騰訊雲、華為雲、海外雲和 IDC。
• 多信號關聯：接入支持的資料並對齊服務身份、時間和關聯欄位後，可驗證日誌、指標、trace、RUM、基礎設施和告警之間的調查路徑。
• Obsy Agent Teams：官方文件描述了按職責設定 Agent、Skill、MCP 和任務的工作台。可執行的動作取決於連接的工具、運行環境和授權；它不保證自動找出根因或完成安全復原。
• 免費版可用於小範圍試用，使用前核對當前配額、功能和資料保留限制。

Obsy Agent Teams 應該怎麼理解？

如果你的目標只是讓 Codex、Claude Code、OpenClaw 或內部 Agent 呼叫觀測雲能力，觀測雲提供 OWL CLI、MCP Server、OpenAPI，負責把日誌、指標、鏈路、事件、RUM、APM、基礎設施等能力變成可呼叫工具。這一層解決“能不能呼叫”。

但企業真正卡住的通常不是接口，而是生產運行：一次 P1 事故應該先看影響面還是最近發佈？P99 抖動、錯誤率上升、資料庫連接池耗盡和下游超時之間如何建立假設？什麼時候只讀分析，什麼時候升級給 SRE，什麼時候觸發審批，什麼時候進入安全排查？

Obsy AI 文件將 Obsy Copilot 的即時協助與 Obsy Agent Teams 的持續任務區分開來。Teams 可以設定職責、Skill、MCP 服務和 Channel；任務文件説明如何查看產出、處理高風險動作審批請求和停止執行。審批請求的存在不代表所有風險動作都會自動被識別，停止執行也不等於已完成復原。上線前仍要驗證工具權限、敏感欄位、動作範圍和恢復步驟。

這也是它和“自己接一個 Agent”的區別：

一個具體例子：同一個服務可能在日誌裏叫 checkout-service，在鏈路裏叫 checkout-api，在告警裏叫“支付下單服務”，在團隊文件裏叫“交易核心鏈路”。無論使用外接 Agent 還是 Obsy Agent Teams，都需要先統一這些身份或建立可驗證的對應。關聯實體和上下文能幫助查詢，但產品不會憑空補齊未採集的日誌、未登記的負責人或不存在的歷史記錄。

對 AI 能力強、平台工程團隊成熟的客户，OWL CLI / MCP Server 可以把觀測雲作為 AI-native observability tool layer 接入自有 Agent 體系。需要持續任務和協作的團隊可以評估 Obsy Agent Teams；其效果應以實際任務記錄和人工複核衡量。服務説明明確要求對 AI 輸出複核，不承諾故障必然解決或特定準確率。

限制

• 如果你的團隊已經深度使用 Datadog 的大量海外集成，遷移需要分階段做。
• 如果你主要業務在海外，且國際 SaaS 採購沒有阻力，Datadog 仍然是強選擇。
• 對某些 Datadog 專有模塊或非常細分的集成，需要逐項做 POC，不應只看宣傳頁。

什麼時候選觀測雲？

當你的痛點是中國區落地、多雲統一、日誌和鏈路成本、告警定位效率、本地支持，以及希望把 AI 從“問答助手”推進到“生產級診斷與協同”時，觀測雲值得放進第一批 shortlist。

2. Grafana LGTM / Prometheus + Grafana：適合開源優先團隊

**適用團隊：**平台工程能力強、希望保留開源控制權、已經大量使用 Prometheus/Grafana 的團隊。

Grafana 生態的優勢是開放、靈活、開發者熟悉。Prometheus 負責指標，Loki 負責日誌，Tempo 負責 trace，Mimir 或獨立項目 Thanos 可擴展指標儲存；Grafana 負責查詢與可視化，這條路線很適合開源文化強的團隊。

優勢

• 開源生態成熟，社區經驗多。
• Prometheus/Grafana 已經是很多雲原生團隊的默認語言。
• 靈活，可控，可按內部規範深度定製。

限制

• 長期維護成本容易被低估。
• 自建模式需要團隊承擔高基數治理、權限、儲存、升級和備份；Grafana Cloud 的託管責任不同，不能套用同一份運維清單。
• 日誌、trace、RUM、事件和告警閉環需要自己拼。

什麼時候選它？

如果你有強平台團隊，願意維護開源棧，並且可觀測平台本身就是你的核心工程能力，Grafana/Prometheus 路線仍然很好。

3. Elastic Observability / ELK：適合日誌檢索重的團隊

**適用團隊：**重視日誌查詢、全文檢索並具備 Elasticsearch 經驗的團隊；安全分析需要另核對 Elastic Security 的產品和許可。

Elastic 的強項是日誌和搜索。很多團隊從集中日誌開始，會自然走向 ELK/EFK，再擴展到 APM 和 Observability。

優勢

• 日誌檢索能力強。
• Elasticsearch 生態成熟。
• 對安全日誌、審計日誌、全文搜索場景友好。

限制

• 自建 Elasticsearch 需要索引、mapping、分片、冷熱、擴容和升級經驗；Elastic Cloud Hosted 與 Serverless 的責任邊界不同。
• 如果只把它當日誌平台，仍然容易形成日誌孤島。
• 大規模日誌成本和查詢性能需要持續治理。

什麼時候選它？

如果日誌搜索是核心需求，團隊有 ES 能力，Elastic 仍然是強候選。但如果主要目標是從告警一路定位到用戶影響和服務根因，要確認它的全棧聯動能力是否滿足。

4. New Relic：適合另一個成熟國際 SaaS 選擇

**適用團隊：**海外 SaaS 可接受、希望獲得成熟 APM/RUM/日誌體驗的團隊。

New Relic 是 Datadog 最常被拿來對比的國際可觀測廠商之一。它在 APM、RUM、日誌、基礎設施和平台化體驗上都有積累。

優勢

• 產品成熟度高。
• APM/RUM 體驗較完整。
• 國際市場資料、生態和案例多。

限制

• 對中國團隊來説，仍然需要評估採購、本地支持、訪問體驗、合規和成本。
• 如果你找替代方案的主要原因是國際 SaaS 落地難，它不一定解決根本問題。

什麼時候選它？

如果你主要業務在海外，或者公司已經能順暢採購國際 SaaS，New Relic 是值得比較的 Datadog alternative。

5. Dynatrace：適合大型企業和複雜拓撲

**適用團隊：**預算充足、系統複雜、需要評估自動發現、拓撲和根因分析的大型企業。

Dynatrace 的定位偏企業級，強調自動發現、服務拓撲、智能分析和企業治理。

優勢

• 提供自動發現和服務拓撲能力，覆蓋範圍取決於支持的技術與接入設定。
• 適合複雜企業環境。
• 提供輔助根因分析及自動化能力，結果、授權和恢復路徑需要在目標環境驗證。

限制

• 需要按實際產品範圍、使用量及實施工作估算採購和運維成本。
• 對中國區團隊仍需評估本地落地路徑。
• 如果只是想降低 Datadog 成本，Dynatrace 未必是更輕的選擇。

什麼時候選它？

當你的主要問題是複雜企業系統治理，而不是單純成本或中國區採購時，可以把 Dynatrace 放進 shortlist。

6. 阿里雲 SLS / ARMS：適合阿里雲單雲棧

**適用團隊：**主要資源在阿里雲，日誌、APM 和雲資源監控都希望走雲廠體系的團隊。

SLS 和 ARMS 對阿里雲內資源有天然集成優勢，採購和賬單也更容易進入雲廠體系。

優勢

• 雲內資源接入方便。
• 日誌服務、APM 和雲產品聯動更直接。
• 適合阿里雲強綁定業務。

限制

• SLS 可以採集其他雲和 IDC 的日誌，不能把它描述成只能看阿里雲資源；跨雲時仍要評估網絡、權限、出口流量和關聯欄位。
• 如果業務同時跑在騰訊雲、華為雲、AWS 或 IDC，跨雲排障仍需要額外工作。
• SLS 與 ARMS 的產品邊界、鏈路關聯和授權需要分別驗證，不能僅憑廠商歸屬判斷是否能完成端到端調查。

什麼時候選它？

如果你的業務幾乎都在阿里雲，雲廠方案值得優先看。如果你要的是雲中立統一可觀測，需要再比較觀測雲這類平台。

7. 騰訊雲可觀測 / CLS / TMP：適合騰訊雲棧

**適用團隊：**主要資源在騰訊雲，希望使用雲廠監控、日誌和託管 Prometheus 的團隊。

騰訊雲可觀測體系適合騰訊雲資源監控、日誌和雲原生場景。

優勢

• 騰訊雲資源集成方便。
• 雲廠採購路徑清晰。
• 對騰訊雲內部服務和日誌場景友好。

限制

• 多雲中立性需要驗證。
• CLS 的 LogListener 支持騰訊雲、其他雲和自建 IDC。跨環境接入可行，但統一身份、鏈路關聯、網絡和費用需要實測。

什麼時候選它？

騰訊雲資源佔絕對多數時可以優先看。多雲團隊應同時評估雲中立平台。

8. SigNoz / OpenObserve 等開源方案：適合希望自主部署、願意維護的團隊

**適用團隊：**重視開放代碼與部署選擇權，並願意承擔所選自建版本維護工作的團隊。

SigNoz和OpenObserve都提供自建及託管路線。選擇自建時，許可、版本能力、容量和維護責任需要逐項確認，不能把“開源”直接等同於更輕或更便宜。

優勢

• 可以評估自建與託管路線，許可、資源、支持與維護成本要一起計算。
• 更開放，可控性強。
• 適合內部平台實驗和特定場景。

限制

• 自建版本的長期維護、升級、安全、權限、容量和告警治理仍由團隊承擔；託管版本需按合同確認責任分工。
• 企業級能力、生態和本地支持需要逐項驗證。

什麼時候選它？

如果你有工程能力，也願意把可觀測平台作為內部基礎設施長期維護，開源方案值得看。如果你想減少平台維護負擔，它不一定是最省事的替代。

怎麼做 POC 才不浪費時間？

先在隔離環境確認採集、權限和停止路徑，再用有代表性的非關鍵服務或脱敏回放檢驗依賴、流量和故障場景。簡單 demo 可以驗證連通性，但不足以證明生產規模下的功能、成本或性能。

更好的 POC 是：

1. 選一條真實業務鏈路：最好包含前端入口、後端 API、資料庫或中間件、Kubernetes 工作負載和錯誤日誌。
2. 保留 Datadog 或現有工具不動：候選平台並行接入，不做一次性替換。
3. 用歷史故障覆盤測試：看從告警到根因要跳幾個系統，需要多少人參與。
4. 計算真實成本：日誌、指標、trace、RUM、保留、席位、AI 能力都要算進去。
5. 驗證 Agent 邊界：在隔離環境檢查工具呼叫、證據引用、權限、審批、審計和恢復步驟，記錄失敗與人工糾正；不能僅靠功能描述認定生產處置閉環成立。
6. 問值班同學是否願意長期用：可觀測平台最終是值班和排障工具，不只是採購表格。

按實際限制決定選擇

• 如果你是中國區、多雲、混合雲團隊，優先試觀測雲。
• 如果你是開源優先、平台工程能力強的團隊，優先看 Grafana/Prometheus/LGTM。
• 如果你是日誌檢索重度用戶，優先看 Elastic/ELK，同時評估日誌之外的可觀測閉環。
• 如果你主要業務在單一雲，優先看對應雲廠可觀測產品。
• 如果你是大型企業、預算充足、系統複雜，Dynatrace 和 New Relic 可以進入國際 SaaS 對比。

真正的 Datadog 替代，不是找一個功能表更長的工具，而是找一個更適合你團隊運行環境、預算模型和排障方式的平台。

如果你只是想驗證資料接入和排障工作台，可以先用觀測雲免費版並行接入一條關鍵鏈路。如果你要評估 AI Agent 在生產環境裏的可靠運行、權限治理和協同閉環，可以進一步看 Obsy Agent Teams 與 Obsy AI 文件。

---

作者：觀測雲編輯部
技術依據：下列官方公開文件；本文未進行生產規模對照測試。
最後技術核驗：2026-10-27
參考資料：Datadog 價格與產品、Prometheus 架構、Grafana Cloud、Elastic Observability、OpenTelemetry、SLS 採集、CLS 採集、觀測雲產品。