新加坡 Datadog 替代方案：觀測雲的部署、費用與遷移評估

新加坡團隊尋找 Datadog 替代方案，通常不是因為少一個功能按鈕，而是現有部署地點、帳單結構或運行方式開始不適合下一階段的業務。觀測雲值得進入驗證名單的條件，是 AWS 新加坡站點、私有部署或不同計費方式確實能解決這些約束。是否更省錢，要把同一工作負載、信號範圍、留存、支援、合同和遷移人力代入後再判斷。

如果團隊已經深度依賴 Datadog 的監控器、儀表板、SLO、權限和處置流程，保留 Datadog 可能更穩妥。觀測雲接收 DDTrace 或 OpenTelemetry 數據，並不意味著這些資產會自動搬過來。

本文由觀測雲編輯部發佈，觀測雲也是比較對象之一。本文是 Datadog 與觀測雲的雙產品評估，不是獨立排名或全市場榜單。價格單位、公開區域、採集路徑和支援邊界於 2026 年 10 月 27 日復核；沒有進行生產規模性能測試，也沒有審閱客戶合同。

先把決策條件放在同一張表裡

“APM”“RUM”“OpenTelemetry 支援”這些共同名稱，只能說明類別重疊，不能證明工作流、限制和運行成本相同。價格的公開單位、公式和場景敏感性見新加坡 Datadog 價格指南，這裡不重復給出未經同負載覈算的節省比例。

從一次故障調查比較產品範圍

兩邊都公開說明瞭基礎設施、APM、日誌和真實用戶監測。真正有價值的比較，是工程師能否從同一個用戶問題出發，沿著服務、追蹤、日誌和資源找到足夠的證據。

基礎設施需要核對主機、容器、Kubernetes、雲資源和網絡是否覆蓋實際資產，標籤、拓撲和告警在真實規模下能否使用。APM 則用同一個慢介面、下游依賴、錯誤和版本回歸，檢查入口、Span、服務圖與 Profiling 的調查過程。不能因為界面都有服務圖，就跳過傳播和身份映射。

日誌要比較解析、管道、索引、訪問控制、歸檔、回查和留存。RUM 需要核對瀏覽器與移動平台支援、會話定義、採樣、隱私、Session Replay，以及前後端追蹤關聯。對 AI 輔助分析、自動化和告警，也要用相同輸入檢查解釋依據、權限、噪聲和誤報，不能把產品介紹中的能力當作已經復現的結果。

Datadog 產品與價格目錄和觀測雲產品介紹可以用於建立範圍清單；觀測雲基礎設施、APM、日誌、RUM說明瞭各自的接入與分析路徑。集成數量不作為質量評分，因為不同廠商的“集成”定義、字段映射和維護邊界不同。

保留 Datadog 也可能是最好的結果

如果現有儀表板、SLO、權限、歷史記錄和事故流程已經成為組織標準，替換成本可能高於收益。某些必需的安全、網絡、數據庫或其他專有功能已經在 Datadog 驗證，而候選方案還沒有證據，也應保留現有路徑。

已有承諾用量、協商折扣、較低索引量和支援合同，可能讓客戶的實際商業條件比公開單價更有利。若團隊無力承擔私有部署的容量、數據庫、備份、災備、升級和安全維護，就不應因為“可私有部署”而直接選擇它。

觀測雲也有明確的停止條件：所需功能沒有可接受的替代方案；站點、模塊、留存或支援條款遲遲未確認；合同駐留要求無法書面滿足；數據雖然接收成功，但身份、採樣、關聯、查詢、告警或隱私測試失敗；計入重建與並行運行人力後，商業理由仍不成立；或者不能可靠回滾。此時保留 Datadog、縮小遷移範圍或讓兩者共存，都是合理結果。

採集器相似，不代表接入結果相同

Datadog Agent 和 DataKit 都運行在客戶環境中並轉發遙測數據，僅憑這種架構不能推斷誰的開銷更低、可靠性更高或維護更容易。

Datadog 提供 Agent OTLP、OpenTelemetry Collector、Datadog 自身發行版和直接 OTLP 接收等路徑。相容表、Agent OTLP、直接 OTLP分別說明路徑級功能與限制，不宜把其中一條的能力推廣到全部路徑。

