Mysql

关注公众号 jb51net

关闭
首页 > 数据库 > Mysql > Prometheus 监控 MySQL 告警

Prometheus 监控 MySQL 告警规则

作者:黑疯雷

本文主要介绍了Prometheus 监控 MySQL 告警规则

说明:mysqld_exporter 采集上来的指标,配合 Prometheus 告警规则,可以实现对 MySQL 数据库的全面监控。下面按严重级别归类整理。

写在前面

MySQL 的告警指标主要涉及三个方面:

  1. 数据库可用性:MySQL 是否活着、主从复制是否正常
  2. 性能与配置:连接数、InnoDB 状态、日志配置、缓存大小
  3. 容量:磁盘空间、打开文件数

告警分三个级别:

级别含义处理方式
严重告警立即需要处理线上问题,随时可能影响业务
警告需要关注潜在风险,不处理可能升级
提示备案记录但不一定告警

严重告警(Critical)

MySQL 实例宕机

- alert: MySQL 服务宕机
  expr: mysql_up == 0
  for: 1m
  labels:
    severity: 严重告警
  annotations:
    summary: "MySQL {{ $labels.instance }} 宕机"
    description: "MySQL 数据库无法连接"

主从复制 IO 线程停止

- alert: MySQL 复制 IO 线程异常
  expr: mysql_slave_status_slave_io_running != 1
  for: 1m
  labels:
    severity: 严重告警
  annotations:
    summary: "主从复制 IO 线程停止"
    description: "从库无法连接主库,复制中断"

IO 线程停了,说明从库连不上主库。常见原因:网络不通、主库宕机、复制账号密码不对。

主从复制 SQL 线程停止

- alert: MySQL 复制 SQL 线程异常
  expr: mysql_slave_status_slave_sql_running != 1
  for: 1m
  labels:
    severity: 严重告警
  annotations:
    summary: "主从复制 SQL 线程停止"
    description: "从库无法应用 relay log,复制中断"

SQL 线程停了,说明从库在执行主库传过来的 SQL 时出了问题。常见原因:表结构冲突、主键冲突、磁盘满。

主从复制延迟

- alert: MySQL 主从复制延迟
  expr: mysql_slave_status_seconds_behind_master > 30
  for: 1m
  labels:
    severity: 严重告警
  annotations:
    summary: "主从复制延迟"
    description: "从库落后主库 {{ $value }} 秒"

警告(Warning)

连接数超过 80%

- alert: MySQL 连接数告警
  expr: mysql_global_status_threads_connected / mysql_global_variables_max_connections * 100 > 80
  for: 1m
  labels:
    severity: 警告
  annotations:
    summary: "MySQL 连接数过高"
    description: "当前连接 {{ $value }}%,超过最大连接数的 80%"

如果这个值不断上涨,说明应用端连接没有及时释放,或者连接池配置过大。

打开文件数超过 75%

- alert: MySQL 打开文件数过多
  expr: mysql_global_status_innodb_num_open_files > mysql_global_variables_open_files_limit * 0.75
  for: 1m
  labels:
    severity: 警告
  annotations:
    summary: "InnoDB 打开文件数过高"
    description: "已用文件数超过限制的 75%,建议增大 open_files_limit"

InnoDB 日志文件太小

- alert: InnoDB 日志文件过小
  expr: mysql_global_variables_innodb_log_file_size < 16777216
  for: 1m
  labels:
    severity: 警告
  annotations:
    summary: "InnoDB 日志文件太小"
    description: "当前 ib_logfile 小于 16MB,影响写入性能"

InnoDB 的 redo log (ib_logfile)太小,会导致日志频繁切换,触发检查点(checkpoint),影响写入性能。生产环境建议 1GB 以上。

排序缓冲区配置不合理

- alert: 排序缓冲区配置错误
  expr: mysql_global_variables_innodb_sort_buffer_size < 262144 or mysql_global_variables_read_buffer_size > 4194304
  for: 1m
  labels:
    severity: 警告
  annotations:
    summary: "排序缓冲区配置不合理"
    description: "建议 innodb_sort_buffer_size 不低于 256KB,read_buffer_size 不超过 4MB"

