Prometheus+Grafana监控实战

Prometheus与Grafana核心概念及2024新版特性解析

其实，咱们搞监控，Prometheus 和 Grafana 这对 CP 现在基本上就是业界的标配了。很多刚入门的小伙伴容易搞混，这俩到底谁是干啥的？一句话给你讲清楚：Prometheus 负责“抓数据”和“存数据”，Grafana 负责“看数据”和“报警展示”。它俩分工明确，一个像勤劳的采集工，一个像大屏设计师。

核心概念扫盲

咱们先聊聊 Prometheus。它最核心的设计哲学就是 Pull 模式（拉取）。可以这么理解，就是 Prometheus 服务器会主动找你配置的那些目标（Target），比如你的 Java 应用或者 Linux 机器，每隔一段时间去问它们：“嘿，你现在的 CPU 用了多少啊？给我报个数呗。” 这种方式在云原生环境里特别舒服，因为服务实例可能会频繁重启或扩容，Prometheus 配合服务发现（Service Discovery）就能自动找到这些新实例，不用你手动去改配置。

而 Grafana 呢，它不做采集，它只做展示。它支持连接几十种数据源，当然也包括 Prometheus。你在 Grafana 里写 PromQL（Prometheus 的查询语言），它帮你去 Prometheus 里取数，然后画成漂亮的曲线图。

2024 新版特性与版本号

咱们做技术的最忌讳用老掉牙的版本。截止到 2024 年 3 月，Prometheus 的最新稳定版已经到了 v2.49.1。如果你现在去官网下，会发现它的主要分支正在向 v3.0 演进，重点都在优化存储引擎的性能。

Grafana 这边更猛，最新版已经到了 v10.4.x（2024年初发布的）。这个版本有几个很骚的新特性，咱们必须要提一下：

AI/ML 能力增强：Grafana 现在内置了 Sift 异常检测，不用你死磕阈值了，它能自己看出数据曲线是不是“不对劲”。
统一存储（Unified Storage）：这是 Grafana 9/10 新架构的核心，以前 Dashboard 是存在数据库里的文件，现在更像是一个配置中心，迁移起来方便多了。

核心组件与数据模型

Prometheus 的数据模型很有意思，它不像传统数据库那样是表格，而是 多维数据模型。

Metric Name：指标名，比如 http_requests_total。
Labels：标签。这是 Prometheus 的灵魂。比如 {method="POST", handler="/api/login"}。
Time Series：指标名 + 一组唯一的标签，就构成了一个时间序列。

Labels 千万别乱用！很多新手喜欢把 user_id 这种基数特别大的东西当标签，这会导致 Prometheus 产生海量的时间序列，直接把内存撑爆。这叫 High Cardinality（高基数） 陷阱，面试的时候也经常问。

2024-2026 发展趋势

咱们看远一点，现在的监控圈有几个很火的趋势：

eBPF 深度集成：以后监控不用在容器里装 Agent 了，利用 Linux 内核的 eBPF 技术，直接从内核层抓网络包和调用链，无侵入式监控，这玩意儿以后绝对是主流。
OpenTelemetry (OTel) 融合：以前 Trace（链路）、Log（日志）、Metric（指标）是三家分立的。现在 OpenTelemetry 想一统天下，Prometheus 现在也在逐步兼容 OTLP 协议，以后采集标准会越来越统一。
LLM 辅助运维：现在社区里都在讨论怎么用大语言模型来生成 PromQL。你想想，以后你直接说“帮我查一下过去 5 分钟 CPU 最高的那个 Pod”，AI 直接给你生成查询语句，多爽。

📖 学习建议

🔧 实战技巧：如果你是新项目，直接上 Prometheus v2.49+ 和 Grafana v10.4+。千万别为了所谓的“稳定”去用 v1.x 或者 v8.x 的 Grafana，你会错过很多 AI 辅助诊断的功能，而且新版的存储引擎对 SSD 的优化非常好，能省不少机器成本。

---

Docker Compose快速部署Prometheus v2.49与Grafana v10.4

很多教程一上来就让你 wget 一堆二进制文件，手动敲启动命令，那叫一个麻烦。作为过来人，我强烈建议你直接用 Docker Compose 来起环境。打个比方，咱们是为了学监控，不是为了学怎么配置 Linux 系统服务，能一键启动就别折腾。

环境准备

首先你得有个 Docker 环境。如果你本地没装，赶紧去装一个 Docker Desktop（Windows/Mac）或者直接在 Linux 上装 Docker Engine。

编写 Docker Compose 配置