觀測雲的OpenTelemetry 集成定義了 DataKit 接收指標、日誌和追蹤的連接埠與協議；Tracing inputs列出了 DDTrace、Jaeger、OpenTelemetry、SkyWalking 和 Zipkin。把 Collector 放在 DataKit 前面，是基於標準 pipeline 的候選架構，本文沒有把它當作實測完成的組合。

評估時固定服務名、環境、版本、區域和請求集合，再檢查資源與主機元數據、跨語言和網關的上下文傳播、錯誤與數據庫 Span、HTTP route、peer service、日誌關聯字段和時間戳。復現計劃採用的 head/tail 採樣，並測量隊列、重試、丟棄、CPU、內存及網絡。把某條 OTel 路徑不支援的後端功能逐項列出來。

OpenTelemetry Collector可以把數據發送給多個支援的後端，可能降低採集層耦合；這是架構上的推論，不是本文已經測出的收益，也不意味著後端資產可以自動轉換。

新加坡站點與合同駐留是兩個問題

截至復核日，Datadog Sites列出 AP1 日本、AP2 澳大利亞，沒有列出新加坡數據站點。這只描述公開站點表，不代表 Datadog 在新加坡沒有業務，也不排除其他數據位置方案。

例如BYOC Logs把支援的日誌處理和儲存放在客戶基礎設施內，由 Datadog 提供界面並路由查詢，匹配的查詢結果仍會返回 Datadog。這是日誌專用的混合架構，不能當作整個 Datadog 平台私有化。如果要求僅是日誌處理和儲存留在自己的雲帳號，應把它納入比較。

觀測雲商業站點文檔列出 AP1 AWS 新加坡、AP2 阿里雲新加坡、ID1 騰訊雲雅加達。**觀測雲 AP2 與 Datadog AP2 是不同廠商的命名，後者位於澳大利亞。**文檔還說明不同站點的帳號和數據獨立，不能共享或遷移。另有本地基礎設施或私有雲部署方案，具體可採購模塊、版本、限制和責任仍需設計與合同確認。

站點位置並不能回答備份、災備、支援診斷資料、分包處理者、跨境訪問、密鑰歸屬、模塊可用性、通知、刪除、導出和退出條款。應要求書面資料，而不是從地圖上的點推斷整個數據生命週期都留在新加坡。

本輪也沒有找到足以承諾“新加坡免費工作空間”的公開依據。需要指定新加坡架構和成本評估，不能把通用免費體驗宣傳等同於這個站點的可用方案。

不同計費單位，要放進同一個工作負載

Datadog 的AP1 詳細價格表涉及主機、容器、自定義指標、日誌寫入與索引、APM、索引 Span、會話和測試等單位；包含額度、留存、站點、年度承諾和支援都會改變結果。

觀測雲的商業計費明細與計費邏輯按指標數據點或時間線、日誌條數或開通的寫入流量模式、Trace 或 Span、RUM 計費 PV、回放會話、測試次數等分別計算。指標當前預設按數據點計費，既有時間線工作空間或合同模式需單獨確認。RUM 計費可能取頁面瀏覽量與 resource、long-task、error、action 記錄總數除以 100 的較大值；不能把它簡化為純頁面瀏覽次數。部分替代計費方式需要客戶經理開通。

成本評估應記錄主機與容器、serverless、自定義指標、原始日誌量和事件大小、索引或計費條數、歸檔與查詢、追蹤和 Span、採樣、RUM 與回放、可用性測試、安全與網絡，以及支援、上線、承諾、折扣、遷移人力和區域條款。相同原始數據不一定產生相同計費數量。

公開計量方式不同，不能證明某個平台一定便宜。保留現有工作流的價值和遷移成本，可能改變結論；把公式、敏感性、2 倍與 5 倍數據增長場景放進獨立價格模型再判斷。

支援響應與恢復服務也要分開

Datadog 公佈支援方案和響應目標，首次響應不等於恢復或解決時間保證。需要把等級、嚴重程度、時間和客戶合同對應起來。

