📚 课程目录第4章监控数据采集

4. 监控数据采集：Prometheus 架构与指标抓取、Exporter 部署、数据存储与查询基础

在 On-Call 自动化故障排查体系中，监控数据采集是感知系统状态的第一环。Prometheus 作为云原生监控的事实标准，其 Pull 模型、多维数据模型和强大的 PromQL 查询语言，为值班基线核验提供了实时、可靠的数据基础。本节将深入剖析 Prometheus 的架构设计、指标抓取机制、Exporter 部署策略以及数据存储与查询的核心原理。

4.1 Prometheus 整体架构与核心组件

Prometheus 采用 Pull（拉取） 模式主动从目标端点采集指标，区别于传统的 Push（推送）模式。这种设计使得监控系统对目标实例的状态感知更加主动，且易于水平扩展。其核心架构由以下组件构成：

  架构核心要点： Prometheus Server 通过服务发现或静态配置，定期向各 Exporter 或应用实例的 /metrics 端点发起 HTTP 请求，拉取指标数据并存入本地时序数据库（TSDB）。Alertmanager 负责处理告警，Grafana 等工具用于可视化。

4.2 指标抓取机制与 /metrics 端点

Prometheus 通过 HTTP 协议定期访问目标实例的 /metrics 端点来获取指标数据。每次抓取（Scrape）是一个完整的 HTTP GET 请求，返回的响应体为纯文本格式，遵循 Prometheus exposition 格式。

4.2.1 抓取生命周期

服务发现： Prometheus 根据配置（如 Kubernetes 服务发现、Consul、文件发现）动态获取目标列表。
目标实例化： 对每个目标生成一个 target 对象，包含地址、标签、抓取间隔等信息。
HTTP 请求： 向 <host>:<port>/metrics 发起 GET 请求，超时时间默认 10s。
数据解析： 解析返回的文本，提取指标名称、标签集合和样本值。
样本存储： 将解析后的样本追加到 TSDB 的当前块中。

4.2.2 指标类型

类型	说明	典型场景
Counter	只增不减的计数器，重启归零	请求总数、错误总数
Gauge	可增可减的瞬时值	CPU 使用率、内存使用量
Histogram	对观测值进行分桶统计	请求延迟分布、响应大小
Summary	类似 Histogram，但计算分位数	请求延迟的 p99 值

On-Call 实战提示： 在故障排查时，优先关注 Gauge 类型指标（如内存、磁盘）的突增或突降，以及 Counter 类型指标（如错误计数）的速率变化。使用 rate() 函数将 Counter 转换为每秒速率，避免因重启导致误判。

4.3 Exporter 部署与配置

Exporter 是 Prometheus 生态中负责采集第三方系统指标并暴露为 /metrics 端点的代理程序。对于无法直接修改的应用，Exporter 是接入监控的唯一方式。

4.3.1 常用 Exporter 清单

Exporter 名称	采集目标	默认端口	关键指标示例
node_exporter	Linux/Windows 主机	9100	node_cpu_seconds_total, node_memory_MemAvailable_bytes
mysqld_exporter	MySQL 数据库	9104	mysql_global_status_threads_connected, mysql_global_status_queries
nginx_exporter	Nginx 状态页	9113	nginx_connections_active, nginx_http_requests_total
blackbox_exporter	HTTP/HTTPS/TCP/ICMP 探测	9115	probe_success, probe_duration_seconds
kube-state-metrics	Kubernetes 对象状态	8080	kube_deployment_status_replicas_available

4.3.2 部署示例：Node Exporter

以下为在 Linux 主机上部署 Node Exporter 的标准步骤：

# 1. 下载并解压
wget https://github.com/prometheus/node_exporter/releases/download/v1.7.0/node_exporter-1.7.0.linux-amd64.tar.gz
tar xvf node_exporter-1.7.0.linux-amd64.tar.gz

