📚 课程目录第4章 Prometheus架构回顾

4. Prometheus 架构回顾：Prometheus Server、Alertmanager、Exporters、Service Monitor 的核心组件与数据流

在深入告警规则与控制面弹性伸缩的适配之前，有必要系统回顾 Prometheus 的核心架构。理解各组件职责及数据流转路径，是后续编写适配性告警规则、设计弹性伸缩策略的基础。

4.1 核心组件一览

Prometheus 生态由四个主要组件构成，它们协同完成指标采集、存储、查询与告警触发。下表总结了各组件的定位与关键特征：

组件	核心职责	关键特征
Prometheus Server	指标拉取、存储、查询、告警评估	基于 Pull 模型；内置时序数据库（TSDB）；支持 PromQL 查询；负责评估告警规则
Alertmanager	告警去重、分组、静默、路由与通知	接收来自 Prometheus Server 的告警；支持多种接收器（Email、PagerDuty、Webhook 等）
Exporters	将非原生指标转换为 Prometheus 格式	运行在被监控目标侧；暴露 /metrics 端点；常见有 node_exporter、kube-state-metrics 等
Service Monitor	定义 Prometheus 如何发现与采集服务指标	Kubernetes CRD；通过标签选择器匹配 Service；指定指标路径与端口

架构要点： Prometheus Server 是核心引擎，Exporters 是数据源头，Service Monitor 是 Kubernetes 环境下的自动发现配置层，Alertmanager 是告警生命周期的管理者。四者缺一不可。

4.2 数据流全景

下图展示了从指标产生到告警通知的完整数据流。箭头方向代表数据或事件的传递方向。

4.3 组件交互细节

4.3.1 Prometheus Server 内部工作流

Prometheus Server 是数据流的核心枢纽，其内部包含多个子模块：

采集管理器（Scrape Manager）：根据配置或服务发现结果，定期向目标端点发起 HTTP 请求，拉取指标数据。
时序数据库（TSDB）：将拉取到的指标按时间序列存储，支持高效压缩与查询。
规则引擎（Rule Engine）：周期性评估告警规则与记录规则，当告警规则表达式结果为 true 时生成告警事件。
查询引擎（Query Engine）：对外提供 PromQL 查询接口，支持即时查询与范围查询。

4.3.2 Alertmanager 告警生命周期

Alertmanager 接收告警后，经历以下处理阶段：

接收与去重：对相同告警名称、标签组合的重复告警进行合并。
分组（Grouping）：按配置的标签（如 severity、cluster）将告警归入同一通知。
静默（Silencing）：匹配静默规则，抑制特定告警的发送。
抑制（Inhibition）：当高优先级告警触发时，抑制低优先级告警。
路由（Routing）：根据告警标签匹配路由树，决定发送到哪个接收器。
通知（Notification）：通过配置的接收器（Email、Webhook、PagerDuty 等）发送告警消息。

  控制面弹性伸缩场景提示： 在控制面弹性伸缩中，Alertmanager 的分组与抑制能力尤为重要。例如，当多个控制面组件同时触发“CPU 过载”告警时，分组可以将它们合并为一条通知，避免告警风暴；抑制规则可以确保在“控制面不可用”告警触发时，抑制所有次级告警。

4.4 Service Monitor 在 Kubernetes 中的角色

Service Monitor 是 Prometheus Operator 引入的 CRD，用于声明式定义指标采集目标。其核心字段包括：

字段	作用	示例值
`spec.selector`	通过标签选择器匹配目标 Service	`app: kube-controller-manager`
`spec.endpoints`	定义指标路径、端口、采集间隔	`port: metrics, path: /metrics`
`spec.namespaceSelector`	限定 Service 所在的命名空间	`matchNames: [kube-system]`

以下是一个典型的 Service Monitor 配置示例：

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: kube-controller-manager
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: kube-controller-manager
  endpoints:
  - port: metrics
    interval: 30s
    path: /metrics
  namespaceSelector:
    matchNames:
    - kube-system

注意： Service Monitor 本身不采集指标，它只是为 Prometheus Server 提供“发现目标”的配置。Prometheus Server 根据 Service Monitor 生成最终的 scrape_config，然后执行拉取操作。在控制面弹性伸缩场景中，Service Monitor 的 interval 字段直接影响告警规则的评估时效性——间隔越短，告警响应越快，但资源消耗也越大。

4.5 数据流总结

将上述组件串联起来，完整的 Prometheus 数据流可以概括为以下步骤：

指标暴露：Exporters 或应用自身在 /metrics 端点暴露 Prometheus 格式指标。
服务发现：Service Monitor（或静态配置）告知 Prometheus Server 哪些目标需要采集。
指标拉取：Prometheus Server 的 Scrape Manager 按周期拉取指标并存入 TSDB。
规则评估：Rule Engine 定期执行告警规则，若条件满足则生成告警事件。
告警推送：Prometheus Server 将告警事件发送到 Alertmanager 的 API。
告警处理：Alertmanager 执行去重、分组、静默、抑制，最终路由到接收器。
通知发送：接收器（如 Webhook）将告警消息送达运维人员或自动化系统。