Skywalking(v8.5.0)优化系列-拓扑篇上(分钟级到毫秒级的快乐)

对skywalking架构设计、性能调优感兴趣可以查看文章:

  • 【Skywalking on the way-千亿级的数据储能、毫秒级的查询耗时】

  • 【当月亮守护地球 | SkyWalking Agent守护你的应用...有它相伴才安逸】

  • 【Skywalking(v8.5.0)优化系列汇总】

1、背景

1.1 前文

溯源:Boss Li 提出部门的基础设施引入Skywalking, 于是踏上全链路监控之旅。。。其他暂略。。。

1.2 现状简述

一期规划,司内200多核心应用接入Skywalking,伴随着接入的进行,主IDC一个多月内每天的segment在10亿以下,整个系统运行的也比较稳定;随着网关、基础资料等几十个大流量应用的接入,segment总量快速上升到25亿左右,自此噩梦来袭,服务端的各种稳定性、性能问题接踵而至,压力和优化的动力也相伴而生。

当时问题爆发的集中且突然,受资源、资料、精力多方面制约,选择了“弃车保帅”的策略:全方位功能降级,集中优化trace功能,把拓扑等功能隐藏起来,如此取舍的原因是:

  1. Trace的价值是引入Skywalking的主要原因,必须作为首要攻坚目标。
  2. 应用尚未全面接入,拓扑功能还无法体现出其全视角的C位价值。

而最近SA同学刚好聊到一些大盘看板的需求,加上skywalking的其他优化也早已完成,在预研Seata框架的间隙抽点时间把拓扑功能优化一下。

2、目标

对Trace查询做优化时,在保留15天记录的情况下,将基于traceId的查询从30秒优化到了1秒内,所以拓扑查询的目标自然也要优化到毫秒级别

3、思路

基于对skywalking的掌握和之前优化的经验,快速梳理出一些优化项。

3.1 程序侧
  1. 增加查询的并行度,减少串行耗时。
  2. 规避无效查询的触发,避免带来额外消耗。
  3. 提升分片检索的命中,缩小检索分片数
3.2 ES存储侧
  1. 从ES日志中定位耗时逻辑,作为重点优化分析项
  2. 增加分片数,减少分片大小
  3. 增加机器,减少但个机器上承载的分片数量

4、措施与效果

4.1 问题定位

问题定位-接口:
拓扑页现实会有两个请求调用:

  1. queryServiceTopo 耗时在300ms内(整体优化未开始的时候,这个接口也超慢,现在其速度在毫秒级得益于早期其他的优化)
  2. queryTopoInfo 耗时在1min以上(限定了60s的超时);切换任意一个service这个接口都超时。

问题定位-ES日志:
部门的科科老师是ES专家,经过之前协同攻坚优化skywalking后,已然是老战友了,这次把思路简单沟通后,科科便开始从ES日志中找线索。多次尝试后,日志中未检测到耗时语句,两人默契的会心一笑,因为不是存储层的问题,那就可以优先从OAP程序中找逻辑的问题,而这边逻辑的问题,相对ES会更容易解决一些。

4.2 梳理接口代码

因为已经确定了queryTopoInfo调用会超时,从其接口实现梳理,调试定位源码过程比较繁杂,咱们忽略直接从结论说起,此接口实现中后边会多次调用MetricQuery#getValues方法,逻辑简单总结即为双层循环:

image.png
  1. 外层循环为:遍历多个metric ,如service_cpmservice_resp_timeservice_sla,每个metric 执行一次MetricQuery#getValues
  2. 内层循环为:遍历每个metric中的id列表,对每个id执行一次MetricsQuery#readMetricsValue

通过分析http请求的数据可知,这个id列表可能是成百上千个;并通过一次模拟确认了此处的确耗时

4.3 改造

确定此处双循环逻辑的耗时后,首先考虑内、外层循环如何调整,外层循环次数不可减少(可考虑并行),内层循环可以考虑把多次变少次,也可考虑并行;这个过程咱们跳过直接从结论说出:


image.png

原逻辑是每个id查询,最终进入图中所示的terms方法,但只传入了1个参数,而terms可以传入数组,即多个参数,于是尝试开辟另外一个执行链路,将第二层循环里的id数组传入到这个terms中。

4.4 效果

为了对比新老逻辑的差异,并留个后路达到快速回滚,代码中专门增加走新老逻辑的开关,执行4次请求看效果:


image.png

上图4次请求中,第二次的请求是原始逻辑,1分钟后超时,而其他三次是执行优化后的逻辑,耗时都是毫秒级的;从分钟级到毫秒级的,随已是老码农,但仍然会开心难抑,或许正是这种简单的快乐让咱坚持到今天变成老码农一枚吧。

5、其他措施与效果

web页还是要有一些改造处理的

  1. 拓扑的服务清单中去除了所有服务
  2. 增加查询按钮,只有点击查询按钮才能触发查询

目前的效果已初步满足需求,或许在后续数据量增大后,其他的优化项就会被启用。

附语

对skywalking架构设计、性能调优感兴趣可以查看:

  • 【Skywalking on the way-千亿级的数据储能、毫秒级的查询耗时】

  • 【当月亮守护地球 | SkyWalking Agent守护你的应用...有它相伴才安逸】

你可能感兴趣的:(Skywalking(v8.5.0)优化系列-拓扑篇上(分钟级到毫秒级的快乐))