印刻数据库

外观

MySQL 告警级别分类 ​

告警级别定义 ​

告警级别是根据告警事件的严重程度和影响范围进行的分类，用于指导运维人员对告警事件的响应优先级和处理方式。合理的告警级别分类可以帮助运维团队快速识别和处理关键问题，减少故障恢复时间，提高系统可用性。

合理的告警级别分类具有以下重要性：

  • 优先级明确：帮助运维人员快速识别关键问题，优先处理高优先级告警
  • 资源合理分配：根据告警级别分配相应的人力和资源
  • 流程标准化：建立标准化的告警处理流程，提高处理效率
  • 责任明确：明确不同级别告警的处理责任人
  • 统计分析：便于进行告警统计和分析，优化监控策略

紧急告警（Critical） ​

严重程度：最高 影响范围：整个数据库系统或核心业务功能 响应时间要求：立即响应（通常要求 5-15 分钟内） 示例场景：

  • 数据库实例宕机
  • 主从复制中断
  • 磁盘空间不足（剩余空间 < 5%）
  • 内存使用率过高（> 95% 持续 5 分钟）
  • CPU 使用率过高（> 98% 持续 10 分钟）
  • 关键业务表不可访问

重要告警（Major） ​

严重程度：高 影响范围：部分业务功能或重要性能指标异常 响应时间要求：尽快响应（通常要求 30 分钟内） 示例场景：

  • 慢查询数量激增（比基线增加 200%）
  • 连接数接近上限（> 90%）
  • 主从复制延迟过大（> 300 秒）
  • 索引使用率过低（< 50%）
  • 临时表空间增长过快
  • 死锁数量增加（> 10 个/小时）

警告告警（Warning） ​

严重程度：中 影响范围：单个指标异常，可能影响系统性能 响应时间要求：计划响应（通常要求 24 小时内） 示例场景：

  • 磁盘空间使用率过高（> 80%）
  • 内存使用率偏高（> 85%）
  • CPU 使用率偏高（> 80% 持续 10 分钟）
  • 连接数偏高（> 70%）
  • 主从复制延迟（> 60 秒）
  • 表碎片化严重（> 30%）

信息告警（Info） ​

严重程度：低 影响范围：单个指标变化，不影响系统正常运行 响应时间要求：定期关注 示例场景：

  • 数据库配置变更
  • 备份完成通知
  • 索引创建/删除
  • 表结构变更
  • 新增用户
  • 定期维护任务执行完成

告警分级标准 ​

基于影响范围的分级 ​

影响范围建议告警级别
整个系统不可用紧急（Critical）
核心业务功能不可用紧急（Critical）
部分业务功能不可用重要（Major）
系统性能明显下降重要（Major）
单个指标异常警告（Warning）
系统状态变化信息（Info）

基于持续时间的分级 ​

持续时间建议告警级别
立即影响（< 1 分钟）紧急（Critical）
短期影响（1-5 分钟）重要（Major）
中期影响（5-30 分钟）警告（Warning）
长期影响（> 30 分钟）根据影响范围决定

基于恢复难度的分级 ​

恢复难度建议告警级别
立即恢复（< 10 分钟）重要（Major）或警告（Warning）
需计划恢复（10-60 分钟）警告（Warning）
需复杂恢复（> 60 分钟）紧急（Critical）或重要（Major）

告警级别处理流程 ​

紧急告警处理流程 ​

  1. 告警触发：监控系统检测到紧急告警事件
  2. 通知方式：
    • 短信通知所有值班人员
    • 电话告警主值班人员
    • 企业微信/钉钉群告警
    • 邮件通知相关负责人
  3. 响应要求：
    • 主值班人员 5 分钟内响应
    • 15 分钟内开始故障排查
    • 每 30 分钟更新一次故障处理进展
  4. 故障排查：
    • 确认告警真实性
    • 定位故障原因
    • 实施紧急修复措施
  5. 恢复验证：
    • 验证系统恢复正常
    • 确认业务功能恢复
  6. 告警关闭：手动关闭告警
  7. 事后分析：
    • 24 小时内完成故障分析报告
    • 提出改进措施，防止类似问题再次发生

重要告警处理流程 ​

  1. 告警触发：监控系统检测到重要告警事件
  2. 通知方式：
    • 企业微信/钉钉群告警
    • 邮件通知相关负责人
    • 如 30 分钟未处理，升级为短信通知
  3. 响应要求：
    • 30 分钟内响应
    • 1 小时内开始故障排查
  4. 故障排查：
    • 确认告警真实性
    • 定位问题原因
    • 实施修复措施
  5. 恢复验证：
    • 验证指标恢复正常
    • 确认业务不受影响
  6. 告警关闭：手动或自动关闭告警
  7. 事后分析：
    • 48 小时内完成问题分析
    • 提出改进建议

