SkyWalking 拓扑功能的性能优化

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 1. 增加查询的并行度,减少串行耗时。2. 规避无效查询的触发,避免带来额外消耗。3. 提升分片检索的命中,缩小检索分片数
我是石页兄,朋友不因远而疏,高山不隔友谊情;偶遇美羊羊,我们互相鼓励

欢迎关注微信公众号「架构染色」交流和学习

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

一、背景

1.1 前文

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

1.2 现状简述

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

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

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

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

二、目标

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

三、思路

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

3.1 程序侧

  1. 增加查询的并行度,减少串行耗时。
  2. 规避无效查询的触发,避免带来额外消耗。
  3. 提升分片检索的命中,缩小检索分片数

3.2 ES存储侧

  1. 从ES日志中定位耗时逻辑,作为重点优化分析项
  2. 增加分片数,减少分片大小
  3. 增加机器,减少但个机器上承载的分片数量

四、措施与效果

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分钟后超时,而其他三次是执行优化后的逻辑,耗时都是毫秒级的;从分钟级到毫秒级的,随已是老码农,但仍然会开心难抑,或许正是这种简单的快乐让咱坚持到今天变成老码农一枚吧。

五、其他措施与效果

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

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

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

六、最后说一句

我是石页兄,如果这篇文章对您有帮助,或者有所启发的话,欢迎关注笔者的微信公众号【 架构染色 】进行交流和学习。您的支持是我坚持写作最大的动力。

欢迎点击链接扫马儿关注、交流。

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
监控 网络协议 Java
分布式链路追踪- SkyWalking使用手册
分布式链路追踪- SkyWalking使用手册
1241 0
分布式链路追踪- SkyWalking使用手册
|
4月前
|
Prometheus 监控 Cloud Native
【揭秘可观测性】构建完美参考框架,打造系统监控的瑞士军刀!
【8月更文挑战第25天】在现代软件设计中,可观测性是确保系统稳定性和效率的关键因素。它主要由日志、指标及链路追踪(统称LMx)三大核心组件构成。本文详细介绍了构建高效可观测性框架的六个步骤:需求分析、工具选择、数据收集策略设计、实施集成、数据可视化及持续优化。并通过一个Spring Boot应用集成Prometheus和Micrometer收集指标的示例,展示了具体实践方法。合理构建可观测性框架能显著提升团队对软件系统的管理和监控能力,进而增强系统整体性能和可靠性。
76 2
|
4月前
|
监控 Java 测试技术
分布式链路监控系统问题之Skywalking和Eagleeye在数据收集方面的问题如何解决
分布式链路监控系统问题之Skywalking和Eagleeye在数据收集方面的问题如何解决
|
5月前
|
消息中间件 存储 Java
kafka 性能优化与常见问题优化处理方案
kafka 性能优化与常见问题优化处理方案
66 1
|
4月前
|
监控 Java
分布式链路监控系统问题之OpenTracing规范的问题如何解决
分布式链路监控系统问题之OpenTracing规范的问题如何解决
|
4月前
|
监控 Java API
分布式链路监控系统问题之Skywalking中的witness工作的问题如何解决
分布式链路监控系统问题之Skywalking中的witness工作的问题如何解决
|
4月前
|
监控 API 开发者
分布式链路监控系统问题之ClassMatch在Skywalking中有什么作用
分布式链路监控系统问题之ClassMatch在Skywalking中有什么作用
|
存储 Prometheus 监控
Prometheus的架构原理,如何使用其进行监控告警配置实现?
Prometheus的架构原理,如何使用其进行监控告警配置实现?
368 0
Prometheus的架构原理,如何使用其进行监控告警配置实现?
|
存储 JavaScript 数据可视化
大型网站重构指南 第1.2部分:Nodejs 系统可观测性 OpenTelemetry+SigNoz
大型网站重构指南 第1.2部分:Nodejs 系统可观测性 OpenTelemetry+SigNoz
742 0
大型网站重构指南 第1.2部分:Nodejs 系统可观测性 OpenTelemetry+SigNoz
|
监控 Dubbo 关系型数据库
基于SkyWalking的分布式跟踪系统 - 微服务监控
基于SkyWalking的分布式跟踪系统 - 微服务监控
180 1