1. Prometheus 基础入门
1.1 Prometheus 发展史
Prometheus 起源于 2012 年，由前 Google 工程师在 SoundCloud 内部孵化，旨在解决传统监控系统在微服务与容器化场景下的局限性。2015 年项目正式开源，2016 年加入 CNCF（Cloud Native Computing Foundation），成为继 Kubernetes 之后的第二个毕业项目。其设计哲学继承自 Google 内部监控系统 Borgmon，强调“拉取（Pull）”模型、多维数据模型与强大的 PromQL 查询语言。
关键里程碑： 2012 年内部诞生 → 2015 年开源 → 2016 年加入 CNCF → 2018 年毕业 → 2020 年成为 CNCF 生态中部署最广泛的监控项目之一。
1.2 核心特性
Prometheus 的核心特性围绕“时间序列数据库 + 主动拉取 + 多维标签”展开，使其在云原生环境中具备天然优势：
- 多维数据模型： 每个时间序列由指标名称和一组键值对标签唯一标识，支持灵活的聚合与过滤。
- PromQL 查询语言： 提供丰富的函数、操作符与聚合能力，支持实时计算与历史回溯。
- 主动拉取（Pull）模式： Server 定期从目标端点抓取指标，降低被监控系统的耦合度。
- 服务发现： 原生支持 Kubernetes、Consul、DNS 等动态发现机制，适应弹性伸缩环境。
- 告警与通知： 通过 Alertmanager 实现告警分组、抑制、静默与多渠道推送。
- 高效存储： 本地存储采用自定义时间序列格式，支持压缩与数据保留策略。
运维提示： Prometheus 的 Pull 模式要求 Server 能够直接访问目标端点，在跨网络隔离或防火墙场景下，可借助 Pushgateway 作为中间代理。
1.3 架构组件
Prometheus 生态由多个独立组件构成，各组件职责清晰，协同完成数据采集、存储、查询与告警。下图展示了核心架构与数据流：
1.4 与 Zabbix / Graphite 对比
传统监控系统（Zabbix）与早期时间序列方案（Graphite）在架构设计、数据模型与扩展性上与 Prometheus 存在显著差异。下表从多个维度进行对比：
| 对比维度 | Prometheus | Zabbix | Graphite |
|---|---|---|---|
| 数据模型 | 多维标签 + 指标名称 | 扁平键值对 | 层级路径（点分隔） |
| 采集模式 | 主动拉取（Pull） | 主动推送（Push） | 被动接收（Push） |
| 查询语言 | PromQL（强大灵活） | 内置表达式（有限） | 简单函数（有限） |
| 服务发现 | 原生支持（K8s/Consul） | 需手动配置或脚本 | 不支持 |
| 告警能力 | Alertmanager（分组/抑制） | 内置告警（触发器） | 需第三方集成 |
| 存储扩展 | 本地 + 远程读写（Thanos/Cortex） | 数据库后端（MySQL/Elasticsearch） | Whisper 文件（单机） |
| 适用场景 | 云原生、微服务、容器 | 传统 IT 基础设施、网络设备 | 时间序列可视化、轻量场景 |
选型建议： 若监控环境以 Kubernetes 和微服务为主，Prometheus 是首选；若以传统物理机、网络设备或 SNMP 为主，Zabbix 生态更成熟；Graphite 适合作为时间序列存储后端，但缺乏告警与服务发现能力。
1.5 核心组件交互流程
下图进一步细化 Prometheus Server 内部组件之间的交互关系，帮助理解数据从采集到存储再到查询的完整链路：