监控系统需要持续采集、保存、查询、可视化和告警。

但这些命令主要解决“现在发生了什么”，而监控系统需要进一步解决“持续采集、保存、查询、可视化和告警”。

Prometheus 负责采集和存储指标，PromQL 负责查询，Grafana 负责把这些数据展示出来，并进一步形成 Dashboard 与告警。

一、Prometheus 与 Grafana 概述#

1.1 为什么需要监控系统#

在 Linux 主机上，可以先用以下命令查看当前状态：

1
top
2
free -h
3
df -h
4
ss -lntp
5
systemctl status nginx

查看当前系统状态。

但是这些工具存在一个问题：

1
需要人工执行

例如：

1
CPU = 30%

只能说明：

1
现在 CPU 大约是 30%

如果希望知道：

1
过去 24 小时 CPU 怎么变化？
2
什么时候开始升高？
3
部署之后有没有明显变化？
4
什么时候超过阈值？

就需要持续采集并保存数据。

因此监控系统的基本流程是：

1
目标主机
2
   │
3
   ▼
4
指标暴露
5
   │
6
   ▼
7
Prometheus
8
   │
9
   ├── 采集
10
   ├── 存储
11
   └── 查询
12
        │
13
        ▼
14
      PromQL
15
        │
16
        ▼
17
      Grafana
18
        │
19
        ├── Dashboard
20
        └── Alerting

1.2 Prometheus 是什么#

Prometheus 是开源的监控与告警工具，同时具备时间序列数据库能力。

它最核心的数据模型是：

1
Metric
2
+
3
Labels
4
+
5
Timestamp
6
+
7
Value

例如：

1
http_requests_total{
2
    job="api",
3
    method="GET",
4
    status="200"
5
}

在某一个时间点可能对应：

1
15320

随着时间变化：

这些数据就组成了一条时间序列。

Prometheus 官方将自己的核心特点概括为：

多维度时间序列数据模型
PromQL 查询语言
HTTP Pull 模型
Service Discovery
本地时间序列存储
告警规则与 Alertmanager

官方文档： Prometheus Overview

1.3 Grafana 是什么#

Grafana 更偏向：

1
查询
2
+
3
可视化
4
+
5
Dashboard
6
+
7
告警

它本身不是 Prometheus 的替代品。

典型关系：

1
Prometheus
2
    │
3
    │ PromQL
4
    ▼
5
 Grafana
6
    │
7
    ├── Graph
8
    ├── Gauge
9
    ├── Table
10
    ├── Stat
11
    └── Alert

Grafana 通过 Data Source 连接外部数据系统。

除了 Prometheus，还可以连接：

1
Loki
2
Elasticsearch
3
MySQL
4
PostgreSQL
5
InfluxDB
6
CloudWatch
7
...

也就是说：

1
Prometheus
2
→ 保存和提供 Metrics
3

4
Grafana
5
→ 查询和展示 Metrics

Grafana 官方： Grafana Data Sources

二、Prometheus 的核心数据模型#

2.1 Metric#

Metric 就是需要观察的指标。

例如：

1
CPU 使用率
2
内存使用量
3
磁盘空间
4
HTTP 请求数
5
HTTP 错误数
6
数据库连接数

可以用：

1
node_cpu_seconds_total
2
node_memory_MemAvailable_bytes
3
node_filesystem_avail_bytes

等指标表示。

2.2 Labels#

Prometheus 最大的特点之一就是：

1
Labels

例如：

1
http_requests_total{
2
    method="GET",
3
    status="200",
4
    instance="10.0.0.10:8080"
5
}

同一个 Metric：

1
http_requests_total

通过不同的 Label 可以形成不同的时间序列：

1
method=GET
2
status=200
3

4
method=GET
5
status=500
6

7
method=POST
8
status=200

因此：

1
Metric Name
2
+
3
Labels

共同确定一条具体的时间序列。

Prometheus 官方数据模型： Data model

2.3 Label Cardinality#

Label 虽然非常强大，但不能无限制地增加。

例如：

1
user_id
2
request_id
3
session_id

如果每个请求都产生不同的 Label 值：

1
request_id=abc001
2
request_id=abc002
3
request_id=abc003
4
...

就会产生大量时间序列。

这就是：

