韓國團隊如何選 Datadog 替代方案：六個候選的成本、區域與遷移條件

韓國團隊尋找 Datadog 替代方案，真正要換的往往不止一張帳單。原來的告警能不能繼續工作，事故發生時還能不能找到同樣的證據，數據會經過哪些地區，以及凌晨需要幫助時由誰接手，都會影響最後的選擇。

本文比較六個候選：Dynatrace、Elastic Observability、Grafana Cloud、觀測雲、New Relic 和 Splunk Observability Cloud，按英文名稱排序，不做名次排名。入選依據是公開可查的可觀測性範圍、OpenTelemetry 接入方式，以及值得核對的部署和區域條件。它們的產品邊界並不相同。

觀測雲是本文發佈方，也是比較對象之一。技術與商業資料於 2026 年 10 月 27 日對照官方文檔復核；本文沒有完成同工況生產測試、審閱客戶合同，也沒有執行後面的試點。以下分別說明公開事實、編輯部建議的評估方法，以及必須由具體環境或合同回答的問題。

先確認：繼續用 Datadog 是否更合適

Datadog 覆蓋基礎設施、APM、日誌、數字體驗、合成測試、安全等領域。已有看板、監控器、SLO、集成和穩定值班流程的團隊，應把這些資產的價值算進比較。Datadog 也提供 OpenTelemetry 接入，因此統一採集標準本身並不要求更換後端。

如果所需功能已經可用，歷史數據與權限滿足審計，實際合同價格合理，或者團隊沒有遷移人力，保留 Datadog 可能更合適。有時縮小索引範圍、調整採集和保留策略就能解決成本問題。試點得出“繼續使用”的結論，並不意味著試點失敗。

先寫清幾個問題：是哪項計費用量驅動了替換；哪些看板、告警、SLO 和歷史必須保留；數據與支援材料允許在哪裡處理；韓語技術支援和 KST 覆蓋是不是硬要求；現有 SDK、Agent 與 OpenTelemetry 組件是什麼。隱私、保留期、性能目標和遷移人力也要進入同一份要求。

這是選型與驗證方法示意，不代表已經完成遷移或測得收益。

六個候選，先看各自的邊界

Dynatrace：別把首爾探測點當作韓國儲存區

Dynatrace 文檔分別介紹 SaaS monitoring environment 和客戶環境部署選項。亞太數據儲存位置包括悉尼、新加坡、孟買和東京，部分區域需要聯繫銷售。首爾的 Synthetic 執行點不代表可觀測性後端在韓國儲存數據。環境說明、數據安全控制

OpenTelemetry 接入提供受支援的直接 OTLP 和 Collector 路徑。應按實際語言與運行時組合，驗證自動發現、依賴關係、選定部署形式中的模塊，以及維運責任。產品介紹中的因果分析能力，不等於已經定位了自己環境中的事故原因。

Elastic：首爾 Hosted 是具體產品事實，不是全線承諾

Elastic Observability 覆蓋日誌、指標、APM、數字體驗等領域，產品組合也包含剖析能力。Cloud Hosted 區域表列出 AWS 首爾 aws-ap-northeast-2。不能據此推斷所有 Serverless 產品、全部功能都在首爾提供。

其 OpenTelemetry 方案適合納入搜索型平台的評估。Hosted、Serverless、自建三種方式要分別比較映射、儲存、伸縮和維運人員。跨區域或數據模型變化可能需要新部署、重建索引；查詢相容與歷史保留也要單獨安排。

Grafana Cloud：託管平台不等於自己搭一套 OSS

Grafana Cloud 提供託管指標、日誌、追蹤、剖析與可視化，不只是一個 Grafana 界面。其技術體系包含 Mimir、Loki、Tempo 等，但 Cloud 的責任分工與自己運行這些組件不同。平台介紹

區域列表包含 AWS 東京、新加坡，以及 Google Cloud 新加坡。已有 stack 的 region 不能原地修改；需要其他區域時，應建立新 stack 並準備遷移。按 OTLP 接入資料與適用的 Alloy 路徑，驗證屬性與標籤轉換、基數、採樣、看板和告警規則。

觀測雲：把數據路徑與運營模式一起核對

觀測雲公開的產品範圍包含基礎設施、指標、日誌、APM、RUM、可用性監測及其他模塊。比較應以實際選用的模塊為準，不能因為都叫可觀測性平台，就預設 Datadog 的每條工作流都有對應實現。

