Prometheus

Prometheus 是一个开源的监控系统与时序数据库，由 SoundCloud 工程师于 2012 年开发，2016 年成为继 Kubernetes 之后第二个加入 CNCF（云原生计算基金会）的项目，并于 2018 年正式从孵化阶段毕业，跻身 CNCF 顶级项目行列。其核心设计哲学是基于拉取式（Pull）的指标采集模式，Prometheus Server 主动从被监控目标抓取指标数据，配合专为时序数据设计的 PromQL 查询语言，构成了当今云原生可观测性体系中最重要的基础设施组件之一。

发展背景与设计哲学

在 Prometheus 诞生之前，传统监控系统（如 Nagios、Zabbix）主要采用推送模式，被监控端主动上报数据，配置复杂且难以适应容器与微服务架构下服务实例频繁变化的动态场景。SoundCloud 受 Google 内部监控系统 Borgmon 的架构启发，设计了以时序数据为核心存储单元、以标签（Label）键值对区分多维度的数据模型，这一设计极好地契合了容器化、服务网格与弹性伸缩环境的监控需求。Prometheus 的生态系统包含 Prometheus Server、Alertmanager、各类 Exporter 采集器、Pushgateway 以及多语言客户端库，各组件职责清晰、松耦合组合，共同构成完整的监控闭环。该项目目前由来自 Grafana Labs、Red Hat、Google 等公司的开发者联合维护，保持着活跃的版本迭代节奏与完善的文档体系。

核心概念与指标类型

• 四种指标类型：Prometheus 定义了四种语义明确的指标类型：Counter（单调递增计数器，如 HTTP 请求总数、错误总数，重启后归零）；Gauge（可任意增减的瞬时值，如当前内存占用、在线用户数、温度）；Histogram（将观测值分配到预定义分桶中，同时记录总和与计数，适合延迟分布统计）；Summary（在客户端预计算指定百分位数，适合高精度分位统计但不可跨实例聚合）。
• 标签（Labels）与多维度模型：每条时序由指标名称加一组键值标签唯一标识，例如 http_requests_total{method=POST, status=200, service=api} 是一条独立的时序。标签是 Prometheus 多维分析的核心机制，支持按环境、服务名、实例、区域等维度灵活聚合与筛选。
• PromQL 查询语言：专为时序数据设计的函数式查询语言，支持瞬时向量选择、区间向量选择（用于 rate/increase 等函数）、标量运算、聚合函数（sum、avg、max、min、topk、histogram_quantile 等），可构造从简单阈值判断到复杂 SLO 计算的各类查询表达式。
• Recording Rules（记录规则）：将高频执行的复杂 PromQL 表达式预计算后保存为新的时序序列，以空间换时间，显著降低仪表盘在查询海量历史数据时的延迟，同时减轻 Prometheus Server 的实时计算压力。
• Alerting Rules（告警规则）：基于 PromQL 条件持续评估，满足条件时向 Alertmanager 发送告警通知；for 子句实现告警防抖，要求条件持续满足一段时间后才真正触发，有效减少因短暂波动引发的误报告警。

存储引擎与技术架构

Prometheus Server 内置 TSDB（时序数据库）引擎，采用面向列存储的压缩格式，数据按约两小时时间窗口写入不可变的数据块（Block）。每个 Block 目录包含四个组成部分：chunks（压缩后的时序样本数据）、index（标签到序列的倒排索引，支持高效标签匹配）、tombstones（逻辑删除标记，记录待物理清理的时间范围）与 meta.json（Block 的元数据描述文件）。内存中正在写入的活跃数据通过 WAL（预写日志）机制保证崩溃后可恢复，WAL 文件存储在数据目录下的 wal/ 子目录中，是恢复最近未落盘数据的唯一依据。

核心配置文件 prometheus.yml 是 Prometheus 行为的中枢，主要包含：