警告告警处理流程 ​

  1. 告警触发：监控系统检测到警告告警事件
  2. 通知方式：
    • 企业微信/钉钉群告警
    • 邮件通知相关负责人
  3. 响应要求：
    • 24 小时内响应
    • 纳入日常维护计划
  4. 问题处理：
    • 分析告警原因
    • 实施优化措施
  5. 验证效果：
    • 监控指标变化
    • 确认问题得到缓解
  6. 告警关闭：自动关闭或手动关闭

信息告警处理流程 ​

  1. 告警触发：监控系统检测到信息告警事件
  2. 通知方式：
    • 邮件通知相关负责人
    • 日志记录
  3. 响应要求：
    • 定期关注
    • 无需立即处理
  4. 处理方式：
    • 作为系统状态参考
    • 用于审计和统计分析
  5. 告警关闭：自动关闭

告警级别配置示例 ​

使用 Prometheus + Alertmanager 配置告警级别 ​

yaml
# Alertmanager 配置文件示例
route:
  group_by: ['alertname', 'cluster', 'service']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 3h
  receiver: 'default-receiver'
  routes:
    # 紧急告警路由
    - match:
        severity: 'critical'
      receiver: 'critical-receiver'
      group_wait: 10s
      group_interval: 1m
      repeat_interval: 30m
    # 重要告警路由
    - match:
        severity: 'major'
      receiver: 'major-receiver'
      group_wait: 30s
      group_interval: 5m
      repeat_interval: 1h
    # 警告告警路由
    - match:
        severity: 'warning'
      receiver: 'warning-receiver'
      group_wait: 1m
      group_interval: 10m
      repeat_interval: 2h

receivers:
  - name: 'default-receiver'
    email_configs:
      - to: 'monitoring@example.com'
  - name: 'critical-receiver'
    email_configs:
      - to: 'oncall@example.com'
    webhook_configs:
      - url: 'https://hooks.example.com/dingtalk/critical'
  - name: 'major-receiver'
    email_configs:
      - to: 'dba@example.com'
    webhook_configs:
      - url: 'https://hooks.example.com/dingtalk/major'
  - name: 'warning-receiver'
    email_configs:
      - to: 'dba@example.com'

MySQL 告警规则示例 ​

yaml
# Prometheus 告警规则示例
groups:
- name: mysql-alerts
  rules:
  # 紧急告警：数据库实例宕机
  - alert: MySQLInstanceDown
    expr: mysql_up == 0
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "MySQL 实例宕机"
      description: "MySQL 实例 {{ $labels.instance }} 已宕机超过 5 分钟"

  # 紧急告警：磁盘空间不足
  - alert: MySQLDiskSpaceLow
    expr: mysql_global_status_disk_free / mysql_global_status_disk_total * 100 < 5
    for: 10m
    labels:
      severity: critical
    annotations:
      summary: "MySQL 磁盘空间不足"
      description: "MySQL 实例 {{ $labels.instance }} 磁盘剩余空间不足 5%"

  # 重要告警：主从复制中断
  - alert: MySQLReplicationBroken
    expr: mysql_slave_status_sql_running == 0 or mysql_slave_status_io_running == 0
    for: 5m
    labels:
      severity: major
    annotations:
      summary: "MySQL 主从复制中断"
      description: "MySQL 实例 {{ $labels.instance }} 主从复制中断"

  # 重要告警：主从复制延迟过大
  - alert: MySQLReplicationLagHigh
    expr: mysql_slave_status_seconds_behind_master > 300
    for: 10m
    labels:
      severity: major
    annotations:
      summary: "MySQL 主从复制延迟过大"
      description: "MySQL 实例 {{ $labels.instance }} 主从复制延迟超过 300 秒"

  # 警告告警：连接数接近上限
  - alert: MySQLConnectionsHigh
    expr: mysql_global_status_threads_connected / mysql_global_variables_max_connections * 100 > 90
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: "MySQL 连接数接近上限"
      description: "MySQL 实例 {{ $labels.instance }} 连接数使用率超过 90%"

  # 信息告警：备份完成
  - alert: MySQLBackupCompleted
    expr: mysql_backup_status == 1
    for: 5m
    labels:
      severity: info
    annotations:
      summary: "MySQL 备份完成"
      description: "MySQL 实例 {{ $labels.instance }} 备份已完成"