商業站點包括 AP1 的 AWS 新加坡、AP2 的阿里雲新加坡、ID1 的騰訊雲雅加達，以及 CN6 的阿里雲香港。此次復核的公開資料沒有列出首爾或韓國公共 SaaS 站點。不同站點相互獨立，帳號與數據不會自動遷移或共享。

DataKit OpenTelemetry與追蹤採集器提供相應 OTLP、DDTrace 等路徑。私有部署方案則需另外核對商業提供條件、模塊、資源容量、用量上報、網絡、升級和事故責任。界面支援韓語、能夠提交工單，都不能直接證明有韓語技術值守、KST 升級響應或特定 SLA。

New Relic：日本已不只是 Preview，但條件仍需逐項確認

New Relic 提供 APM、基礎設施、日誌、瀏覽器與移動端、合成測試、網絡及告警能力。數據區域文檔區分美國、歐盟和日本。當前不能繼續把日本一概寫成 Preview，不過通過相應日本法人採購、區域功能和舊 API 的限制仍然存在。

客戶數據選擇某個 region，不代表所有處理和支援活動都只在該地區發生。數據位置說明區分客戶數據與 Systems Operations Data，後者在各區域場景中都涉及美國處理。日本 OTLP endpoint 既不是韓國託管證明，也不能證明所有區域功能一致。應在實際採購條件下驗證 OTLP 路徑、用戶模式和日常工作流。

Splunk：先分清 Observability Cloud 與日誌平台

Splunk Observability Cloud 的後端是 SaaS，覆蓋基礎設施、APM、RUM、Synthetic；亞太 realm 包括新加坡、東京、悉尼。它能觀測雲上和本地負載，不代表後端可以自建。服務說明

Splunk 的 OpenTelemetry 分發版提供採集路徑。完整日誌調查可能還要配合 Splunk Platform、Log Observer Connect，並涉及獨立的寫入、許可與設定。先核對產品概覽，再判斷“日誌”是否已經包含在報價與功能範圍內。

用同一個事故比較，才能看到功能差異

基礎設施要核對實體身份、標籤、拓撲；APM 要在相同採樣條件下比較保留追蹤、錯誤、依賴和剖析；日誌要包含解析、索引、歸檔、重載查詢及權限；RUM 要包含會話、同意、Replay 和保留；Synthetic 則要看執行區域、腳本、私有探測點。安全規則、響應流程與 AI 輔助還要驗證輸入、權限、誤報和解釋依據。

OpenTelemetry 標準化的是遙測介面與數據路徑，不會讓後端的數據語義和功能完全相同。支援的 Collector 設定可以向多個 exporter 發送選定信號，但只改一次 endpoint 通常是切換，不是自動雙寫。隊列、重試、丟棄、外網流量和重複埋點都需要測量。OpenTelemetry 概覽、Collector

看板、notebook、monitor、升級規則、SLO 歷史、RBAC、日誌 pipeline 與歸檔、RUM 腳本、合成測試、事故記錄和廠商專有分析，不會隨著一份 OTLP 數據自動遷移。

韓國業務的數據位置與部署要求

Datadog Sites中，AP1 是日本，AP2 是澳大利亞，都不代表韓國站點或韓國合同價格。觀測雲 AP1、AP2 則是新加坡的不同雲廠商。同樣的編號必須連同廠商和地理位置一起理解。

對每個候選，都應畫出主儲存、處理、備份、災備、支援訪問、分包處理方和跨境路徑。核對區域功能、從實際韓國網絡訪問的時延、加密和密鑰、保留與刪除、導出和退出條款。地圖上的位置不能證明符合韓國監管；應讓適用合同、數據處理條件和安全審核覆蓋實際場景。

Datadog BYOC Logs允許受支援的日誌處理與儲存放到客戶雲中，同時保留 Datadog UI/控制路徑和查詢結果返回。這是有明確範圍的客戶側部署選項，並不是整個平台的自建版。觀測雲私有部署的產品範圍與維運合同不同，不能只用一個“私有化”勾選框來比較。

費用要看計費用量，不能只看原始數據量

數值案例統一放在韓國 Datadog 價格指南。比較從相同工作負載與調查要求開始，再測每個產品如何計算這份負載。

記錄日誌 GB、事件大小、Datadog Standard/Flex 索引範圍，以及觀測雲大日誌拆分成計費條數的規則。指標要核對基數和實際啓用的時間序列或數據點模式；追蹤要看採樣和 indexed spans；RUM、Replay、Synthetic、保留、支援、最低承諾、折扣、稅費和遷移人力也不能遺漏。同樣的原始輸入不等於相同的計費用量，應按觀測雲計費明細讀取實際帳號的模式。

