OpenObserve vs Datadog Logs：索引、归档和自建成本

Datadog 日志费用高，第一步未必是迁走。正常日志是否全部进入标准索引，七天以前的数据还有多少人在查，归档是否已经用起来，这些使用方式本身就可能影响很大。先调整一版，再拿剩下的费用与 OpenObserve 比较，得到的才接近迁移收益。

如果调整以后，仍有大量必须热查的数据，团队又具备自建能力，OpenObserve 就有认真投入的理由。反过来，日志和 Datadog 的 APM、监控器已经紧密结合，只搬存储会多出跨平台调查和规则改造。便宜的存储要能够覆盖这些新增工作。

下面按计量、访问方式和维护投入逐项算。这里不引用某个客户的节省比例，也不假设一套统一单价；不同平均事件大小、留存和查询频率，确实会得出不同选择。

作者：观测云。计量规则核对于 2026-10-09。下文数字为公开可复算的容量示例，不是客户账单、产品报价或节省承诺。没有执行 Datadog 性能测试。

Datadog 的计费口径

假设每天进入处理环节的是 500 GB 未压缩日志，平均每条 1 KB。这里明确采用十进制单位：1 GB 等于 10⁹ 字节，1 KB 等于 10³ 字节。则每天约有五亿条事件。

若其中 20% 进入七天 Standard Indexing，每天约一亿条，一个三十天计费月累计约三十亿条。对应的计量基础如下：

如果同样 500 GB/天，平均每条变成 10 KB，事件数就下降到十分之一。对按事件数计费的部分，结论会明显变化；按字节摄取计费的部分却未必变化。没有平均事件大小和多行合并策略，单说“一天 500 GB 很贵”还不足以比较技术栈。

Datadog 的公开定价把摄取量和 Standard Indexing 分开，标准索引按事件数及保留档位计量。设每 GB 摄取单价为 Pg，每百万条七天保留档位单价为 P7，本例基础费用可写成：

15,000 × Pg + 3,000 × P7

P7 已经对应七天档位，不能再乘七。实际合同还可能涉及承诺量、超额、折扣和其他使用项，这个式子只用于把口径对齐。Datadog 定价、日志计费说明。

其他平台的计量也要从这份原始样本换算。摄取字节、事件数、压缩后上报量与物理存储，对应不同环节。单位相同不代表数据范围相同，单价相除很容易得出错误差距。

减少标准索引

Datadog 的索引排除规则发生在摄取之后。被排除的日志不进入相应索引，但仍可流向 Live Tail、日志指标和归档。因此，把标准索引比例从 100% 降到 20%，不代表整张日志账单下降 80%。Datadog 索引与排除规则。

延伸阅读OpenObserve vs 观测云：自建和托管的日志成本→

完全不需要的调试日志在采集端裁剪，会减少后续传输和摄取；需要留证、平时几乎不查的部分，保留归档更合适；每天参与告警和排障的部分，才需要维持对应查询能力。三类数据分开，才能看清还有多少费用值得为迁移付出。

设置日索引配额也只是一个控制点。达到配额后，相应新日志不再被索引，仍可能进入其他已配置路径。它可以限制索引使用，却可能让晚间发生的事件无法走原来的热查询和告警流程。若每天预期一亿条进入索引，配额只有八千万，差额不是免费被保留在同一功能层里。

因此，优化留存和索引的收益要先算在当前方案里。同样的分层策略也用于 OpenObserve，剩下的差额才主要来自产品费用和运行方式。否则只是把未经整理的现有账单与精细规划的新方案放在一起。

历史日志查询

Datadog 除 Standard Indexing 外，还有 Flex Logs 和归档访问。Flex 面向长期保留与查询，相应方案把存储和查询计算分别考虑；具体组合取决于站点与档位。Flex Logs。

一周前的记录偶尔查几条，与每次调查都要跨一个月做复杂聚合，需要的能力不同。前者可以接受一些等待，后者会持续消耗查询计算。对后者使用最便宜的保留方案，最后还可能把费用补在查询上。

Datadog 的 Archive Search 可以从归档流式返回结果，不重新索引，按扫描量计费；需要对应完整平台访问或保留时，可采用 Search & Rehydration。历史访问不一定都要完整回灌，但每条路径有自己的处理与费用。归档访问。

对于再水化，官方说明查询过滤在所选时间范围的文件下载后执行，扫描量基于取回的数据，而不是最终命中条数。选择一天、过滤 service:A，可能仍要取回这个时间范围内包含其他服务的文件。缩小时间范围才更直接影响这条路径的扫描量。归档所在云存储与传输也应单独计算。

