osiman/SuperBizAgent-java
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

commit

Browse Source
This commit is contained in:
zhuyongxin
2026-04-30 11:19:46 +08:00
parent 0671ad8bab
commit 80eada415d
42 changed files with 9135 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
aiops-docs/cpu_high_usage.md
+135
View File
@@ -0,0 +1,135 @@
# CPU使用率过高告警处理方案
## 告警名称
- **告警名**: `HighCPUUsage`
- **告警级别**: 严重
- **触发条件**: CPU使用率持续5分钟超过80%
## 问题描述
当服务器或容器的CPU使用率持续超过80%时，可能导致：
- 应用响应变慢
- 请求超时增加
- 系统负载过高
- 可能触发雪崩效应
## 排查步骤
### 步骤1: 获取当前时间
**工具**: `get_current_time`
**目的**: 确定告警发生的时间范围，用于后续日志查询
### 步骤2: 查询系统日志
**工具**: `query_logs`
**参数要求**:
- **地域**: `ap-guangzhou` (广州)
- **日志主题**: `system-metrics`
- **时间范围**: 最近30分钟
- **查询条件**: `level:ERROR OR cpu_usage:>80`
**查询示例**:
```
地域: ap-guangzhou
日志主题: system-metrics
时间范围: 2024-01-20 14:00:00 到 2024-01-20 14:30:00
查询语句: cpu_usage > 80 AND service_name:*
```
### 步骤3: 分析CPU消耗进程
查看日志中的进程信息，重点关注：
- 进程名称和PID
- CPU占用百分比
- 进程启动时间
- 进程所属服务
### 步骤4: 查询应用日志
**工具**: `query_logs`
**参数要求**:
- **地域**: `ap-guangzhou`
- **日志主题**: `application-logs`
- **时间范围**: 与告警时间一致
- **查询条件**: `level:ERROR OR level:WARN`
## 常见原因分析
### 原因1: 死循环或无限递归
**特征**:
- 单个进程CPU占用接近100%
- 应用日志中有大量重复的错误堆栈
- 内存使用也可能同步增长
**处理方案**:
1. 立即重启受影响的服务实例
2. 查看应用日志定位代码问题
3. 回滚到上一个稳定版本
4. 通知开发团队修复代码bug
### 原因2: 流量突增
**特征**:
- 多个进程CPU使用率均匀升高
- 请求量明显增加
- 响应时间变长但无明显错误
**处理方案**:
1. 检查是否有营销活动或突发流量
2. 启动自动扩容机制
3. 如果是恶意流量，启用限流策略
4. 监控扩容后的CPU使用率
### 原因3: 定时任务重叠执行
**特征**:
- CPU使用率周期性升高
- 特定时间点出现
- 日志中有定时任务执行记录
**处理方案**:
1. 检查定时任务配置
2. 调整任务执行时间，避免重叠
3. 优化任务执行逻辑
4. 增加任务执行互斥锁
### 原因4: 数据库查询慢
**特征**:
- 应用CPU高，但实际业务逻辑简单
- 日志中有慢查询记录
- 数据库连接池占用高
**处理方案**:
1. 查询慢SQL日志
2. 优化SQL语句或添加索引
3. 检查是否有全表扫描
4. 考虑增加缓存层
## 紧急处理措施
### 立即操作（5分钟内）
1. **扩容**: 如果是流量问题，立即增加实例数量
2. **限流**: 如果怀疑恶意流量，启用限流规则
3. **重启**: 如果是单个实例问题，重启该实例
### 短期措施（30分钟内）
1. 分析日志找出根本原因
2. 如果是代码问题，准备回滚
3. 如果是配置问题，调整配置
4. 持续监控CPU使用率变化
### 长期优化
1. 代码性能优化
2. 增加监控告警阈值
3. 完善自动扩缩容策略
4. 定期进行压力测试
## 验证步骤
1. 确认CPU使用率降到正常水平（<60%）
2. 检查应用响应时间恢复正常
3. 确认无新的错误日志产生
4. 观察30分钟确保问题不再复现
## 相关告警
- `HighMemoryUsage`: 内存使用率过高
- `HighLoadAverage`: 系统负载过高
- `SlowResponse`: 响应时间过长
## 联系方式
- **运维团队**: ops-team@company.com
- **开发团队**: dev-team@company.com
- **紧急电话**: 400-xxx-xxxx
aiops-docs/disk_high_usage.md
+343
View File
@@ -0,0 +1,343 @@
# 磁盘使用率过高告警处理方案
## 告警名称
- **告警名**: `HighDiskUsage`
- **告警级别**: 警告（>80%）/ 严重（>90%）
- **触发条件**: 磁盘使用率持续5分钟超过阈值
## 问题描述
磁盘使用率过高会导致：
- 无法写入新数据
- 日志无法记录
- 应用崩溃
- 数据库损坏
- 系统性能下降
## 排查步骤
### 步骤1: 获取当前时间
**工具**: `get_current_time`
**目的**: 记录告警时间，用于日志查询
### 步骤2: 查询系统磁盘使用情况
**工具**: `query_logs`
**参数要求**:
- **地域**: `ap-guangzhou`
- **日志主题**: `system-metrics`
- **时间范围**: 最近30分钟
- **查询条件**: `disk_usage:>80 OR disk_full:true`
**查询示例**:
```
地域: ap-guangzhou
日志主题: system-metrics
时间范围: [当前时间-30分钟] 到 [当前时间]
查询语句: disk_usage > 80 OR filesystem:full
```
### 步骤3: 查询应用日志
**工具**: `query_logs`
**参数要求**:
- **地域**: `ap-guangzhou`
- **日志主题**: `application-logs`
- **查询条件**: `No space left on device OR disk full`
### 步骤4: 分析磁盘占用
从日志中分析：
- 哪个目录占用空间最大
- 日志文件大小
- 临时文件数量
- 数据文件增长趋势
## 常见原因分析
### 原因1: 日志文件过大
**特征**:
- /var/log 目录占用大量空间
- 应用日志文件持续增长
- 没有日志轮转或轮转失败
- 日志级别设置为DEBUG
**处理方案**:
1. **立即清理**:
```bash
# 查找大日志文件
find /var/log -type f -size +100M
# 清空日志文件（保留文件）
> /var/log/application.log
# 压缩旧日志
gzip /var/log/*.log.1
# 删除旧日志
find /var/log -name "*.log.*" -mtime +7 -delete
```
2. **配置日志轮转**:
- 启用logrotate
- 设置日志保留天数
- 配置日志压缩
- 限制单个日志文件大小
3. **优化日志级别**:
- 生产环境使用INFO或WARN级别
- 避免打印大对象
- 减少不必要的日志
### 原因2: 临时文件堆积
**特征**:
- /tmp 目录占用大量空间
- 大量临时文件未清理
- 文件上传临时目录满
- 缓存文件过多
**处理方案**:
1. **清理临时文件**:
```bash
# 查找大临时文件
find /tmp -type f -size +100M
# 删除7天前的临时文件
find /tmp -type f -mtime +7 -delete
# 清理应用临时目录
rm -rf /app/temp/*
```
2. **定期清理**:
- 设置定时任务清理临时文件
- 应用启动时清理旧临时文件
- 文件处理完成后立即删除
3. **优化临时文件使用**:
- 使用流式处理避免临时文件
- 限制临时文件大小
- 使用内存缓存替代临时文件
### 原因3: 数据文件增长过快
**特征**:
- 数据库文件持续增长
- 业务数据量激增
- 没有数据归档策略
- 历史数据未清理
**处理方案**:
1. **数据清理**:
- 删除过期数据
- 归档历史数据
- 清理测试数据
- 优化数据存储
2. **数据归档**:
- 建立数据归档策略
- 定期归档历史数据
- 使用对象存储保存归档数据
- 实现冷热数据分离
3. **扩容磁盘**:
- 如果是正常业务增长，扩容磁盘
- 使用云盘动态扩容
- 考虑分布式存储
### 原因4: 备份文件占用空间
**特征**:
- 备份目录占用大量空间
- 多个历史备份文件
- 备份文件未压缩
- 备份未转移到其他存储
**处理方案**:
1. **清理旧备份**:
```bash
# 查找备份文件
find /backup -name "*.bak" -mtime +30
# 删除30天前的备份
find /backup -name "*.bak" -mtime +30 -delete
```
2. **优化备份策略**:
- 只保留最近N天的备份
- 压缩备份文件
- 备份到对象存储
- 实现增量备份
3. **备份转移**:
- 将备份转移到专用存储
- 使用云存储服务
- 定期清理本地备份
### 原因5: 应用缓存文件过多
**特征**:
- 缓存目录占用大量空间
- 缓存文件未过期清理
- 缓存策略不合理
- 缓存命中率低
**处理方案**:
1. **清理缓存**:
```bash
# 清理应用缓存
rm -rf /app/cache/*
# 清理Maven缓存
rm -rf ~/.m2/repository
# 清理Docker缓存
docker system prune -a
```
2. **优化缓存策略**:
- 设置缓存过期时间
- 限制缓存大小
- 实现LRU淘汰策略
- 使用Redis等外部缓存
### 原因6: Docker镜像和容器占用
**特征**:
- Docker占用大量磁盘空间
- 大量未使用的镜像
- 停止的容器未清理
- 容器日志过大
**处理方案**:
1. **清理Docker资源**:
```bash
# 清理未使用的镜像
docker image prune -a
# 清理停止的容器
docker container prune
# 清理未使用的卷
docker volume prune
# 清理所有未使用资源
docker system prune -a --volumes
```
2. **限制容器日志**:
- 配置日志驱动
- 限制日志文件大小
- 设置日志轮转
3. **优化镜像**:
- 使用多阶段构建
- 减小镜像体积
- 定期清理旧镜像
## 紧急处理措施
### 立即操作（5分钟内）
1. **快速清理**:
- 删除大日志文件
- 清理临时文件
- 删除不必要的文件
2. **释放空间**:
```bash
# 查找最大的10个文件
du -ah / | sort -rh | head -n 10
# 查找最大的10个目录
du -h --max-depth=1 / | sort -rh | head -n 10
```
3. **紧急扩容**:
- 如果无法快速清理，立即扩容磁盘
### 短期措施（30分钟内）
1. **系统清理**:
- 清理包管理器缓存
- 清理系统日志
- 清理core dump文件
2. **应用优化**:
- 配置日志轮转
- 清理应用缓存
- 删除过期数据
3. **监控设置**:
- 设置磁盘使用率告警
- 监控磁盘增长趋势
- 定期检查大文件
### 长期优化
1. **自动化清理**:
- 设置定时清理任务
- 实现自动日志轮转
- 自动归档历史数据
2. **容量规划**:
- 根据业务增长规划容量
- 预留足够的磁盘空间
- 实现弹性扩容
3. **监控完善**:
- 监控各目录磁盘使用
- 预测磁盘使用趋势
- 提前告警
## 常用命令
### 查看磁盘使用情况
```bash
# 查看磁盘使用率
df -h
# 查看目录大小
du -sh /var/log
# 查找大文件
find / -type f -size +1G
# 查看inode使用情况
df -i
```
### 清理命令
```bash
# 清空文件内容（保留文件）
> /var/log/large.log
# 删除N天前的文件
find /path -mtime +N -delete
# 压缩日志文件
gzip /var/log/*.log
# 清理包管理器缓存
yum clean all # CentOS
apt-get clean # Ubuntu
```
## 验证步骤
1. 确认磁盘使用率降到安全水平（<70%）
2. 检查应用运行正常
3. 验证日志可以正常写入
4. 确认数据库运行正常
5. 持续监控磁盘使用情况
## 预防措施
1. **监控告警**: 设置60%预警，80%严重告警
2. **定期清理**: 每周自动清理临时文件和旧日志
3. **容量规划**: 根据增长趋势提前扩容
4. **日志管理**: 实施统一的日志管理策略
5. **数据归档**: 建立数据归档和清理机制
## 相关告警
- `InodeFull`: inode耗尽
- `DiskIOHigh`: 磁盘IO过高
- `DiskReadOnly`: 磁盘只读
- `FileSystemError`: 文件系统错误
## 联系方式
- **运维团队**: ops-team@company.com
- **存储团队**: storage-team@company.com
- **紧急电话**: 400-xxx-xxxx
## 参考文档
- [磁盘管理最佳实践](internal-docs/disk-management.md)
- [日志管理规范](internal-docs/log-management.md)
- [数据归档策略](internal-docs/data-archiving.md)
aiops-docs/memory_high_usage.md
+180
View File
@@ -0,0 +1,180 @@
# 内存使用率过高告警处理方案
## 告警名称
- **告警名**: `HighMemoryUsage`
- **告警级别**: 严重
- **触发条件**: 内存使用率持续5分钟超过85%
## 问题描述
当服务器或容器的内存使用率持续超过85%时，可能导致：
- 应用频繁GC（垃圾回收）
- OOM（Out Of Memory）错误
- 应用崩溃或重启
- 系统swap频繁，性能急剧下降
## 排查步骤
### 步骤1: 获取当前时间
**工具**: `get_current_time`
**目的**: 确定告警发生的时间范围
### 步骤2: 查询系统监控日志
**工具**: `query_logs`
**参数要求**:
- **地域**: `ap-guangzhou`
- **日志主题**: `system-metrics`
- **时间范围**: 最近30分钟
- **查询条件**: `memory_usage:>85 OR event:OOM`
**查询示例**:
```
地域: ap-guangzhou
日志主题: system-metrics
时间范围: [当前时间-30分钟] 到 [当前时间]
查询语句: memory_usage > 85 OR oom_kill:true
```
### 步骤3: 查询应用日志
**工具**: `query_logs`
**参数要求**:
- **地域**: `ap-guangzhou`
- **日志主题**: `application-logs`
- **查询条件**: `OutOfMemoryError OR GC overhead`
### 步骤4: 分析内存使用情况
从日志中提取：
- JVM堆内存使用情况
- GC频率和耗时
- 是否有内存泄漏迹象
- 大对象分配记录
## 常见原因分析
### 原因1: 内存泄漏
**特征**:
- 内存使用率持续缓慢上升
- Full GC后内存无法释放
- 应用运行时间越长，内存占用越高
- 日志中有大量GC记录
**处理方案**:
1. **紧急措施**: 重启应用释放内存
2. **获取堆转储**: 在重启前dump内存快照
3. **分析内存泄漏**: 使用MAT工具分析堆转储文件
4. **定位代码问题**: 找出持有大量对象引用的代码
5. **修复并发布**: 修复内存泄漏代码并重新部署
### 原因2: 流量突增导致对象激增
**特征**:
- 内存使用率突然升高
- 与流量增长同步
- GC能够回收大部分内存
- 应用日志显示请求量激增
**处理方案**:
1. **立即扩容**: 增加应用实例数量
2. **启用限流**: 保护系统不被压垮
3. **优化缓存**: 检查缓存策略是否合理
4. **增加内存**: 如果是合理的业务增长，考虑增加内存配置
### 原因3: 缓存配置不当
**特征**:
- 缓存占用内存过大
- 缓存命中率低
- 缓存数据长时间不过期
- 日志中有缓存相关警告
**处理方案**:
1. **调整缓存大小**: 减少缓存容量上限
2. **优化过期策略**: 设置合理的TTL
3. **启用LRU淘汰**: 确保缓存能自动淘汰旧数据
4. **监控缓存指标**: 持续观察缓存命中率和内存占用
### 原因4: 大文件或大数据处理
**特征**:
- 特定时间点内存突增
- 日志中有文件上传或数据导入记录
- 处理完成后内存可以释放
- 与定时任务或用户操作相关
**处理方案**:
1. **优化处理逻辑**: 改为流式处理，避免一次性加载
2. **限制文件大小**: 设置上传文件大小限制
3. **分批处理**: 大数据处理改为分批次进行
4. **异步处理**: 将大数据处理任务放到后台队列
### 原因5: JVM参数配置不合理
**特征**:
- 堆内存配置过小
- 新生代和老年代比例不合理
- GC算法选择不当
- 元空间（Metaspace）溢出
**处理方案**:
1. **调整堆内存**: 增加-Xmx和-Xms参数
2. **优化GC参数**: 根据应用特点选择合适的GC算法
3. **调整代际比例**: 优化-XX:NewRatio参数
4. **增加元空间**: 调整-XX:MetaspaceSize参数
## 紧急处理措施
### 立即操作（5分钟内）
1. **重启高内存实例**: 快速释放内存，恢复服务
2. **扩容**: 增加实例数量，分散内存压力
3. **限流**: 如果是流量问题，启用限流保护
### 短期措施（30分钟内）
1. **分析日志**: 确定内存增长的根本原因
2. **dump内存快照**: 保留现场用于后续分析
3. **调整JVM参数**: 如果是配置问题，临时调整参数
4. **清理缓存**: 手动清理不必要的缓存数据
### 长期优化
1. **代码优化**: 修复内存泄漏，优化对象创建
2. **监控完善**: 增加内存监控指标和告警
3. **压力测试**: 定期进行内存压力测试
4. **容量规划**: 根据业务增长合理规划内存容量
## 验证步骤
1. 确认内存使用率降到正常水平（<70%）
2. 观察GC频率和耗时是否正常
3. 检查应用日志无OOM错误
4. 持续监控30分钟确保稳定
## 预防措施
1. **设置合理的内存告警阈值**: 70%预警，85%严重
2. **定期内存分析**: 每周分析内存使用趋势
3. **代码审查**: 关注大对象创建和集合使用
4. **压力测试**: 上线前进行充分的内存压力测试
## 相关工具命令
### 查看JVM内存使用
```bash
jmap -heap <pid>
```
### 生成堆转储文件
```bash
jmap -dump:format=b,file=heap.hprof <pid>
```
### 查看GC日志
```bash
jstat -gc <pid> 1000
```
## 相关告警
- `HighCPUUsage`: CPU使用率过高（可能伴随频繁GC）
- `FrequentGC`: GC频率过高
- `OOMError`: 内存溢出错误
- `SlowResponse`: 响应时间过长
## 联系方式
- **运维团队**: ops-team@company.com
- **开发团队**: dev-team@company.com
- **紧急电话**: 400-xxx-xxxx
## 参考文档
- [JVM内存管理最佳实践](internal-docs/jvm-memory-best-practices.md)
- [内存泄漏排查指南](internal-docs/memory-leak-troubleshooting.md)
aiops-docs/service_unavailable.md
+289
View File
@@ -0,0 +1,289 @@
# 服务不可用告警处理方案
## 告警名称
- **告警名**: `ServiceUnavailable`
- **告警级别**: 紧急
- **触发条件**: 服务健康检查失败或错误率超过50%
## 问题描述
服务不可用是最严重的故障，会导致：
- 用户无法访问服务
- 业务完全中断
- 可能造成经济损失
- 影响公司声誉
## 排查步骤
### 步骤1: 获取当前时间
**工具**: `get_current_time`
**目的**: 记录故障发生时间，用于后续分析
### 步骤2: 查询服务状态日志
**工具**: `query_logs`
**参数要求**:
- **地域**: `ap-guangzhou`
- **日志主题**: `application-logs`
- **时间范围**: 最近15分钟
- **查询条件**: `level:ERROR OR level:FATAL OR status:500`
**查询示例**:
```
地域: ap-guangzhou
日志主题: application-logs
时间范围: [当前时间-15分钟] 到 [当前时间]
查询语句: (level:ERROR OR level:FATAL) AND service_name:*
```
### 步骤3: 查询系统事件日志
**工具**: `query_logs`
**参数要求**:
- **地域**: `ap-guangzhou`
- **日志主题**: `system-events`
- **查询条件**: `event:restart OR event:crash OR event:oom_kill`
### 步骤4: 检查依赖服务状态
**工具**: `query_logs`
**参数要求**:
- **地域**: `ap-guangzhou`
- **日志主题**: `application-logs`
- **查询条件**: `downstream_service OR database OR redis OR mq`
## 常见原因分析
### 原因1: 应用崩溃或无法启动
**特征**:
- 所有实例都无法响应
- 日志中有启动失败记录
- 可能有OOM或其他致命错误
- 健康检查全部失败
**处理方案**:
1. **立即回滚**:
- 如果是新版本发布后出现，立即回滚到上一个稳定版本
- 使用蓝绿部署或金丝雀发布策略
2. **紧急修复**:
- 查看启动日志定位问题
- 检查配置文件是否正确
- 验证依赖服务是否可用
- 修复后重新部署
3. **临时方案**:
- 启用备用服务
- 显示维护页面
- 通知用户服务异常
### 原因2: 数据库连接失败
**特征**:
- 日志中有数据库连接错误
- "Connection refused" 或 "Too many connections"
- 数据库服务异常
- 连接池耗尽
**处理方案**:
1. **检查数据库状态**:
- 确认数据库服务是否运行
- 检查数据库连接数
- 查看数据库错误日志
2. **恢复数据库连接**:
- 重启数据库（如果必要）
- 增加最大连接数
- 释放僵死连接
- 检查网络连通性
3. **应用层处理**:
- 重启应用重建连接池
- 调整连接池配置
- 实现连接重试机制
### 原因3: 依赖服务故障
**特征**:
- 日志中有调用第三方服务失败
- Redis、MQ等中间件不可用
- 网络连接超时
- 级联故障
**处理方案**:
1. **快速降级**:
- 启用熔断机制
- 跳过非关键依赖
- 使用缓存数据
- 返回降级响应
2. **恢复依赖服务**:
- 检查Redis、MQ等服务状态
- 重启故障的依赖服务
- 修复网络连接问题
3. **隔离故障**:
- 防止故障扩散
- 限制重试次数
- 实现超时控制
### 原因4: 配置错误
**特征**:
- 最近有配置变更
- 日志中有配置加载错误
- 特定环境变量缺失
- 启动参数错误
**处理方案**:
1. **回滚配置**:
- 恢复到上一个正确的配置
- 检查配置文件语法
- 验证环境变量
2. **修复配置**:
- 对比正确的配置文件
- 修正错误的配置项
- 重新加载配置
3. **配置管理**:
- 使用配置中心统一管理
- 配置变更需要审批
- 保留配置历史版本
### 原因5: 资源耗尽
**特征**:
- 磁盘空间满
- 文件描述符耗尽
- 端口被占用
- 内存不足导致OOM
**处理方案**:
1. **清理资源**:
- 清理磁盘空间（日志、临时文件）
- 释放文件描述符
- 杀死占用端口的进程
2. **扩容资源**:
- 增加磁盘空间
- 调整系统限制（ulimit）
- 增加内存配置
3. **优化使用**:
- 实现日志轮转
- 及时关闭文件句柄
- 优化内存使用
### 原因6: 网络故障
**特征**:
- 无法访问服务
- 网络连接超时
- 负载均衡器异常
- DNS解析失败
**处理方案**:
1. **检查网络**:
- 测试网络连通性（ping, telnet）
- 检查防火墙规则
- 验证安全组配置
- 检查DNS解析
2. **修复网络**:
- 重启网络服务
- 修正路由配置
- 更新负载均衡器配置
- 切换到备用网络
3. **流量切换**:
- 切换到备用地域
- 使用备用域名
- 启用CDN
## 紧急处理流程
### 第一时间（1分钟内）
1. **确认故障**: 通过监控和日志确认服务确实不可用
2. **启动应急**: 通知相关人员，启动应急响应流程
3. **止损措施**:
- 如果是部分实例故障，摘除故障实例
- 如果是全部故障，启用备用服务或维护页面
### 5分钟内
1. **快速定位**: 查看日志和监控，快速定位问题原因
2. **决策处理**:
- 如果能快速修复，立即修复
- 如果无法快速修复，执行回滚
- 如果是依赖故障，启用降级
### 15分钟内
1. **恢复服务**: 通过回滚、修复或降级恢复服务
2. **验证功能**: 确认核心功能可用
3. **监控观察**: 持续监控服务状态
### 30分钟内
1. **全面验证**: 验证所有功能正常
2. **通知用户**: 如果影响用户，发布公告
3. **初步总结**: 记录故障原因和处理过程
## 验证步骤
1. **健康检查**: 确认所有实例健康检查通过
2. **功能测试**: 测试核心业务功能
3. **性能验证**: 确认响应时间和吞吐量正常
4. **错误率**: 确认错误率降到正常水平（<1%）
5. **持续监控**: 观察30分钟确保稳定
## 预防措施
1. **高可用架构**:
- 多实例部署
- 多地域容灾
- 数据库主从复制
- 关键服务冗余
2. **监控告警**:
- 完善的健康检查
- 实时监控告警
- 自动故障转移
- 异常自动恢复
3. **发布策略**:
- 灰度发布
- 蓝绿部署
- 金丝雀发布
- 快速回滚机制
4. **容错设计**:
- 熔断降级
- 限流保护
- 超时控制
- 重试机制
5. **演练测试**:
- 定期故障演练
- 压力测试
- 混沌工程
- 应急预案演练
## 故障复盘
故障恢复后，必须进行复盘：
1. **故障时间线**: 记录故障发生、发现、处理、恢复的完整时间线
2. **根因分析**: 深入分析故障根本原因
3. **影响评估**: 评估故障影响范围和损失
4. **改进措施**: 制定防止类似故障的改进措施
5. **文档更新**: 更新运维文档和应急预案
## 相关告警
- `HighErrorRate`: 错误率过高
- `HealthCheckFailed`: 健康检查失败
- `AllInstancesDown`: 所有实例下线
- `DatabaseConnectionFailed`: 数据库连接失败
## 紧急联系方式
- **运维值班**: 400-xxx-1111（24小时）
- **开发值班**: 400-xxx-2222（24小时）
- **DBA值班**: 400-xxx-3333（24小时）
- **网络团队**: 400-xxx-4444
- **安全团队**: 400-xxx-5555
## 升级机制
- **15分钟未恢复**: 升级到技术总监
- **30分钟未恢复**: 升级到CTO
- **1小时未恢复**: 启动最高级别应急响应
## 参考文档
- [应急响应流程](internal-docs/emergency-response.md)
- [故障处理手册](internal-docs/incident-handbook.md)
- [高可用架构设计](internal-docs/ha-architecture.md)
aiops-docs/slow_response.md
+257
View File
@@ -0,0 +1,257 @@
# 服务响应时间过长告警处理方案
## 告警名称
- **告警名**: `SlowResponse`
- **告警级别**: 警告
- **触发条件**: P99响应时间持续5分钟超过3秒
## 问题描述
当服务的响应时间持续超过阈值时，会导致：
- 用户体验下降
- 请求堆积
- 可能触发超时错误
- 影响下游服务
## 排查步骤
### 步骤1: 获取当前时间
**工具**: `get_current_time`
**目的**: 确定告警发生的准确时间
### 步骤2: 查询应用性能日志
**工具**: `query_logs`
**参数要求**:
- **地域**: `ap-guangzhou`
- **日志主题**: `application-logs`
- **时间范围**: 最近30分钟
- **查询条件**: `response_time:>3000 OR slow_query:true`
**查询示例**:
```
地域: ap-guangzhou
日志主题: application-logs
时间范围: [当前时间-30分钟] 到 [当前时间]
查询语句: response_time > 3000 AND level:WARN
```
### 步骤3: 查询数据库慢查询日志
**工具**: `query_logs`
**参数要求**:
- **地域**: `ap-guangzhou`
- **日志主题**: `database-slow-query`
- **时间范围**: 与告警时间一致
- **查询条件**: `query_time:>1000`
### 步骤4: 查询系统资源使用情况
**工具**: `query_logs`
**参数要求**:
- **地域**: `ap-guangzhou`
- **日志主题**: `system-metrics`
- **查询条件**: `cpu_usage OR memory_usage OR disk_io`
## 常见原因分析
### 原因1: 数据库慢查询
**特征**:
- 慢查询日志中有大量记录
- 数据库CPU使用率高
- 特定SQL执行时间长
- 数据库连接池接近满载
**处理方案**:
1. **立即优化**:
- 找出最慢的SQL语句
- 检查是否缺少索引
- 查看执行计划（EXPLAIN）
- 临时添加索引或优化SQL
2. **短期措施**:
- 增加数据库连接池大小
- 启用查询缓存
- 考虑读写分离
3. **长期优化**:
- 定期分析慢查询日志
- 优化数据库表结构
- 建立合适的索引策略
- 考虑分库分表
### 原因2: 外部API调用超时
**特征**:
- 日志中有第三方API调用记录
- 特定接口响应时间长
- 可能有网络超时错误
- 下游服务响应慢
**处理方案**:
1. **设置合理超时**:
- 调整HTTP客户端超时时间
- 避免无限等待
- 设置连接超时和读取超时
2. **实施降级策略**:
- 启用熔断机制
- 返回默认值或缓存数据
- 异步处理非关键调用
3. **优化调用方式**:
- 并行调用多个API
- 使用批量接口减少调用次数
- 增加本地缓存
### 原因3: 代码性能问题
**特征**:
- CPU使用率高
- 特定代码路径执行慢
- 日志中有性能警告
- 无明显外部依赖问题
**处理方案**:
1. **性能分析**:
- 使用APM工具定位慢方法
- 查看火焰图找出热点
- 分析代码执行路径
2. **代码优化**:
- 优化循环和递归
- 减少不必要的对象创建
- 使用更高效的数据结构
- 避免重复计算
3. **异步处理**:
- 非关键逻辑异步执行
- 使用消息队列解耦
- 实现异步响应
### 原因4: 缓存失效或缓存穿透
**特征**:
- 缓存命中率突然下降
- 数据库查询量激增
- 特定时间点响应变慢
- 日志中有缓存miss记录
**处理方案**:
1. **缓存预热**:
- 重启后立即预热热点数据
- 定时刷新缓存
- 避免缓存同时失效
2. **防止缓存穿透**:
- 对空值也进行缓存
- 使用布隆过滤器
- 参数校验防止恶意查询
3. **优化缓存策略**:
- 设置合理的过期时间
- 使用多级缓存
- 实现缓存更新机制
### 原因5: 系统资源不足
**特征**:
- CPU或内存使用率高
- 磁盘IO繁忙
- 网络带宽占用高
- 系统负载过高
**处理方案**:
1. **资源扩容**:
- 增加实例数量（水平扩展）
- 升级实例规格（垂直扩展）
- 优化资源分配
2. **负载均衡**:
- 检查负载均衡配置
- 确保流量均匀分布
- 移除异常实例
3. **限流降级**:
- 启用限流保护
- 降级非核心功能
- 优先保证核心业务
### 原因6: 网络问题
**特征**:
- 跨地域调用延迟高
- 网络丢包率增加
- 特定时间段网络拥堵
- 日志中有网络超时错误
**处理方案**:
1. **网络优化**:
- 使用CDN加速
- 优化网络路由
- 启用HTTP/2或QUIC
2. **就近访问**:
- 部署多地域实例
- 智能DNS解析
- 边缘计算
3. **压缩传输**:
- 启用GZIP压缩
- 优化数据传输格式
- 减少传输数据量
## 紧急处理措施
### 立即操作（5分钟内）
1. **扩容**: 如果是资源不足，立即增加实例
2. **限流**: 保护系统不被压垮
3. **降级**: 关闭非核心功能
4. **重启**: 如果是内存泄漏等问题，重启受影响实例
### 短期措施（30分钟内）
1. **定位根因**: 通过日志分析找出慢的环节
2. **临时优化**:
- 增加缓存
- 优化慢SQL
- 调整超时时间
3. **监控观察**: 持续观察响应时间变化
### 长期优化
1. **性能优化**: 代码层面的性能优化
2. **架构优化**: 引入缓存、消息队列等
3. **监控完善**: 增加更细粒度的性能监控
4. **压力测试**: 定期进行性能压测
## 验证步骤
1. 确认P99响应时间降到正常水平（<1秒）
2. 检查错误率是否下降
3. 观察用户投诉是否减少
4. 持续监控30分钟确保稳定
## 性能优化检查清单
- [ ] 数据库查询是否有索引
- [ ] 是否有N+1查询问题
- [ ] 缓存策略是否合理
- [ ] 外部API调用是否有超时设置
- [ ] 是否有不必要的同步等待
- [ ] 日志级别是否过于详细
- [ ] 是否有大对象序列化
- [ ] 网络调用是否可以批量化
## 相关监控指标
- **响应时间**: P50, P90, P99, P999
- **吞吐量**: QPS, TPS
- **错误率**: 4xx, 5xx错误比例
- **资源使用**: CPU, 内存, 网络, 磁盘IO
- **数据库**: 慢查询数量, 连接池使用率
- **缓存**: 命中率, 失效率
## 相关告警
- `HighCPUUsage`: CPU使用率过高
- `HighMemoryUsage`: 内存使用率过高
- `DatabaseSlowQuery`: 数据库慢查询
- `HighErrorRate`: 错误率过高
- `ServiceTimeout`: 服务超时
## 联系方式
- **运维团队**: ops-team@company.com
- **开发团队**: dev-team@company.com
- **DBA团队**: dba-team@company.com
- **紧急电话**: 400-xxx-xxxx
## 参考文档
- [性能优化最佳实践](internal-docs/performance-optimization.md)
- [数据库优化指南](internal-docs/database-optimization.md)
- [缓存使用规范](internal-docs/cache-best-practices.md)