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

Team A：Grafana Cloud，月订阅约 $2k（读者自填），2 名 SRE 不全职运维观测栈。Team B：自建 LGTM，机器约 $3k/月 + 0.5 FTE SRE，总 TCO 约 $10k/月（人力按团队月薪自填）。Team B 保留 180 天 Trace、自定义 PromQL、数据不出 VPC。

OpenTelemetry 成熟后，自建不再是超大厂专属——但人力与迁出成本常被低估。本文给 TCO 假设模型与决策矩阵，不列 Datadog/Grafana Cloud/ARMS 单价表（会过期）。成本公式延续 存储与成本；国内商业选项见 中国厂商对比。

一、连续谱，不是二元

flowchart LR
  SaaS[全托管] --> Hybrid[混合]
  Hybrid --> Self[全自建]
  Hybrid --> SaaS

可组合：Metrics 托管 + Logs 自建；Traces 双写；Profile 按需 SaaS。

二、自建 LGTM 架构

2.1 组件对照

中枢：11 OpenTelemetry Collector。

2.2 最小生产拓扑

3× (16 vCPU, 64GB RAM, 500GB SSD) + S3 兼容对象存储
Collector DaemonSet → Distributor → Ingester → Object Store

2.3 人力模型

三、托管架构抽象

托管方承担：升级、多租户隔离、baseline 安全补丁。你承担：埋点规范、埋点哲学、SLO 规则语义。

计费维度通常：Host 数、ingest GB、Active Series、保留期档位——读者向厂商索取计量样例，代入下文公式，不用本文虚构单价。

四、TCO 假设模型

4.1 总公式

\[TCO_{month} = C_{compute} + C_{storage} + C_{network} + C_{human} + C_{overage} + C_{training}\]

与 20-storage-cost §2 一致。

4.2 Scenario A（200 服务 / 5000 Pod）

日增量公式见 20 篇 §2.2–2.3。

4.3 Scenario B（治理后）

4.4 规模临界点（工程判断）

图示见 tco-comparison.svg。

4.5 代入模板

# 读者 worksheet（复制到表格）
C_storage_self = GiB_month × $/GiB-month × retention
C_storage_saas = ingest_GiB_day × 30 × $/GiB-ingest
C_human = FTE × $/month
TCO_self = C_compute + C_storage_self + C_human
TCO_saas = subscription + C_overage

五、五维决策矩阵

计分：≥3 维自建 → LGTM POC；≥3 维托管 → SaaS POC；否则混合。

六、混合与渐进迁移

6.1 Collector fan-out

exporters:
  prometheusremotewrite/mimir:
    endpoint: http://mimir:9009/api/v1/push
  otlphttp/grafana-cloud:
    endpoint: https://otlp-gateway-prod.grafana.net/otlp
service:
  pipelines:
    metrics:
      receivers: [otlp]
      exporters: [prometheusremotewrite/mimir, otlphttp/grafana-cloud]

6.2 迁移阶段

1. 双写 30 天
2. Grafana 数据源并行
3. 告警切自建 Recording Rules
4. 停 SaaS 写入（保留只读备）

反向迁移同理。

七、与治理层联动

• 18-slo：SLI 数据 retention 不可短于 SLO 窗口
• 19-alerting：Alertmanager HA 自建需 3 副本
• 20-storage-cost：降本杠杆顺序
• 21-multi-tenancy：托管多租户 vs Mimir tenant
• 23-china-vendors：国内托管选项

八、自建收益与代价

九、托管收益与代价

十、POC 设计（30 天）

十一、工程坑点

• 签合同前未确认默认保留期，上线后只剩 7 天。
• 未做 Trace 数据量 POC，按量计费后账单失控。
• 以为 OTel 兼容等于可无缝迁出，专有 attribute 未映射。
• 未测迁出 API 吞吐，历史数据导出按月计。
• TCO 只算机器，漏算人力、超额与跨 AZ egress。
• 未记录计量口径，账单争议没有对照证据。
• 自建 Compaction 无告警，查询超时后才发现堆积。

十二、落地清单

• TCO 是否含人力、超额与培训，而不只算机器
• 是否评估 LGTM 与托管成本曲线交叉点
• 是否完成 OTLP 双写与历史数据迁出 POC
• 合同是否写清默认保留期与计量口径

十三、常见误解

十四、系列收束

从 全景 到本篇，可观测性被拆解为：信号分层、数据模型、三大支柱、内核与网络、eBPF、SLO 与告警、成本与多租户、混沌、国内选型、事故剧本、自建决策。下一步回到 系列索引 按路径复习。

十五、关键概念回顾

• TCO = 机器 + 存储 + 网络 + 人力 + 超额 + 培训
• 规模与合规决定曲线交叉点
• OTel Collector 是迁移枢纽
• 用假设模型而非报价表做决策

上一篇：事故复盘剧本

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

参考资料

1. Grafana Labs, LGTM, https://grafana.com/about/lgtm/
2. OpenTelemetry, Collector, https://opentelemetry.io/docs/collector/
3. Google, Site Reliability Workbook, Ch.5
4. 本系列 20-storage-cost
5. 本系列 23-china-vendors
6. Charity Majors et al., Observability Engineering, O’Reilly