韩国团队如何选 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 厂商要求