Prometheus入门指南：系统监控与告警基础

2025-4-13

Prometheus入门指南：系统监控与告警基础

在当今以云原生、微服务和容器化为主导的技术浪潮中，系统的复杂性与日俱增。传统的监控手段往往难以应对这种动态、分布式的环境。此时，一个强大、灵活且适应性强的监控系统变得至关重要。Prometheus，作为云原生计算基金会（CNCF）的第二个毕业项目（仅次于 Kubernetes），已成为现代监控领域的领先者和事实标准。本指南旨在为初学者提供一个全面的 Prometheus 入门介绍，涵盖其核心概念、架构、安装部署、基本系统监控实践、强大的查询语言 PromQL 以及告警基础，助你迈出使用 Prometheus 构建可靠监控体系的第一步。

第一章：为什么选择 Prometheus？监控的重要性

在深入了解 Prometheus 之前，我们首先需要理解为什么监控如此重要。

可见性与洞察力：没有监控，系统就像一个黑盒子。监控提供了必要的可见性，让我们了解系统内部正在发生什么，包括资源使用情况（CPU、内存、磁盘、网络）、应用程序性能指标（请求延迟、错误率、吞吐量）以及业务关键指标。
故障检测与诊断：当系统出现问题时，监控数据是定位和诊断问题的关键。通过历史趋势和实时指标，运维和开发团队可以快速识别异常，缩短故障恢复时间（MTTR）。
性能优化：监控数据揭示了系统的瓶颈所在。通过分析资源利用率和响应时间等指标，可以针对性地进行优化，提升系统性能和用户体验。
容量规划：长期监控数据有助于预测未来的资源需求，为容量规划提供数据支撑，避免资源浪费或因资源不足导致的服务中断。
自动化与告警：基于预设的规则，监控系统可以自动检测异常状态并触发告警，通知相关人员及时介入处理，实现主动运维。

Prometheus 的优势：

多维度数据模型：采用时间序列数据（Time Series Data）模型，通过键值对（Labels）为指标（Metrics）打上任意标签，提供了强大的数据查询、过滤和聚合能力。
强大的查询语言 PromQL：专为时间序列数据设计的查询语言，表达能力丰富，可以轻松实现复杂的查询和计算。
拉取模型（Pull Model）：Prometheus 主动从被监控目标（Targets）抓取（Scrape）指标数据，简化了目标服务的部署，更容易发现和管理监控目标。对于无法被主动拉取的短期作业，也支持通过 Pushgateway 进行推送。
高效存储：内置本地时序数据库（TSDB），针对时间序列数据进行了优化，占用空间小，查询速度快。
服务发现：支持静态配置，也支持多种动态服务发现机制（如 Consul、Kubernetes、EC2 等），能够自动发现和监控动态环境中的目标。
告警管理：通过 Alertmanager 组件，实现对告警的聚合、去重、分组、静默和路由。
生态系统：拥有庞大且活跃的社区，提供了大量的官方和第三方 Exporter（用于暴露现有服务的指标）、客户端库以及与 Grafana 等可视化工具的无缝集成。
云原生设计：天然适合监控容器化和微服务架构。

第二章：Prometheus 核心概念与架构

理解 Prometheus 的核心概念和组件是有效使用它的基础。

核心概念：