1
High Cardinality

可能导致：

1
内存增加
2
磁盘增加
3
查询变慢

因此 Prometheus 中需要谨慎设计 Label。

一般来说：

1
服务名
2
实例
3
HTTP Method
4
HTTP Status
5
环境

这类有限集合更适合作为 Label。

而：

1
用户 ID
2
订单 ID
3
请求 ID
4
UUID

通常不适合直接作为高频 Metric Label。

三、Prometheus 的 Pull 模型#

3.1 Prometheus 如何获取指标#

Prometheus 最典型的工作方式是：

1
Exporter / Application
2
        │
3
        │ HTTP /metrics
4
        ▼
5
    Prometheus

Prometheus 主动去目标地址抓取：

1
GET /metrics

这就是：

1
Pull

模型。

官方文档明确说明，Prometheus 默认通过 HTTP Pull 模型采集时间序列。

3.2 /metrics#

很多 Prometheus Exporter 会提供：

1
/metrics

例如：

1
http://10.0.0.10:9100/metrics

内容通常类似：

1
# HELP node_cpu_seconds_total ...
2
# TYPE node_cpu_seconds_total counter
3

4
node_cpu_seconds_total{
5
    cpu="0",
6
    mode="idle"
7
} 12345

因此：

1
/metrics
2
→ 向 Prometheus 暴露可采集指标

3.3 Push 与 Pull#

Prometheus 主要采用：

1
Pull

但也支持某些特殊场景下通过 Pushgateway 接收短生命周期任务推送的数据。

不过应该注意：

1
Pushgateway
2
≠
3
Prometheus 默认采集方式

对于长期运行的服务，通常优先使用：

1
Prometheus → Pull → Target

四、Exporter#

4.1 Exporter 是什么#

Exporter 可以理解为：

1
把某个系统的数据
2
转换成 Prometheus Metrics

例如：

1
Linux
2
  │
3
  ▼
4
node_exporter
5
  │
6
  ▼
7
/metrics
8
  │
9
  ▼
10
Prometheus

不同系统可能使用不同 Exporter：

1
Linux
2
→ node_exporter
3

4
MySQL
5
→ mysqld_exporter
6

7
Redis
8
→ redis_exporter
9

10
PostgreSQL
11
→ postgres_exporter

这使 Prometheus 能够统一采集不同系统的指标。

4.2 node_exporter#

Linux 主机监控中最常见的是：

1
node_exporter

它可以暴露：

1
CPU
2
Memory
3
Disk
4
Network
5
Filesystem
6
Load
7
...

因此：

1
Linux Kernel / /proc / /sys
2
             │
3
             ▼
4
        node_exporter
5
             │
6
             ▼
7
         /metrics

官方： node_exporter

五、安装 Prometheus#

Prometheus 可以直接以二进制方式运行，也可以运行在容器中。

对于理解 Linux 运维，直接二进制部署是一个很好的学习方式：

1
Linux
2
 ├── prometheus
3
 └── node_exporter

而实际项目中也常见：

1
Docker
2
 ├── prometheus
3
 └── grafana

5.1 创建 Prometheus 用户#

生产环境不应该默认使用 root 运行 Prometheus。

例如：

1
sudo useradd \
2
  --no-create-home \
3
  --shell /usr/sbin/nologin \
4
  prometheus

创建目录：

1
sudo mkdir -p /etc/prometheus
2
sudo mkdir -p /var/lib/prometheus

设置权限：

1
sudo chown -R prometheus:prometheus \
2
  /etc/prometheus \
3
  /var/lib/prometheus

5.2 配置文件#

Prometheus 的核心配置文件通常是：

1
prometheus.yml

一个最简单的配置：

1
global:
2
  scrape_interval: 15s
3

4
scrape_configs:
5

6
  - job_name: prometheus
7
    static_configs:
8
      - targets:
9
          - localhost:9090

这里：

1
scrape_interval

决定采集间隔。

例如：

1
15s

意味着：

1
每 15 秒采集一次

5.3 启动 Prometheus#

直接运行：

1
prometheus \
2
  --config.file=/etc/prometheus/prometheus.yml \
3
  --storage.tsdb.path=/var/lib/prometheus

验证：

1
curl http://127.0.0.1:9090/-/ready

