如何利用Prometheus和Grafana监控MySQL数据库性能指标

阿墨同学_2788

发布时间：2025-09-08 12:45:01

495人浏览过

来源于php中文网

原创

部署MySQL监控需先配置mysqld_exporter收集指标，再由Prometheus抓取，最后在Grafana可视化。核心步骤包括：创建专用监控用户并授予权限（SELECT on performance_schema, information_schema, sys；REPLICATION CLIENT；PROCESS）；正确设置DATA_SOURCE_NAME连接字符串；确保网络连通性及端口开放（MySQL 3306，exporter 9104）；将mysqld_exporter作为systemd服务运行；在Prometheus中添加job抓取exporter指标；Grafana导入模板或自定义仪表盘展示QPS、TPS、连接数、缓冲池命中率、慢查询、锁等待、复制延迟等关键指标；并通过PromQL设置基于阈值和持续时间的告警规则，结合Alertmanager实现有效通知。常见问题多源于权限不足、连接配置错误或防火墙限制，需通过日志排查。该体系实现对MySQL性能瓶颈的深度分析与提前预警。

如何利用prometheus和grafana监控mysql数据库性能指标

利用Prometheus和Grafana监控MySQL数据库性能，核心在于部署一个MySQL Exporter来收集数据库的各种指标，然后让Prometheus抓取这些数据，最终在Grafana中进行可视化和报警。这套组合拳能让你对MySQL的运行状况一览无余，及时发现并解决潜在的性能问题。

解决方案

要搭建这套监控体系，我们需要依次完成几个关键步骤。这不仅仅是技术上的部署，更是一种对数据驱动型运维的思维转变。

首先，部署

mysqld_exporter

。这是Prometheus生态中专门用于MySQL监控的工具。你需要在每个需要监控的MySQL实例所在的服务器上安装并运行它。通常，我会选择从GitHub下载预编译的二进制文件，解压后直接运行。为了让

mysqld_exporter

能够访问MySQL的性能数据，你需要在MySQL中创建一个专门的用户，并赋予其只读的权限，例如

GRANT SELECT ON performance_schema.* TO 'exporter'@'localhost' IDENTIFIED BY 'your_password';

此外，为了获取更全面的指标，比如InnoDB的统计信息，还需要授予对

information_schema

和

sys

数据库的

SELECT

权限。配置时，通过

DATA_SOURCE_NAME

环境变量或命令行参数指定连接字符串，比如

user:password@(hostname:port)/

。我个人习惯把它作为一个systemd服务来管理，确保它能随系统启动并保持运行，这样也方便日志管理和状态检查。

其次，配置Prometheus抓取

mysqld_exporter

的指标。在Prometheus的配置文件

prometheus.yml

中，你需要添加一个新的

scrape_config

。这部分告诉Prometheus去哪里找

mysqld_exporter

暴露的HTTP接口。通常，

mysqld_exporter

默认监听

端口。一个典型的配置片段可能看起来像这样：

- job_name: 'mysql'
  static_configs:
    - targets: ['your_mysql_server_ip:9104']
      labels:
        instance: 'mysql-primary' # 给实例一个有意义的标签

别忘了重启Prometheus服务，让新的配置生效。我发现很多人会在这里犯错，忘记重启服务，然后疑惑为什么看不到数据。Prometheus的Web UI（通常在

端口）可以帮助你检查

Targets

状态，确认是否成功抓取到

mysqld_exporter

的指标。

最后，在Grafana中构建仪表盘。这是将原始数据转化为有意义图表的关键一步。你需要在Grafana中添加Prometheus作为数据源，这很简单，只需要指定Prometheus的URL。之后，你可以选择导入社区已经共享的MySQL仪表盘模板（例如，Grafana Labs上有很多优秀且成熟的模板，ID如7362或10705就非常流行），这些模板通常包含了丰富的图表，覆盖了MySQL的各种核心性能指标。当然，如果你有特定的监控需求，也可以从零开始，根据Prometheus抓取到的指标（比如

mysql_global_status_queries_total