告警级别最佳实践 ​

告警级别设置原则 ​

  • 基于业务影响：告警级别应主要基于对业务的影响程度，而非单纯的技术指标
  • 分级合理：建议设置 4-5 个告警级别，不宜过多或过少
  • 可操作性：每个告警级别应有明确的处理流程和责任人
  • 动态调整：根据业务变化和系统运行情况，定期调整告警级别
  • 避免告警风暴：对相似告警进行分组，避免同一事件产生大量告警

告警级别配置建议 ​

  • 紧急告警：仅用于最严重的故障，数量应控制在总告警数的 5% 以内
  • 重要告警：用于影响业务的重要事件，数量应控制在总告警数的 15% 以内
  • 警告告警：用于需要关注的异常情况，数量可占总告警数的 30% 左右
  • 信息告警：用于系统状态通知，数量可占总告警数的 50% 左右

告警级别管理建议 ​

  • 定期Review：每月或每季度Review告警级别设置，根据实际情况调整
  • 告警统计分析：定期统计分析不同级别告警的数量、处理时间和解决率
  • 告警抑制：对已知问题或维护期间的告警进行抑制，减少无效告警
  • 告警升级机制：建立明确的告警升级机制，确保告警得到及时处理
  • 自动化处理：对部分告警实现自动化处理，减少人工干预

版本差异 ​

MySQL 5.7 及之前版本 ​

  • 内置监控功能有限，主要依赖第三方监控工具
  • 告警级别分类简单，通常只有基本的错误和警告
  • 缺乏灵活的告警配置选项
  • 日志分析功能较弱，难以实现复杂的告警规则

MySQL 8.0 ​

  • 增强了内置监控功能，引入了 Performance Schema 和 Sys Schema
  • 支持更丰富的监控指标
  • 提供了更灵活的日志配置选项
  • 支持自定义审计规则，便于实现复杂的告警逻辑
  • 与现代监控工具（如 Prometheus、Grafana）更好集成

第三方监控工具版本差异 ​

  • Zabbix 3.x：支持基本的告警级别分类，配置相对复杂
  • Zabbix 5.x+：增强了告警级别管理，支持更灵活的告警路由和通知方式
  • Prometheus 2.x+：支持基于标签的告警规则，与 Alertmanager 配合实现强大的告警级别管理
  • Grafana 7.x+：增强了告警功能，支持内置告警和多种通知方式

常见问题（FAQ） ​

Q1: 如何确定告警级别？ ​

A1: 确定告警级别应考虑以下因素：

  • 对业务的影响程度：是否影响核心业务功能
  • 影响范围：单个实例还是整个集群
  • 持续时间：临时异常还是持续异常
  • 恢复难度：容易恢复还是需要复杂操作
  • 历史经验：类似问题的处理经验

Q2: 告警级别设置过多或过少有什么问题？ ​

A2:

  • 级别过多：会导致运维人员难以记忆和区分，增加处理复杂度
  • 级别过少：无法有效区分告警的严重程度，可能导致重要问题被忽略或资源浪费

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

A3: 可以采取以下措施避免告警风暴：

  • 对相似告警进行分组，合并通知
  • 设置合理的告警阈值和持续时间
  • 对已知问题或维护期间的告警进行抑制
  • 实现告警分级和升级机制
  • 定期Review和优化告警规则

Q4: 告警级别是否应该固定不变？ ​

A4: 告警级别不应该固定不变，应该根据业务变化和系统运行情况定期调整。例如，当业务增长导致系统负载增加时，可能需要调整某些告警的阈值和级别。

Q5: 如何评估告警级别的合理性？ ​

A5: 可以通过以下方式评估告警级别的合理性：

  • 统计不同级别告警的数量和处理时间
  • 分析告警的准确率和误报率
  • 收集运维人员的反馈
  • 评估告警处理的及时性和有效性
  • 分析故障恢复时间与告警级别的关系

Q6: 自动化处理应该应用于哪些级别的告警？ ​

A6: 自动化处理通常适用于以下级别的告警：

  • 信息告警：如备份完成通知，无需人工干预
  • 警告告警：如磁盘空间告警，可以自动清理日志或扩展存储空间
  • 部分重要告警：如主从复制延迟，可以尝试自动修复

对于紧急告警，通常需要人工干预，以确保故障得到正确处理。