如果正常，Prometheus Web UI 通常可以通过：

1
http://<server>:9090

访问。

六、使用 systemd 管理 Prometheus#

将 Prometheus 作为长期运行的服务时，可以使用 systemd。

创建：

1
/etc/systemd/system/prometheus.service

例如：

1
[Unit]
2
Description=Prometheus
3
After=network.target
4

5
[Service]
6
User=prometheus
7
Group=prometheus
8

9
ExecStart=/usr/local/bin/prometheus \
10
  --config.file=/etc/prometheus/prometheus.yml \
11
  --storage.tsdb.path=/var/lib/prometheus
12

13
Restart=on-failure
14

15
[Install]
16
WantedBy=multi-user.target

重新加载：

1
sudo systemctl daemon-reload

启动：

1
sudo systemctl start prometheus

设置开机启动：

1
sudo systemctl enable prometheus

查看：

1
systemctl status prometheus

日志：

1
journalctl -u prometheus

这样就把上一篇 Linux 服务监控的知识连接到了 Prometheus：

1
systemd
2
   │
3
   ▼
4
Prometheus Service
5
   │
6
   ▼
7
Metrics

七、配置 node_exporter#

7.1 启动 node_exporter#

node_exporter 默认监听：

1
9100

启动后：

1
curl http://127.0.0.1:9100/metrics

如果能够看到：

1
node_cpu_seconds_total
2
node_memory_...
3
node_filesystem_...

说明 Exporter 工作正常。

7.2 systemd#

也可以把 node_exporter 配置成服务：

1
[Unit]
2
Description=Node Exporter
3
After=network.target
4

5
[Service]
6
User=node_exporter
7
Group=node_exporter
8

9
ExecStart=/usr/local/bin/node_exporter
10

11
Restart=on-failure
12

13
[Install]
14
WantedBy=multi-user.target

启动：

1
sudo systemctl daemon-reload
2
sudo systemctl enable --now node_exporter

检查：

1
systemctl status node_exporter

7.3 Prometheus 配置 Target#

修改：

1
scrape_configs:
2

3
  - job_name: node
4
    static_configs:
5
      - targets:
6
          - 127.0.0.1:9100

然后让 Prometheus 重新加载配置。

最简单的方式可以直接重启：

1
sudo systemctl restart prometheus

生产环境也可以通过 Prometheus 提供的配置 reload 机制减少中断。

八、Target 与 Job#

Prometheus 中非常重要的两个概念：

1
Job
2
Target

例如：

1
- job_name: linux
2
  static_configs:
3
    - targets:
4
        - 192.168.1.10:9100
5
        - 192.168.1.11:9100
6
        - 192.168.1.12:9100

这里：

1
job = linux

而：

1
targets
2
=
3
192.168.1.10:9100
4
192.168.1.11:9100
5
192.168.1.12:9100

可以理解为：

1
Job
2
 │
3
 ├── Target A
4
 ├── Target B
5
 └── Target C

Prometheus 会根据配置定期抓取这些 Target。

九、Prometheus Targets 页面#

Prometheus 自带 Web UI。

打开：

1
http://<prometheus>:9090

然后查看：

1
Status
2
→ Targets

可以看到：

1
UP
2
DOWN

例如：

1
linux/node
2
192.168.1.10:9100
3
UP

表示：

1
Prometheus
2
   ↓
3
192.168.1.10:9100
4
   ↓
5
成功采集

如果：

1
DOWN

可能是：

1
Exporter 没启动
2
端口错误
3
网络不通
4
防火墙
5
DNS
6
目标机器故障

因此：

Prometheus Targets 页面本身就是非常重要的故障排查入口。

十、PromQL 基础#

PromQL 是 Prometheus 的查询语言。

官方文档： PromQL basics

10.1 查询 Metric#

例如：

1
node_load1

表示查询：

1
1 分钟 Load

又例如：

1
node_memory_MemAvailable_bytes

表示：

1
可用内存

10.2 Label 过滤#

例如：

1
node_load1{instance="192.168.1.10:9100"}

只查询某个实例。

也可以：

1
http_requests_total{status="500"}

查询：

1
HTTP 500

10.3 Rate#

很多指标是 Counter，例如：

1
http_requests_total

它通常只增加：