时间序列（Time Series）：Prometheus 存储的所有数据都是时间序列。一个时间序列由两部分定义：
- 指标名称（Metric Name）：描述被测量的通用属性，例如 http_requests_total（HTTP 请求总数）、node_cpu_seconds_total（CPU 使用时间）。
- 一组键值对标签（Labels）：用于唯一标识一个时间序列的维度特征。例如，http_requests_total{method="POST", handler="/api/users"} 表示处理 /api/users 路径的 POST 请求的总数。指标名称和所有标签共同构成了时间序列的唯一标识符。
样本（Sample）：每个时间序列包含一系列样本。一个样本由两部分组成：
- 时间戳（Timestamp）：通常是毫秒精度的 Unix 时间戳。
- 值（Value）：一个 64 位浮点数。
指标类型（Metric Types）：Prometheus 定义了四种主要的指标类型：
- Counter（计数器）：一个单调递增的累积值，例如请求总数、任务完成数。只能增加或在重启时归零。适合计算速率，如 rate(http_requests_total[5m]) 计算过去 5 分钟内每秒平均请求数。
- Gauge（仪表盘）：表示一个可以任意上升或下降的瞬时值，例如当前内存使用量、队列中的任务数、温度。
- Histogram（直方图）：对观察结果（通常是请求持续时间或响应大小）进行采样，并在可配置的存储桶（buckets）中进行计数。它还提供所有观察值的总和。这使得可以计算分位数（Quantiles），例如 histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])) 计算过去 5 分钟内 95% 的请求延迟。
- Summary（摘要）：与 Histogram 类似，也用于观察分布。但它直接存储可配置的分位数（例如 φ=0.5, φ=0.9, φ=0.99）以及观察值的总数和总和。分位数是在客户端计算的，这在聚合时可能存在问题，但开销比 Histogram 低。

架构组件：

Prometheus 生态系统由多个核心和可选组件构成：

Prometheus Server：核心组件，负责：
- 服务发现（Service Discovery）：动态或静态地发现需要监控的目标。
- 指标抓取（Scraping）：定期从配置的目标（Exporters 或直接插桩的应用）拉取指标数据。
- 数据存储（Storage）：将抓取到的时间序列数据存储在本地时序数据库（TSDB）中。
- PromQL 查询处理：提供 HTTP API，接收 PromQL 查询请求并返回结果。
- 告警规则评估：根据配置的告警规则（Alerting Rules），定期评估 PromQL 表达式，并将触发的告警发送给 Alertmanager。
Exporter：用于暴露现有服务的指标。由于很多服务本身并不直接暴露 Prometheus 格式的指标，需要 Exporter 作为中间代理。Exporter 接收服务的传统指标，将其转换为 Prometheus 格式，并通过 HTTP 端点（通常是 /metrics）暴露出来，供 Prometheus Server 抓取。常见的 Exporter 有：
- node_exporter：暴露 *nix 系统的硬件和操作系统指标。
- mysqld_exporter：暴露 MySQL 数据库指标。
- redis_exporter：暴露 Redis 指标。
- blackbox_exporter：用于探测端点（HTTP, HTTPS, DNS, TCP, ICMP），进行黑盒监控。
Client Libraries：用于在应用程序代码中直接插桩（Instrumentation），定义和暴露自定义的应用内部指标。支持多种语言（Go, Java, Python, Ruby 等）。
Pushgateway：适用于无法被 Prometheus 主动拉取的短期作业（如批处理任务）。这些作业可以将它们的指标推送到 Pushgateway，然后 Prometheus Server 从 Pushgateway 拉取这些指标。注意：Pushgateway 并非用于替代拉取模型，应谨慎使用。
Alertmanager：独立于 Prometheus Server 的组件，负责处理由 Prometheus Server 发送过来的告警（Alerts）。它提供以下功能：
- 去重（Deduplication）：将相同告警的多个实例合并为一个通知。
- 分组（Grouping）：将性质相似的告警（例如同一集群中的多个实例宕机）分组到一个通知中。
- 静默（Silencing）：根据配置的规则，临时禁止某些告警的通知。
- 抑制（Inhibition）：如果某些其他告警已经触发，则抑制某些告警的触发（例如，当整个区域网络中断时，抑制该区域所有服务的告警）。
- 路由（Routing）：根据标签将告警路由到不同的接收器（Receiver），如 Email、Slack、PagerDuty、Webhook 等。
Web UI / Grafana：
- Prometheus Server 自带一个简单的 Web UI，可以查看配置、目标状态、执行 PromQL 查询和查看简单图形。
- Grafana 是目前最流行的与 Prometheus 集成的可视化工具，提供了强大而灵活的仪表盘创建能力，可以展示复杂的监控视图。

数据流：

