1. Prometheus 架构总览：核心组件及其资源消耗角色
在深入资源配额与性能优化之前，必须首先理解 Prometheus 的整体架构。每个核心组件在数据采集、存储、告警和转发链路中承担不同职责，其资源消耗模式也截然不同。本章将逐一拆解 Prometheus Server、TSDB、Alertmanager 和 Pushgateway 的功能定位与资源特征。
1.1 核心组件功能矩阵
| 组件 | 核心职责 | 资源消耗主要来源 | 优化关注点 |
|---|---|---|---|
| Prometheus Server | 指标抓取、规则评估、查询服务 | CPU（解析/计算）、内存（缓存/索引）、网络（抓取） | 抓取并发、规则复杂度、查询超时 |
| TSDB | 时序数据存储、压缩、保留 | 磁盘 I/O（写入/压缩）、内存（WAL/缓存）、CPU（压缩） | 样本写入速率、块压缩策略、保留周期 |
| Alertmanager | 告警去重、分组、静默、路由 | 内存（告警状态）、CPU（模板渲染）、网络（通知） | 告警数量、分组窗口、通知后端 |
| Pushgateway | 接收短任务/批处理推送的指标 | 内存（累积指标）、网络（推送/拉取） | 指标过期清理、推送频率 |
1.2 架构数据流与资源消耗链路
下图展示了 Prometheus 各组件之间的数据流向，以及每个环节对系统资源的典型影响。理解这条链路是后续配额规划的基础。
1.3 各组件资源消耗深度解析
1.3.1 Prometheus Server — 调度与计算核心
Prometheus Server 是资源消耗的主力，其资源占用主要分布在以下三个子系统中：
- 抓取调度器（Scrape Manager）：负责按配置的间隔和并发度拉取目标指标。每个抓取目标消耗一个 goroutine，抓取响应体越大、目标越多，CPU 和内存开销越高。
- 规则评估引擎（Rule Manager）：周期性执行记录规则和告警规则。复杂 PromQL 表达式（如大量聚合、范围向量）会显著增加 CPU 和临时内存分配。
- 查询服务（Query Engine）：处理来自 UI、API 或 Grafana 的即时查询和范围查询。高并发查询或大时间范围查询会大量消耗内存和 CPU。
关键指标速查：
prometheus_target_interval_length_seconds— 实际抓取间隔与配置间隔的偏差prometheus_rule_evaluation_duration_seconds— 规则评估耗时prometheus_engine_query_duration_seconds— 查询耗时分布
1.3.2 TSDB — 存储与压缩引擎
TSDB 是磁盘和内存资源的主要消费者。其内部工作流程决定了资源消耗模式：
- WAL 写入：所有样本先写入预写日志（WAL），产生顺序磁盘 I/O。写入速率越高，磁盘带宽需求越大。
- 内存缓存：最近写入的样本在内存中暂存，用于加速查询。内存占用与
--storage.tsdb.retention.time和样本基数正相关。 - 块压缩：后台 goroutine 将内存中的块压缩为不可变块，压缩过程消耗 CPU 和临时磁盘空间。
- 保留删除：超过保留期的块被删除，产生 I/O 开销。
| TSDB 操作 | 资源类型 | 典型瓶颈 | 优化方向 |
|---|---|---|---|
| WAL 写入 | 磁盘 I/O | 磁盘吞吐 | 使用 SSD、调整 WAL 段大小 |
| 内存缓存 | 内存 | 基数过高 | 减少标签基数、降低保留时间 |
| 块压缩 | CPU + 磁盘 | 压缩并发 | 调整 --storage.tsdb.max-block-duration |
| 保留删除 | 磁盘 I/O | 删除频率 | 合理设置保留周期 |
1.3.3 Alertmanager — 告警状态与通知
Alertmanager 的资源消耗通常低于 Server 和 TSDB，但在大规模告警场景下仍需关注：
- 告警状态内存：所有活跃告警和已解决告警（在配置的保留期内）都保存在内存中。告警数量越多，内存占用越高。
- 分组与去重：对告警进行标签分组和去重需要 CPU 计算，分组窗口越大，CPU 开销越高。
- 通知发送：向邮件、PagerDuty、Slack 等后端发送通知时，网络 I/O 和模板渲染是主要开销。
避坑提示： 避免在 Alertmanager 中配置大量高频率的告警规则。建议在 Prometheus Server 侧通过 alertmanager_config 的 group_wait 和 group_interval 参数控制告警聚合节奏，减少 Alertmanager 的瞬时压力。
1.3.4 Pushgateway — 短任务指标暂存
Pushgateway 用于接收无法被直接拉取的短任务（如批处理作业、CronJob）的指标。其资源消耗特征如下：
- 内存累积：Pushgateway 默认不会自动清理过期指标，所有推送的指标会一直驻留在内存中，直到被 Prometheus Server 拉取或手动删除。长期累积会导致内存泄漏式增长。
- 网络接收：每次推送都会产生 HTTP 请求，推送频率越高，网络和 CPU 开销越大。
警告： Pushgateway 是资源管理的常见盲区。务必设置 --pushgateway.retention 参数或通过 pushgateway_metrics_total 指标监控其内存增长。对于高频推送场景，建议评估是否可以直接使用 Prometheus Server 的拉取模式。
1.4 组件资源消耗对比总览
下表从四个维度对比各组件在典型生产环境中的资源消耗特征，帮助你在容量规划时快速定位重点：
| 组件 | CPU 敏感度 | 内存敏感度 | 磁盘 I/O 敏感度 | 网络敏感度 |
|---|---|---|---|---|
| Prometheus Server | 高（规则评估、查询） | 高（缓存、索引） | 中（WAL 写入） | 高（抓取） |
| TSDB | 中（压缩） | 高（内存缓存） | 高（写入、压缩、删除） | 低 |
| Alertmanager | 中（分组、模板） | 中（告警状态） | 低 | 中（通知） |
| Pushgateway | 低 | 高（累积指标） | 低 | 中（推送接收） |