当前位置：首页 > news >正文

Prometheus详解

news 2025/11/2 15:18:40

Prometheus 是一套开源的监控与时间序列数据（Time-Series Data）分析系统，核心用于收集、存储、查询和分析分布式系统的指标（如服务响应时间、CPU 使用率、请求量等），广泛应用于微服务、云原生、K8s 等场景。其用法需围绕 “组件协作” 和 “核心流程” 展开，以下从核心组件、核心用法（数据流转）、关键操作、典型场景四个维度系统总结：

一、先理清：Prometheus 的核心组件

Prometheus 不是单一工具，而是由多个组件构成的生态系统，各组件分工明确，需配合使用才能实现完整监控。

组件名称	核心功能	角色定位
Prometheus Server	1. 核心：负责从目标（Targets）拉取指标数据；2. 存储：将指标以时间序列格式存本地（TSDB）；3. 查询：提供 PromQL 语言查询指标。	系统 “中枢”（数据采集 + 存储 + 查询）
Exporters	1. 采集 “非 Prometheus 原生” 目标的指标（如 MySQL、Linux 主机、Redis）；2. 将指标转换为 Prometheus 能识别的格式，暴露在 HTTP 接口（通常是 `/metrics`）。	数据 “采集器”（对接第三方系统）
Alertmanager	1. 接收 Prometheus Server 发送的告警规则触发信号；2. 处理告警：去重、分组、路由（如转发到邮件、钉钉、Slack）、抑制（避免重复告警）。	告警 “处理器”
Grafana	1. 对接 Prometheus 等数据源；2. 通过可视化面板（Dashboard）展示指标（如折线图、柱状图、仪表盘）；3. 支持交互式查询和报表导出。	数据 “可视化工具”（非 Prometheus 官方组件，但强绑定）
Pushgateway	1. 接收 “短生命周期任务”（如定时脚本、一次性任务）主动推送的指标；2. 暂存指标，等待 Prometheus Server 拉取（解决短任务无法被 “拉取” 的问题）。	数据 “中转站”（适配推送场景）

二、核心用法：Prometheus 数据流转全流程

Prometheus 的核心逻辑是 “拉取式采集（Pull） ”，即 Prometheus Server 主动从目标（Targets）获取指标，整个流程分 5 步，是用法的核心框架：

1. 第一步：指标采集（Exporters / 原生埋点）

首先需要让监控目标 “产生可被 Prometheus 识别的指标”，有两种方式：

方式 1：用 Exporters 采集第三方系统（最常用）针对 MySQL、Linux 主机、Redis、K8s 等非原生系统，直接部署对应 Exporters，例如：
- 监控 Linux 主机：部署 node_exporter，它会采集 CPU、内存、磁盘、网络等指标，暴露在 http://<主机IP>:9100/metrics；
- 监控 MySQL：部署 mysqld_exporter，配置 MySQL 连接信息后，暴露在 http://<主机IP>:9104/metrics；
- 监控 K8s：直接用 K8s 内置的 kube-state-metrics（暴露 Pod、Service、Deployment 等资源指标）。

方式 2：业务代码原生埋点（监控自定义指标）若需监控业务指标（如 “接口请求量”“订单转化率”），需在代码中嵌入 Prometheus 客户端（如 Go 用 client_golang、Java 用 micrometer-registry-prometheus），示例（Go 代码）：

运行

