1. 课程导论与工程背景
1.1 跨集群调度场景下的监控挑战
现代企业 IT 架构正加速向混合云与多云演进，Kubernetes 集群数量从个位数增长到数十甚至上百个。跨集群调度（Cross-Cluster Scheduling）成为资源弹性、地域容灾与成本优化的关键手段，但同时也给监控体系带来了前所未有的复杂性。
核心痛点： 传统单集群 Prometheus 架构在跨集群场景下存在数据孤岛、标签冲突、时间线膨胀三大难题，导致故障定位从“分钟级”退化到“小时级”。
跨集群调度场景下的监控挑战可归纳为以下四个维度：
| 维度 | 具体挑战 | 典型表现 |
|---|---|---|
| 数据一致性 | 各集群指标采集频率、保留周期、标签命名规范不统一 | 同一业务在不同集群的 CPU 使用率指标名不同，导致聚合查询失败 |
| 网络可达性 | 跨 VPC/Region 的 Prometheus 实例间存在防火墙、NAT 网关限制 | 联邦集群（Federation）拉取超时，指标数据丢失 |
| 时间线膨胀 | 跨集群调度导致 Pod 频繁迁移，产生大量孤儿时间序列 | 单个业务 Pod 在 24 小时内产生 300+ 条不同 instance 标签的时间线 |
| 告警风暴 | 全局告警规则在多个集群重复触发，缺乏去重与聚合机制 | 一次节点故障引发 5000+ 条重复告警，淹没关键通知 |
工程教训： 某金融科技公司在迁移至 3 个公有云 + 2 个私有云的混合架构后，因未提前设计跨集群监控方案，导致一次跨集群调度故障的排查耗时 8 小时，其中 6 小时花在数据对齐与指标溯源上。
1.2 Prometheus 在混合云/多云架构中的定位
Prometheus 作为 CNCF 毕业的监控项目，凭借其拉取模型、多维数据模型和强大的 PromQL，已成为云原生监控的事实标准。在混合云/多云架构中，Prometheus 的定位从“单集群监控工具”演变为“多集群可观测性数据平面”的核心组件。
其架构定位包含三个关键层次：
- 数据采集层： 每个 Kubernetes 集群内部署独立的 Prometheus Server，负责本集群的指标采集与短期存储，保证故障隔离。
- 数据聚合层： 通过 Thanos / VictoriaMetrics 等兼容方案实现全局视图，解决 Prometheus 无内置全局查询的问题。
- 数据消费层： 基于全局指标数据构建统一告警、容量规划与成本分析平台。
1.3 课程目标与案例总览
本课程以工程实战为导向，围绕“跨集群调度故障”这一核心场景，系统讲解 Prometheus 监控体系的设计、部署与排障方法。课程覆盖从单集群到多集群的演进路径，重点解决以下工程问题：
- 如何设计 可跨集群扩展的 Prometheus 采集架构？
- 如何配置 全局告警规则并避免告警风暴？
- 如何排查 跨集群调度导致的指标丢失与时间线膨胀？
- 如何构建 基于 Thanos / VictoriaMetrics 的全局可观测性平台？
课程共包含 30 个章节，按知识递进分为四大模块：
| 模块 | 章节范围 | 核心内容 |
|---|---|---|
| 基础篇 | 第 1-6 章 | 跨集群监控挑战、Prometheus 架构演进、指标设计规范 |
| 架构篇 | 第 7-14 章 | Thanos 部署、VictoriaMetrics 集群、全局查询与告警 |
| 实战篇 | 第 15-24 章 | 跨集群调度故障模拟、指标丢失排查、时间线优化 |
| 进阶篇 | 第 25-30 章 | 成本控制、SLO 工程、混沌工程与持续改进 |
学习建议： 建议读者具备基本的 Kubernetes 与 Prometheus 操作经验。每章均提供可复现的故障场景与排查步骤，建议在实验环境中跟随操作以获得最佳效果。