mysqld_exporter无法直接提供慢查询告警指标，因其不解析慢查询日志文件，且global_status中slow_queries为累计值、slow_log表默认不采集；需配合promtail+loki或pt-query-digest+textfile_collector实现可告警监控。
MySQL 5.7 的慢查询报警不能靠 mysqld_exporter 直接暴露指标——它本身不采集慢查询日志内容，必须配合日志文件 + file_sd 或外部日志采集器（如 promtail）才能实现真正可告警的慢查询监控。
为什么 mysqld_exporter 默认不提供 slow_query_count 指标
mysqld_exporter 的核心数据来源是 SHOW GLOBAL STATUS、INFORMATION_SCHEMA 和 PERFORMANCE_SCHEMA，而 MySQL 5.7 的慢查询日志（slow_query_log_file）是纯文本文件，不在这些系统表中持久化。因此：
-
mysqld_exporter不解析日志文件，也不暴露类似mysql_slow_queries_total的计数器 -
global_status中的Slow_queries只是自实例启动以来的累计值，无法区分“最近1分钟新增了多少条”，不适合做阈值告警 - 即使开启
log_output=TABLE并写入mysql.slow_log表，该表默认是CSV引擎，mysqld_exporter也**不采集该表**（无对应--collect.slow_log参数）
可行方案：用 promtail + loki + PromQL 告警（推荐）
这是目前最轻量、可落地、且能保留原始 SQL 上下文的方式。关键点不是改 MySQL 配置，而是让日志“可度量”：
- 确保 MySQL 已启用慢查询日志：
SET GLOBAL slow_query_log = 'ON'，且long_query_time = 1（按需调整） - 确认日志路径可读：
SELECT @@slow_query_log_file→ 通常是/var/lib/mysql/hostname-slow.log - 部署
promtail，配置其 tail 该文件，并打上标签：scrape_configs: - job_name: mysql-slow-log static_configs: - targets: [localhost] pipeline_stages: - match: selector: '{job="mysql-slow-log"} |~ "Query_time:"' stages: - regex: expression: 'Query_time: ([0-9.]+)' - labels: query_time: "$1" - 在 Prometheus 中通过
count_over_time({job="mysql-slow-log"}[5m]) > 3做基础频次告警；或用rate(...[5m])+quantile_over_time(0.95, ...)判断 P95 查询耗时突增
替代方案：用 pt-query-digest 定时生成指标文件（离线但稳定）
如果无法引入 loki/promtail，可用定时任务把慢日志转成 Prometheus 格式指标文件，再用 textfile_collector 拉取：
- 写一个脚本，每5分钟执行：
pt-query-digest --report-format json \ --limit 100% \ /var/lib/mysql/$(hostname)-slow.log \ > /var/lib/node_exporter/textfile_collector/mysql_slow_report.json
- 用
node_exporter的--collector.textfile.directory加载该 JSON（需转换为.prom格式，例如提取Query_time最大值、平均值、总条数） - Prometheus 抓取
node_exporter的/metrics，即可用mysql_slow_query_max_seconds等自定义指标写告警规则 - 注意：该方式有延迟（至少2个周期），且无法关联具体 SQL 文本，只适合“有没有明显恶化”的粗粒度判断
容易被忽略的关键细节
MySQL 5.7 的 slow_query_log_file 默认权限是 -rw-r-----，属主 mysql:mysql。无论用 promtail 还是 pt-query-digest，运行用户（如 prometheus 或 root）必须有读权限，否则日志根本读不到——别只盯着配置项，先 ls -l 看权限。