、

mysql_global_status_innodb_buffer_pool_reads_total

等）构建自己的图表。我通常会从导入一个通用模板开始，然后根据实际情况调整或添加一些我特别关心的指标，比如特定业务查询的QPS或慢查询计数。

核心MySQL性能指标有哪些，以及如何通过Prometheus进行采集？

在我看来，监控MySQL不仅仅是看它有没有“活着”，更重要的是看它“活得好不好”，以及在面临压力时表现如何。因此，选择合适的性能指标至关重要。我通常会关注以下几类核心指标：

连接数（Connections）：
```
mysql_global_status_threads_connected
```
和
```
mysql_global_status_threads_running
```
。前者表示当前打开的连接数，后者表示正在执行查询的连接数。过高的连接数可能导致MySQL资源耗尽，而运行连接数长时间居高不下则暗示着查询效率低下或并发瓶颈。
```
mysqld_exporter
```
会直接采集这些数据。
查询吞吐量（QPS/TPS）：
```
mysql_global_status_queries_total
```
和
```
mysql_global_status_com_commit
```
、
```
mysql_global_status_com_rollback
```
。QPS（每秒查询数）是衡量数据库活跃度的直接指标，而TPS（每秒事务数）则反映了事务处理能力。通过计算这些指标的速率（
```
rate()
```
函数在Prometheus中非常有用），我们可以得到实时的QPS和TPS。
缓冲池命中率（Buffer Pool Hit Rate）：InnoDB缓冲池是MySQL性能的关键。我主要关注
```
mysql_global_status_innodb_buffer_pool_reads_total
```
和
```
mysql_global_status_innodb_buffer_pool_read_requests_total
```
。理想情况下，命中率应该非常高（99%以上），如果持续下降，说明MySQL正在频繁地从磁盘读取数据，这通常是性能瓶颈的信号。
慢查询（Slow Queries）：
```
mysql_global_status_slow_queries_total
```
。慢查询是性能杀手，它们的数量激增往往意味着某些SQL语句需要优化，或者索引失效。这个指标可以直接告诉你是否存在这类问题。
锁与等待（Locks & Waits）：
```
mysql_global_status_innodb_row_lock_current_waits
```
和
```
mysql_global_status_innodb_row_lock_time_avg
```
。高并发场景下，锁竞争是常态，但如果等待时间过长或等待数量过多，就可能导致事务阻塞，影响整体性能。
```
mysqld_exporter
```
会暴露这些来自
```
information_schema
```
和
```
performance_schema
```
的指标。
复制延迟（Replication Lag）：对于主从架构，
```
mysql_slave_status_seconds_behind_master
```
至关重要。这个指标直接反映了从库与主库的数据同步延迟，过高的延迟可能导致数据不一致或读写分离失效。

git摸鱼周报自动化
生成周报：读取本机 Git 仓库最近一周的提交记录，按项目分类提炼总结，生成标准周报格式，通过微信推送并返回给用户。触发词：周报、weekly report、git总结、提交记录总结、工作周报。

下载

mysqld_exporter

通过连接到MySQL实例，查询

SHOW GLOBAL STATUS

、

SHOW ENGINE INNODB STATUS

、

SHOW SLAVE STATUS

以及

information_schema

和

performance_schema

中的各种视图来获取这些指标，然后以Prometheus可识别的格式暴露出来。所以，只要

mysqld_exporter

配置正确，这些核心指标都能被Prometheus轻松采集到。

配置

mysqld_exporter

时，有哪些常见的权限和连接问题需要注意？

说实话，我在配置

mysqld_exporter

的时候，最常遇到的问题就是权限和连接相关的。这些小细节往往最容易被忽视，却能让你抓狂好一阵子。

1. MySQL用户权限不足： 这是最常见的“拦路虎”。

mysqld_exporter

需要一个MySQL用户来连接数据库并查询各种状态信息。如果这个用户的权限不足，它就无法获取到所有需要的指标，或者根本无法连接。

