osiman/SuperBizAgent-java
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
emdash/mvp-waq54
SuperBizAgent-java/aiops-docs/slow_response.md
T
zhuyongxin 80eada415d commit
2026-04-30 11:19:46 +08:00

6.5 KiB
Raw Permalink Blame History

服务响应时间过长告警处理方案

告警名称

  • 告警名: 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: 服务超时

联系方式

参考文档

Reference in New Issue View Git Blame Copy Permalink