典型的监控流程如下：
1. 应用程序通过 Client Library 或 Exporter 暴露 /metrics 端点。
2. Prometheus Server 通过服务发现找到这些目标。
3. Prometheus Server 定期（由 scrape_interval 配置）向目标发送 HTTP GET 请求，抓取 /metrics 端点的数据。
4. Prometheus Server 将抓取到的样本存储到本地 TSDB。
5. 用户通过 Prometheus Web UI 或 Grafana，使用 PromQL 查询 Prometheus Server 获取数据并可视化。
6. Prometheus Server 根据配置的告警规则评估数据。
7. 如果规则条件满足，Prometheus Server 将告警发送给 Alertmanager。
8. Alertmanager 处理告警（去重、分组、静默等），并根据路由规则发送通知给指定的接收器。

第三章：安装与基本配置

Prometheus 可以通过多种方式安装，包括下载预编译的二进制文件、使用 Docker 镜像或通过包管理器。这里以二进制文件为例：

下载 Prometheus：访问 Prometheus 官方下载页面（https://prometheus.io/download/），选择适合你操作系统的最新稳定版二进制包。
解压：
bash tar xvfz prometheus-*.tar.gz cd prometheus-*
解压后会看到 prometheus (可执行文件)、prometheus.yml (默认配置文件)、consoles 和 console_libraries (Web UI 相关)等文件。
配置 prometheus.yml：这是 Prometheus 的核心配置文件。一个最简单的配置如下：

```yaml

全局配置

global:
scrape_interval: 15s # 设置默认抓取间隔为 15 秒
evaluation_interval: 15s # 设置默认规则评估间隔为 15 秒
# scrape_timeout 默认为 10s

告警管理配置 (如果使用 Alertmanager)

alerting:
alertmanagers:
- static_configs:
- targets:
# - alertmanager:9093 # Alertmanager 的地址和端口

规则文件配置 (用于告警和记录规则)

rule_files:
# - "first_rules.yml"
# - "second_rules.yml"

抓取配置 (定义要监控的目标)

scrape_configs:
# 第一个抓取作业：监控 Prometheus 自身
- job_name: 'prometheus'
# scrape_interval 和 scrape_timeout 可以在 job 级别覆盖 global 配置
static_configs:
- targets: ['localhost:9090'] # Prometheus 默认监听 9090 端口

# 第二个抓取作业：(示例) 监控 Node Exporter
# - job_name: 'node'
# static_configs:
# - targets: [':9100']
```
- global: 全局设置，如抓取间隔、评估间隔。
- alerting: 配置 Alertmanager 的地址。
- rule_files: 指定包含告警规则或记录规则的文件路径。
- scrape_configs: 定义抓取作业（Jobs）。每个 job 定义了一组具有相同目的的目标（Targets）。job_name 是附加到从该 job 抓取的时序数据上的标签。static_configs 是最简单的服务发现方式，直接列出目标的 host:port。
启动 Prometheus Server：
bash ./prometheus --config.file=prometheus.yml
Prometheus Server 会加载配置文件并开始运行，默认监听 9090 端口。
访问 Web UI：在浏览器中打开 http://<your_prometheus_server_ip>:9090。你可以看到 Prometheus 的 Web UI，包含以下主要页面：
- Alerts: 显示当前活动的告警（如果配置了告警规则）。
- Graph: 输入 PromQL 表达式执行查询，并以表格或图形方式展示结果。
- Status:
  - Runtime & Build Information: 查看 Prometheus Server 的运行时和构建信息。
  - Command-Line Flags: 查看启动时使用的命令行参数。
  - Configuration: 查看当前加载的配置文件内容。
  - Rules: 查看已加载的告警和记录规则。
  - Targets: 查看所有已配置的抓取目标及其状态（UP / DOWN）、上次抓取时间、抓取错误等。这是排查监控目标问题的关键页面。
  - Service Discovery: 查看通过各种服务发现机制发现的目标。

第四章：实践：使用 Node Exporter 监控系统指标

