Skip to content

MySQL 告警阈值设置 ​

关键监控指标 ​

1. 系统级指标 ​

CPU 指标 ​

  • CPU 使用率:系统整体 CPU 使用率
  • 用户 CPU 使用率:用户空间 CPU 使用率
  • 系统 CPU 使用率:内核空间 CPU 使用率
  • I/O 等待:等待 I/O 操作的 CPU 时间百分比

内存指标 ​

  • 内存使用率:已使用内存占总内存百分比
  • Swap 使用率:已使用 swap 空间占总 swap 百分比
  • 页交换次数:每秒页换入/换出次数

磁盘指标 ​

  • 磁盘使用率:已使用磁盘空间百分比
  • 磁盘 I/O 使用率:磁盘 I/O 使用率百分比
  • 平均读写延迟:磁盘平均读写延迟
  • 磁盘吞吐量:每秒磁盘读写数据量

网络指标 ​

  • 网络连接数:系统当前网络连接数
  • MySQL 连接数:MySQL 当前连接数
  • 网络吞吐量:每秒网络数据传输量

2. MySQL 服务指标 ​

连接指标 ​

  • 当前连接数:当前活跃连接数
  • 连接使用率:当前连接数/最大连接数百分比
  • 连接错误数:每秒连接错误次数
  • 慢查询数:每秒慢查询数量

复制指标 ​

  • 复制延迟:主从复制延迟时间
  • 复制状态:复制是否正常运行
  • 复制错误:复制错误信息

InnoDB 指标 ​

  • 缓冲池命中率:InnoDB 缓冲池命中率
  • 日志等待:InnoDB 日志等待次数
  • 锁等待:InnoDB 锁等待次数
  • 脏页比例:InnoDB 缓冲池脏页比例

查询指标 ​

  • QPS:每秒查询次数
  • TPS:每秒事务数
  • 锁定时间:查询锁定时间
  • 全表扫描次数:每秒全表扫描次数

告警级别划分 ​

1. 告警级别定义 ​

级别名称严重程度响应时间要求处理方式
P0紧急极高立即处理(5分钟内)中断当前工作,立即处理
P1严重高15分钟内处理优先处理,暂停其他工作
P2警告中4小时内处理正常工作时间内处理
P3提示低24小时内处理计划内处理

2. 级别划分依据 ​

P0 紧急告警 ​

  • 数据库服务不可用
  • 主从复制中断
  • 磁盘空间已满
  • 连接数达到上限
  • 数据丢失或损坏

P1 严重告警 ​

  • CPU 使用率持续高于90%
  • 内存使用率持续高于95%
  • 磁盘使用率持续高于90%
  • 复制延迟超过300秒
  • 慢查询数量突增5倍以上

P2 警告告警 ​

  • CPU 使用率持续高于80%
  • 内存使用率持续高于85%
  • 磁盘使用率持续高于80%
  • 复制延迟超过60秒
  • 锁等待次数持续增加

P3 提示告警 ​

  • 数据库版本过期
  • 配置参数不合理
  • 索引使用率低
  • 表碎片过多
  • 备份成功率低

告警阈值设置方法 ​

1. 基于历史数据 ​

sql
-- 收集历史 CPU 使用率数据
SELECT 
    AVG(CPU_usage) AS avg_cpu,
    MAX(CPU_usage) AS max_cpu,
    PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY CPU_usage) AS p95_cpu
FROM performance_metrics
WHERE metric_name = 'cpu_usage'
AND collection_time >= DATE_SUB(NOW(), INTERVAL 7 DAY);

2. 基于业务需求 ​

  • 核心业务系统:阈值设置更严格,告警级别更高
  • 非核心业务系统:阈值设置相对宽松,告警级别较低
  • 高峰期:调整阈值以适应业务高峰
  • 低峰期:恢复正常阈值

3. 基于资源容量 ​

  • CPU 阈值:根据 CPU 核心数和业务负载设置
  • 内存阈值:考虑内存总量和 MySQL 内存配置
  • 磁盘阈值:预留足够空间用于数据增长和维护
  • 连接数阈值:基于 max_connections 参数设置

4. 动态阈值调整 ​

  • 基于时间的动态阈值:不同时间段使用不同阈值
  • 基于负载的动态阈值:根据系统负载自动调整阈值
  • 基于趋势的动态阈值:根据指标变化趋势调整阈值