OpenObserve 第一次读取旧对象，也要付出远端读取、解压和计算资源。重复查询命中缓存很快，并不能代替首次历史回查。长期保留多而访问少，可以把查询资源配得节制些；多人每天跨长时间范围分析，缓存和计算就不能只按最低部署估算。

OpenObserve 的资源费用

第一类是写入和加工。峰值、字段清洗和异常消息处理决定接收能力，平均日流量只能给出下限。第二类是长期对象与相关元数据；第三类是索引、缓存和临时磁盘；第四类是查询计算，包括并发排障和积压回放期间的资源。

它们不会总按数据量等比例增长。对象数据可能随留存近似增长，计算节点却往往按容量台阶扩容；一次大量冷查询可能先碰到网络、请求次数或解压计算。把所有资源都统一乘一个压缩率，会低估实际部署成本。OpenObserve 存储架构。

OpenObserve 已有查询、仪表板、告警和 Trace 能力，不需要从零开发这些功能。需要迁的是现有 Datadog 配置、字段规范和使用流程：原监控器怎样表达，关联调查从哪里进入，团队如何继续值班。软件功能存在与迁移完成，是不同投入。OpenObserve traces。

只迁日志、APM 等仍留在 Datadog 时，原合同中的其他费用未必减少，跨平台调查还可能增加操作成本；一起迁移则扩大了项目范围。实际可节省金额，应该是能够停止支付的那部分费用，而不是整张账单。

三年成本与人力

把运行期放到三年，费用可以这样拆：

延伸阅读日志平台迁移：双写、对账和回滚怎么安排→

托管三年成本 = 各月实际计量费用之和
             + 接入与迁移 + 内部配置维护 + 过渡支出

自建三年成本 = 各月基础设施与所需软件/支持费用之和
             + 建设与迁移 + 持续运维 + 过渡支出

双方都需要采集、字段治理和业务告警维护，不能只给自建计入这些共同工作；自建额外承担的容量、版本、故障恢复和存储运行，也不能全部藏在“现有人力”里。员工工资可能已经固定，但同一段时间仍然不能同时交付其他项目。

若第一年用量为基准、之后每年增长 30%，三年的可变用量系数是 12 × (1 + 1.3 + 1.69) = 47.88 个基准月，而不是 36。这个系数可以用于近似线性的使用项，不能直接乘整套自建成本：固定费用与容量台阶需要分别处理。

再看人力的临界值。设同等功能范围下，自建每月资源和支持费为 R，额外运行工时折算为 H；托管完整月费用为 S，自建相比托管额外的一次性投入为 A。忽略增长和差异化过渡费用时，第一年托管更省的条件是：

S < R + H + A / 12

已有平台团队和闲置容量，H 与 A 可能很低，自建更容易划算；业务运维还要临时抽人搭平台，这两项就不能忽略。建设投入通常只发生一次，第二年不再重复计入，运行期的判断可能与第一年不同。

什么时候值得迁走

Datadog 现有能力使用深入，日志是整套排障的一部分，我倾向先优化分层。直接拆走，可能省了索引费，却增加工程师在两套系统之间切换的时间。

日志量大、访问模式清楚、维护人员稳定，而且主要查询容易迁移，OpenObserve 更有成本空间。资源采购之外，查询与告警改造、双写和旧合同费用也计入后，仍然能在可接受时间回本，迁移就有依据。

如果最紧张的是人和交付时间，托管方案也应该进入比较。省下的云资源费不足以支付新增建设与值守，就没有必要坚持自建。

观测云的费用怎么算

观测云提供日志加工、索引、查询和关联调查；在 SaaS 托管部署下，相应后端部署和持续运行由服务方承担，私有部署需另行明确运维责任。采用上述 SaaS 托管时，自建原本计划投入的集群维护可以省去，采集端与业务规则的工作仍然保留。

企业版按实际计量项目计算费用，长期存储的查询范围、索引条件与所需算力也会影响选择。企业版计费、存储策略。

比较时拿同一份摄取字节、事件数、留存和常用查询，分别估算优化后的 Datadog、完整 OpenObserve 自建与观测云。服务费高于单独的机器费，仍有可能低于机器加建设和维护；已有成熟平台，结果也可能相反。这样得到的差额，才是团队实际能够省下的投入。

下载计量示例与计算依据。未填入虚构供应商价格，示例中的 GB 与 GiB 分别标注，合同条款与版本变化后需要重新核算。