理论结合实践是最好的学习方式。让我们来配置 Prometheus 监控一台 Linux 服务器的系统指标。这需要使用 node_exporter。

下载并运行 Node Exporter：在需要被监控的 Linux 服务器上执行：
- 访问 Prometheus 下载页面，找到 Node Exporter 部分，下载适合的二进制包。
- 解压：tar xvfz node_exporter-*.tar.gz && cd node_exporter-*
- 运行：./node_exporter
  Node Exporter 默认会监听 9100 端口，并在 /metrics 路径暴露大量系统指标（CPU、内存、磁盘 I/O、网络、文件系统等）。你可以通过 curl http://localhost:9100/metrics 查看。
配置 Prometheus 抓取 Node Exporter：编辑 Prometheus Server 上的 prometheus.yml 文件，在 scrape_configs 部分添加一个新的 job：

```yaml
scrape_configs:
- job_name: 'prometheus'
static_configs:
- targets: ['localhost:9090']
- job_name: 'node'
  static_configs:
  # 将
  替换为运行 Node Exporter 的服务器 IP 地址
  - targets: [':9100']
    # 可以为这个目标添加自定义标签，例如环境或角色
    labels:
    instance: 'my-linux-server-01'
    env: 'production'
```
- 我们定义了一个名为 node 的 job。
- 在 static_configs 中指定了 Node Exporter 的 IP 地址和端口 9100。
- 通过 labels 可以为从这个目标抓取的所有指标附加额外的标签，这对于区分来自不同机器或环境的相同指标非常有用。instance 标签通常用于标识具体的实例。
重启 Prometheus Server：停止之前的 Prometheus 进程 (Ctrl+C)，然后使用更新后的配置文件重新启动：
bash ./prometheus --config.file=prometheus.yml
或者，可以向 Prometheus 发送 SIGHUP 信号来热加载配置（无需重启）：
bash kill -HUP <prometheus_pid>
验证抓取状态：访问 Prometheus Web UI (http://<prometheus_server_ip>:9090)，导航到 "Status" -> "Targets"。你应该能看到 node job 下的目标，其状态（State）应为 UP。如果状态是 DOWN，请检查网络连接、防火墙设置以及 Node Exporter 是否在目标机器上正常运行。
查询系统指标：导航到 "Graph" 页面，现在你可以查询由 Node Exporter 暴露的指标了。例如：
- 查看 CPU 总使用时间（所有核心，所有模式）：node_cpu_seconds_total
- 查看空闲 CPU 时间：node_cpu_seconds_total{mode="idle"}
- 计算过去 5 分钟内，非空闲 CPU 使用率（百分比）：
  promql (1 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]))) * 100
  这里用到了 PromQL 的函数 rate()（计算 Counter 类型指标的平均每秒增长率）和聚合操作 avg by (instance)（按 instance 标签分组计算平均值）。
- 查看可用内存（以 MB 为单位）：node_memory_MemAvailable_bytes / 1024 / 1024
- 查看根目录可用空间（百分比）：
  promql node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"} * 100

通过 Node Exporter 和 Prometheus，我们已经成功地建立了一个基础的系统监控。你可以探索 /metrics 端点或使用 Web UI 的指标浏览器来发现更多有用的系统指标。

第五章：PromQL 基础入门

PromQL (Prometheus Query Language) 是 Prometheus 的核心优势之一。它允许你灵活地选择、聚合、转换和计算时间序列数据。

基本选择器：

即时向量（Instant Vector）：选择一组时间序列在某个时间点的最新样本。
- metric_name: 选择所有名为 metric_name 的时间序列的最新样本。例如 node_memory_MemAvailable_bytes。
- metric_name{label="value", another_label!="othervalue"}: 使用标签选择器进行过滤。支持 =(等于), !=(不等于), =~(正则匹配), !~(正则不匹配)。例如 http_requests_total{method="GET", status_code=~"5.."} 选择所有 GET 请求且状态码为 5xx 的请求总数。
范围向量（Range Vector）：选择一组时间序列在一段时间范围内的所有样本。范围向量不能直接在图表中绘制，通常作为函数（如 rate(), increase(), delta()）的输入。
- 表示方法是在即时向量选择器后附加 [duration]，例如 node_cpu_seconds_total{mode="idle"}[5m] 表示选择过去 5 分钟内所有 node_cpu_seconds_total{mode="idle"} 的样本。Duration 可以是 s(秒), m(分钟), h(小时), d(天), w(周), y(年)。