import ("github.com/prometheus/client_golang/prometheus""github.com/prometheus/client_golang/prometheus/promhttp""net/http"
)// 定义一个“接口请求量”计数器指标
var apiRequests = prometheus.NewCounterVec(prometheus.CounterOpts{Name: "api_requests_total", // 指标名（需符合 Prometheus 规范）Help: "Total number of API requests", // 指标说明},[]string{"path", "method"}, // 标签（维度，如接口路径、请求方法）
)func init() {// 将指标注册到 Prometheus 默认注册器prometheus.MustRegister(apiRequests)
}func main() {// 模拟接口请求：每调用一次，计数器+1http.HandleFunc("/api/user", func(w http.ResponseWriter, r *http.Request) {apiRequests.WithLabelValues("/api/user", r.Method).Inc() // 指标累加w.Write([]byte("success"))})// 暴露指标接口（供 Prometheus Server 拉取）http.Handle("/metrics", promhttp.Handler())http.ListenAndServe(":8080", nil)
}

启动服务后，访问 http://localhost:8080/metrics 即可看到 api_requests_total 指标。

2. 第二步：配置 Prometheus Server 拉取指标

Prometheus Server 需知道 “从哪些目标（Targets）拉取指标”，通过配置文件（通常是 prometheus.yml）定义 “采集任务（Scrape Configs）”：

yaml

global:scrape_interval: 15s # 全局默认拉取间隔（15秒拉取一次指标）evaluation_interval: 15s # 全局默认告警规则评估间隔scrape_configs:# 任务1：拉取 Linux 主机指标（node_exporter）- job_name: "node" # 任务名（自定义，用于区分）static_configs:- targets: ["192.168.1.100:9100", "192.168.1.101:9100"] # 目标IP:端口（node_exporter 暴露的端口）# 任务2：拉取业务服务指标（原生埋点的服务）- job_name: "api-service"static_configs:- targets: ["192.168.1.200:8080"] # 业务服务暴露的 /metrics 端口# 任务3：拉取 Pushgateway 暂存的短任务指标- job_name: "pushgateway"static_configs:- targets: ["192.168.1.300:9091"] # Pushgateway 端口

启动 Prometheus Server：通过命令指定配置文件

bash

./prometheus --config.file=prometheus.yml --storage.tsdb.path="./data" # data 目录存储 TSDB 数据

验证拉取：访问 Prometheus Web UI（默认 http://localhost:9090），进入 Status → Targets，若目标状态为 UP，说明采集正常。

3. 第三步：用 PromQL 查询指标

Prometheus 提供专属查询语言 PromQL（Prometheus Query Language），用于从 TSDB 中筛选、计算指标，支持在 Web UI、Grafana、API 中使用。

基础语法示例（在 Prometheus Web UI 的 “Graph” 面板测试）：
1. 查询 “Linux 主机 CPU 使用率”（需 node_exporter 采集）：
  promql
```
100 - (avg(irate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance) * 100)
```
  - 解释：node_cpu_seconds_total{mode="idle"} 是空闲 CPU 时间指标；irate([5m]) 计算 5 分钟内的瞬时增长率；avg(...) by (instance) 按主机（instance）分组求平均；最后用 100 减得到使用率。
2. 查询 “业务接口 GET /api/user 的请求总量”：
  promql
```
api_requests_total{path="/api/user", method="GET"}
```
3. 查询 “业务接口过去 5 分钟的平均请求 QPS”：
  promql
```
sum(rate(api_requests_total[5m])) by (path)
```
PromQL 核心能力：
- 筛选：用 {标签名=“值”} 过滤指标（如 instance="192.168.1.100:9100"）；
- 聚合：sum()（求和）、avg()（平均）、max()（最大），配合 by (标签) 分组；
- 时间范围：[5m]（过去 5 分钟）、[1h]（过去 1 小时），用于计算增长率（rate()）、增长量（increase()）。

4. 第四步：配置告警规则（Alertmanager）

当指标超过阈值（如 “CPU 使用率持续 5 分钟> 90%”）时，Prometheus Server 会触发告警，再由 Alertmanager 处理并推送通知。

步骤 1：在 Prometheus 配置中定义告警规则

在 prometheus.yml 中添加 rule_files 配置，指定告警规则文件路径：

yaml

rule_files:- "alert_rules.yml" # 告警规则文件

创建 alert_rules.yml，定义具体告警规则：

yaml

groups:- name: 主机监控告警rules:# 规则1：CPU 使用率 > 90% 持续 5 分钟- alert: 主机CPU使用率过高expr: 100 - (avg(irate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance) * 100) > 90for: 5m # 持续 5 分钟触发告警labels:severity: critical # 告警级别（自定义，如 critical/warning/info）annotations:summary: "主机 {{ $labels.instance }} CPU 使用率过高"description: "CPU 使用率已超过 90%，当前值：{{ $value | humanizePercentage }}" # $value 是指标实际值# 规则2：内存使用率 > 85% 持续 10 分钟- alert: 主机内存使用率过高expr: 100 - (node_memory_available_bytes / node_memory_total_bytes * 100) > 85for: 10mlabels:severity: warningannotations:summary: "主机 {{ $labels.instance }} 内存使用率过高"description: "内存使用率已超过 85%，当前值：{{ $value | humanizePercentage }}"

步骤 2：配置 Alertmanager 对接通知渠道

创建 Alertmanager 配置文件 alertmanager.yml，定义告警路由（如转发到钉钉、邮件）：

yaml

global:resolve_timeout: 5m # 告警恢复后，5分钟内不再发送“恢复通知”route:group_by: ['alertname'] # 按告警名分组（同类型告警合并）group_wait: 10s # 分组后等待 10 秒，再发送第一个告警group_interval: 10s # 同一组告警，间隔 10 秒发送下一个repeat_interval: 1h # 同一告警，1小时内只重复发送一次receiver: 'dingtalk' # 默认接收者（对应下方 receivers 中的名称）receivers:- name: 'dingtalk'webhook_configs:- url: 'http://dingtalk-webhook-url' # 钉钉机器人 Webhook 地址（需提前创建机器人）send_resolved: true # 发送“告警恢复”通知

步骤 3：启动 Alertmanager 并关联 Prometheus

启动 Alertmanager：

bash

./alertmanager --config.file=alertmanager.yml

在 Prometheus 配置中添加 Alertmanager 地址（修改 prometheus.yml）：

yaml

alerting:alertmanagers:- static_configs:- targets: ["localhost:9093"] # Alertmanager 默认端口 9093

验证告警：访问 Alertmanager Web UI（http://localhost:9093），可查看告警状态（Pending/Firing/Resolved）；当指标触发阈值时，钉钉会收到告警通知。

5. 第五步：用 Grafana 可视化指标

Prometheus 的 Web UI 仅支持简单查询，Grafana 是更专业的可视化工具，通过 “Dashboard” 将指标转化为直观图表。

步骤 1：对接 Prometheus 数据源

启动 Grafana（默认端口 3000，初始账号密码 admin/admin）；
进入 Configuration → Data Sources → Add data source，选择 Prometheus；
填写 Prometheus Server 地址（如 http://localhost:9090），点击 “Save & Test”，显示 “Data source is working” 即成功。

步骤 2：导入 / 创建 Dashboard

导入现成 Dashboard（推荐，无需从零开始）：Grafana 官网提供大量开源 Dashboard（Dashboards 库），例如：
- 监控 Linux 主机：搜索 Dashboard ID 1860（Node Exporter Full）；
- 监控 MySQL：搜索 Dashboard ID 7362（MySQL Overview）；导入步骤：Grafana 首页 → Create → Import → 输入 Dashboard ID → 选择 Prometheus 数据源 → 点击 “Import”。
自定义 Dashboard：点击 “Create → Dashboard → Add visualization”，选择 Prometheus 数据源，输入 PromQL 查询语句（如 api_requests_total），选择图表类型（折线图、柱状图等），保存后即可在 Dashboard 中展示。

三、关键操作：日常维护与进阶用法

1. 数据存储优化（TSDB）

Prometheus 本地存储（TSDB）默认保留 15 天数据，可通过启动参数调整：
bash
```
./prometheus --config.file=prometheus.yml --storage.tsdb.retention.time=30d # 保留 30 天
```
大规模场景（数据量超 100GB）：建议使用远程存储（如 Thanos、Cortex），将历史数据存储到 S3、GCS 等对象存储，避免本地磁盘不足。

2. 动态发现目标（替代 static_configs）

当监控目标（如 K8s Pod、云服务器）动态变化时，static_configs 无法实时更新，需用服务发现：

监控 K8s：使用 kubernetes_sd_configs，自动发现 K8s 中的 Pod/Service/Endpoint；
监控云服务：使用 ec2_sd_configs（AWS）、gce_sd_configs（GCP）等，对接云厂商 API 发现实例。示例（K8s 服务发现配置）：

yaml

scrape_configs:- job_name: "k8s-pods"kubernetes_sd_configs:- role: pod # 发现 Pod 角色relabel_configs:# 只监控带 label "monitor: prometheus" 的 Pod- source_labels: [__meta_kubernetes_pod_label_monitor]regex: prometheusaction: keep# 将 Pod 的端口作为拉取端口（假设 Pod 暴露 8080 端口）- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_port]action: replacetarget_label: __address__regex: (.+)replacement: $1:8080

四、典型应用场景

场景	核心用法
微服务监控	用 `spring-boot-starter-actuator` + `micrometer` 埋点，部署 `prometheus` 拉取接口指标，Grafana 展示调用链、响应时间，Alertmanager 告警异常。
K8s 集群监控	部署 `kube-state-metrics` + `node_exporter`，监控 Pod 状态、Node 资源（CPU / 内存）、Deployment 副本数，告警 “Pod 重启次数过多”“Node 磁盘满”。
数据库监控	部署 `mysqld_exporter`/`redis_exporter`，监控连接数、慢查询数、缓存命中率，告警 “连接数超过阈值”“慢查询激增”。
定时任务监控	定时脚本通过 `pushgateway` 推送 “任务执行状态”“执行时长” 指标，配置告警 “任务失败”“执行超时”。

总结：Prometheus 用法核心逻辑

Prometheus 的用法围绕 “指标从产生到消费” 的全链路展开：Exporters/埋点产生指标 → Prometheus Server 拉取并存储 → PromQL 查询指标 → Alertmanager 告警异常 → Grafana 可视化展示。其关键是理解 “拉取式采集”“时间序列数据”“PromQL 语法”，并根据场景选择 Exporters、服务发现方式和告警渠道，最终实现分布式系统的可观测性（Observability）。

查看全文

http://www.dtcms.com/a/558783.html