系统性能与可用性问题排查指南

东哥Jeffery
80 阅读5分钟

后端必须掌握的系统性能与可用性问题排查指南（附实战答题模板）

本文适用于搭建了 ARMS + SLS + Grafana 的同学，也适用于准备高级/资深后端工程师面试时对系统稳定性、性能问题的复盘与总结。内容深入覆盖系统资源、服务性能、依赖服务、容量限流、业务异常、高可用等问题，附带场景复盘与答题模板。

🔍 常用排查工具/定位手段

  • jstack / top / jstat / vmstat / iotop：系统资源类问题（CPU、内存、IO）
  • heap dump + MAT：定位内存泄漏、对象逃逸
  • ARMS Trace Drill：慢链路识别、依赖服务耗时分析
  • SLS 日志检索：错误栈聚合、频率统计、异常行为发现
  • Grafana 仪表盘：大盘维度趋势分析（RT/QPS/错误率/资源使用）
  • 慢 SQL 日志 + explain plan：数据库性能热点
  • Kafka Consumer Lag + 监控分区：消息积压识别
  • thread dump + 可视化分析：线程阻塞、死锁分析

📊 可视化指标面板（Grafana）设计参考

1. 节点资源监控

  • CPU 使用率 / 核心负载
  • 内存使用量（Heap / Non-Heap）
  • 磁盘 IOPS、使用率
  • 系统负载（load1/load5）
  • 活跃线程数、线程状态分布

2. JVM 大盘

  • GC 次数、GC 耗时
  • OldGen/Eden/Survivor 占用趋势
  • Full GC 时间分布
  • 类加载数量、线程池队列长度

3. 链路追踪面板

  • trace 总量 / trace 错误率
  • RT/P99/P95 分布图
  • 调用拓扑图（微服务间依赖）
  • traceId 聚类对比慢调用源头

4. 依赖服务监控

  • Redis 命中率、连接耗时
  • MySQL QPS、慢查询 Top10
  • Kafka Lag / 消费 TPS
  • 外部 API 调用成功率 / 耗时曲线

5. 高可用监控

  • 实例存活数变化趋势
  • 各接口可用率（HTTP 2xx 比例）
  • Sentinel/SpringCloud 限流命中数
  • 服务发布状态追踪（版本号 + 发布时间）

📌 全链路架构总览图（建议配图说明）

用户 → 网关（限流/灰度）→ 应用服务A → 应用服务B → Redis / MySQL / MQ
           ↓                   ↓               ↓
        ARMS Trace      SLS 日志收集     Prometheus Exporter
                                 ↓
                            Grafana 大盘

该架构通过链路追踪 + 指标监控 + 日志分析的组合，实现了系统行为的可观测性，支持问题快速定位与闭环处理。

🧠 全链路问题维度细化对照表（含案例说明）

以下表格将原有问题分类进一步细化，帮助你在复盘或面试中更具条理地表达每类问题：

问题类型现象排查手段原因分析解决方案
CPU 飙升CPU > 90%，系统响应慢top、jstack死循环、热点服务、单线程阻塞分析热点线程、限流、异步化
Full GC 频繁GC 日志频繁出现 Full GCjstat、GC log、heap dump内存泄露、OldGen 溢出dump 内存分析，优化对象生命周期
RT 变慢P99 RT 异常升高ARMS trace drill、接口级别耗时分解下游慢、缓存穿透、IO 阻塞引入缓存、异步解耦、数据库优化
Redis 命中率低缓存层命中率下降指标 + trace log 检查缓存命中热 key 丢失、缓存未预热添加布隆过滤器、缓存预加载
MySQL 连接耗尽无法从连接池取连接连接池监控、慢 SQL 分析SQL 执行慢、连接未释放SQL 优化、增加连接池、限流保护
Kafka 积压严重消费 lag 持续增长消费速率 vs TPS 曲线、消费异常堆栈消费线程慢、消息堆积多线程消费、消息处理拆分
实例频繁重启探针异常、服务剔除SLS 日志 + 健康检查 + pod 日志依赖接口超时、OOM增加容错/熔断、降级处理

📚 案例补充

案例：生产环境 CPU 飙升，业务雪崩

  • 现象：多个服务实例 CPU 飙升至 100%，接口 RT 急剧上升，trace 中部分链路耗时达数秒。
  • 排查路径：通过 Prometheus 发现 CPU 异常 -> 使用 jstack 分析发现某个热接口循环递归异常 -> SLS 日志出现错误堆栈爆炸。
  • 根因分析：一次配置错误导致部分用户请求触发循环依赖逻辑，未做缓存与限流控制。
  • 解决策略：修复递归逻辑，加入参数校验和缓存控制，接口增加 Sentinel 限流保护，发布时加入预发布和灰度机制。

案例：Redis 缓存命中率骤降，MySQL QPS 飙升

  • 现象：大促期间某服务 Redis 命中率从 98% 掉至 40%，DB QPS 直线飙升，导致慢 SQL 大量报警。
  • 排查路径：通过 Grafana Redis 命中率大盘 + trace 调用链日志，发现某个 key 过期频率异常。
  • 根因分析：商品缓存 key 在更新逻辑中未设置失效时间，触发穿透请求 DB。
  • 解决策略：补全 key TTL 策略，添加空值缓存与布隆过滤器，避免无效请求打满数据库。

案例：Kafka 消费积压导致下游服务不可用

  • 现象：MQ 消费堆积，部分 topic lag 达百万级别，下游写库任务严重延迟，影响最终订单同步。
  • 排查路径：Kafka 消费 TPS 下降，通过消费者日志发现反序列化异常 + 写库失败重试导致阻塞。
  • 根因分析：某类数据格式更新后未兼容旧 consumer 反序列化逻辑，consumer 线程重试阻塞主消费逻辑。
  • 解决策略：引入消费失败兜底队列，异常数据落盘告警，分离主消费线程池与重试队列。

🧩 高价值建议与扩展方向

  • 建议结合服务分层设计（如网关层 / 业务服务 / 底层服务）分别定义健康指标和告警阈值
  • trace 的异常聚类分析可辅助发现平台性 BUG（如参数传递异常、NPE、非法状态）
  • 使用 SLO 驱动可观测系统设计，定义合理的"错误预算"与“降级容忍边界”
  • 推进灰度发布和 Canary Release，以防配置或新版本导致系统雪崩

（文档持续补充中，如需添加“容器/云原生可观测”、“AIOps 告警分类”等内容请留言）

avatar
文章
阅读
粉丝