常用函数：

rate(range_vector)：计算范围向量中 Counter 类型指标的平均每秒增长率。非常适合计算 QPS、错误率等。
- rate(http_requests_total{job="api-server"}[5m])：计算 api-server job 过去 5 分钟的平均每秒请求速率。
increase(range_vector)：计算范围向量中 Counter 类型指标的总增长量。
- increase(node_network_receive_bytes_total{device="eth0"}[1h])：计算过去 1 小时内 eth0 网卡接收的总字节数。
sum(vector) / avg(vector) / min(vector) / max(vector) / count(vector) 等聚合操作符：将向量中的多个时间序列聚合成一个或少数几个时间序列。可以配合 by (label1, label2) 或 without (label1) 子句来保留或排除某些标签进行分组聚合。
- sum(rate(http_requests_total[5m]))：计算所有 HTTP 请求的总 QPS。
- sum by (job) (rate(http_requests_total[5m]))：按 job 标签分组，计算每个 job 的 QPS。
- avg without (instance) (node_load1)：计算所有实例（排除了 instance 标签）的平均 1 分钟负载。
topk(k, vector) / bottomk(k, vector)：选出向量中值最大或最小的 k 个时间序列。
- topk(5, instance:node_load1:ratio)：选出 1 分钟负载最高的 5 个实例（这里假设有一个记录规则生成了 instance:node_load1:ratio 指标）。
histogram_quantile(φ, range_vector)：计算 Histogram 类型指标的分位数。φ 是 0 到 1 之间的分位数（例如 0.95 代表 95th percentile）。输入通常是 rate() 应用于 _bucket 指标。
- histogram_quantile(0.99, sum by (le) (rate(http_request_duration_seconds_bucket[10m])))：计算过去 10 分钟内 HTTP 请求延迟的 99 分位数。

运算符：

算术运算符 (+, -, *, /, %, ^)：可以对向量进行逐元素的运算。如果两边都是向量，Prometheus 会尝试基于标签进行匹配（一对一或多对一/一对多，需要使用 on(label) 或 ignoring(label) 指定匹配行为）。
- node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100：计算可用内存百分比。
比较运算符 (==, !=, >, <, >=, <=)：对向量进行逐元素比较，结果为 0 或 1。可以使用 bool 修饰符来强制返回 0 或 1。
- node_filesystem_free_bytes{mountpoint="/"} < 10 * 1024 * 1024 * 1024：筛选出根目录可用空间小于 10GB 的文件系统。
逻辑运算符 (and, or, unless)：对向量进行集合操作。
- vector1 and vector2：结果包含 vector1 中，与 vector2 中标签完全匹配的所有元素。

PromQL 非常强大，需要持续学习和实践。建议从简单查询开始，逐步尝试更复杂的函数和聚合。Prometheus Web UI 的 Graph 页面是练习 PromQL 的好地方。

第六章：告警基础：Alertmanager 与告警规则

监控的最终目的之一是能在问题发生时及时得到通知。Prometheus 通过 Alertmanager 实现告警功能。

流程：

定义告警规则（Alerting Rules）：在 Prometheus 的规则文件中定义。规则包含一个 PromQL 表达式（expr），当该表达式在一定时间（for）内持续为真时，告警状态变为 Firing。
Prometheus 评估规则：Prometheus Server 根据 evaluation_interval 定期评估所有规则。
Prometheus 发送告警给 Alertmanager：当规则状态变为 Firing，Prometheus 将包含告警信息（标签、注解等）的通知发送给 prometheus.yml 中配置的所有 Alertmanager 实例。
Alertmanager 处理告警：Alertmanager 接收告警，进行去重、分组、静默、抑制等处理。
Alertmanager 路由通知：根据 Alertmanager 的配置文件 (alertmanager.yml) 中的路由规则，将处理后的告警信息发送给最终的接收器（如 Email, Slack, PagerDuty）。