咱们直接上代码。我会把版本号写死，确保你跑起来和我写的一样。咱们不仅要起 Prometheus 和 Grafana，顺便把 Node Exporter（监控主机用的）也一起带上，这样一会儿直接就能看到数据。

创建一个文件夹，比如叫 monitoring-stack，在里面新建一个 docker-compose.yml 文件。

version: '3.8'

networks:
  monitoring:
    driver: bridge

services:
  # Prometheus 服务
  prometheus:
    image: prom/prometheus:v2.49.1
    container_name: prometheus
    restart: unless-stopped
    ports:
      - "9090:9090"
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
      - '--web.console.libraries=/usr/share/prometheus/console_libraries'
      - '--web.console.templates=/usr/share/prometheus/consoles'
      - '--web.enable-lifecycle' # 允许通过 API 重载配置，不用重启容器
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    networks:
      - monitoring

  # Grafana 服务
  grafana:
    image: grafana/grafana:10.4.1
    container_name: grafana
    restart: unless-stopped
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin123 # 设置管理员密码，别用默认的了
      - GF_USERS_ALLOW_SIGN_UP=false
    volumes:
      - grafana_data:/var/lib/grafana
    networks:
      - monitoring

  # Node Exporter 服务
  node_exporter:
    image: prom/node-exporter:v1.7.0
    container_name: node_exporter
    restart: unless-stopped
    ports:
      - "9100:9100"
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/rootfs:ro
    command:
      - '--path.procfs=/host/proc'
      - '--path.rootfs=/rootfs'
      - '--path.sysfs=/host/sys'
    networks:
      - monitoring

volumes:
  prometheus_data:
  grafana_data:

配置 Prometheus

注意上面 Compose 文件里挂载了 ./prometheus.yml。咱们得在同一目录下创建这个配置文件，告诉 Prometheus 去哪儿抓数据。

global:
  scrape_interval: 15s # 每 15 秒抓一次数据
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  - job_name: 'node_exporter'
    static_configs:
      - targets: ['node_exporter:9100'] # 这里用的是 Docker 服务名，不是 localhost

启动与验证

代码写好了，直接启动。在 monitoring-stack 目录下打开终端，运行：

docker compose up -d

等几秒钟，容器就跑起来了。

访问 http://localhost:9090，这是 Prometheus 的界面。点击顶部的 Status -> Targets，你应该能看到 node_exporter 的状态是 UP。
访问 http://localhost:3000，这是 Grafana。账号是 admin，密码是咱们在 Compose 里设的 admin123。

避雷经验指南

避雷经验提醒：很多新手在配置 Prometheus 的 targets 时，喜欢写 localhost:9100。在 Docker Compose 环境里，这是大忌！因为 Prometheus 容器里的 localhost 指的是它自己那个容器，而不是你宿主机。所以一定要写成服务名，比如 node_exporter:9100，利用 Docker 的内网 DNS 去解析。

📖 学习建议

🔧 实战技巧：记得加上 --web.enable-lifecycle 这个启动参数。加了它之后，你修改了 prometheus.yml 配置，不用重启容器，直接发一个 HTTP POST 请求 curl -X POST http://localhost:9090/-/reload 就能热加载配置，这在生产环境里非常有用，避免监控中断。

---

实战：监控Linux主机与MySQL数据库（Node Exporter配置）

环境搭好了，现在咱们来干点实事。监控 Linux 主机是最基础的需求，但很多教程只教你怎么装 Node Exporter，不教你怎么在 Grafana 里看。咱们这一章直接打通任督二脉，从采集到可视化，一条龙搞定。

Node Exporter 深度解析

Node Exporter 是 Prometheus 官方提供的，专门用来暴露 *NIX 内核（Linux/Unix）硬件和操作系统指标的。它跑起来后会监听 9100 端口。

咱们上一章已经用 Docker 把 Node Exporter 跑起来了。如果你没用 Docker，直接下载二进制包运行也行，但记得要暴露 /proc 和 /sys 目录，因为 CPU、内存、磁盘这些数据全在这两个内核伪文件系统里读出来的。

在 Grafana 中配置数据源

有了 Node Exporter 采集数据，Prometheus 也抓到了，现在咱们得让 Grafana 去读这些数据。

