自建 vs 托管：OpenTelemetry 自建栈与 SaaS 的选型决策

两个真实团队的对比。Team A：Grafana Cloud（Loki + Tempo + Mimir + Grafana 全托管），每月 $2000，2 个 SRE（全职，但不是专门维护可观测性栈），团队规模 8 人。Team B：自建 LGTM 栈（Loki + Grafana + Tempo + Mimir），每月机器 $3000 + 0.5 FTE SRE 人力 = 总成本约 $10000。但 Team B 能跑自定义 PromQL 查询（无 SaaS 限制）、数据不出境（合规）、保留期 6 个月（远超 SaaS 免费版 30 天限制）。

自建 vs 托管不是一个二选一问题——它是一个连续谱。可以 Metrics 托管 + Logs 自建，也可以全部托管 + 关键服务自建并行。OpenTelemetry 的成熟让”渐进式迁移”成为可能——Collector 的 fan-out 能力使数据可以同时写给托管和自建两个后端。

一、自建的典型架构与成本

LGTM 栈（Loki + Grafana + Tempo + Mimir）的最小生产部署：3 节点 K8s 集群，每节点 16 vCPU + 64GB RAM + 500GB SSD + S3 对象存储。机器成本约 $2000–3000/月（按需或预留实例）。

人力成本模型：初始化（选型、搭建、配置、集成到 CI/CD）约 2–4 周。日常维护（升级、扩缩容、处理故障）约 0.3–0.5 FTE。如果专门有一个 SRE 能把维护时间控制在每天 1-2 小时——TCO 中的劳动力成本低于托管方案。

二、托管的典型架构与成本

Grafana Cloud：按 Active Metrics Series + Log/Trace 吞吐量计费。小规模（< 100 节点）通常 $500–2000/月。DataDog：按 Host 数 + Log Retention + Custom Metrics 数计费——中大规模（> 500 节点）时账单很容易过 $10K/月。国内各家：ARMS、AOM、腾讯 APM——通常包含在云服务总账单中，按”探针实例数”或”数据量”计费。

托管的隐性成本：数据超出免费额度的超额费（通常超额部分价格翻倍）、Premium Support 包、数据迁出费（如果你想走）。

三、TCO 对比模型

TCO = 机器/云成本 + 人力成本 + 数据超额/迁出成本 + 培训成本。

规模临界点： - 小规模（< 100 节点）：托管通常更便宜。每月 $500–2000 对绝大多数创业公司来说比养一个 SRE 便宜。 - 中等规模（100–500 节点）：两者成本开始趋近。自建每月 $2000–4000（机器 + 存储 + 0.3 FTE），托管每月 $2000–6000。 - 大规模（> 500 节点）：自建边际成本更低。托管的数据量计费模型在 log/trace 量大时会非线性增长——日志 > 1TB/天 时账单压力显著。

数据量临界点：日志 > 1TB/天 → 托管方案的吃数据量计费模型开始出现非线性增长 → 自建的成本优势出现。Traces > 5B span/天 → 托管方案的价格开始远超同规模的自建 S3 存储。

团队能力权重：如果团队没有懂 Prometheus/Loki/Tempo 运维的人——托管是唯一选项。反过来如果团队已经有一套 K8s 运维经验，LGTM 栈的学习曲线是可控的。

四、混合方案：渐进式自建

不做一个”大跃进”式的移植。先全部托管。等团队中有 1–2 人对可观测性栈有了深入理解（通常是半年到一年后），启动第一个自建组件。OTA Collector 的 fan-out 能力让你可以同时把数据写给 Grafana Cloud 和自建 Loki——双写一段时间，验证自建栈稳定后用 Grafana Data Source 切过去。

迁移是双向的：如果自建栈运维压力太大，随时可以切回托管（前提是你没有销毁托管环境，只是停止了 active 写入）。

五、决策框架：五个问题

1. 数据量有多大？< 1TB/天日志 → 托管更省心。> 10TB/天 → 几乎必然自建。中间地带 → 做 POC 实测。
2. 团队有没有 TSDB 和 Loki/Tempo 运维能力？没有 → 托管。有且想发展 → 自建。
3. 数据出境/合规有没有约束？有 → 自建或国内托管。金融/政企客户 → 自建（数据全部在自有 VPC 内）。
4. 查询需求是否超出 SaaS 限制？需要跑超大范围 PromQL 聚合或自定义 Loki 查询 → 自建。SaaS 通常有查询并发数和查询超时限制。
5. 预算结构？CapEx 友好（一次性投入自建）→ 自建。OpEx 友好（每月的按需付费）→ 托管。

六、关键概念回顾

• TCO = 机器 + 人力 + 数据超额 + 培训。只比较 sticker price 是大错。
• 规模临界点 > 500 节点或 > 1TB/天日志 → 自建边际成本更低。
• 混合方案的渐进迁移：OTA Collector fan-out → 双写 → 验证 → 切数据源。
• OpenTelemetry 是迁移的基石：Collector 让你不需要在第一天就确定最终方案。

七、工程坑点

低估了自建的运维成本。Loki 的 compaction 失败不会自动告警——某天你发现 80% 的查询都超时了，因为 compaction 卡住了导致海量小文件没有被合并。

低估了托管的数据锁定风险。三年后想要迁走——PB 级数据通过 API 导出的速度和成本远超预期。在签合同之前就要测试数据导出通道。

自建和托管同时运行时 Collector 配置过于复杂。一个 fan-out pipeline 配了 8 个后端——任何一个后端变慢都可能拖慢整个 Collector 的数据处理。Pipeline 越简单越好——托管和自建走不同的 Collector 实例。

八、下一步

这是”可观测性工程”系列的最后一篇。从全景概览、信号分层、基数控制、采样策略，到五大支柱的数据模型、日志管道、Traces 栈、eBPF 内核追踪、SLO 工程、告警体系、成本控制、多租户安全、混沌工程、中国厂商对比，再到事故复盘和自建 vs 托管的最终决策——这套 25 篇的系列试图把可观测性从”装几个工具”变成一门可以系统化学习的工程学科。

回到 系列索引 选择你的阅读路径。

回到 全站系列索引 探索其他专题。

上一篇：真实事故复盘剧本：从指标抖动到根因的全链路追查

回到系列索引：可观测性工程

参考资料

1. Grafana Cloud, Pricing, https://grafana.com/pricing/
2. Grafana, LGTM Stack, https://grafana.com/about/lgtm/
3. OpenTelemetry, Collector — Fan-out, https://opentelemetry.io/docs/collector/