告警规则文件（例如 my_alerts.rules.yml）：

```yaml
groups:
- name: node_alerts
rules:
# 告警：实例宕机
- alert: InstanceDown
# PromQL 表达式：如果 up 指标等于 0 (表示抓取失败)
expr: up == 0
# 持续时间：如果 up==0 的状态持续了 1 分钟，则触发告警
for: 1m
# 告警标签：附加到告警上的标签，用于路由和识别
labels:
severity: critical # 严重程度
# 告警注解：提供更多描述性信息
annotations:
summary: "Instance {{ $labels.instance }} down"
description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 1 minute."

# 告警：主机 CPU 使用率过高
- alert: HostHighCpuLoad
expr: (1 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]))) * 100 > 85
for: 5m
labels:
severity: warning
annotations:
summary: "Host high CPU load on {{ $labels.instance }}"
description: "{{ $labels.instance }} CPU load is > 85% for the last 5 minutes (current value: {{ $value | printf \"%.2f\" }}%)."

# 告警：主机内存使用率过高
- alert: HostHighMemoryLoad
expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100 > 90
for: 5m
labels:
severity: warning
annotations:
summary: "Host high memory usage on {{ $labels.instance }}"
description: "{{ $labels.instance }} memory usage is > 90% for the last 5 minutes (current value: {{ $value | printf \"%.2f\" }}%)."
```

groups: 将相关的规则组织在一起。
alert: 告警的名称。
expr: 触发告警的 PromQL 表达式。
for: 表达式结果持续为真多久才触发告警（状态变为 Firing）。这有助于避免因短暂波动而产生的误报。
labels: 附加到告警上的标签。severity 是一个常用的标签，用于 Alertmanager 路由或通知优先级。
annotations: 提供更详细的告警信息，通常包含 summary 和 description。可以使用 Go 模板语法（如 {{ $labels.instance }} 和 {{ $value }}）来引用告警的标签和当前值。

配置 Prometheus 加载规则文件：

编辑 prometheus.yml，在 rule_files 部分添加你的规则文件路径：

yaml rule_files: - "my_alerts.rules.yml" # 可以添加更多规则文件
然后重启或热加载 Prometheus 配置。你可以在 Prometheus Web UI 的 "Status" -> "Rules" 页面看到加载的规则及其当前状态（Inactive, Pending, Firing）。

设置 Alertmanager：

Alertmanager 是一个独立的程序，需要单独下载、配置和运行。

下载并解压 Alertmanager。
配置 alertmanager.yml：定义接收器（Receivers）和路由（Routing）规则。一个简单的例子，将所有严重级别为 critical 的告警发送到 Slack，其他告警发送到 Email：

