外观
OceanBase 常见告警场景
集群状态告警
1. 集群不可用告警
告警信息：集群状态变为不可用（CLUSTER_UNAVAILABLE）
可能原因：
- 超过半数的RootService节点故障
- 集群网络出现分区，导致节点无法通信
- 集群资源耗尽，无法处理请求
- 集群发生严重数据一致性问题
处理步骤：
- 立即登录集群，检查RootService状态：sql
SELECT * FROM __all_root_service_status; - 检查节点状态，确认可用节点数量：sql
SHOW SERVERS; - 检查网络连接，确认是否存在网络分区：bash
# 在各个节点上执行ping和telnet命令，检查网络连通性 ping 192.168.1.20
telnet 192.168.1.20 2882
4. 检查资源使用情况，确认是否资源耗尽：
```sql
SELECT * FROM GV$OB_SERVERS WHERE status = 'active';- 如果是RootService节点故障，尝试重启故障节点；如果是网络分区，联系网络团队修复网络；如果是资源耗尽，考虑扩容集群或优化资源使用。
2. Zone不可用告警
告警信息：Zone状态变为不可用（ZONE_UNAVAILABLE）
可能原因：
- Zone内所有节点故障
- Zone内网络故障
- Zone内资源耗尽
- Zone被手动禁用
处理步骤：
- 检查Zone状态：sql
SHOW ZONES; - 检查Zone内节点状态：sql
SELECT * FROM GV$OB_SERVERS WHERE zone = 'zone_name'; - 检查Zone内网络连接：bash
# 在Zone内节点上执行网络连通性测试 - 检查Zone内资源使用情况：sql
SELECT zone, SUM(cpu_assigned) AS assigned_cpu, SUM(mem_assigned) AS assigned_mem FROM GV$OB_TENANTS GROUP BY zone; - 根据检查结果，采取相应措施：重启故障节点、修复网络问题、扩容Zone资源或启用Zone。
节点状态告警
1. 节点故障告警
告警信息：节点状态变为故障（SERVER_DOWN）
可能原因：
- 节点硬件故障（CPU、内存、磁盘、网卡等）
- 节点操作系统故障
- 节点进程崩溃
- 节点网络中断
处理步骤：
- 尝试登录故障节点，检查硬件和操作系统状态：bash
# 检查CPU和内存使用情况 top # 检查磁盘状态 df -h iostat -x # 检查网卡状态 ifconfig ethtool eth0 - 检查OceanBase进程状态：bash
ps aux | grep observer - 检查OceanBase日志，查找故障原因：bash
tail -f /home/admin/oceanbase/log/observer.log | grep -i error - 如果是硬件故障，更换故障硬件；如果是操作系统故障，修复或重装操作系统；如果是进程崩溃，重启OceanBase进程；如果是网络中断，修复网络连接。
- 节点恢复后，检查节点状态：sql
SHOW SERVERS;
2. 节点负载过高告警
告警信息：节点CPU/内存/IO使用率超过阈值
可能原因：
- 节点上运行的租户过多
- 某个租户的负载突然增加
- 节点资源配置不足
- 存在慢查询或性能问题
处理步骤：
- 检查节点资源使用情况：sql
SELECT * FROM GV$OB_SERVERS WHERE server_ip = '192.168.1.20'; - 检查节点上各租户的资源使用情况：sql
SELECT tenant_id, tenant_name, cpu_total, cpu_assigned, mem_total, mem_assigned FROM GV$OB_TENANTS WHERE svr_ip = '192.168.1.20'; - 检查是否存在慢查询：sql
SELECT * FROM GV$OB_SLOW_QUERY WHERE svr_ip = '192.168.1.20' ORDER BY start_time DESC LIMIT 10; - 检查是否存在性能问题：sql
SELECT * FROM GV$OB_PROCESS_LIST WHERE svr_ip = '192.168.1.20' ORDER BY TIME DESC LIMIT 10; - 根据检查结果，采取相应措施：迁移部分租户到其他节点、调整租户资源配置、优化慢查询、扩容节点资源。
资源使用告警
1. 内存使用率过高告警
告警信息：集群/节点/租户内存使用率超过阈值
可能原因：
- 内存配置不足
- 存在内存泄漏
- 租户内存使用不合理
- 有大量并发请求
处理步骤：
- 检查内存使用分布：sql
-- 集群内存使用 SELECT SUM(mem_total) AS total_mem, SUM(mem_assigned) AS assigned_mem FROM GV$OB_TENANTS; -- 节点内存使用 SELECT * FROM GV$OB_SERVERS WHERE mem_assigned / mem_total > 0.8; -- 租户内存使用 SELECT tenant_id, tenant_name, mem_total, mem_assigned FROM GV$OB_TENANTS WHERE mem_assigned / mem_total > 0.8; - 检查内存使用明细：sql
-- 查看租户内存使用明细 SELECT * FROM GV$OB_MEMORY_USAGE WHERE tenant_id = 1001; - 检查是否存在内存泄漏：sql
-- 监控内存使用趋势，确认是否持续增长 SELECT sample_time, sum(hold) FROM GV$OB_MEMORY_HOLD_HISTORY GROUP BY sample_time ORDER BY sample_time; - 根据检查结果，采取相应措施：增加内存配置、优化内存使用、调整租户资源、排查内存泄漏问题。
2. CPU使用率过高告警
告警信息：集群/节点/租户CPU使用率超过阈值
可能原因：
- CPU配置不足
- 存在大量并发请求
- 有耗时较长的SQL
- 存在CPU密集型操作
处理步骤：
- 检查CPU使用分布：sql
-- 集群CPU使用 SELECT SUM(cpu_total) AS total_cpu, SUM(cpu_assigned) AS assigned_cpu FROM GV$OB_TENANTS; -- 节点CPU使用 SELECT * FROM GV$OB_SERVERS WHERE cpu_assigned / cpu_total > 0.8; -- 租户CPU使用 SELECT tenant_id, tenant_name, cpu_total, cpu_assigned FROM GV$OB_TENANTS WHERE cpu_assigned / cpu_total > 0.8; - 检查CPU使用明细：sql
-- 查看租户CPU使用明细 SELECT * FROM GV$OB_PROCESS_LIST WHERE tenant_id = 1001 ORDER BY TIME DESC LIMIT 10; - 检查是否存在慢查询：sql
SELECT * FROM GV$OB_SLOW_QUERY ORDER BY query_time DESC LIMIT 10; - 根据检查结果，采取相应措施：增加CPU配置、优化SQL、调整租户资源、分散并发请求。
存储相关告警
1. 磁盘空间不足告警
告警信息：磁盘使用率超过阈值
可能原因：
- 数据量增长过快
- 备份数据未及时清理
- 日志文件过大
- 磁盘配置不足
处理步骤：
- 检查磁盘使用情况：bash
df -h - 检查目录占用情况，找出占用空间较大的目录：bash
du -sh /* | sort -hr - 检查OceanBase数据目录占用情况：bash
du -sh /home/admin/oceanbase/data/* - 检查备份目录占用情况：bash
du -sh /data/backup/* - 检查日志文件大小：bash
ls -lh /home/admin/oceanbase/log/ - 根据检查结果，采取相应措施：清理过期备份数据、归档或清理日志文件、扩容磁盘、优化数据存储（如压缩表）。
2. IOPS过高告警
告警信息：磁盘IOPS超过阈值
可能原因：
- 存在大量随机读写操作
- 有批量数据导入
- 正在执行备份或恢复操作
- 存储设备性能不足
处理步骤：
- 检查IO使用情况：bash
iostat -x 1 10 - 检查OceanBase的IO使用情况：sql
SELECT * FROM GV$OB_IO_STAT; - 检查是否有备份或恢复操作正在执行：sql
SHOW BACKUP TASKS; SHOW RESTORE TASKS; - 检查是否有大量写入操作：sql
SELECT * FROM GV$OB_SQL_AUDIT WHERE event = 'insert' OR event = 'update' OR event = 'delete' ORDER BY executions DESC LIMIT 10; - 根据检查结果，采取相应措施：优化SQL，减少随机IO、调整备份恢复策略、扩容存储设备、优化存储配置。
复制同步告警
1. 副本同步延迟告警
告警信息：副本同步延迟超过阈值
可能原因：
- 主副本负载过高，无法及时生成日志
- 备副本性能不足，无法及时应用日志
- 网络延迟过高，影响日志传输
- 存在大量写入操作，导致日志积压
处理步骤：
- 检查副本同步状态：sql
SELECT * FROM GV$OB_PARTITION_REPLICA WHERE status != 'NORMAL'; - 检查副本同步延迟：sql
SELECT * FROM GV$OB_LOG_STAT WHERE role = 'follower'; - 检查主副本和备副本的性能：sql
SELECT * FROM GV$OB_SERVERS WHERE svr_ip IN ('192.168.1.20', '192.168.1.21'); - 检查网络延迟：bash
ping -c 10 192.168.1.20 - 检查写入量：sql
SELECT sample_time, sum(write_bytes) FROM GV$OB_SSTABLE_WRITE_HISTORY GROUP BY sample_time ORDER BY sample_time; - 根据检查结果，采取相应措施：优化主副本性能、提升备副本配置、优化网络、调整写入模式或增加副本数量。
2. 副本丢失告警
告警信息：分区副本数量低于配置的副本数
可能原因：
- 节点故障，导致副本不可用
- 副本所在节点被移除集群
- 副本数据损坏，被自动删除
- 手动删除了副本
处理步骤：
- 检查分区副本状态：sql
SELECT * FROM GV$OB_PARTITION_REPLICA WHERE replica_count < desired_count; - 检查节点状态，确认是否有节点故障：sql
SHOW SERVERS; - 检查是否有节点被移除集群：sql
SELECT * FROM __all_server_event_history WHERE event_type = 'remove_server'; - 检查副本数据完整性：sql
SELECT * FROM GV$OB_CHECKPOINT WHERE status != 'VALID'; - 根据检查结果，采取相应措施：恢复故障节点、添加新节点、重新创建副本、修复数据损坏问题。
事务相关告警
1. 事务超时告警
告警信息：事务执行时间超过阈值
可能原因：
- 事务包含大量操作，执行时间过长
- 事务涉及的锁被其他事务占用
- 事务等待资源超时
- 存在死锁
处理步骤：
- 检查超时事务：sql
SELECT * FROM GV$OB_TRANSACTIONS WHERE state = 'RUNNING' AND elapse_time > 60000; - 检查锁等待情况：sql
SELECT * FROM GV$OB_LOCK_WAIT_STAT; - 检查是否存在死锁：sql
SELECT * FROM GV$OB_DEADLOCK_EVENT; - 检查事务涉及的SQL：sql
SELECT * FROM GV$OB_SQL_AUDIT WHERE trace_id = 'xxx'; - 根据检查结果，采取相应措施：优化事务，减少操作数量、调整事务隔离级别、优化锁使用、解决死锁问题。
2. 死锁告警
告警信息：检测到死锁
可能原因：
- 多个事务相互等待对方持有的锁
- 事务获取锁的顺序不一致
- 存在长事务持有锁时间过长
处理步骤：
- 查看死锁事件详情：sql
SELECT * FROM GV$OB_DEADLOCK_EVENT ORDER BY event_time DESC LIMIT 1; - 分析死锁日志，找出导致死锁的事务和SQL：bash
grep -i deadlock /home/admin/oceanbase/log/observer.log - 检查死锁涉及的表和索引：sql
SHOW CREATE TABLE db_name.table_name; - 根据分析结果，采取相应措施：调整事务获取锁的顺序、优化长事务、增加索引减少锁范围、调整事务隔离级别。
SQL相关告警
1. 慢查询告警
告警信息：SQL执行时间超过阈值
可能原因：
- SQL语句编写不合理，缺少索引
- 表数据量过大，没有分区
- 统计信息过期，导致执行计划不佳
- 存在全表扫描或全索引扫描
处理步骤：
- 查看慢查询详情：sql
SELECT * FROM GV$OB_SLOW_QUERY ORDER BY query_time DESC LIMIT 10; - 查看SQL的执行计划：sql
EXPLAIN EXTENDED SELECT * FROM table_name WHERE condition; - 检查表结构和索引：sql
SHOW CREATE TABLE table_name; SHOW INDEX FROM table_name; - 检查统计信息状态：sql
SELECT * FROM __all_table_stat WHERE table_name = 'table_name'; - 根据检查结果，采取相应措施：优化SQL语句、添加或修改索引、更新统计信息、分区表优化、调整执行计划。
2. 执行计划异常告警
告警信息：SQL执行计划发生异常变化
可能原因：
- 统计信息过期或不准确
- 表数据分布发生变化
- 索引被删除或修改
- 参数配置发生变化
处理步骤：
- 查看异常SQL的执行计划：sql
EXPLAIN EXTENDED SELECT * FROM table_name WHERE condition; - 查看历史执行计划，对比差异：sql
SELECT * FROM GV$OB_PLAN_CACHE_PLAN WHERE plan_id = 'xxx'; - 检查统计信息：sql
ANALYZE TABLE table_name; - 检查索引状态：sql
SHOW INDEX FROM table_name; - 检查参数配置：sql
SHOW PARAMETERS LIKE '%optimizer%'; - 根据检查结果，采取相应措施：更新统计信息、优化索引、调整参数配置、使用计划绑定固定执行计划。
权限安全告警
1. 权限变更告警
告警信息：用户权限发生变更
可能原因：
- 管理员手动调整了用户权限
- 存在恶意权限提升操作
- 权限管理脚本执行了权限变更
处理步骤：
- 查看权限变更记录：sql
SELECT * FROM __all_tenant_privilege_history ORDER BY gmt_create DESC LIMIT 10; - 确认权限变更是否为正常操作：
- 联系管理员确认是否有计划内的权限变更
- 检查权限变更的时间和操作者
- 如果是异常权限变更，采取相应措施：
- 立即撤销异常权限变更
- 检查并加固权限管理流程
- 审计权限变更操作，找出原因
2. 失败登录尝试告警
告警信息：检测到多次失败的登录尝试
可能原因：
- 用户输入了错误的密码
- 存在恶意暴力破解尝试
- 应用配置了错误的密码
处理步骤：
- 查看登录失败记录：sql
SELECT * FROM __all_tenant_login_history WHERE result = 'FAIL' ORDER BY gmt_create DESC LIMIT 10; - 分析登录失败的模式：
- 检查失败登录的IP地址，确认是否为合法IP
- 检查失败登录的用户名，确认是否为合法用户
- 如果是恶意攻击，采取相应措施：
- 临时封禁恶意IP
- 加强密码策略，使用复杂密码
- 启用双因素认证
- 限制登录IP范围
- 如果是应用配置错误，通知应用团队修正配置。
告警处理最佳实践
1. 告警分级管理
根据告警的严重程度和影响范围，将告警分为不同级别，采取不同的处理策略：
| 告警级别 | 严重程度 | 处理时间要求 | 处理策略 |
|---|---|---|---|
| 严重（Critical） | 高 | 立即处理（<15分钟） | 立即通知相关人员，启动应急响应流程 |
| 警告（Warning） | 中 | 尽快处理（<2小时） | 通知相关人员，在规定时间内处理 |
| 提示（Info） | 低 | 定期处理（<24小时） | 记录日志，定期分析和优化 |
2. 告警抑制和聚合
- 告警抑制：对于同一问题导致的多个告警，只保留最关键的告警，避免告警风暴
- 告警聚合：将同一类型或同一节点的告警聚合为一个告警，减少告警数量
- 告警降噪：过滤掉已知的、不影响业务的告警
3. 告警自动化处理
- 自动恢复：对于一些可以自动恢复的问题，配置自动恢复脚本
- 自动扩容：对于资源使用告警，配置自动扩容策略
- 自动切换：对于节点或Zone故障，配置自动切换策略
4. 告警复盘和优化
- 定期复盘：每周或每月对告警进行复盘，分析告警原因和处理效果
- 告警优化：根据复盘结果，优化告警阈值、告警规则和处理流程
- 根因分析：对于频繁出现的告警，进行根因分析，从根本上解决问题
- 文档更新：及时更新告警处理文档，积累处理经验
5. 告警监控工具
选择合适的监控工具，提高告警处理效率：
| 工具 | 适用场景 | 功能特点 |
|---|---|---|
| OCP | 企业级监控 | 可视化界面，全面的告警管理，支持告警抑制和聚合 |
| Prometheus + Alertmanager | 开源监控 | 灵活的告警规则配置，支持多种告警通知方式 |
| Zabbix | 传统监控 | 成熟稳定，支持多种监控方式和告警通知 |
| 自定义脚本 | 特定场景 | 针对特定需求定制，灵活高效 |
告警场景案例分析
案例1：慢查询导致CPU使用率过高
背景：某生产集群突然出现CPU使用率过高告警，影响业务正常运行。
处理过程：
- 检查CPU使用情况，发现有几个节点的CPU使用率超过90%。
- 查看慢查询日志，发现有一条SQL语句执行时间超过10秒，且执行频率很高。
- 分析该SQL语句的执行计划，发现缺少必要的索引，导致全表扫描。
- 为该表添加了合适的索引，SQL执行时间从10秒缩短到0.1秒。
- CPU使用率恢复正常，业务恢复稳定运行。
经验总结：
- 慢查询是导致CPU使用率过高的常见原因之一
- 及时分析慢查询，优化SQL和索引，能够快速解决问题
- 定期监控和分析慢查询，能够预防类似问题的发生
案例2：副本同步延迟导致数据不一致
背景：某生产集群出现副本同步延迟告警，延迟时间超过5分钟。
处理过程：
- 检查副本同步状态，发现备副本的同步延迟确实超过5分钟。
- 检查主副本和备副本的性能，发现备副本的CPU使用率超过90%，而主副本的CPU使用率只有50%。
- 检查备副本上的运行任务，发现有一个备份任务正在执行，占用了大量CPU资源。
- 暂停了该备份任务，备副本的CPU使用率下降到40%，同步延迟逐渐减少。
- 调整了备份策略，将备份任务安排在业务低峰期执行。
经验总结：
- 备副本的性能问题是导致同步延迟的常见原因
- 合理安排备份、统计信息收集等任务的执行时间，避免影响副本同步
- 监控副本同步状态，及时发现和解决同步延迟问题
常见问题（FAQ）
Q1: 如何设置合理的告警阈值？
A1: 设置告警阈值需要考虑以下因素：
- 业务的重要程度和敏感度
- 集群的规模和配置
- 历史性能数据和趋势
- 资源使用的正常波动范围
建议从小的阈值开始，逐步调整，找到合适的平衡点，既不会产生过多的误告警，又能及时发现问题。
Q2: 如何避免告警风暴？
A2: 避免告警风暴的方法包括：
- 合理设置告警阈值，减少误告警
- 配置告警抑制和聚合规则
- 对同一问题只发送一次告警
- 分级处理告警，只关注关键告警
- 定期清理无效的告警规则
Q3: 告警处理的优先级如何确定？
A3: 告警处理的优先级应根据以下因素确定：
- 告警的严重程度
- 告警对业务的影响范围
- 告警的紧急程度
- 处理告警所需的时间和资源
一般来说，影响整个集群的严重告警应优先处理，其次是影响单个Zone或节点的告警，最后是影响单个租户或表的告警。
Q4: 如何验证告警是否已经解决？
A4: 验证告警是否已经解决的方法包括：
- 查看告警状态，确认是否已恢复
- 检查相关指标，确认是否回到正常范围
- 执行相关命令，确认功能正常
- 运行业务测试，确认业务正常运行
Q5: 如何建立有效的告警管理流程？
A5: 建立有效的告警管理流程需要：
- 明确告警的分级标准和处理时间要求
- 明确各角色的职责和权限
- 建立告警通知和升级机制
- 建立告警处理和复盘流程
- 定期优化告警规则和处理流程
Q6: 如何利用告警数据进行容量规划？
A6: 利用告警数据进行容量规划的方法包括：
- 分析历史告警数据，识别资源瓶颈
- 监控资源使用趋势，预测未来需求
- 根据告警阈值和资源使用率，计算扩容需求
- 结合业务增长情况，制定容量规划
Q7: 如何区分真正的问题和误告警？
A7: 区分真正的问题和误告警的方法包括：
- 检查多个相关指标，确认是否真的存在问题
- 查看历史数据，确认是否为正常波动
- 检查业务是否受到影响
- 结合其他监控信息，综合判断
Q8: 如何持续优化告警系统？
A8: 持续优化告警系统的方法包括：
- 定期复盘告警处理情况，总结经验教训
- 分析告警数据，识别高频告警和误告警
- 调整告警阈值和规则，减少误告警
- 优化告警通知方式，提高告警的可读性和可操作性
- 引入自动化处理机制，提高告警处理效率