最大连接数使用率过高

- alert: 最大连接数使用率过高
  expr: mysql_global_status_max_used_connections > mysql_global_variables_max_connections * 0.8
  for: 1m
  labels:
    severity: 警告
  annotations:
    summary: "最大连接数使用率过高"
    description: "历史上最多同时使用了 {{ $value }} 的可用连接数"

这个指标跟 threads_connected 不同,它记录的是历史上同时连接的最大值。如果超过了 80%,说明你的 max_connections 可能设小了。

二进制日志未开启

- alert: 二进制日志未开启
  expr: mysql_global_variables_log_bin != 1
  for: 1m
  labels:
    severity: 警告
  annotations:
    summary: "二进制日志未开启"
    description: "log_bin 未开启,无法进行基于时间点的恢复(PITR)"

生产环境强烈建议开启 binlog。如果没有 binlog,误删数据后只能从全量备份恢复,丢失最近一段时间的全部数据。

InnoDB 刷新策略不安全

- alert: InnoDB 刷新策略不安全
  expr: mysql_global_variables_innodb_flush_log_at_trx_commit != 1
  for: 1m
  labels:
    severity: 警告
  annotations:
    summary: "InnoDB 日志刷新策略可能丢数据"
    description: "innodb_flush_log_at_trx_commit 当前值为 {{ $value }},非 1 的情况下断电可能丢已提交事务"

innodb_flush_log_at_trx_commit=1 性能最差但最安全,每次提交都刷盘。如果是银行、支付类业务,建议设置为 1。

需要关注(Page / Info)

表定义缓存太小

- alert: 表定义缓存太小
  expr: mysql_global_status_open_table_definitions > mysql_global_variables_table_definition_cache
  for: 1m
  labels:
    severity: 警告
  annotations:
    summary: "表定义缓存不足"
    description: "打开的表的数量已超过 cache 限制,建议增大 table_definition_cache"

表打开缓存太小

- alert: 表打开缓存太小
  expr: mysql_global_status_open_tables > mysql_global_variables_table_open_cache * 0.99
  for: 1m
  labels:
    severity: 警告
  annotations:
    summary: "表打开缓存不足"
    description: "table_open_cache 几乎满,建议增大"

从库未设置只读

- alert: 从库未设置为只读
  expr: mysql_global_variables_read_only == 0
  for: 1m
  labels:
    severity: 警告
  annotations:
    summary: "从库未开启 read_only"
    description: "从库不是只读模式,可能发生数据误写导致主从不一致"

Binlog 缓存大小可能太小

- alert: Binlog 缓存过小
  expr: mysql_global_variables_binlog_cache_size < 1048576
  for: 1m
  labels:
    severity: 警告
  annotations:
    summary: "Binlog 缓存过小"
    description: "当前 binlog_cache_size 小于 1MB,建议增大"

告警规则使用建议

  1. 先测试再上线:把规则加到 Prometheus 后,在 Alerts 页面观察一段时间,确认不会误报再正式启用 Alertmanager 通知。

  2. 分级通知:严重告警走电话/短信,警告走邮件/钉钉/企微,提示级别可以只在告警页面展示。

  3. 调整阈值

    • 连接数 80% → 如果业务流量波动大,可以调到 85% 或 90%
    • 复制延迟 30 秒 → 如果业务对延迟不敏感,可以调到 120 秒
    • InnoDB 日志 16MB → 生产环境建议 1GB 起步,这里的告警阈值主要用来发现配置过于保守的情况
  4. 搭配 mysqld_exporter:这些规则的指标全部来自 mysqld_exporter,确认 exporter 版本支持后再启用规则。部分指标在低版本 exporter 中不存在。

到此这篇关于Prometheus 监控 MySQL 告警规则的文章就介绍到这了,更多相关Prometheus 监控 MySQL 告警内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!

您可能感兴趣的文章:
阅读全文