首页 > 数据库 >mysql如何监控数据库运行状态_利用Prometheus与Grafana监控

mysql如何监控数据库运行状态_利用Prometheus与Grafana监控

来源：互联网 2026-05-02 16:48:07

mysql_exporter 启动报错主因是MySQL 8.0+禁用root@localhost socket登录且TCP未启用，应创建专用监控用户、确保skip-networking=OFF、bind_address兼容、显式传参配置文件，并验证Prometheus能采集到metrics。 mys

mysql_exporter 启动报错主因是MySQL 8.0+禁用root@localhost socket登录且TCP未启用，应创建专用监控用户、确保skip-networking=OFF、bind_address兼容、显式传参配置文件，并验证Prometheus能采集到metrics。

mysql_exporter 启动就报 `ERROR: unable to connect to MySQL instance`

这大概是部署监控时遇到的第一个，也是最常见的“拦路虎”。问题根源很明确：mysql_exporter 默认试图用 root@localhost 去连接，但 MySQL 8.0 及更高版本，默认已经禁用了 auth_socket 插件方式的本地 root 登录，同时，TCP连接权限也可能没开。

长期稳定更新的攒劲资源： >>>点此立即查看<<<

怎么解决？别跟默认配置硬碰硬，试试下面这几步：

创建专用监控用户，别再折腾 root 了：

CREATE USER 'exporter'@'localhost' IDENTIFIED BY 'safe_password';
GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'exporter'@'localhost';
FLUSH PRIVILEGES;

确保 MySQL 配置允许 TCP 连接：检查 my.cnf 里 skip-networking 是不是设成了 OFF。另外，注意 bind_address 的坑：如果它绑定的是 127.0.0.1（纯IPv4），而 exporter 连接时用了 localhost（系统可能解析为IPv6或socket），就可能连不上。最稳妥的办法，连接时统一使用 127.0.0.1:3306。
启动时显式传递配置文件，别依赖不靠谱的环境变量：
```
./mysqld_exporter --config.my-cnf=/etc/mysql_exporter.cnf
```
其中，/etc/mysql_exporter.cnf 这个配置文件里，老老实实写上 [client] 段，填好用户名和密码。

Grafana 导入 MySQL Dashboard 后指标全空

仪表盘导入了，面板一片空白？先别急着怀疑模板有问题。十有八九，是 Prometheus 压根没抓到数据。这里有个常见的误解：能用 curl 访问到 mysql_exporter 的 metrics 端点（默认是 :9104/metrics），并不等于 Prometheus 就能正常采集。

排查思路可以这么走：

先看 Prometheus 的采集目标状态：打开 Prometheus 的 Web UI，进入 Status > Targets 页面，找到 mysql_exporter 对应的 target。看看状态是不是 UP。如果是 DOWN，点进去看 LastError，常见错误是 DNS 解析失败——比如配置里写了MySQL的容器服务名，但 Prometheus 跑在宿主机上，根本解析不了。
检查 mysql_exporter 的监听地址：确认启动参数 --web.listen-address 绑定的是 0.0.0.0:9104，而不是 127.0.0.1:9104。后者只允许本机访问，容器外或者另一台主机上的 Prometheus 自然抓不到。
注意指标与 MySQL 版本的兼容性：很多 Dashboard 面板用的是 mysql_global_status_threads_connected 这类指标。如果你的 MySQL 版本比较老（比如 5.6），部分状态变量可能不存在，图表自然就是空的。这时候，可以尝试换用兼容性更好的指标，例如 mysql_info_schema_processlist_threads。

高并发下 mysql_exporter 拖慢 MySQL 响应

监控装上了，数据库却变慢了？这可不是危言耸听。mysql_exporter 默认每15秒就会去查询 information_schema 和 performance_schema。其中像 SELECT * FROM information_schema.PROCESSLIST 这样的查询，在连接数高达几千的场景下，可能会引发锁表或者触发全表扫描，成为性能瓶颈。

要避免监控反噬业务，可以这么调整：

关闭非必要的指标收集：启动 exporter 时，通过参数关掉一些重量级的收集项。
```
--collect.global_status=false --collect.info_schema.processlist=false
```
保留像 global_variables、sla ve_status 这类对性能影响较小的核心指标即可。
有连接监控的刚需？换个更高效的数据源：如果必须监控进程列表，可以考虑用 performance_schema.threads 表来替代（前提是 MySQL 版本 ≥ 5.7，并且开启了 performance_schema）。
拉长采集间隔：别把 Prometheus 的 scrape_interval 设得太密。对于数据库监控，30秒甚至60秒的采集间隔，往往比默认的15秒对数据库更友好。mysql_exporter 本身不支持动态调整采集频率，节奏由 Prometheus 控制。

MySQL 主从延迟监控值始终为 0

主从延迟监控显示一直是0，就真的万事大吉了吗？未必。mysql_exporter 获取延迟数据主要依赖 SHOW SLA VE STATUS 中的 Seconds_Behind_Master 字段。但这个值在某些情况下会“说谎”：比如 IO 线程断开、SQL 线程卡住，或者在 GTID 模式下主从关系异常时，它都可能返回 NULL 或者 0，这并不代表真的没有延迟。

想要获得真实的延迟情况，得这么看：

先手动检查从库复制状态：连接到从库，执行 SHOW SLA VE STATUS\G。重点看 Sla ve_IO_Running 和 Sla ve_SQL_Running 两个字段是不是都为 Yes。只要有一个不是，Seconds_Behind_Master 的值就失去了参考意义。
在查询指标时增加过滤条件：使用 mysql_sla ve_status_seconds_behind_master 这个指标时，应该加上复制状态正常的条件：
```
mysql_sla ve_status_seconds_behind_master > 0 and mysql_sla ve_status_sla ve_io_running == 1 and mysql_sla ve_status_sla ve_sql_running == 1
```
这样筛选出来的延迟数据才靠谱。
考虑更底层的延迟指标：其实，更可靠的延迟衡量标准是主从之间 binlog position 的差值。不过，mysql_exporter 默认不直接提供这个指标。如果需要，可以通过自定义 query collector 来实现，编写SQL查询 master_log_file/position 与 relay_master_log_file/exec_master_log_pos 的差值。