问题表现：
```
mysqld_exporter
```
的日志中会报错，提示权限不足，或者Prometheus抓取到的指标数量异常少，很多关键指标缺失。

解决策略： 确保你创建的用户拥有以下权限：

```
SELECT
```
权限在
```
performance_schema.*
```
、
```
information_schema.*
```
和
```
sys.*
```
上。
```
performance_schema
```
提供了大量的运行时统计信息，
```
information_schema
```
包含元数据，
```
sys
```
库则聚合了许多有用的性能视图。
对于某些高级指标，例如InnoDB的死锁信息，可能需要
```
PROCESS
```
权限。
如果你要监控复制状态，还需要
```
REPLICATION CLIENT
```
权限。

一个比较通用的授权语句（仅限监控，不建议用于生产写操作）：

CREATE USER 'exporter'@'localhost' IDENTIFIED BY 'your_strong_password';
GRANT SELECT ON *.* TO 'exporter'@'localhost'; # 广度，但通常建议更精细
-- 或者更精细的授权：
-- GRANT SELECT ON performance_schema.* TO 'exporter'@'localhost';
-- GRANT SELECT ON sys.* TO 'exporter'@'localhost';
-- GRANT SELECT ON information_schema.* TO 'exporter'@'localhost';
-- GRANT REPLICATION CLIENT ON *.* TO 'exporter'@'localhost';
-- GRANT PROCESS ON *.* TO 'exporter'@'localhost';
FLUSH PRIVILEGES;

我通常会先用一个拥有
```
SELECT ON *.*
```
的账户测试，确认功能正常后，再逐步收紧权限，找到最小权限集。

DATA_SOURCE_NAME

配置错误：

mysqld_exporter

通过

DATA_SOURCE_NAME

环境变量或命令行参数来获取MySQL的连接信息。格式通常是

user:password@(hostname:port)/

。

问题表现：
```
mysqld_exporter
```
启动失败，或者日志显示无法连接到MySQL服务器。
解决策略： 仔细检查连接字符串中的用户名、密码、主机名和端口是否正确。特别注意主机名，如果是本地连接，
```
localhost
```
或
```
127.0.0.1
```
通常都可以，但如果MySQL配置了只监听特定IP，或者
```
mysqld_exporter
```
运行在不同的服务器上，就需要填写正确的IP地址。

3. 网络连接问题： 防火墙、网络策略或MySQL绑定地址限制都可能导致

mysqld_exporter

无法连接到MySQL服务器。

问题表现：
```
mysqld_exporter
```
日志显示连接超时或拒绝连接。Prometheus也无法抓取到
```
mysqld_exporter
```
的指标。
解决策略：
- 防火墙： 确保MySQL服务器的
```
3306
```
  端口（或自定义端口）对
```
mysqld_exporter
```
  所在的主机开放。同时，也要确保
```
mysqld_exporter
```
  暴露的
```
9104
```
  端口对Prometheus服务器开放。
- MySQL绑定地址： 检查MySQL的
```
my.cnf
```
  配置文件中的
```
bind-address
```
  设置。如果设置为
```
127.0.0.1
```
  ，则MySQL只允许本地连接。如果你想从其他主机连接，需要将其设置为
```
0.0.0.0
```
  （允许所有IP连接，但安全性较低，建议配合防火墙）或具体的服务器IP。
- 网络连通性： 在
```
mysqld_exporter
```
  所在的主机上，尝试使用
```
telnet your_mysql_server_ip 3306
```
  或
```
mysql -h your_mysql_server_ip -u exporter -p
```
  命令，手动测试与MySQL的连接。

mysqld_exporter

端口冲突或未启动：

问题表现： Prometheus无法抓取到
```
mysqld_exporter
```
的指标，
```
Targets
```
页面显示
```
connection refused
```
或
```
timeout
```
。
解决策略：
- 确认
```
mysqld_exporter
```
  是否已成功启动，并且没有其他服务占用
```
9104
```
  端口。可以使用
```
netstat -tulnp | grep 9104
```
  命令检查。