关键指标告警阈值参考 ​

1. 系统级指标阈值 ​

指标名称P0 阈值P1 阈值P2 阈值P3 阈值持续时间
CPU 使用率>95%>90%>80%>70%5分钟
I/O 等待>50%>30%>20%>10%5分钟
内存使用率>98%>95%>85%>80%5分钟
Swap 使用率>50%>30%>20%>10%10分钟
磁盘使用率>98%>90%>85%>80%10分钟
磁盘 I/O 使用率>95%>90%>80%>70%5分钟
磁盘读写延迟>500ms>200ms>100ms>50ms5分钟

2. MySQL 服务指标阈值 ​

连接指标 ​

指标名称P0 阈值P1 阈值P2 阈值P3 阈值持续时间
连接使用率>98%>95%>85%>80%5分钟
连接错误数>100/秒>50/秒>20/秒>10/秒1分钟
慢查询数>100/秒>50/秒>20/秒>10/秒1分钟

复制指标 ​

指标名称P0 阈值P1 阈值P2 阈值P3 阈值持续时间
复制状态中断---立即
复制延迟>300秒>120秒>60秒>30秒5分钟
复制错误存在---立即

InnoDB 指标 ​

指标名称P0 阈值P1 阈值P2 阈值P3 阈值持续时间
缓冲池命中率<90%<95%<98%<99%5分钟
锁等待次数>100/秒>50/秒>20/秒>10/秒1分钟
脏页比例>50%>30%>20%>10%5分钟
日志等待次数>50/秒>30/秒>20/秒>10/秒1分钟

查询指标 ​

指标名称P0 阈值P1 阈值P2 阈值P3 阈值持续时间
QPS 突降<正常50%<正常70%<正常80%<正常90%2分钟
TPS 突降<正常50%<正常70%<正常80%<正常90%2分钟
全表扫描次数>100/秒>50/秒>20/秒>10/秒1分钟
锁定时间>10秒>5秒>2秒>1秒1分钟

告警规则配置示例 ​

1. Prometheus 告警规则 ​

yaml
# mysql_alerts.yml
groups:
- name: mysql_alerts
  rules:
  # CPU 使用率告警
  - alert: MySQLHighCPUUsage
    expr: rate(node_cpu_seconds_total{job="mysql", mode="system"}[5m]) * 100 > 90
    for: 5m
    labels:
      severity: critical
      service: mysql
    annotations:
      summary: "MySQL 服务器 CPU 使用率过高"
      description: "{{ $labels.instance }} CPU 使用率超过 90%,当前值: {{ $value | round(2) }}%"

  # 连接数告警
  - alert: MySQLHighConnectionCount
    expr: mysql_global_status_threads_connected / mysql_global_variables_max_connections * 100 > 95
    for: 5m
    labels:
      severity: critical
      service: mysql
    annotations:
      summary: "MySQL 连接数过高"
      description: "{{ $labels.instance }} 连接使用率超过 95%,当前值: {{ $value | round(2) }}%"

  # 复制延迟告警
  - alert: MySQLReplicationLag
    expr: mysql_slave_status_seconds_behind_master > 60
    for: 5m
    labels:
      severity: warning
      service: mysql
    annotations:
      summary: "MySQL 复制延迟"
      description: "{{ $labels.instance }} 复制延迟超过 60 秒,当前值: {{ $value }} 秒"

  # 磁盘使用率告警
  - alert: MySQLDiskSpaceLow
    expr: (node_filesystem_size_bytes{mountpoint="/data/mysql"} - node_filesystem_avail_bytes{mountpoint="/data/mysql"}) / node_filesystem_size_bytes{mountpoint="/data/mysql"} * 100 > 90
    for: 10m
    labels:
      severity: critical
      service: mysql
    annotations:
      summary: "MySQL 磁盘空间不足"
      description: "{{ $labels.instance }} 磁盘使用率超过 90%,当前值: {{ $value | round(2) }}%"

2. Zabbix 告警配置 ​

连接数监控项配置 ​

bash
# 监控项键值
mysql.status[Threads_connected]

# 触发器表达式
{Template MySQL:mysql.status[Threads_connected].last()} / {Template MySQL:mysql.status[max_connections].last()} * 100 > 95