如果我们想知道：

1
每秒增加多少请求

可以使用：

1
rate(http_requests_total[5m])

意思可以理解为：

1
根据最近 5 分钟的数据
2
计算平均每秒增长速度

10.4 Sum#

例如：

1
sum(rate(http_requests_total[5m]))

将多个时间序列聚合到一起。

10.5 By#

例如：

1
sum by (status) (
2
  rate(http_requests_total[5m])
3
)

可以得到：

1
200 → xxx req/s
2
404 → xxx req/s
3
500 → xxx req/s

因此 PromQL 的核心能力之一就是：

1
选择
2
+
3
过滤
4
+
5
计算
6
+
7
聚合

官方文档也将 PromQL 定义为用于实时选择和聚合时间序列数据的函数式查询语言。

十一、常用 Linux 监控 PromQL#

11.1 CPU#

CPU 使用率可以从：

1
node_cpu_seconds_total

计算。

常见查询：

1
100 - (
2
  avg by (instance) (
3
    rate(node_cpu_seconds_total{
4
      mode="idle"
5
    }[5m])
6
  ) * 100
7
)

结果：

1
CPU 使用率 %

11.2 Memory#

可以使用：

1
100 * (
2
  1 -
3
  node_memory_MemAvailable_bytes
4
  /
5
  node_memory_MemTotal_bytes
6
)

得到大致的：

1
Memory 使用率

这与上一篇：

1
free -h

所观察的概念对应。

11.3 Disk#

例如：

1
100 * (
2
  1 -
3
  node_filesystem_avail_bytes
4
  /
5
  node_filesystem_size_bytes
6
)

可以估算文件系统使用率。

11.4 Network#

例如统计网络接收速率：

1
rate(
2
  node_network_receive_bytes_total[5m]
3
)

发送：

1
rate(
2
  node_network_transmit_bytes_total[5m]
3
)

这样上一篇：

1
ip
2
ss
3
网络统计

就进入了持续监控体系。

十二、Prometheus 的指标类型#

Prometheus 常见 Metric Type：

1
Counter
2
Gauge
3
Histogram
4
Summary

12.1 Counter#

Counter 表示只增不减的累计值。

例如：

1
HTTP 请求总数
2
错误请求总数

类似：

适合计算：

1
rate(...)
2
increase(...)

12.2 Gauge#

Gauge 表示可以上下变化的当前值。

例如：

1
CPU 温度
2
内存使用量
3
并发连接数
4
队列长度

可能：

12.3 Histogram#

Histogram 用于观察一组数值的分布。

最常见：

1
HTTP 请求耗时

例如：

1
0.1s
2
0.2s
3
0.5s
4
1s
5
2s

Histogram 可以帮助回答：

这对于服务性能监控非常重要。

12.4 Summary#

Summary 也可以描述分布和分位数，但它与 Histogram 在计算方式和适用场景上有所区别。

初学阶段最需要掌握：

1
Counter
2
Gauge
3
Histogram

十三、Grafana 安装与运行#

Grafana 可以直接安装在 Linux 上，也可以运行在 Docker 中。

对于学习环境，可以使用 Docker Compose 快速启动：

1
services:
2

3
  grafana:
4
    image: grafana/grafana
5
    ports:
6
      - "3000:3000"
7
    volumes:
8
      - grafana-data:/var/lib/grafana
9

10
volumes:
11
  grafana-data:

启动：

1
docker compose up -d

查看：

1
docker compose ps

日志：

1
docker compose logs grafana

访问：

1
http://<server>:3000

Grafana 官方安装文档： Install Grafana

十四、Grafana Data Source#

Grafana 启动之后，需要告诉它：

1
数据在哪里？

这就是：

1
Data Source

例如：

1
Grafana
2
   │
3
   ▼
4
Prometheus
5
http://prometheus:9090

Grafana 官方把 Data Source 定义为连接到实际数据存储后端的连接；Grafana 可以通过这些数据源查询、可视化和告警，而不会要求把数据迁移到 Grafana 中。

添加 Prometheus：

1
Connections
2
   ↓
3
Data Sources
4
   ↓
5
Prometheus

填写：

1
URL

例如 Docker Compose 环境：

1
http://prometheus:9090

而不是：

1
http://localhost:9090