```yaml
global:
resolve_timeout: 5m # 告警恢复后多久标记为 resolved
slack_api_url: '' # Slack Webhook URL (如果使用Slack)

route:
group_by: ['alertname', 'cluster', 'service'] # 按这些标签分组告警
group_wait: 30s # 等待 30s 看是否有更多同组告警到来
group_interval: 5m # 同组告警之间发送通知的最小间隔
repeat_interval: 1h # 对已发送的告警，多久重复发送一次通知
receiver: 'default-email' # 默认接收器

routes:
# 如果告警标签 severity=critical，则路由到 slack-notifications 接收器
- match:
severity: 'critical'
receiver: 'slack-notifications'
# continue: true # 如果为 true，匹配后还会继续尝试匹配后续路由

receivers:
- name: 'default-email'
email_configs:
- to: '[email protected]'
from: '[email protected]'
smarthost: 'smtp.example.com:587'
auth_username: '[email protected]'
auth_identity: '[email protected]'
auth_password: 'your_password'
# require_tls: true
- name: 'slack-notifications'
  slack_configs:
- channel: '#alerts-channel'
  # api_url: '' # 可选，覆盖全局设置
  send_resolved: true # 是否发送恢复通知
  title: '[{{ .Status | toUpper }}{{ if eq .Status "firing" }}:{{ .Alerts.Firing | len }}{{ end }}] {{ .CommonLabels.alertname }} for {{ .CommonLabels.job }}'
  text: >-
  {{ range .Alerts }}
  Alert: {{ .Annotations.summary }} - {{ .Labels.severity }}
  Description: {{ .Annotations.description }}
  Details: {{ range .Labels.SortedPairs }} • {{ .Name }}: {{ .Value }} {{ end }}
  {{ end }}
```
- global: 全局设置。
- route: 定义告警路由树的根节点。group_by 定义如何分组告警。group_wait, group_interval, repeat_interval 控制通知频率。receiver 是默认接收器。routes 定义子路由，根据 match 或 match_re（正则匹配）标签来选择不同的接收器。
- receivers: 定义具体的通知方式和目的地。每个接收器有唯一的 name，并包含特定通知渠道（如 email_configs, slack_configs, webhook_configs, pagerduty_configs等）的配置。
运行 Alertmanager：
bash ./alertmanager --config.file=alertmanager.yml
Alertmanager 默认监听 9093 端口。
配置 Prometheus 指向 Alertmanager：确保 prometheus.yml 的 alerting 部分配置了正确的 Alertmanager 地址：

yaml alerting: alertmanagers: - static_configs: - targets: ['localhost:9093'] # Alertmanager 的地址
重启或热加载 Prometheus。

现在，当 Prometheus 中的告警规则被触发时，告警会发送到 Alertmanager，后者会根据配置进行处理并发送通知。你可以在 Prometheus Web UI 的 "Alerts" 页面和 Alertmanager 的 Web UI (http://<alertmanager_ip>:9093) 查看告警状态。

第七章：可视化：与 Grafana 集成

虽然 Prometheus 自带 Web UI 用于查询和查看简单图形，但 Grafana 提供了更强大、灵活和美观的可视化能力。

安装并运行 Grafana：参考 Grafana 官方文档 (https://grafana.com/docs/grafana/latest/installation/) 进行安装。通常可以通过 Docker 或包管理器安装。Grafana 默认监听 3000 端口。
登录 Grafana：访问 http://<grafana_server_ip>:3000，默认用户名/密码是 admin/admin（首次登录会提示修改密码）。
添加 Prometheus 数据源：
- 在 Grafana 左侧菜单，点击齿轮图标 (Configuration) -> "Data Sources"。
- 点击 "Add data source"。
- 搜索并选择 "Prometheus"。
- 在 "HTTP" 部分，设置 "URL" 为 Prometheus Server 的地址，例如 http://<prometheus_server_ip>:9090。
- 其他设置通常可以保持默认。点击 "Save & Test"。如果配置正确，会显示 "Data source is working"。
创建仪表盘（Dashboard）：
- 点击左侧菜单的 "+" 图标 -> "Dashboard"。
- 点击 "Add new panel"。
- 在 Panel 编辑页面的底部：
  - Data source: 选择你刚刚添加的 Prometheus 数据源。
  - Query: 在 "Metrics browser" 或直接在输入框中输入你的 PromQL 查询语句，例如 (1 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[$__rate_interval]))) * 100。$__rate_interval 是 Grafana 提供的一个变量，会根据图表的时间范围和分辨率自动调整，推荐在 rate() 等函数中使用。
  - Legend: 可以使用模板（如 {{instance}}）来格式化图例，使其更易读。
  - Panel options / Visualization: 在右侧选择合适的图表类型（如 Time series, Stat, Gauge, Table 等），并调整其外观和选项（标题、单位、坐标轴、阈值等）。