# 触发器名称
MySQL 连接使用率过高

# 告警级别
Disaster

慢查询监控项配置 ​

bash
# 监控项键值
mysql.status[Slow_queries]

# 触发器表达式
{Template MySQL:mysql.status[Slow_queries].delta(60)} > 50

# 触发器名称
MySQL 慢查询数量突增

# 告警级别
High

3. Grafana Alerting 配置 ​

json
{
  "alert": {
    "name": "MySQL 锁等待告警",
    "message": "MySQL 锁等待次数超过阈值",
    "rule": {
      "for": "5m",
      "condition": "B > 50",
      "query": {
        "params": ["A", "5m", "now"]
      },
      "type": "graph"
    },
    "notifications": [
      {
        "uid": "email-notification",
        "settings": {
          "addresses": "admin@example.com"
        }
      }
    ]
  }
}

告警抑制与聚合 ​

1. 告警抑制规则 ​

时间抑制 ​

  • 同一告警:短时间内同一告警只发送一次
  • 重复告警:相同告警在指定时间内不再重复发送
  • 恢复通知:告警恢复后发送恢复通知

级别抑制 ​

  • 高级别抑制低级别:当高级别告警触发时,抑制同类型低级别告警
  • 关联告警抑制:当父告警触发时,抑制子告警

2. 告警聚合策略 ​

按实例聚合 ​

  • 将同一实例的多个告警聚合为一个通知
  • 减少告警风暴,便于集中处理

按时间聚合 ​

  • 将短时间内的多个告警聚合为一个通知
  • 避免频繁发送告警,减少干扰

按级别聚合 ​

  • 按告警级别分组发送
  • 优先处理高级别告警

告警通知方式 ​

1. 通知渠道比较 ​

渠道实时性可靠性适用场景配置复杂度
邮件中高所有级别告警低
短信高高P0/P1 级别告警中
电话极高高P0 级别告警高
即时通讯高中P0/P1/P2 级别告警低
监控平台实时高所有级别告警中

2. 多级通知策略 ​

P0 告警通知 ​

  1. 立即发送邮件、短信、即时通讯通知
  2. 5分钟未确认,发送电话通知
  3. 15分钟未处理,升级通知上级领导

P1 告警通知 ​

  1. 立即发送邮件、短信、即时通讯通知
  2. 15分钟未确认,发送二次通知
  3. 30分钟未处理,升级通知上级领导

P2 告警通知 ​

  1. 发送邮件、即时通讯通知
  2. 4小时未处理,发送二次通知

P3 告警通知 ​

  1. 发送邮件通知
  2. 24小时内处理

告警处理流程 ​

1. 告警接收 ​

  • 接收告警通知
  • 记录告警信息(时间、级别、内容、来源)
  • 确认告警真实性

2. 问题诊断 ​

  • 分析告警指标
  • 查看相关日志
  • 检查系统状态
  • 定位问题根源

3. 问题处理 ​

  • 执行修复操作
  • 监控修复效果
  • 验证问题解决

4. 告警关闭 ​

  • 手动关闭告警
  • 或等待自动恢复
  • 记录处理过程
  • 分析根本原因

5. 后续改进 ​

  • 分析告警原因
  • 优化系统配置
  • 调整告警阈值
  • 更新监控策略

最佳实践 ​

1. 阈值设置最佳实践 ​

  • 循序渐进:从宽松阈值开始,逐步调整到合适值
  • 基于数据:根据实际监控数据设置阈值
  • 定期 review:每季度 review 一次阈值设置
  • 业务驱动:根据业务需求调整阈值
  • 差异化设置:不同环境使用不同阈值

2. 告警管理最佳实践 ​

  • 避免告警风暴:合理设置抑制和聚合规则
  • 精准定位:告警信息应包含足够的上下文信息
  • 分级响应:根据告警级别采取不同的响应策略
  • 自动化处理:对于常见问题,实现自动化处理
  • 持续优化:定期分析告警数据,优化告警策略

3. 监控覆盖最佳实践 ​

  • 全面覆盖:监控所有关键指标
  • 分层监控:从系统、服务、应用层面进行监控
  • 端到端监控:监控从客户端到数据库的完整链路
  • 预测性监控:基于趋势预测可能出现的问题