这是容器化环境中非常常见的区别：

1
Grafana Container
2
       │
3
       │
4
       ▼
5
prometheus:9090

这里的：

1
prometheus

是 Compose 网络中的服务名。

十五、Grafana Dashboard#

Dashboard 是 Grafana 最核心的使用方式之一。

可以包含多个 Panel：

1
┌──────────────────────────────────────┐
2
│ CPU Usage                            │
3
│              /\                      │
4
│         /\   /  \__                  │
5
│ _______/  \_/       \___             │
6
└──────────────────────────────────────┘
7

8
┌───────────────────┐
9
│ Memory Usage      │
10
│       62%         │
11
└───────────────────┘
12

13
┌───────────────────┐
14
│ Disk Usage        │
15
│       74%         │
16
└───────────────────┘

一个 Linux Server Dashboard 可以包含：

1
CPU
2
Memory
3
Load
4
Disk
5
Network
6
Filesystem

15.1 Panel#

每个 Panel 通常包含：

1
Query
2
+
3
Visualization

例如：

1
node_load1

然后选择：

1
Time Series

就可以看到 Load 随时间变化的曲线。

15.2 常见 Visualization#

Grafana 中常见：

1
Time Series
2
Stat
3
Gauge
4
Table
5
Bar Chart

不同数据应该选择合适的展示方式。

例如：

1
CPU 趋势
2
→ Time Series
3

4
当前 CPU
5
→ Gauge / Stat
6

7
多个服务状态
8
→ Table / Stat

十六、Grafana 变量#

当 Dashboard 面向多个主机时，不能为每台机器建立一张完全独立的 Dashboard。

可以使用：

1
Variables

例如：

1
instance

用户选择：

1
192.168.1.10:9100

Dashboard 自动切换。

例如 PromQL：

1
node_load1{
2
  instance="$instance"
3
}

于是：

1
一个 Dashboard
2
     │
3
     ├── server1
4
     ├── server2
5
     ├── server3
6
     └── server4

这对于实际运维非常重要。

十七、Prometheus 告警#

17.1 为什么需要 Alert#

监控系统不应该要求运维人员：

1
一直盯着 Grafana

例如：

1
凌晨 3 点
2
CPU > 95%

应该主动产生：

1
Alert

而不是等到早上才发现。

Prometheus 的传统告警体系可以理解为：

1
Prometheus
2
    │
3
    │ Alert Rule
4
    ▼
5
 Alert
6
    │
7
    ▼
8
Alertmanager
9
    │
10
    ├── Grouping
11
    ├── Inhibition
12
    ├── Silence
13
    └── Notification

Prometheus 官方明确将告警分成两个部分：Prometheus 中定义和评估告警规则，Alertmanager 负责对告警进行聚合、抑制、静默和通知。

17.2 Alert Rule#

例如：

1
groups:
2
  - name: node
3
    rules:
4

5
      - alert: HighCPUUsage
6
        expr: |
7
          (
8
            100 - (
9
              avg by (instance) (
10
                rate(node_cpu_seconds_total{
11
                  mode="idle"
12
                }[5m])
13
              ) * 100
14
            )
15
          ) > 90
16
        for: 5m
17

18
        labels:
19
          severity: warning
20

21
        annotations:
22
          summary: "CPU 使用率过高"
23
          description: "实例 {{ $labels.instance }} CPU 使用率超过 90%"

这里：

1
expr
2
→ 告警条件
3

4
for
5
→ 持续多久才触发
6

7
labels
8
→ 告警分类
9

10
annotations
11
→ 告警描述

17.3 为什么需要 for#

假设：

1
CPU = 95%

只持续：

1
10 秒

可能只是瞬时波动。

如果规定：

1
for: 5m

则表示：

1
条件持续 5 分钟

才触发。

这样可以减少：

1
瞬时波动
2
→ 大量误告警

十八、Alertmanager#

Alertmanager 并不是用来计算：

1
CPU > 90%

它主要负责收到 Prometheus 产生的告警后进行：

1
Grouping
2
Inhibition
3
Silencing
4
Routing
5
Notifications

例如：

1
Prometheus
2
  │
3
  ├── CPU Alert
4
  ├── Memory Alert
5
  ├── Disk Alert