• scrape_interval：全局默认采集间隔，生产环境常见配置为 15 秒或 30 秒，可在单个 scrape_config 中覆盖以针对不同采集目标差异化配置。
• evaluation_interval：告警规则与记录规则的评估频率，通常与 scrape_interval 保持一致，确保规则评估基于最新采集数据。
• scrape_configs：定义采集目标列表，支持静态配置与多种服务发现机制，包括 Kubernetes、Consul、EC2、DNS、文件等，实现目标的动态发现与自动注册。
• remote_write：将本地采集的时序数据实时写往外部长期存储系统，如 Thanos、VictoriaMetrics 或 Grafana Mimir，突破本地磁盘容量限制，支持数据的长期归档。

Alertmanager 告警路由体系

Alertmanager 是 Prometheus 生态中独立运行的告警处理组件，负责接收来自 Prometheus 的原始告警，并进行去重、分组、路由与多渠道通知。其路由树（Route Tree）通过标签匹配将不同类型的告警分发到对应的接收者（Receiver），支持电子邮件、Slack、PagerDuty、OpsGenie、Webhook 等主流通知渠道。抑制（Inhibition）规则可在高优先级告警激活时自动抑制关联的低优先级告警，避免基础设施故障引发的级联告警风暴淹没运维人员的注意力。静默（Silence）功能允许在已知的计划维护时间窗口内临时屏蔽特定告警，减少维护期间的无效通知干扰。

生态系统与部署方案

• Exporter 采集器生态：Node Exporter（主机系统指标）、Blackbox Exporter（HTTP/TCP/ICMP 端点探测）、MySQL Exporter、PostgreSQL Exporter、Redis Exporter、JMX Exporter（Java 应用）等官方与社区 Exporter，覆盖几乎所有主流基础设施组件与中间件，实现开箱即用的指标采集。
• Pushgateway 批处理支持：专为短生命周期的批处理任务（如 Cron Job）设计，任务执行完成后主动推送指标到 Pushgateway，由 Prometheus 定期从 Pushgateway 抓取，实现对无法持续暴露 HTTP 端点服务的指标采集。
• kube-prometheus-stack：基于 Helm 的 Kubernetes 监控一体化解决方案，集成 Prometheus Operator、Alertmanager、Grafana 与预置的 Kubernetes 监控仪表盘，是 Kubernetes 集群可观测性建设的首选部署方案。
• Federation 联邦架构：允许上层聚合 Prometheus 从下层各区域 Prometheus拉取经过聚合的部分时序序列，实现多数据中心指标数据的层级汇总，在保持本地细粒度监控的同时支持全局视图的构建。

典型使用场景

• Kubernetes 集群全栈监控：采集 kubelet、kube-apiserver、etcd、kube-scheduler 等核心组件指标，配合 Grafana 仪表盘实现集群资源使用、工作负载健康度与 API 调用延迟的全景视图，是 K8s 运维不可缺少的基础能力。
• SLO 服务水平目标追踪：基于 Histogram 计算 P95、P99 请求延迟，结合错误率指标构建 Error Budget 燃尽图，实现对服务可用性承诺的量化监控与预警。
• 容量规划与趋势分析：通过分析历史时序数据的增长趋势，预测服务器、数据库与网络资源的消耗走向，提前制定扩容或优化方案，避免容量危机。

常见陷阱与注意事项

• 高基数标签问题：若将用户 ID、完整 URL 路径或随机生成的 Trace ID 等高唯一性字段作为标签值，时序数量会指数级爆炸，导致 Prometheus Server 内存急剧消耗直至 OOM，这是 Prometheus 生产部署中最常见的致命性配置错误，设计指标时须严格控制标签的基数上限。
• 本地存储容量限制：Prometheus 本地 TSDB 默认仅保留 15 天的历史数据，不适合长期历史数据的归档查询，需要长期存储的场景须配置 remote_write接入 Thanos、VictoriaMetrics 或 Cortex 等外部长期存储方案。
• 高可用部署：Prometheus 本身不内置高可用机制，生产环境通常部署两个配置完全相同的独立 Prometheus 实例同时采集相同目标，再由 Thanos Query 或 Grafana 层进行数据聚合与去重，实现查询层的高可用。