4. 团队协作最佳实践 ​

  • 明确责任:指定每个告警的负责人
  • 建立流程:建立清晰的告警处理流程
  • 培训团队:培训团队成员如何处理告警
  • 定期演练:定期进行告警响应演练
  • 知识共享:分享告警处理经验和教训

常见问题与解决方案 ​

1. 告警噪音过多 ​

问题:收到大量无用告警,影响正常工作

解决方案:

  • 调整告警阈值,避免误报
  • 设置合理的告警抑制规则
  • 优化告警聚合策略
  • 关闭非关键指标告警

2. 告警延迟 ​

问题:告警通知延迟,影响问题处理

解决方案:

  • 优化监控数据采集频率
  • 确保告警系统高可用
  • 使用多种通知渠道
  • 减少告警处理环节

3. 告警漏报 ​

问题:关键问题未触发告警

解决方案:

  • 检查监控配置是否正确
  • 调整告警阈值,避免漏报
  • 增加监控指标覆盖范围
  • 定期测试告警系统

4. 告警优先级混乱 ​

问题:无法区分告警优先级,影响处理顺序

解决方案:

  • 明确告警级别定义
  • 基于业务影响设置优先级
  • 实现告警分级通知
  • 建立告警升级机制

常见问题(FAQ) ​

Q1: 如何确定合适的告警阈值? ​

A1: 确定合适告警阈值的方法:

  • 分析历史监控数据,了解正常范围
  • 考虑业务需求和SLA要求
  • 参考行业最佳实践
  • 从小范围试点,逐步调整
  • 定期review和优化

Q2: 告警阈值应该多久调整一次? ​

A2: 建议:

  • 新系统:前3个月每月调整一次
  • 稳定系统:每季度review一次
  • 业务变化后:及时调整
  • 系统升级后:重新评估

Q3: 如何避免告警风暴? ​

A3: 避免告警风暴的方法:

  • 设置合理的告警抑制规则
  • 实现告警聚合,减少通知数量
  • 调整告警阈值,减少误报
  • 建立告警分级机制
  • 实现自动化处理

Q4: 如何处理大量相似告警? ​

A4: 处理大量相似告警的方法:

  • 按实例或时间聚合告警
  • 查找根本原因,一次性解决多个告警
  • 优化系统配置,避免类似问题再次发生
  • 调整监控策略,减少相似告警

Q5: 告警恢复后需要做什么? ​

A5: 告警恢复后的处理:

  • 确认告警已恢复
  • 记录处理过程和结果
  • 分析根本原因
  • 提出改进措施
  • 优化告警策略

Q6: 如何测试告警系统? ​

A6: 测试告警系统的方法:

  • 模拟故障场景,验证告警是否触发
  • 检查告警通知是否及时送达
  • 验证告警级别和内容是否正确
  • 测试告警恢复通知
  • 测试告警抑制和聚合效果

Q7: 不同环境的告警阈值是否应该相同? ​

A7: 不同环境的告警阈值应该差异化设置:

  • 生产环境:阈值更严格,告警级别更高
  • 测试环境:阈值相对宽松,告警级别较低
  • 开发环境:只监控关键指标,阈值宽松

Q8: 如何实现告警自动化处理? ​

A8: 实现告警自动化处理的方法:

  • 对于常见问题,编写自动化处理脚本
  • 集成监控系统与自动化运维平台
  • 实现基于规则的自动修复
  • 建立闭环的自动化处理流程

Q9: 如何评估告警系统的有效性? ​

A9: 评估告警系统有效性的指标:

  • 告警准确率:有效告警/总告警数
  • 告警漏报率:漏报告警/应告警总数
  • 平均响应时间:从告警触发到开始处理的时间
  • 平均解决时间:从告警触发到问题解决的时间
  • 告警处理效率:每个告警的平均处理时间

Q10: 未来告警系统的发展趋势是什么? ​

A10: 未来告警系统的发展趋势:

  • 智能化:使用AI和机器学习预测故障,提前告警
  • 自动化:实现告警自动处理和修复
  • 可视化:提供更直观的告警可视化和分析
  • 一体化:与监控、日志、追踪系统深度集成
  • 云原生:支持云环境和容器化部署
  • 可观测性:从单一指标监控向全栈可观测性发展