觀測雲公佈標準與高級服務及工單流程。公開服務時間、響應目標不自動證明新加坡本地英語覆蓋；其時區、當地人員、合同納入方式、恢復目標、遷移負責人、專屬技術支援和夜間最高嚴重度流程，都應書面確認。對兩家提出相同問題。

私有部署還需明確容量、升級、數據庫、備份、災備、補丁、監控系統自身的監控和事故響應負責人。私有化選項本身不保證更簡單或更便宜。

先保住現有告警與歷史，再談遷移

公開資料沒有證明 DDTrace 或 OTLP 接收成功就能自動遷移 Datadog 的全部儀表板、監控器、SLO、角色、管道、集成、Notebook、事件記錄、歷史與權限。應盤點資產，再決定保留、重建或退出；歷史數據還可能受到技術和商業限制。

新加坡 DDTrace 接入驗證指南只覆蓋保留現有插樁、切換一個預發佈服務的接收端、檢查追蹤並恢復舊路徑。那是一套待執行的操作方案，不是已經完成 POC 的證據。

讓 30 天評估產出證據，而不是分數

下面是建議執行方案，本文沒有執行該 POC，沒有原始測試結果，也沒有完成回滾。30 天只是排期示例，不是生產準備時間保證。

開始前寫清負責人、測試者與批准者，限定非關鍵集群、語言、版本、流量、已知故障和站點。記錄 Agent、SDK、DataKit、Collector、exporter、隊列、重試，以及主機、Pod、時間線基數、日誌、追蹤、RUM、回放、留存與採樣。提前確定身份映射、脫敏、禁止字段、正確性與資源閾值、停止條件和證據位置。API Key、Token、個人資訊和內部敏感域名不進入共享記錄。

用同一組任務比較：慢 SQL、Pod 重啓或資源飽和、下游超時、前端 JavaScript 錯誤到後端追蹤、發佈後的版本回歸、採集器故障和恢復、不可失效的告警與升級路徑、實際工作負載與帳單核對，以及關閉候選路徑後的恢復。每項記錄接收、拒絕、重試、排隊、丟棄、資源、字段差異、時間戳、缺失上下文和可復現查詢。

可以按以下節奏推進：

1. 第 1–5 天凍結資產與用量基線，確定區域、隱私、測試、停止和回滾要求。
2. 第 6–12 天僅連接批准的小範圍，統一身份，測接收健康與開銷，保留原 Datadog 告警。
3. 第 13–20 天由相同工程師調查相同問題，保存查詢與時間，不給未經驗證的自動根因能力打分。
4. 第 21–26 天檢查權限、審計、告警路由、支援和計費輸入。
5. 第 27–30 天執行回滾，評估重建與並行運行人力，決定保留、共存、部分遷移、延長或停止。

結果分別記為“已驗證滿足相同要求”“可接受的差異”“阻斷項”“尚待證據”“未測試”。未測試不能當作產品不支援，廠商文檔中的能力也不能當作測試通過。

最後仍需明確的邊界

完整功能等價、設定或歷史自動遷移、生產級延遲與併發、高基數行為、數據完整性、採集開銷、採樣與元數據、查詢與告警、歸檔回查、導出、安全、自動化和 AI 行為，都需要具體範圍的驗證。合同駐留、SaaS 與私有部署等價、AP1 模塊、英語支援、價格、服務可用性、恢復、合規和退出，則需要客戶對應資料。

這不是說文章整體“尚未確認”，而是區分公開事實、廠商能力說明、尚未執行的試驗和客戶合同。下一步應帶著產品清單、數據路徑、區域限制、調查任務和支援要求做新加坡架構評估，而不是先承諾固定節省比例。

官方資料

資料復核日期：2026 年 10 月 27 日。採購前再次核對可能變化的產品、站點、價格和條款。

• Datadog：Agent、AP1 價格、Sites、OTel 相容、支援方案、支援條款、BYOC Logs 架構。
• 觀測雲：產品、商業站點、私有部署、DataKit 架構、OpenTelemetry、計費明細、計費邏輯。
• OpenTelemetry Collector。