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

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 的差值。

说到底，把监控配通只是第一步。真正的难点在于理解每一个指标背后，exporter 究竟查询了哪张系统表、可能触发了什么锁、又在哪个 MySQL 版本下会失效。监控数据一旦失真，带来的误导可能比没有监控更加危险。