2. Kubernetes 集群可观测性栈选型：Prometheus、Thanos、Grafana、Loki、OpenTelemetry 对比与选型
在构建 Kubernetes 集群误差预算台账监控体系时，可观测性栈的选型直接决定了数据采集的完整性、存储的持久性、查询的灵活性以及告警的准确性。本章将围绕 Prometheus、Thanos、Grafana、Loki 和 OpenTelemetry 五个核心组件，从架构定位、功能边界、适用场景三个维度进行系统性对比，并给出面向误差预算场景的推荐选型组合。
2.1 核心组件功能定位与数据流
下图展示了在 Kubernetes 集群中，各可观测性组件之间的数据采集、存储、查询与可视化关系。误差预算台账的数据流从指标（Metrics）、日志（Logs）和链路（Traces）三条路径汇入，最终在 Grafana 仪表盘上呈现 SLO 状态与预算消耗。
2.2 组件对比矩阵
下表从数据模型、存储策略、查询能力、扩展性、社区活跃度及误差预算适配性六个维度，对五个核心组件进行横向对比。
| 维度 | Prometheus | Thanos | Grafana | Loki | OpenTelemetry |
|---|---|---|---|---|---|
| 数据模型 | 时序指标 (Metric + Label) | Prometheus 兼容 + 对象存储 | 仪表盘 / 告警规则 / 数据源抽象 | 日志流 (Stream + Label) | Metrics / Logs / Traces 统一信号 |
| 存储策略 | 本地 TSDB (默认 15d 保留) | 对象存储 (S3/GCS/MinIO) 长期归档 | 无内置存储，依赖数据源 | 对象存储 + 内存缓存 | 无内置存储，依赖后端 (Prometheus/Loki/Tempo) |
| 查询能力 | PromQL (单实例) | PromQL (全局视图 + 降采样) | 多数据源联合查询 / 告警状态 | LogQL (标签 + 全文检索) | OTLP + 多后端转发 |
| 扩展性 | 单机 / 联邦集群 | 水平扩展 (Store/Query/Compactor) | 高可用部署 / 插件扩展 | 水平扩展 (Ingester/Querier) | Collector 水平扩展 / 多协议支持 |
| 社区活跃度 | CNCF 毕业项目，生态核心 | CNCF 毕业项目，广泛生产使用 | CNCF 毕业项目，仪表盘标准 | CNCF 毕业项目，日志标准 | CNCF 孵化项目，增长迅速 |
| 误差预算适配性 | 直接采集 SLO 指标，本地查询 | 长期存储 SLO 历史，跨集群查询 | 可视化预算消耗 / 燃烧率告警 | 关联错误日志与 SLO 降级 | 统一采集标准，避免厂商锁定 |
2.3 选型决策原则
在误差预算台账场景下，选型应遵循以下原则：
- 指标优先：误差预算的核心是 SLO 指标（请求量、错误率、延迟），Prometheus + Thanos 组合是必选底座。
- 日志辅助：当 SLO 降级时，需要快速定位错误日志，Loki 提供低成本、高可用的日志聚合能力。
- 链路可选：对于微服务架构，OpenTelemetry 提供端到端追踪，但初期可暂缓部署，优先保证指标与日志覆盖。
- 统一可视化：Grafana 作为唯一可视化入口，对接 Prometheus/Thanos 和 Loki，实现“一个面板看预算”。
选型建议：对于中小规模集群（节点数 < 50），Prometheus + Grafana + Loki 即可满足需求；对于大规模或多集群场景，必须引入 Thanos 实现全局查询与长期存储，同时使用 OpenTelemetry Collector 统一数据采集格式，避免未来迁移成本。
2.4 组件职责边界与集成关系
下图进一步拆解了各组件在误差预算台账生命周期中的具体职责边界，以及它们之间的集成接口。
2.5 选型决策流程
在实际项目中，可按以下步骤快速完成选型：
- 确定信号类型优先级：误差预算台账以 Metrics 为主，Logs 为辅，Traces 按需引入。
- 评估集群规模与数据量：单集群 < 50 节点且指标量 < 500 万时间序列，Prometheus 单机即可；否则必须引入 Thanos。
- 选择日志方案：如果已有 Elasticsearch 集群且运维成本可接受，可沿用；否则推荐 Loki，因其与 Prometheus 标签体系天然对齐。
- 确定采集标准：新项目直接使用 OpenTelemetry SDK 埋点，存量项目通过 Prometheus 客户端库或 exporter 过渡。
- 统一可视化入口：Grafana 作为唯一前端，对接所有数据源，避免多平台切换。
常见选型陷阱：
- 不要试图用 Prometheus 联邦集群替代 Thanos：联邦集群在跨集群查询、长期存储、降采样方面能力有限，且运维复杂度高。
- 不要忽略日志的标签设计：Loki 的查询性能高度依赖标签基数，错误日志的标签应与 Prometheus 指标标签保持一致（如 service、namespace、error_code）。
- 不要过早引入 OpenTelemetry 链路追踪：链路数据量通常是指标的 10-100 倍，初期应优先保证指标与日志的覆盖率和存储可靠性。
2.6 推荐选型组合
| 场景 | 推荐组合 | 说明 |
|---|---|---|
| 小型集群（< 20 节点） | Prometheus + Grafana + Loki | 单实例 Prometheus 即可满足，Loki 单进程部署，Grafana 对接两个数据源 |
| 中型集群（20-100 节点） | Prometheus + Thanos + Grafana + Loki | Thanos 提供长期存储与全局查询，Loki 水平扩展 |
| 大型多集群（100+ 节点） | OpenTelemetry Collector + Prometheus + Thanos + Grafana + Loki + Tempo | OTel 统一采集，Thanos 跨集群查询，Tempo 链路追踪按需启用 |
| 误差预算台账专用 | Prometheus + Thanos + Grafana | 日志和链路作为辅助，初期可暂不部署，优先保证 SLO 指标的可观测性 |
核心结论：在误差预算台账场景下，Prometheus + Thanos + Grafana 构成不可替代的铁三角。Loki 和 OpenTelemetry 根据团队运维能力和业务复杂度按需引入，但不应在初期阶段同时铺开所有组件，避免运维负担过重导致数据质量下降。