登录 Grafana (http://localhost:3000)。
左边菜单栏点 Connections (连接) -> Data Sources (数据源)。
点 Add data source，选 Prometheus。
最关键的一步：在 Prometheus server URL 里填 http://prometheus:9090。

- *注意：还是那个 Docker 网络的问题，Grafana 容器访问 Prometheus 容器，必须用服务名 prometheus，不能用 localhost。*

拉到最下面点 Save & Test。如果看到绿色对勾，说明通了。

导入 Dashboard

配置好数据源后，咱们得画图。简单来说，没人会自己从零开始画 CPU、内存的图，太累了。社区有现成的 JSON 模板。

左边菜单栏点 Dashboards (看板) -> New -> Import。
在 Import via grafana.com 输入框里，输入著名的 Node Exporter 仪表盘 ID：1860（这是最经典的一个，兼容性极好）。
点 Load，选择你刚才配置的 Prometheus 数据源。
点 Import。

瞬间，一个包含 CPU、内存、磁盘 IO、网络流量的高大上监控面板就出来了。

监控 MySQL 数据库

光看机器不够，咱们的数据库也得盯着。监控 MySQL，咱们得用 mysqld_exporter。

#### 1. 配置 MySQL 权限

首先得在 MySQL 里给 Exporter 一个只读账号，别给它 root 权限，这是安全规范。

CREATE USER 'exporter'@'%' IDENTIFIED BY 'exporter_password' WITH MAX_USER_CONNECTIONS 3;
GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'exporter'@'%';
FLUSH PRIVILEGES;

#### 2. 修改 Docker Compose

咱们继续修改之前的 docker-compose.yml，把 MySQL 和 mysqld_exporter 加进去。

  # 新增 MySQL 服务
  mysql:
    image: mysql:8.0
    container_name: mysql
    environment:
      MYSQL_ROOT_PASSWORD: rootpass
      MYSQL_DATABASE: testdb
    networks:
      - monitoring

  # 新增 mysqld_exporter 服务
  mysqld_exporter:
    image: prom/mysqld-exporter:v0.15.1
    container_name: mysqld_exporter
    ports:
      - "9104:9104"
    environment:
      - DATA_SOURCE_NAME=exporter:exporter_password@(mysql:3306)/testdb
    networks:
      - monitoring
    depends_on:
      - mysql

#### 3. 修改 Prometheus 配置

再去 prometheus.yml 里加一个 job，让 Prometheus 去抓 MySQL 的指标。

  - job_name: 'mysql'
    static_configs:
      - targets: ['mysqld_exporter:9104']

重启一下 Prometheus 或者热加载配置，去 Targets 页面确认 mysql 这个 job 是 UP 状态。

#### 4. 导入 MySQL Dashboard

同样在 Grafana 里 Import，这次用 ID：7362（这是 Percona 出品的一个很详细的 MySQL 监控模板）。

核心指标解读

咱们看面板不能只看热闹，得看门道。

对于 Linux：重点看 node_memory_MemAvailable_bytes（可用内存）和 node_filesystem_avail_bytes（磁盘剩余）。如果磁盘满了，服务必挂。
对于 MySQL：重点看 mysql_global_status_threads_connected（当前连接数）和 mysql_slave_status_seconds_behind_master（主从延迟，如果有主从的话）。

mysqld_exporter 默认不会抓取所有指标，有些需要通过启动参数开启，比如 collect.info_schema.processlist。如果你发现有些面板没数据，先去 Exporter 的启动参数里看看是不是没开启对应的采集项。

⚡ 效率提示

📌 要点提醒：不要盲目导入所有的 Dashboard。Node Exporter 的 1860 模板非常重，包含了几百个指标。对于生产环境，建议你根据“黄金四指标”（延迟、流量、错误、饱和度）精简一下面板，只保留你真正关心的。不然 Grafana 渲染起来也很吃资源，而且看着眼晕。

4. PromQL查询语言详解与Grafana智能可视化面板构建

搞监控如果不懂 PromQL，那你基本上就是用 Prometheus 做了个高级版的“看图说话”。可以这么理解，PromQL 就是 Prometheus 的 SQL，它是让你从海量时序数据里捞出你想要的东西的核心武器。咱们现在用的 Prometheus 最新稳定版是 v2.49.1（2024年3月发布），这版本在查询引擎上做了不少性能优化，跑复杂查询时比老版本快不少。

PromQL 核心概念与即时查询

PromQL 的强大之处在于它的多维数据模型。你不要把它当成简单的 Key-Value，它其实是 Metric Name + Labels 的组合。

比如你有一个指标叫 http_requests_total，它后面可能跟了 job="web", status="200" 这样的标签。

核心要点：PromQL 分为即时查询（Instant Query）和范围查询（Range Query）。

即时查询：就是看这一刻的值。比如 up，看看现在是 0 还是 1。
范围查询：看一段时间内的变化。比如 rate(http_requests_total[5m])，看过去 5 分钟的增长率。

这里有个新手必踩的坑：直接对着 Counter 类型的指标（比如请求总数）做算术运算是没意义的，因为它只增不减。你必须要对它做 rate 或者 increase 处理，后面章节会细讲。

Grafana 可视化与变量联动

光会查还不够，咱们得把数据“秀”出来。现在 Grafana 最新版都 v10.4.x 了，这版本在 AI 可视化和交互上做得挺丝滑的。咱们在构建面板时，千万别把 IP 写死，要用 Variables（变量）。

举个实战例子，我们想做一个通用的主机监控面板，能切换不同的主机。

🔧 实战技巧：在 Grafana 里配置变量时，一定要用 label_values() 函数去自动抓取 Prometheus 里的标签，这样以后加了新机器，面板自动更新，不用手动改。

Grafana Dashboard 变量配置示例（以监控 Node Exporter 为例）：

在 Dashboard 设置 -> Variables 里新建一个变量：

Name: instance
Type: Query
Data source: 你的 Prometheus
Query: label_values(node_uname_info, instance)

这样，你就能在 Panel 里引用 $instance 了。

Panel 配置代码示例（PromQL）：

假设你要在 Grafana 里展示某台机器的 CPU 使用率，PromQL 得这么写（注意这里的 $instance 引用了上面的变量）：

# 计算 CPU 非空闲时间占比
1 - (
  sum by(instance) (rate(node_cpu_seconds_total{mode="idle", instance="$instance"}[5m]))
  / 
  sum by(instance) (rate(node_cpu_seconds_total{instance="$instance"}[5m]))
)

这段代码的原理是：抓取所有 CPU 模式的时间片，减去空闲（idle）的，剩下的就是干活的时间。用 rate 计算 5 分钟内的速率，最后算个占比。

2024 新特性：Grafana 的 AI 辅助

现在的 Grafana v10.4 已经开始集成 AI 能力了（虽然还在发展中）。比如它内置的 Sift 异常检测功能，能帮你自动识别指标里的毛刺，不用你死盯着阈值调来调去。如果你在云原生环境下折腾，这种智能分析能省不少事儿。

---

5. Alertmanager告警集成与Thanos高可用存储方案选型

监控做完了，不能光看不叫啊。半夜服务器挂了，你还在梦乡里，这就不行了。所以告警集成是重头戏。同时，Prometheus 默认是单机存储，数据存本地磁盘，撑死也就存个把月，想看去年的数据？没门。这就引出了高可用和长期存储的话题。

Alertmanager 配置实战

Prometheus 抓到数据后，如果触发了告警规则，会把告警发给 Alertmanager。这玩意儿负责“去重、分组、抑制和发送”。

实战经验预警：很多新手直接把邮件配置写在 Prometheus 里，这是不对的。Prometheus 只负责产生告警，Alertmanager 负责发通知。

咱们来看个最经典的配置：通过企业微信或者钉钉发告警，并且做一下分组，别一股脑全发过来把群聊炸了。

Alertmanager 配置文件 (alertmanager.yml) 示例：

global:
  # 这里以企业微信为例，如果是钉钉，需要配置 webhook
  wechat_api_url: 'https://qyapi.weixin.qq.com/cgi-bin/'
  wechat_api_secret: 'YOUR_SECRET' # 建议用环境变量或文件引用，别硬编码
  wechat_api_corp_id: 'YOUR_CORP_ID'

route:
  group_by: ['alertname', 'cluster', 'service'] # 根据这几个标签分组
  group_wait: 10s      # 等 10 秒，看看还有没有同组的告警一起发
  group_interval: 10s  # 两组告警之间间隔 10 秒
  repeat_interval: 12h # 警报发了一次，12小时内不再重复发（除非恢复）
  receiver: 'wechat'   # 默认接收者

receivers:
- name: 'wechat'
  wechat_configs:
  - send_resolved: true # 告警恢复时也发通知
    api_secret: 'YOUR_SECRET'
    corp_id: 'YOUR_CORP_ID'
    agent_id: 'YOUR_AGENT_ID'
    to_user: '@all' # 发给所有人，或者指定用户

# 抑制规则：如果机器都挂了，就别发上面跑的服务的告警了，没意义
inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['instance'] # 同一个实例上发生的

📌 要点提醒：一定要配置 inhibit_rules（抑制规则）。比如你的机器宕机了，上面跑的 10 个服务肯定也挂了，如果不抑制，你会收到 11 条告警（1条机器+10条服务）。配了抑制，你只会收到 1 条机器挂了的告警，清爽多了。

Thanos vs VictoriaMetrics：存储选型

Prometheus 的本地 TSDB 虽然快，但没法做集群。现在社区里吵得最凶的就是 Thanos 和 VictoriaMetrics 的选型。

Thanos：架构比较重，依赖对象存储（S3/OSS），组件多（Sidecar, Store, Query），部署复杂，但它是 CNCF 毕业项目，生态好，跟 Prometheus 原生兼容度极高。
VictoriaMetrics：架构极简，单二进制文件就能跑，对资源消耗比 Thanos 低，查询性能在某些场景下吊打 Thanos，但它是独立项目，不是 CNCF 的“亲儿子”。

我的个人建议：

如果你是小团队或者追求极简运维，直接上 VictoriaMetrics。它的 vmstorage + vminsert + vmselect 架构比 Thanos 的组件堆砌好维护多了，而且它兼容 Prometheus 的 Remote Write 协议，接入成本几乎为零。

如果你已经在用 Kubernetes，且对对象存储有强依赖，Thanos 可能更合适。但换个角度看，对于绝大多数中小规模集群，VictoriaMetrics 是性价比之王。

---

6. 常见问题排查：Rate与Increase区别及Prometheus求职必备知识点

这一章咱们聊聊那些让你面试卡壳、排错头大的细节。特别是 PromQL 里那几个函数，长得像但意思完全不同。

Rate 与 Increase 的爱恨情仇

这是常见面试问题，也是实际工作中最容易算错数据的点。

场景：你有一个 Counter 类型的指标 http_requests_total，记录了从开机到现在的总请求数。

你想知道过去 5 分钟，平均每秒有多少个请求（QPS）。

误区：很多人直接写 increase(http_requests_total[5m])，以为这就是 QPS。

真相：

rate(http_requests_total[5m])：计算的是每秒的增长率。它是 increase 除以时间（秒）。
increase(http_requests_total[5m])：计算的是过去 5 分钟内总共增加了多少请求（是个总量）。

代码示例与对比：

假设你 5 分钟前请求数是 1000，现在是 1600。

rate(...[5m]) 的结果大概是 (1600-1000) / 300秒 = 2。意思是每秒 2 个请求。
increase(...[5m]) 的结果大概是 600。意思是 5 分钟内一共增加了 600 个请求。

注意：

如果你要画 QPS 图，用 rate。
如果你要统计过去 1 小时内订单增长了多少（总量），用 increase。
实际案例提醒：rate 会自动处理 Counter 的重置（比如服务重启计数器归零），所以放心用，别自己瞎写脚本去算差值。

Prometheus 与 Zabbix 的核心区别

面试官问这个，其实是想看你懂不懂云原生。

Pull vs Push：Prometheus 是 Pull（拉） 模式，它主动去目标那儿抓数据。好处是可以通过 UP 指标直接知道目标是否存活。Zabbix 主要是 Push（推）或者基于 Agent 的主动模式，配置起来相对繁琐。
数据模型：Prometheus 用 Labels（标签），Zabbix 用 Host/Item。标签的灵活性完爆固定层级，比如你给一个 Pod 打上 env=prod，Prometheus 瞬间就能筛选出来，Zabbix 可能得重新建一套模板。
存储：Prometheus 是时序数据库（TSDB），Zabbix 依赖关系型数据库（MySQL/PostgreSQL），所以在大规模监控下，Prometheus 的查询性能通常更优。

高可用方案：Thanos 与 Cortex (Mimir)

面试时如果聊到数据持久化和高可用，别只说“加磁盘”。

现在主流方案是 Thanos 或者 Grafana Mimir（前身是 Cortex）。

Thanos：通过 Sidecar 把 Prometheus 的数据上传到 S3，然后 Query 组件去统一查询。它的特点是“无状态查询”，Prometheus 还是各自存各自的数据，Thanos 负责汇总。
Mimir：Grafana Labs 搞的，架构更偏向“统一存储”。它把 Prometheus 当成“写入器”，数据全扔给 Mimir 集群。

🔧 实战技巧：如果你在面试中被问到“Prometheus 怎么保证数据不丢且高可用”，标准的回答套路是：

部署两个一样的 Prometheus 实例（双写）。
用 remote_write 把数据写入 VictoriaMetrics 或 Mimir。
用 Thanos Sidecar 做长期备份到对象存储。

这样一来，既解决了单机故障问题，又解决了数据长期存储问题。

最后，别忘了 Prometheus v2.49.1 已经开始向 v3.0 演进了，未来的趋势是 OpenTelemetry 融合 和 eBPF 深度集成。这意味着以后你写代码抓指标，可能不用埋点，直接用 eBPF 在内核层就把数据抓出来了，这才是真正的“黑科技”。