3. 误差预算台账架构设计：数据采集层、存储层、计算层、展示层分层架构
误差预算台账并非单一组件，而是一个端到端的数据处理管道。为了保障高可用、可扩展与低延迟，我们采用经典的四层分层架构：数据采集层、存储层、计算层与展示层。每一层职责清晰，层间通过标准协议解耦，便于独立扩缩容与故障隔离。
架构设计原则： 采集层无状态可水平扩展；存储层采用时序数据库与对象存储冷热分离；计算层基于流批一体引擎；展示层支持多租户与自定义仪表盘。
3.1 数据采集层
采集层负责从 Kubernetes 集群、中间件、网关及业务应用中拉取或推送 SLO 相关指标。核心指标包括：请求总量、错误量、延迟分布、饱和度等。
| 采集方式 | 适用场景 | 典型组件 | 协议/格式 |
|---|---|---|---|
| Pull 模式 | Kubernetes 原生指标、ServiceMonitor | Prometheus Server / Thanos Sidecar | Prometheus HTTP / protobuf |
| Push 模式 | 短生命周期任务、批处理作业 | Prometheus Pushgateway / OpenTelemetry Collector | OTLP / Prometheus Remote Write |
| 日志提取 | 业务日志中的错误率、延迟 | Fluentd / Logstash / Vector | JSON / Regex 解析 |
| 云厂商 API | 托管服务 (ALB / RDS / API Gateway) | CloudWatch Exporter / Azure Monitor Exporter | HTTP / gRPC |
避坑提示： 避免采集层单点故障。Prometheus 应部署为 StatefulSet 并配置至少 2 副本；Thanos Sidecar 与 Prometheus 同 Pod 部署，确保数据实时上传至对象存储。
3.2 存储层
存储层需要同时满足高写入吞吐与长时间历史查询。我们采用热存储 + 冷存储分层策略：
- 热存储： 保留最近 7~30 天的原始指标数据，使用 Thanos Receive 或 VictoriaMetrics 集群，支持毫秒级查询。
- 冷存储： 超过 30 天的数据压缩后存入对象存储（S3 / GCS / MinIO），通过 Thanos Store Gateway 按需加载。
- 元数据索引： 使用 Cassandra 或 PostgreSQL 记录数据分片位置与时间范围，加速冷数据检索。
| 存储组件 | 热/冷 | 压缩率 | 查询延迟 | 成本 |
|---|---|---|---|---|
| VictoriaMetrics 单节点 | 热 | ~10x | < 10ms | 中 |
| Thanos Receive + Store | 热 | ~5x | < 50ms | 中高 |
| S3 / GCS (Parquet) | 冷 | ~20x | ~1-5s | 低 |
3.3 计算层
计算层是误差预算台账的核心大脑，负责将原始指标转换为 SLO 状态、燃烧速率、误差预算消耗率等衍生指标。计算分为实时流计算与离线批计算两条路径：
关键计算逻辑：
当 burn_rate > 1 持续 1 小时，触发多级告警。
error_budget_consumed = (1 - (good_events / total_events)) * 100%burn_rate = error_budget_consumed / window_hours当 burn_rate > 1 持续 1 小时，触发多级告警。
3.4 展示层
展示层面向不同角色提供差异化的视图：
- SRE 团队： Grafana 仪表盘，展示实时燃烧速率、误差预算剩余百分比、SLO 状态热力图。
- 业务 Owner： 简化版 Web Dashboard，展示月度 SLO 达成率、趋势线、预算消耗日历。
- 告警通知： 通过 Alertmanager 路由至 PagerDuty / Slack / 钉钉，附带燃烧速率与预估剩余时间。
| 展示组件 | 数据源 | 刷新频率 | 典型面板 |
|---|---|---|---|
| Grafana | Prometheus / Thanos | 30s | SLO 状态、燃烧速率、错误预算柱状图 |
| 自定义 Web App | PostgreSQL (台账结果表) | 1min | 月度达成率、团队排名、历史趋势 |
| Alertmanager | Prometheus 告警规则 | 实时 | 燃烧速率告警、预算耗尽预估 |
注意： 展示层应避免直接查询原始指标存储，而是读取计算层产出的台账结果表，以降低查询压力并保证数据一致性。台账结果表建议每 5 分钟更新一次。
3.5 层间数据流与契约
各层之间通过明确的接口契约交互，确保解耦与可替换性：
- 采集层 → 存储层： Prometheus Remote Write 协议，指标带 SLO 标签（
slo_name、window）。 - 存储层 → 计算层： PromQL 查询接口，计算层按固定时间窗口拉取聚合数据。
- 计算层 → 展示层： 写入 PostgreSQL / MySQL 台账表，展示层通过 SQL 或 REST API 读取。