外观
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 | >50ms | 5分钟 |
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 慢查询数量突增
# 告警级别
High3. 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 告警通知
- 立即发送邮件、短信、即时通讯通知
- 5分钟未确认,发送电话通知
- 15分钟未处理,升级通知上级领导
P1 告警通知
- 立即发送邮件、短信、即时通讯通知
- 15分钟未确认,发送二次通知
- 30分钟未处理,升级通知上级领导
P2 告警通知
- 发送邮件、即时通讯通知
- 4小时未处理,发送二次通知
P3 告警通知
- 发送邮件通知
- 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和机器学习预测故障,提前告警
- 自动化:实现告警自动处理和修复
- 可视化:提供更直观的告警可视化和分析
- 一体化:与监控、日志、追踪系统深度集成
- 云原生:支持云环境和容器化部署
- 可观测性:从单一指标监控向全栈可观测性发展