6
  └── Service Alert
7
          │
8
          ▼
9
     Alertmanager
10
          │
11
          ├── Group
12
          ├── Route
13
          └── Notify
14
               │
15
               ├── Email
16
               ├── Webhook
17
               └── On-call

官方： Alerting Overview

十九、Grafana Alerting#

现在 Grafana 自身也提供完整的 Alerting 能力。

例如：

1
Grafana
2
   │
3
   ▼
4
Prometheus Data Source
5
   │
6
   ▼
7
PromQL
8
   │
9
   ▼
10
Alert Rule

Grafana 官方目前支持：

1
Grafana-managed alert rules

也可以查看 Prometheus 自己管理的规则；对于 Prometheus 原生告警规则，Grafana 中主要作为查看入口，而规则修改仍然需要回到 Prometheus 配置或规则文件中。

因此学习阶段可以先这样理解：

1
Prometheus
2
→ Metrics + PromQL + 原生告警规则
3

4
Alertmanager
5
→ 告警聚合与通知
6

7
Grafana
8
→ Dashboard + Query + Grafana Alerting

二十、Prometheus 与 Grafana 的典型架构#

一个最基础的 Linux 监控系统：

1
                 Linux Server
2
                     │
3
                     ▼
4
               node_exporter
5
                     │
6
                  /metrics
7
                     │
8
                     ▼
9
                Prometheus
10
             ┌───────┴────────┐
11
             │                │
12
          TSDB             PromQL
13
                                │
14
                                ▼
15
                             Grafana
16
                                │
17
                    ┌───────────┴───────────┐
18
                    ▼                       ▼
19
                Dashboard                 Alert

多个服务器：

1
Node 1 ── node_exporter ──┐
2
Node 2 ── node_exporter ──┤
3
Node 3 ── node_exporter ──┤
4
Node 4 ── node_exporter ──┤
5
                           ▼
6
                       Prometheus
7
                           │
8
                           ▼
9
                        Grafana

二十一、Service Discovery#

前面的配置：

1
static_configs:
2
  - targets:
3
      - 192.168.1.10:9100

属于：

1
Static Configuration

服务器多了以后：

手动维护就很麻烦。

因此 Prometheus 支持：

1
Service Discovery

例如 Kubernetes 环境中，可以通过 Kubernetes Service Discovery 动态发现目标。

1
Kubernetes
2
   │
3
   ├── Pod
4
   ├── Service
5
   └── Node
6
        │
7
        ▼
8
Service Discovery
9
        │
10
        ▼
11
Prometheus

这也是 Prometheus 非常适合云原生环境的重要原因之一。

二十二、Kubernetes 与 Prometheus#

前面的 Kubernetes 文章里学习了：

1
Node
2
Pod
3
Service
4
Deployment

现在可以将它们与监控连接起来：

1
Kubernetes
2
    │
3
    ├── Node
4
    │     └── node_exporter
5
    │
6
    ├── Pod
7
    │     └── application metrics
8
    │
9
    └── Service
10
            │
11
            ▼
12
       Prometheus
13
            │
14
            ▼
15
         Grafana

这样：

1
Kubernetes
2
→ 管理工作负载
3

4
Prometheus
5
→ 观察工作负载
6

7
Grafana
8
→ 展示观察结果

二十三、一个完整的 Linux 监控案例#

假设现在有：

1
Server A
2
192.168.1.10
3

4
Server B
5
192.168.1.11

每台服务器运行：

1
node_exporter

架构：

1
Server A
2
  │
3
  └── node_exporter :9100
4
          │
5
          ▼
6
          ┐
7
          │
8
Server B  │
9
  │       │
10
  └── node_exporter :9100
11
          │
12
          ▼
13
      Prometheus
14
          │
15
          ▼
16
       Grafana

Prometheus 配置：

1
scrape_configs:
2

3
  - job_name: linux
4
    static_configs:
5
      - targets:
6
          - 192.168.1.10:9100
7
          - 192.168.1.11:9100

在 Prometheus 中查询：

1
up

结果：

1
serverA → 1
2
serverB → 1

如果：

1
serverB → 0

就说明 Prometheus 当前无法成功采集：

1
192.168.1.11:9100

进一步排查：

1
node_exporter
2
   ↓