# 2. 启动（默认监听 0.0.0.0:9100）
cd node_exporter-1.7.0.linux-amd64
./node_exporter --web.listen-address=":9100" --path.procfs=/host/proc --path.sysfs=/host/sys

# 3. 验证指标端点
curl http://localhost:9100/metrics | head -20

安全注意事项： Exporter 默认不开启认证和加密。在生产环境中，应通过反向代理（如 Nginx）添加 Basic Auth 或 HTTPS，或使用 Prometheus 的 basic_auth 配置。避免将 Exporter 端口直接暴露到公网。

4.4 数据存储：本地 TSDB 原理

Prometheus 的本地时序数据库（TSDB）是其核心存储引擎，专为高写入吞吐和高效查询设计。理解其存储原理有助于优化查询性能和规划数据保留策略。

4.4.1 存储结构

Block（块）： 数据按时间窗口（默认 2 小时）切分为独立的块。每个块包含该时间段内的所有样本数据、索引和元数据。
WAL（Write-Ahead Log）： 在数据写入块之前，先写入 WAL 以保证崩溃恢复。WAL 中的数据在块落盘后会被清理。
Compaction（压缩）： 后台定期将多个小块合并为更大的块（如 10 小时、1 天），减少文件数量并删除已删除的样本。
Retention（保留）： 根据配置的保留时间（默认 15 天），自动删除过期的块。

4.5 数据查询基础：PromQL 入门

PromQL（Prometheus Query Language）是查询 Prometheus 数据的核心语言。掌握 PromQL 是 On-Call 工程师进行故障定位和值班基线核验的必备技能。

4.5.1 查询类型

类型	语法示例	返回结果	用途
瞬时查询	`node_memory_MemAvailable_bytes`	当前时刻的单个值	查看当前内存可用量
范围查询	`node_memory_MemAvailable_bytes[5m]`	过去 5 分钟的一组值	分析内存变化趋势
聚合查询	`avg(rate(cpu_seconds_total[1m])) by (instance)`	按实例聚合后的值	查看各主机的平均 CPU 使用率

4.5.2 常用函数

rate()： 计算 Counter 类型指标在指定时间窗口内的每秒平均增长率。例如：rate(http_requests_total[5m])。
irate()： 计算 Counter 的瞬时增长率，基于最后两个样本点，对短期突增更敏感。
increase()： 计算 Counter 在指定时间窗口内的增量。例如：increase(errors_total[1h])。
avg_over_time()： 计算 Gauge 指标在指定时间窗口内的平均值，用于平滑噪声。

4.5.3 值班基线核验查询示例

以下查询用于快速核验主机是否处于正常状态：

# 1. 核验 CPU 使用率是否超过 80%
(1 - avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance)) > 0.8

# 2. 核验内存可用率是否低于 10%
node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes < 0.1

# 3. 核验磁盘根分区使用率是否超过 90%
(node_filesystem_size_bytes{mountpoint="/"} - node_filesystem_free_bytes{mountpoint="/"}) 
/ node_filesystem_size_bytes{mountpoint="/"} > 0.9

# 4. 核验 MySQL 连接数是否接近上限
mysql_global_status_threads_connected / mysql_global_variables_max_connections > 0.8

  On-Call 自动化集成： 上述 PromQL 查询可直接嵌入告警规则（Alertmanager）或自动化故障排查脚本中。当查询返回非空结果（即存在异常实例）时，触发告警或自动执行预定义的排查步骤，如 SSH 登录收集日志、重启服务等。

4.6 本章小结

本章系统梳理了 Prometheus 监控数据采集的完整链路：从架构组件、指标抓取机制，到 Exporter 部署实践，再到 TSDB 存储原理和 PromQL 查询基础。掌握这些知识，SRE 工程师能够独立完成监控系统的搭建与数据采集，并为后续的告警配置、故障定位和自动化运维打下坚实基础。在 On-Call 场景中，快速准确地查询指标是缩短故障恢复时间（MTTR）的关键能力。