2. Prometheus 基础回顾：架构、核心组件与数据模型

在开始模板发布之前，有必要重新梳理 Prometheus 的核心基础。本章将聚焦 Prometheus 的整体架构、三大核心组件（Server、Alertmanager、Pushgateway）以及其独特的数据模型，为后续的采集作业模板设计打下坚实的理论基础。

2.1 Prometheus 整体架构

Prometheus 采用“拉取（Pull）”模式作为主要的指标采集方式，同时支持通过 Pushgateway 接收“推送（Push）”模式的指标。其核心组件围绕指标的生命周期进行设计：采集、存储、查询、告警。

2.2 核心组件详解

Prometheus 生态由多个组件构成，其中 Server、Alertmanager 和 Pushgateway 是三个最核心的组件。下表对比了它们的功能定位与使用场景。

2.2.1 Prometheus Server

Server 是 Prometheus 的大脑，负责所有核心工作。它通过 scrape_configs 定义采集作业，定期从目标端点拉取指标数据，并将其存储在本地的时间序列数据库中。同时，Server 会定期评估 rules 文件中定义的告警规则和记录规则。

global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'node_exporter'
    static_configs:
      - targets: ['localhost:9100']

rule_files:
  - 'alert_rules.yml'
  - 'record_rules.yml'

2.2.2 Alertmanager

Alertmanager 负责处理由 Prometheus Server 推送过来的告警。它不是一个简单的转发器，而是具备强大的告警管理能力：

• 分组（Grouping）：将同一类告警合并为一条通知，避免告警风暴。
• 静默（Silencing）：在维护窗口期屏蔽特定告警。
• 抑制（Inhibition）：当某个高级别告警触发时，自动抑制相关的低级别告警。

2.2.3 Pushgateway

Pushgateway 主要用于解决 Prometheus 无法直接 Pull 的场景。例如，一个运行几分钟的批处理任务，在任务结束时才暴露指标，Server 无法在任务运行期间拉取到数据。此时，任务可以将指标 Push 到 Pushgateway，由 Server 从 Pushgateway 拉取。

2.3 数据模型

Prometheus 的数据模型是其强大查询能力的基础。所有采集到的数据都被存储为时间序列（Time Series），每个时间序列由指标名称（Metric Name）和一组标签（Labels）唯一标识。

2.3.1 指标名称与标签

• 指标名称：用于描述被监控的通用特征，例如 http_requests_total、node_cpu_seconds_total。命名遵循 [a-zA-Z_:][a-zA-Z0-9_:]* 正则规范。
• 标签：键值对形式，用于对指标进行多维度的划分。例如 method="GET"、status="200"、instance="10.0.0.1:9100"。标签是 Prometheus 数据模型的核心，使得查询可以灵活地按任意维度进行聚合。

2.3.2 四种核心指标类型