較低的寫入單價可能被必要的保留、附加產品、用戶權限或維運成本抵消。公開文檔無法證明某個候選在完整範圍內普遍更便宜。

韓語技術支援，要具體到時間和責任

Datadog 韓語支援文檔列出的韓語支援時間為工作日、節假日除外，09:00–17:00 KST；聊天窗口為 10:00–11:30 和 13:00–16:00 KST。實際方案、嚴重度定義和升級條款仍須核對，首次響應目標不是恢復時間保證。

觀測雲的工單服務與界面語言設置，不足以確認韓語技術人員和 KST 覆蓋。對每家廠商，都應書面確認語言、渠道、時區、節假日、嚴重度響應、進展更新、夜間與週末升級、數據訪問地點、實施責任、事後支援及適用的服務補償。

遷移先盤點資產，再安排切換

數據丟失、調查變慢、漏報、權限錯誤、計費用量激增或升級支援失敗，都可以成為停止條件。原 Datadog 告警必須能夠恢復。單服務 DDTrace 灰度只能驗證一條接收路徑，不能證明這份資產清單已經自動遷移。

一個尚未執行的 30 天試點

以下計劃沒有執行結果，不包含實測恢復時間、開銷、節省比例或功能一致性結論。開始前記錄準確版本、環境、負責人、信號基線、隱私措施、驗收閾值、回退步驟與脫敏證據。

選擇具有代表性的故障：Java/Spring 慢 SQL、Pod 重啓與 CPU 飽和、下游超時、關聯後端請求的 JavaScript 錯誤，以及發佈後延遲或錯誤率上升。另外比較日誌計費、OpenTelemetry/DDTrace 屬性映射、Collector 資源與 queue/retry/drop 計數、韓國網絡到候選站點的訪問，以及一次支援升級演練。使用相同時間窗口、查詢、身份、原始數量，並記錄缺失證據。

結果分為已確認等價、可接受差異、阻斷項、未確認。沒有運行的測試屬於未確認，不能記為通過。

1. 固定現有調查方式、用量與合同基線。
2. 選擇代表服務和試點所需的有限信號。
3. 在支援的設定下建立有邊界的並行採集。
4. 讓相同工程師回答相同事故問題。
5. 比較功能缺口、計費用量與維運工作。
6. 書面解決區域、安全與支援條件。
7. 驗收並演練回退，再決定部分採用、共存、延長試點或繼續使用 Datadog。

可把第一周用於基線和設定，中間兩周用於採集與調查，最後一周用於費用、支援和回退。這是安排建議，不是所有組織都能在 30 天內完成的承諾。

最後把結論寫成有條件的選擇

重視廣泛自動發現的團隊可以評估 Dynatrace；重視搜索和首爾 Hosted 的團隊可以評估 Elastic；希望使用託管開放遙測技術棧的團隊可以評估 Grafana Cloud。觀測雲適合在其計量、採集或私有部署條件匹配時做限定試點；New Relic 要滿足實際區域採購與功能條件；Splunk 則需要先明確可觀測性與日誌平台的分界。

如果韓國託管或某項韓國合同條件是硬要求，而候選的公開說明沒有覆蓋，就先向該候選確認。不能因此寫成“所有廠商都沒有韓國選項”——Elastic Hosted 的首爾就是已公開的例子。共存也可能合理，但要承擔額外的負責人分工、重複費用和退出安排。

公開資料仍不能確認完整工作流等價、生產查詢延遲與併發、數據完整性、採集開銷、AI 結果、站點全部模塊、資產與歷史自動遷移、法律適用性、區域實測時延、客戶折扣或觀測雲韓語支援。把這些保留為驗收條件，不應將其改寫成無依據的能力或價格結論。本文不支持“Datadog 用戶都不滿意價格”“沒有公開價格或客戶側部署”“觀測雲普遍更便宜、無縫替換”等說法。

主要資料

• Datadog 產品、Sites、韓語支援、BYOC Logs 功能
• Dynatrace 環境、數據控制、OpenTelemetry
• Elastic Observability、Hosted 區域
• Grafana 區域、OTLP
• 觀測雲站點、部署方案、DDTrace
• New Relic 區域、日本發佈說明、數據位置
• Splunk 服務說明、OpenTelemetry 廠商要求