3
端口 9100
4
   ↓
5
网络
6
   ↓
7
防火墙
8
   ↓
9
服务器

这就是监控系统与 Linux 运维排障的结合。

二十四、Prometheus 常见故障#

24.1 Target DOWN#

现象：

1
Prometheus
2
→ Targets
3
→ DOWN

第一步：

1
curl http://<target>:9100/metrics

如果直接失败：

1
Exporter
2
   ↓
3
网络
4
   ↓
5
端口

继续检查：

1
systemctl status node_exporter

以及：

1
ss -lntp | grep 9100

24.2 Prometheus 启动失败#

首先：

1
systemctl status prometheus

然后：

1
journalctl -u prometheus

如果修改了 YAML：

1
YAML 格式错误

可能导致 Prometheus 无法加载配置。

因此修改配置后应该先验证配置，而不是直接不断重启服务。

24.3 查询没有数据#

例如：

1
node_cpu_seconds_total

没有返回数据。

排查：

1
Metric 是否存在
2
       ↓
3
Target 是否 UP
4
       ↓
5
Exporter 是否正常
6
       ↓
7
Prometheus 是否成功采集
8
       ↓
9
时间范围是否正确
10
       ↓
11
Label 是否匹配

尤其注意：

1
instance="..."

写错后也可能导致：

1
No data

24.4 Grafana 没有数据#

首先不要马上修改 Dashboard。

先检查：

1
Grafana
2
   ↓
3
Data Source
4
   ↓
5
Prometheus
6
   ↓
7
PromQL
8
   ↓
9
Metrics

在 Grafana Data Source 中进行连接测试。

Grafana 当前官方文档也把 Prometheus 作为标准 Data Source，并提供 PromQL Query Editor。

如果 Data Source 正常，再检查：

1
Dashboard Query

二十五、监控系统的几个重要原则#

25.1 监控不是越多越好#

如果一个 Dashboard：

1
1000 个 Panel

看起来非常“专业”。

但真正故障时：

1
找不到重点

就失去了监控的价值。

更好的方式是：

1
Overview
2
   ↓
3
发现异常
4
   ↓
5
Service
6
   ↓
7
Host
8
   ↓
9
Detail

25.2 从业务目标设计指标#

不要只监控：

1
CPU
2
Memory
3
Disk

还要问：

1
用户是否能够访问？
2
请求是否成功？
3
响应是否变慢？
4
错误率有没有增加？

例如 Web 服务：

1
Availability
2
Latency
3
Traffic
4
Errors

这些比单纯：

1
CPU = 50%

更接近业务健康程度。

25.3 监控指标应该能解释问题#

例如发现：

1
HTTP 5xx ↑

接下来应该能够通过：

1
CPU
2
Memory
3
Database Connections
4
Latency

进一步判断：

1
资源不足？
2
数据库问题？
3
网络问题？
4
应用本身异常？

这样监控才真正成为：

1
故障排查工具

二十六、从 Metrics 走向 Logs#

到这里，我们主要处理的是：

1
Metrics

例如：

1
CPU = 80%
2
Memory = 70%
3
QPS = 1000
4
Latency = 200ms

它们很适合回答：

1
发生了什么？
2
什么时候发生？
3
严重程度如何？

但是它们往往不能直接回答：

1
为什么发生？

于是需要：

1
Logs

例如：

1
2026-09-14 10:30:01 ERROR
2
Database connection refused

因此后续会进入：

1
Metrics
2
→ Prometheus
3

4
Visualization
5
→ Grafana
6

7
Logs
8
→ 日志收集 / ELK
9

10
Metrics + Logs + Traces
11
→ OpenTelemetry / 可观测性体系

二十七、监控体系整体模型#

目前已经可以把前两篇监控内容串起来：

1
Linux Server
2
     │
3
     ├── CPU
4
     ├── Memory
5
     ├── Disk
6
     ├── Network
7
     ├── Process
8
     └── Service
9
            │
10
            ▼
11
        Exporter
12
            │
13
            ▼
14
       Prometheus
15
            │
16
            ├── Time Series
17
            ├── PromQL
18
            └── Alert Rules
19
                    │
20
                    ▼
21
               Alertmanager
22
                    │
23
                    ▼
24
                Notification
25