- 配置完成后，点击右上角的 "Apply"。
- 可以继续添加更多 Panel 到仪表盘中。
- 完成后，点击右上角的保存图标，为仪表盘命名并保存。
导入现有仪表盘：Grafana 社区有大量预制的 Prometheus 仪表盘（例如针对 Node Exporter、Kubernetes 等）。你可以通过 Grafana.com 的 Dashboards 页面 (https://grafana.com/grafana/dashboards/) 找到它们的 ID 或 JSON 文件，然后在 Grafana 中点击 "+" -> "Import" 来导入。

通过 Grafana，你可以创建包含各种系统和应用指标的综合性监控仪表盘，极大地提升监控数据的可观察性。

第八章：后续步骤与最佳实践

掌握了 Prometheus 的基础后，你还可以探索更多高级特性和实践：

服务发现：学习使用 Consul, Kubernetes SD, EC2 SD 等动态服务发现机制，自动化监控目标的管理。
记录规则（Recording Rules）：预先计算和存储常用的或计算成本高的 PromQL 表达式结果，作为新的时间序列，可以简化查询并提高仪表盘加载速度。
联邦（Federation）：构建层级式的 Prometheus 部署，用于大规模环境或跨数据中心的监控聚合。
远程存储（Remote Storage）：将 Prometheus 的数据长期存储到外部存储系统（如 Thanos, Cortex, M3DB, InfluxDB 等），解决本地存储容量和持久性限制。
高可用（High Availability）：运行多个 Prometheus 实例抓取相同的目标，并配置 Alertmanager 进行告警去重，实现监控和告警的高可用。
安全性：为 Prometheus、Exporter 和 Alertmanager 配置 TLS 加密和认证。
Exporter 和 Client Library 的选择与使用：根据需要监控的服务和应用，选择合适的 Exporter 或使用 Client Library 进行自定义插桩。
标签规范：制定一致的标签命名和使用规范（例如 env, region, service, instance 等），对于后续的查询、聚合和告警至关重要。避免使用高基数（High Cardinality）的标签值，否则可能导致性能问题。
性能调优：了解 Prometheus 的内存、CPU 和磁盘 I/O 使用情况，根据需要调整配置（如抓取间隔、存储保留期、并发抓取数等）。

结论

Prometheus 提供了一个强大、灵活且可扩展的平台，用于应对现代分布式系统的监控挑战。通过理解其核心概念（时间序列、标签、指标类型）、架构组件（Server, Exporter, Alertmanager）、掌握基础的 PromQL 查询以及配置告警规则，你已经具备了使用 Prometheus 构建基础监控和告警系统的能力。结合 Node Exporter 进行系统监控，并利用 Grafana 进行可视化，可以快速搭建起一套实用的监控解决方案。

监控是一个持续演进的过程。随着你对 Prometheus 生态系统的深入探索和实践经验的积累，你将能够更有效地利用它来保障系统的稳定性、优化性能并驱动业务决策。希望本指南能为你开启 Prometheus 的学习之旅提供坚实的基础。

作者：admin

链接：https://hostlocvps.com/2025/04/13/prometheus%e5%85%a5%e9%97%a8%e6%8c%87%e5%8d%97%ef%bc%9a%e7%b3%bb%e7%bb%9f%e7%9b%91%e6%8e%a7%e4%b8%8e%e5%91%8a%e8%ad%a6%e5%9f%ba%e7%a1%80/

文章版权归作者所有，未经允许请勿转载。

THE END

禁用不必要的 Windows 启动程序，让开机更快

<<上一篇

免费安卓模拟器推荐：MuMu模拟器深度介绍

下一篇>>

Prometheus入门指南：系统监控与告警基础

Prometheus入门指南：系统监控与告警基础

第一章：为什么选择 Prometheus？监控的重要性

第二章：Prometheus 核心概念与架构

第三章：安装与基本配置

全局配置

告警管理配置 (如果使用 Alertmanager)

规则文件配置 (用于告警和记录规则)

抓取配置 (定义要监控的目标)

第四章：实践：使用 Node Exporter 监控系统指标

第五章：PromQL 基础入门

第六章：告警基础：Alertmanager 与告警规则

第七章：可视化：与 Grafana 集成

第八章：后续步骤与最佳实践

结论