258 lines
6.5 KiB
Markdown
258 lines
6.5 KiB
Markdown
# 服务响应时间过长告警处理方案
|
||
|
||
## 告警名称
|
||
- **告警名**: `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)
|