【SkyWalking从入门到精通】第21篇：用SkyWalking排查慢服务——从蛛丝马迹到真相大白-北京尧图网络

上一篇【第20篇】用SkyWalking查找失败服务——从告警到根因的完整追踪术下一篇【第22篇】SkyWalking告警配置实战——让你的系统学会喊救命1. 引言一只慢服务引发的血案凌晨两点你的手机疯狂震动。运维群里炸开了锅——“用户端打开页面要转10秒”“订单接口超时了”老板在群里你了你睡眼惺忪地打开电脑日志密密麻麻像天书几十个微服务互相调用到底是谁拖了后腿如果你经历过这种场景那你一定明白慢是最难排查的问题。因为慢不是错误它不会在日志里留下醒目的红色ERROR慢是温水煮青蛙用户感知越来越差直到某天集中爆发。SkyWalking就像一位经验丰富的老中医望闻问切把脉问诊——它不只看症状还能追溯到病因。今天我们就来聊聊怎么用SkyWalking这把手术刀精准切除系统中的慢肿瘤。2. 慢服务的定义与阈值设置2.1 什么样的服务算慢在程序员的世界里快和慢是相对的。一个批处理任务跑5秒理所当然一个登录接口超过500ms用户就开始不耐烦。所以第一步我们要给慢下一个可量化的定义。------------------------------------------------------------------ | 慢服务定义层级 | ------------------------------------------------------------------ | 层级 | 典型阈值 | 说明 | ------------------------------------------------------------------ | 用户感知层 | 2s | 页面白屏时间用户失去耐心的临界点 | | HTTP接口层 | 500ms | 单个API响应时间前端体验的底线 | | 数据库操作 | 100ms | 单条SQL执行时间超出需要关注 | | 缓存操作 | 10ms | Redis/Memcached单次操作 | | RPC调用 | 200ms | 服务间调用累积效应明显 | | 消息队列 | 1000ms | 生产/消费延迟异步链路的关键指标 | ------------------------------------------------------------------2.2 在SkyWalking中设置响应时间阈值SkyWalking OAP Server的application.yml中可以配置慢端点阈值# application.ymlcore:default:# 慢数据库语句阈值毫秒slowDBAccessThreshold:${SW_SLOW_DB_THRESHOLD:50}# 支持的响应时间范围metrics:# P99响应时间桶分布percentile:-100# 100ms-200-500-1000# 1s-2000-3000-5000# 5s而在SkyWalking UI的拓扑图、端点列表、追踪详情中超过阈值的调用会被高亮标记通常用橙色或红色一眼就能揪出问题。3. 从SkyWalking识别慢Endpoint3.1 端点列表——全局视野登录SkyWalking UI进入端点Endpoint面板你会看到所有被监控的API端点。按平均响应时间降序排列慢端点立马现行。------------------------------------------------------------------ | SkyWalking UI - 端点面板 | ------------------------------------------------------------------ | 端点名称 | 平均RT | P99 | 调用量 | ------------------------------------------------------------------ | /api/order/submit {POST} | 3.2s | 8.7s | 12,345 | | /api/user/profile {GET} | 1.8s | 4.2s | 56,789 | | /api/product/search {GET} | 890ms | 2.1s | 34,210 | | /api/cart/add {POST} | 120ms | 350ms | 98,765 | ------------------------------------------------------------------ | 红色慢端点橙色需要关注绿色正常 | ------------------------------------------------------------------/api/order/submit平均响应时间3.2秒P99高达8.7秒——这就是今晚的罪魁祸首。3.2 热力图——发现时间规律SkyWalking的端点详情页提供了响应时间热力图它以时间为X轴、响应时间为Y轴颜色深浅代表请求密度。一张好的热力图长这样慢 ↑ 响应时间 | 5s | ██ | ████ 2s | ██ ██████ | ████ ████████ 1s | ██ ██████████████ | ████ ██████████████ 0.5s | ████████████████████████ | ████████████████████████████ 快 ---------------------- 时间 00:00 04:00 08:00 12:00 16:00 20:00高峰期12:00-14:00响应时间飙到5秒说明要么是并发压力太大要么是某些依赖在这个时段也不行了。4. 在Trace中定位慢Span识别出慢端点后下一步就是拆解——这个请求到底在哪一步花了最多时间4.1 Trace树结构点击慢端点中的任意一次调用进入Trace详情页。你会看到一颗调用树每个节点就是一个Span------------------------------------------------------------------ | Trace: /api/order/submit (总耗时: 3.2s) | ------------------------------------------------------------------ | ├── [EntrySpan] /api/order/submit (3.2s) | | │ ├── [LocalSpan] 参数校验 (5ms) | | │ ├── [ExitSpan] POST /user-service/verify (200ms) | | │ ├── [ExitSpan] POST /inventory-service/deduct (150ms) | | │ ├── [ExitSpan] MySQL SELECT * FROM products (2.5s) ⚠️ | | │ │ └── DB慢查询确认: SQL耗时占比 78% (2.5s) | | │ ├── [ExitSpan] Redis SET order:lock (8ms) | | │ ├── [ExitSpan] MySQL INSERT INTO orders (120ms) | | │ └── [ExitSpan] Kafka produce order-created (15ms) | ------------------------------------------------------------------ | ⚠️ 慢Span: MySQL SELECT * FROM products 耗时2.5秒占78% | ------------------------------------------------------------------一目了然——MySQL的SELECT * FROM products这条查询占了78%的时间慢的根源在数据库。4.2 各类型Span的定位思路不同类型的慢Span排查思路截然不同Span类型慢场景示例排查方向HTTP ExitSpan调用下游服务超时检查下游服务健康状况、网络延迟、是否触发了限流熔断Database ExitSpanSQL执行慢查看SQL语句、检查索引、分析执行计划Redis ExitSpan缓存操作超时检查key是否是大Key、Redis内存是否打满、网络是否抖动MQ ExitSpan消息发送/消费慢检查队列积压、消费者处理逻辑、批量大小LocalSpan本地方法执行慢检查业务逻辑复杂度、循环/递归、大对象创建5. 数据库SQL慢查询的Trace展示5.1 SkyWalking的SQL详情SkyWalking Agent会自动拦截JDBC驱动记录每一条SQL的完整信息。在Trace详情中点击Database类型的Span展开后你会看到-- SkyWalking Trace中捕获的SQL详情Span: MySQL/JDBI/PreparedStatement/executeQueryDatabase: order_db Endpoint:192.168.1.100:3306SQL:SELECTp.*,i.*,c.*,s.*FROMproducts pLEFTJOINinventory iONp.idi.product_idLEFTJOINcategories cONp.category_idc.idLEFTJOINsuppliers sONp.supplier_ids.idWHEREp.statusonlineANDp.created_at2025-01-01ORDERBYp.sales_volumeDESCLIMIT100耗时:2456ms5.2 慢SQL的典型问题从上面的SQL可以立刻看出几个问题SELECT p.*, i.*, c.*, s.*四表联查返回所有字段数据量爆炸LEFT JOIN连了4张表笛卡尔积膨胀WHERE p.status onlinestatus字段是否有索引ORDER BY p.sales_volume DESCfilesort// 对应的Java代码常见问题代码示例RepositorypublicclassProductRepository{// ❌ 错误示范全字段联表查询Query(SELECT p.*, i.*, c.*, s.* FROM products p LEFT JOIN inventory i ON p.id i.product_id LEFT JOIN categories c ON p.category_id c.id LEFT JOIN suppliers s ON p.supplier_id s.id WHERE p.status :status ORDER BY p.sales_volume DESC)ListObject[]findProductsRaw(Param(status)Stringstatus);// ✅ 优化方案1只查需要的字段Query(SELECT p.id, p.name, p.price, p.imageUrl, i.stock, c.name as categoryName FROM Product p LEFT JOIN Inventory i ON p.id i.productId LEFT JOIN Category c ON p.categoryId c.id WHERE p.status :status ORDER BY p.salesVolume DESC)ListProductDTOfindProductsOptimized(Param(status)Stringstatus);// ✅ 优化方案2加索引// ALTER TABLE products ADD INDEX idx_status_sales (status, sales_volume DESC);}5.3 数据库慢查询定位流程图------------------------------------------------------------------ | 数据库慢查询排查决策树 | ------------------------------------------------------------------ 慢SQL检测到 | ---------------- | | SELECT慢 UPDATE/INSERT慢 | | -------------- 检查锁等待 | | | (行锁/表锁/死锁) 索引缺失返回过多联表过多 | | | 加索引只查需要的拆分查询 EXPLAIN 字段分页或使用缓存 | -------- | | 覆盖索引降级查询生效了逻辑 | 慢SQL解决6. 外部服务依赖超时的识别6.1 拓扑图中的慢依赖SkyWalking的拓扑图会实时展示服务间的调用关系。边的粗细代表调用量颜色代表响应时间------------------------------------------------------------------ | 服务拓扑图部分 | ------------------------------------------------------------------ | | | [订单服务] ──────────── [用户服务] | | | 200ms | | | | | |──────────────── [库存服务] | | | 150ms | | | | | |════════════════ [支付网关] | | | 3.2s ⚠️ 粗线慢依赖 | | | | | |──────────────── [消息队列] | | 15ms | ------------------------------------------------------------------6.2 HTTP请求超时的Trace分析当你怀疑是第三方依赖慢时SkyWalking会在ExitSpan中记录完整信息Span: POST http://payment-gateway/api/pay Type: ExitSpan Component: SpringRestTemplate (HTTP) URL: http://10.0.1.50:8080/api/pay StatusCode: 200 RequestBody: {orderId:ORD123, amount:99.00} 响应大小: 2KB 时间拆解: DNS解析: 2ms TCP连接: 3ms SSL握手: 15ms 请求发送: 1ms 等待响应: 3150ms ⚠️ 大头在这里响应读取: 5ms 总耗时: 3176ms请求只花了20ms就建立连接并发送出去但等待响应花了3.15秒——问题不在网络而在支付网关本身处理慢。6.3 Redis超时排查// 场景Redis缓存命中但查询极慢Cacheable(valueuserSessions,key#userId)publicUserSessiongetSession(StringuserId){// 原本很快的缓存突然变慢// SkyWalking Trace显示 Redis GET 耗时 800msreturnsessionRepository.findByUserId(userId);}在SkyWalking Trace中Redis操作的Span会显示Span: Redis/Jedis/get Key: userSession:10086 Value大小: 1.5MB ⚠️ 大Key 耗时: 823ms1.5MB的Value意味着这是一个大Key——Redis是单线程的大Key操作会阻塞其他请求。解决方案是拆分或压缩。6.4 消息队列延迟排查------------------------------------------------------------------ | 消息队列慢场景分析 | ------------------------------------------------------------------ | | | 生产者慢: 消费者慢: | | ┌──────────────┐ ┌──────────────┐ | | │ 发送耗时 2s │ │ 消费耗时 5s │ | | └──────┬───────┘ └──────┬───────┘ | | | | | | 可能原因: 可能原因: | | - Broker负载高 - 消费逻辑重 | | - 消息体过大 - 下游依赖慢 | | - 网络抖动 - 批量大小不合理 | | - 同步发送等待ACK - 消费线程池不够 | | | ------------------------------------------------------------------7. 实战一次完整的慢服务排查7.1 场景描述用户反馈商品搜索接口响应超慢5秒而之前一直是200ms以内。7.2 排查过程Step 1全局视角进入SkyWalking → 端点面板 → 按响应时间排序 → 发现/api/product/search耗时突增。Step 2锁定异常时间段查看热力图发现14:30开始响应时间飙升——正好是运维发布了新版本的ES集群。Step 3进入Trace详情Trace: /api/product/search?keyword手机page1 (总耗时: 5.2s) ├── [EntrySpan] /api/product/search (5.2s) │ ├── [ExitSpan] Redis GET keyword:hot:手机 (8ms) ✅ │ ├── [ExitSpan] ElasticSearch search (4.8s) ⚠️ │ │ └── ES查询: {query:{match:{name:手机}}} │ │ ES响应状态: 200, 耗时: 4780ms │ ├── [ExitSpan] Redis GET product:detail:* (15ms) ✅ │ └── [LocalSpan] 组装结果 (12ms) ✅Step 4定位原因ES查询耗时4.8秒——对比版本发布前同样的查询只需50ms。检查ES集群发现运维在升级时误删了索引的mapping配置导致全文检索退化成全表扫描。Step 5修复验证恢复ES索引mapping → SkyWalking中观察/api/product/search的响应时间 → 降回200ms以内 → 问题解决。7.3 实战总结------------------------------------------------------------------ | 慢服务排查五步法 | ------------------------------------------------------------------ | | | ① 全局扫描 ② 锁定时间 ③ 深入Trace | | ┌─────────┐ ┌─────────┐ ┌─────────┐ | | │端点面板 │────→│ 热力图 │──────→│Trace树 │ | | │排序找慢 │ │找异常时段│ │找慢Span │ | | └─────────┘ └─────────┘ └────┬────┘ | | │ | | ⑤ 回溯验证 │ ④ 定位根因 | | ┌─────────┐ ┌─────────┐ | | │持续观察 │←──────│展开详情 │ | | │确认恢复 │ │找瓶颈点 │ | | └─────────┘ └─────────┘ | ------------------------------------------------------------------8. 慢服务排查的进阶技巧8.1 告警先行与其被动排查不如主动告警。在alarm-settings.yml中配置rules:# 端点响应时间告警endpoint_avg_rule:metrics-name:endpoint_avgop:threshold:1000# 1秒period:10count:3silence-period:5message:端点{name}平均响应时间超过 1s当前值:{value}ms8.2 慢端点TopN仪表盘SkyWalking支持自定义仪表盘。创建一个慢服务监控大盘包含响应时间Top 10端点实时刷新各端点的P99/P95/P90曲线慢SQL语句列表慢依赖服务排行榜8.3 与日志平台联动SkyWalking的traceId可以注入日志系统// logback-spring.xmlproperty nameLOG_PATTERNvalue%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] [%X{traceId}] %-5level %logger{36} - %msg%n/配置SkyWalking的ToolkitdependencygroupIdorg.apache.skywalking/groupIdartifactIdapm-toolkit-logback-1.x/artifactIdversion${skywalking.version}/version/dependency这样在ELK中搜索traceId就能把日志和Trace串联起来慢服务排查效率翻倍。9. 总结慢服务排查是一场侦探游戏全局扫描端点面板找出最慢的API锁定时间热力图定位异常时段深入TraceTrace树找到慢Span定位根因展开Span详情直击瓶颈回溯验证观察指标确认问题修复SkyWalking的价值在于它把猜变成了看——你不需要靠经验猜测哪里慢Trace会原原本本地告诉你每一毫秒去了哪里。下面一篇文章我们将把被动排查升级为主动告警详细讲解SkyWalking的告警配置实战。上一篇【第20篇】用SkyWalking查找失败服务——从告警到根因的完整追踪术下一篇【第22篇】SkyWalking告警配置实战——让你的系统学会喊救命

【SkyWalking从入门到精通】第21篇：用SkyWalking排查慢服务——从蛛丝马迹到真相大白

相关推荐

2007-2025年上市公司供应链长鞭效应测算数据集

数字 IC 求职加分项：10 节课吃透大厂必考 Verilog 全考点

AutoCAD Plant3D 2026安装包免费下载及详细安装教程

更多资讯

杭州建德电工证培训怎么考，工地太忙也能拿电子证书

船用电工证年龄限制的真实经历：考不考值得你认真考虑

电工证下载打印怎么搞？2026河南最新政策帮你理清实操考试通过率

真实经历告诉你，罗定哪儿可以考电工证，证书过期了怎么办

西安电工证培训公司怎么转异地考试没底怕挂科的别慌

钱东有培训电工证的吗值不值得考这些坑千万别踩

今日更新

电工证考试及格线你知道多少？值不值得考

南通电工证发证单位考前押题怎么搞？工地太忙根本没时间复习考试

黄陵县高低压电工证怎么考？上岗必备全流程避坑指南

本周精选

安监局电工证分数查询怎么查才能知道含金量高不高

新疆电工作业干活累吗良心建议助你避开考不过的坑

中牟县电工证怎么报名外省证能转吗

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？