26
            Prometheus
27
                 │
28
                 ▼
29
              Grafana
30
                 │
31
                 ├── Dashboard
32
                 ├── Visualization
33
                 └── Alerting

而完整的可观测性体系会继续扩展成：

1
                  Observability
2
                       │
3
          ┌────────────┼────────────┐
4
          ▼            ▼            ▼
5
       Metrics        Logs        Traces
6
          │            │            │
7
      Prometheus       │        OpenTelemetry
8
          │            │            │
9
       Grafana       ELK/...        │
10
          │            │            │
11
          └────────────┼────────────┘
12
                       ▼
13
                   Correlation
14
                       │
15
                       ▼
16
                  Root Cause

二十八、Prometheus 与 Grafana 的关系总结#

最后可以用一句非常简单的话区分两者：

1
Prometheus
2
→ “把指标收进来、存下来、查出来”
3

4
Grafana
5
→ “把数据展示出来，让人看懂”

更加完整地说：

1
Exporter
2
   ↓
3
Metrics
4
   ↓
5
Prometheus
6
   ├── Storage
7
   ├── PromQL
8
   └── Alert Rules
9
         ↓
10
    Alertmanager
11

12
Prometheus
13
   ↓
14
Grafana
15
   ├── Dashboard
16
   ├── Visualization
17
   └── Alerting

而上一篇 Linux 服务监控中的：

1
top
2
free
3
df
4
iostat
5
ss
6
systemctl
7
journalctl

现在变成了：

1
人工查看
2
     ↓
3
Exporter
4
     ↓
5
Prometheus
6
     ↓
7
Grafana
8
     ↓
9
持续监控

因此：

Prometheus 解决“持续采集和查询指标”，Grafana 解决“把指标组织成可视化界面”，而 Exporter 则负责把 Linux、数据库和其他系统的状态转换成 Prometheus 能理解的 Metrics。

一、Prometheus 与 Grafana 概述#

1.1 为什么需要监控系统#

1.2 Prometheus 是什么#

1.3 Grafana 是什么#

二、Prometheus 的核心数据模型#

2.1 Metric#

2.2 Labels#

2.3 Label Cardinality#

三、Prometheus 的 Pull 模型#

3.1 Prometheus 如何获取指标#

3.2 /metrics#

3.3 Push 与 Pull#

四、Exporter#

4.1 Exporter 是什么#

4.2 node_exporter#

五、安装 Prometheus#

5.1 创建 Prometheus 用户#

5.2 配置文件#

5.3 启动 Prometheus#

六、使用 systemd 管理 Prometheus#

七、配置 node_exporter#

7.1 启动 node_exporter#

7.2 systemd#

7.3 Prometheus 配置 Target#

八、Target 与 Job#

九、Prometheus Targets 页面#

十、PromQL 基础#

10.1 查询 Metric#

10.2 Label 过滤#

10.3 Rate#

10.4 Sum#

10.5 By#

十一、常用 Linux 监控 PromQL#

11.1 CPU#

11.2 Memory#

11.3 Disk#

11.4 Network#

十二、Prometheus 的指标类型#

12.1 Counter#

12.2 Gauge#

12.3 Histogram#

12.4 Summary#

十三、Grafana 安装与运行#

十四、Grafana Data Source#

十五、Grafana Dashboard#

15.1 Panel#

15.2 常见 Visualization#

十六、Grafana 变量#

十七、Prometheus 告警#

17.1 为什么需要 Alert#

17.2 Alert Rule#

17.3 为什么需要 for#

十八、Alertmanager#

十九、Grafana Alerting#

二十、Prometheus 与 Grafana 的典型架构#

二十一、Service Discovery#

二十二、Kubernetes 与 Prometheus#

二十三、一个完整的 Linux 监控案例#

二十四、Prometheus 常见故障#

24.1 Target DOWN#

24.2 Prometheus 启动失败#

24.3 查询没有数据#

24.4 Grafana 没有数据#

二十五、监控系统的几个重要原则#

25.1 监控不是越多越好#

25.2 从业务目标设计指标#

25.3 监控指标应该能解释问题#

二十六、从 Metrics 走向 Logs#

二十七、监控体系整体模型#

二十八、Prometheus 与 Grafana 的关系总结#

外部参考#