- 查看
```
mysqld_exporter
```
  的启动日志，确认是否有报错信息。

处理这些问题时，我通常会从检查日志开始，日志文件是最好的“侦探”。

如何利用Grafana仪表盘深度分析MySQL性能瓶颈，并设置有效的告警规则？

Grafana不仅仅是展示数据的工具，它更是一个强大的分析平台。要深度分析MySQL性能瓶颈，我们需要学会“阅读”仪表盘，并结合Prometheus的查询语言（PromQL）设置有意义的告警。

1. 深度分析瓶颈：

从宏观到微观： 我通常会从一个概览仪表盘开始，比如查看QPS、TPS、连接数等整体指标。如果看到某个指标出现异常（比如QPS突然下降，或连接数激增），我就会开始深入挖掘。
关联性分析： 性能问题往往不是单一指标引起的。例如，如果看到慢查询计数突然增加，我会立即去查看CPU使用率、IOPS和InnoDB缓冲池命中率。如果CPU和IOPS也同时飙升，而缓冲池命中率下降，那很可能就是因为慢查询导致了大量的磁盘IO，进而拖慢了整个数据库。
时间段对比： Grafana的时间范围选择功能非常强大。我会对比问题发生前后的数据，或者与历史正常运行时期的数据进行对比。例如，某个查询在平时执行很快，但在高峰期却变慢了，这可能意味着资源竞争或锁等待。
利用PromQL进行即时查询： 仪表盘上的图表固然方便，但Prometheus的Explore功能配合PromQL才是真正的利器。当仪表盘无法提供足够细节时，我会在Explore中手动构建查询，例如，查询特定表的行锁等待时间
```
mysql_global_status_innodb_row_lock_time_avg{instance="mysql-primary", schema="your_db"}
```
，或者查看特定SQL语句的执行次数（如果你的
```
mysqld_exporter
```
配置了采集query_digest）。
日志与监控结合： 监控数据告诉你“什么”出了问题，而MySQL的错误日志、慢查询日志则告诉你“为什么”以及“谁”出了问题。将Grafana上的时间点与日志文件中的时间戳对齐，能帮助你快速定位根本原因。

2. 设置有效的告警规则：

告警的目的是在问题变得严重之前通知你，而不是等系统崩溃了才收到通知。我倾向于设置基于阈值和趋势的告警。

Prometheus Alertmanager： Prometheus本身负责收集数据和评估告警规则，而Alertmanager则负责对告警进行去重、分组、路由和发送通知（邮件、Slack、Webhook等）。你需要配置好Alertmanager，并让Prometheus知道它的地址。

告警规则（

alert.rules.yml

示例）：

groups:
- name: mysql_alerts
  rules:
  - alert: HighMySQLConnections
    expr: sum(mysql_global_status_threads_connected) by (instance) > 100 # 假设100是你的阈值
    for: 5m # 持续5分钟以上
    labels:
      severity: warning
    annotations:
      summary: "MySQL实例 {{ $labels.instance }} 连接数过高"
      description: "当前连接数达到 {{ $value }}，可能导致性能下降或连接拒绝。"

  - alert: LowInnoDBBufferPoolHitRate
    expr: 100 * (1 - sum(rate(mysql_global_status_innodb_buffer_pool_reads_total[5m])) by (instance) / sum(rate(mysql_global_status_innodb_buffer_pool_read_requests_total[5m])) by (instance)) < 95
    for: 10m
    labels:
      severity: critical
    annotations:
      summary: "MySQL实例 {{ $labels.instance }} InnoDB缓冲池命中率过低"
      description: "缓冲池命中率已降至 {{ $value }}%，可能存在大量磁盘I/O，请检查慢查询或内存配置。"

  - alert: MySQLReplicationLag
    expr: mysql_slave_status_seconds_behind_master > 60 # 超过60秒延迟
    for: 2m
    labels:
      severity: critical
    annotations:
      summary: "MySQL实例 {{ $labels.instance }} 复制延迟过高"
      description: "从库与主库延迟已达 {{ $value }} 秒，请检查复制状态。"