外观
MariaDB 告警策略与故障分级
告警策略设计原则
告警的目的
- 及时发现问题：在故障影响业务之前发现并处理
- 减少误报：避免过多无效告警导致告警疲劳
- 精准定位：提供足够信息，便于快速定位问题
- 分级处理：根据故障严重程度采取不同处理流程
- 可追溯性：记录告警历史，便于事后分析
告警设计三要素
- 告警指标：选择最能反映数据库健康状态的关键指标
- 告警阈值：根据业务需求和系统性能设置合理阈值
- 告警通知：确保告警能够及时送达相关人员
故障分级标准
分级原则
- 影响范围：故障影响的业务范围和用户数量
- 严重程度：故障对业务的影响程度
- 恢复时间：故障恢复所需的时间
- 技术复杂度：故障排查和恢复的技术难度
故障等级定义
| 级别 | 名称 | 描述 | 响应时间 | 处理流程 |
|---|---|---|---|---|
| P0 | 紧急故障 | 数据库完全不可用，导致核心业务中断 | 立即响应（10分钟内） | 启动应急响应流程，DBA团队全员参与 |
| P1 | 严重故障 | 数据库性能严重下降，核心业务受到明显影响 | 30分钟内响应 | DBA负责人带队处理，必要时升级 |
| P2 | 重要故障 | 数据库出现异常，但核心业务未受到严重影响 | 1小时内响应 | 由DBA团队成员处理，定期汇报进度 |
| P3 | 一般故障 | 数据库存在潜在问题，暂未影响业务 | 4小时内响应 | 安排常规处理，纳入待办事项 |
| P4 | 预警信息 | 数据库指标接近阈值，需要关注 | 24小时内处理 | 监控观察，必要时优化调整 |
核心告警指标与阈值设置
连接相关告警
| 指标名称 | 告警级别 | 告警阈值 | 监控频率 | 备注 |
|---|---|---|---|---|
| 连接数使用率 | P0 | >95% | 1分钟 | 连接数达到最大连接数的95% |
| 连接数使用率 | P1 | >80% | 5分钟 | 连接数达到最大连接数的80% |
| 连接数使用率 | P2 | >70% | 10分钟 | 连接数达到最大连接数的70% |
| 连接失败率 | P1 | >1% | 5分钟 | 连接失败次数/总连接尝试次数 >1% |
| 连接拒绝数 | P1 | >10次/分钟 | 1分钟 | 每分钟连接拒绝次数超过10次 |
性能相关告警
| 指标名称 | 告警级别 | 告警阈值 | 监控频率 | 备注 |
|---|---|---|---|---|
| 慢查询数 | P2 | >5次/分钟 | 5分钟 | 每分钟慢查询次数超过5次 |
| 慢查询数 | P1 | >20次/分钟 | 1分钟 | 每分钟慢查询次数超过20次 |
| 查询响应时间 | P1 | >2秒 | 5分钟 | 平均查询响应时间超过2秒 |
| 事务提交成功率 | P1 | <99.9% | 5分钟 | 事务提交失败率超过0.1% |
| 死锁次数 | P2 | >1次/分钟 | 5分钟 | 每分钟死锁次数超过1次 |
| 死锁次数 | P1 | >5次/分钟 | 1分钟 | 每分钟死锁次数超过5次 |
资源相关告警
| 指标名称 | 告警级别 | 告警阈值 | 监控频率 | 备注 |
|---|---|---|---|---|
| CPU使用率 | P1 | >85% | 1分钟 | 数据库进程CPU使用率超过85% |
| 内存使用率 | P1 | >85% | 1分钟 | 数据库进程内存使用率超过85% |
| 磁盘空间使用率 | P1 | >90% | 10分钟 | 数据目录所在磁盘使用率超过90% |
| 磁盘空间使用率 | P2 | >80% | 30分钟 | 数据目录所在磁盘使用率超过80% |
| 磁盘I/O利用率 | P1 | >90% | 1分钟 | 磁盘I/O使用率超过90% |
| 磁盘I/O等待时间 | P2 | >50ms | 5分钟 | 平均磁盘I/O等待时间超过50ms |
InnoDB 相关告警
| 指标名称 | 告警级别 | 告警阈值 | 监控频率 | 备注 |
|---|---|---|---|---|
| Buffer Pool 命中率 | P2 | <95% | 5分钟 | Buffer Pool 命中率低于95% |
| Buffer Pool 命中率 | P1 | <90% | 1分钟 | Buffer Pool 命中率低于90% |
| 日志文件使用率 | P1 | >90% | 1分钟 | InnoDB 日志文件使用率超过90% |
| 脏页比例 | P2 | >20% | 5分钟 | InnoDB 脏页比例超过20% |
| 脏页比例 | P1 | >50% | 1分钟 | InnoDB 脏页比例超过50% |
| 行锁等待时间 | P2 | >100ms | 5分钟 | 平均行锁等待时间超过100ms |
| 行锁等待时间 | P1 | >500ms | 1分钟 | 平均行锁等待时间超过500ms |
复制相关告警
| 指标名称 | 告警级别 | 告警阈值 | 监控频率 | 备注 |
|---|---|---|---|---|
| 主从延迟 | P2 | >30秒 | 1分钟 | 从库延迟超过30秒 |
| 主从延迟 | P1 | >5分钟 | 1分钟 | 从库延迟超过5分钟 |
| 复制线程状态 | P1 | 停止 | 1分钟 | IO或SQL线程停止 |
| 复制错误数 | P1 | >0 | 1分钟 | 复制过程中出现错误 |
| Galera 集群状态 | P0 | 非Primary | 1分钟 | Galera集群处于非Primary状态 |
| Galera 节点数 | P1 | <预期值 | 1分钟 | Galera集群节点数少于预期 |
| Galera 队列长度 | P1 | >100 | 1分钟 | Galera发送/接收队列长度超过100 |
告警通知机制
通知渠道选择
| 渠道 | 适用场景 | 特点 | 配置要点 |
|---|---|---|---|
| 邮件 | P2-P4级别告警，日报/周报 | 正式、可追溯、支持附件 | 配置邮件服务器，设置收件人列表 |
| 短信 | P0-P1级别告警 | 及时、覆盖面广 | 配置短信网关，注意短信字数限制 |
| 电话 | P0级别告警 | 最及时、确保收到 | 配置电话告警系统，设置轮播机制 |
| 即时通讯 | 所有级别告警 | 实时、支持群聊 | 集成企业微信、Slack、钉钉等 |
| 监控平台 | 所有级别告警 | 集中管理、可视化 | 配置监控平台告警规则，支持告警升级 |
告警通知策略
分级通知：
- P0：电话 + 短信 + 即时通讯 + 邮件，通知DBA团队所有成员
- P1：短信 + 即时通讯 + 邮件，通知DBA负责人和核心成员
- P2：即时通讯 + 邮件，通知DBA团队成员
- P3-P4：邮件，通知DBA团队成员
告警升级机制：
- 初始告警：通知直接责任人
- 15分钟未响应：通知团队负责人
- 30分钟未解决：通知部门领导
- 1小时未解决：启动紧急响应流程
告警静默期：
- 对于频繁触发的告警，设置合理的静默期，避免告警风暴
- 例如：同一指标告警在5分钟内只发送一次
告警抑制：
- 当某一核心告警触发时，抑制相关的次要告警
- 例如：当数据库不可用告警触发时，抑制连接失败、查询超时等告警
告警处理流程
告警接收
- 监控系统检测到异常指标，触发告警
- 告警信息通过多种渠道发送给相关人员
- 接收人员确认告警，记录接收时间
告警验证
- 登录数据库服务器，验证告警真实性
- 检查相关日志和监控指标，初步定位问题
- 评估故障影响范围和严重程度
故障处理
- 根据故障级别启动相应处理流程
- 实施故障修复措施
- 验证修复效果，确保故障已解决
- 记录故障处理过程和结果
告警关闭
- 确认故障已完全恢复
- 检查相关指标，确保稳定
- 关闭告警，记录关闭时间
事后分析
- 分析故障原因和影响
- 评估告警策略的有效性
- 提出改进措施，优化告警策略
- 更新故障知识库
告警策略优化
常见问题及解决方案
| 问题 | 解决方案 |
|---|---|
| 告警风暴 | 1. 设置告警静默期 2. 配置告警抑制规则 3. 优化告警阈值 4. 合并相关告警 |
| 误报率高 | 1. 调整告警阈值 2. 增加告警持续时间条件 3. 结合多个指标进行告警 4. 优化监控数据采集 |
| 漏报 | 1. 补充关键监控指标 2. 降低告警阈值 3. 增加告警渠道 4. 定期测试告警机制 |
| 告警信息不完整 | 1. 丰富告警内容，包含关键信息 2. 提供故障排查建议 3. 链接到相关监控面板 4. 包含历史告警信息 |
告警策略迭代
初始阶段：
- 基于经验设置基础告警策略
- 监控核心指标，避免过多告警
优化阶段：
- 根据实际运行情况调整阈值
- 增加更多关键指标
- 优化告警通知机制
成熟阶段：
- 建立自动化告警处理流程
- 结合机器学习预测异常
- 实现告警自愈功能
自动化告警处理
告警自愈场景
| 场景 | 自愈措施 | 适用条件 |
|---|---|---|
| 连接数过高 | 自动清理空闲连接 | 确认是空闲连接导致 |
| 慢查询堆积 | 自动终止长时间运行的查询 | 查询运行时间超过阈值且非关键查询 |
| 磁盘空间不足 | 自动清理过期日志文件 | 确认是日志文件占用过多空间 |
| 复制延迟 | 自动重启复制线程 | 复制线程异常停止 |
| 内存使用率过高 | 自动优化内存参数 | 内存使用异常且可通过参数调整 |
实现方式
脚本自动化：
- 编写Shell/Python脚本，定期检查告警状态
- 当触发特定告警时，执行预定义的修复脚本
- 记录修复过程和结果
监控平台集成：
- 利用监控平台的告警自愈功能
- 配置告警触发条件和对应的修复动作
- 支持复杂的条件判断和执行逻辑
自动化运维平台：
- 集成到企业自动化运维平台
- 实现告警、处理、验证的闭环管理
- 支持多团队协作和流程审批
常见问题（FAQ）
Q: 如何避免告警风暴？
A: 可以通过以下措施避免告警风暴：
- 设置合理的告警静默期，同一指标短时间内只告警一次
- 配置告警抑制规则，当核心告警触发时抑制相关次要告警
- 优化告警阈值，避免过于敏感
- 合并相关告警，减少告警数量
- 实施告警分级，不同级别采用不同的通知方式
Q: 告警阈值应该如何设置？
A: 告警阈值设置建议：
- 参考MariaDB官方推荐值
- 根据业务需求和系统性能调整
- 考虑系统峰值情况，避免误报
- 采用阶梯式阈值，如80%警告、90%严重
- 定期回顾和调整阈值，适应系统变化
Q: 如何验证告警策略的有效性？
A: 验证方法：
- 进行告警演练，模拟各种故障场景
- 分析历史告警数据，统计误报率和漏报率
- 收集DBA团队对告警的反馈
- 定期回顾告警处理时间，评估告警的及时性
- 检查告警信息的完整性和准确性
Q: 告警升级机制应该如何设计？
A: 告警升级机制设计要点：
- 根据故障级别设置不同的升级时间
- 明确各级别告警的通知对象
- 确保升级路径清晰，避免责任不清
- 记录升级过程，便于事后分析
- 定期测试升级机制，确保有效
Q: 如何处理夜间和节假日的告警？
A: 夜间和节假日告警处理建议：
- 实施轮值制度，确保24小时有人响应
- 对于非紧急告警，延迟到工作时间处理
- 利用自动化工具处理常见问题
- 建立紧急联系机制，确保关键人员可以被及时联系到
- 定期进行夜间告警测试，确保通知渠道畅通
最佳实践
告警指标精简化：
- 只监控最关键的指标，避免指标泛滥
- 每个告警指标都应有明确的业务意义
- 定期清理无用的告警指标
告警阈值动态化：
- 考虑业务高峰期和低谷期的差异
- 对于周期性业务，设置动态阈值
- 利用机器学习算法自动调整阈值
告警信息标准化：
- 统一告警格式，包含必要信息
- 提供故障排查步骤和建议
- 链接到相关监控面板和文档
告警管理可视化：
- 建立告警仪表盘，实时展示告警状态
- 统计告警趋势，识别潜在问题
- 分析告警处理效率，优化流程
持续优化告警策略：
- 定期回顾告警历史，调整策略
- 收集DBA团队反馈，改进告警机制
- 跟踪业务变化，更新告警需求
通过建立完善的告警策略和故障分级机制，可以确保MariaDB数据库出现问题时能够及时发现、快速响应、有效处理，最大限度地减少故障对业务的影响。