对SkyWalking进行改造的相关实践记录

SkyWalking

Apache SkyWalking是一款分布式系统的性能监控工具，在分布式架构下，系统多层，服务各种关联，一款好的可视化全栈监控工具，无疑可以大大降低我们的运维和排障成本。

有兴趣点开链接，看到这篇文章的朋友，可能多少对其都有一些了解，也就不再过多说明了。如果之前没有听说过，但是感兴趣的，可以看一下Apache SkyWalking的官方文档。

下面说明下我过去在我们的实践过程中，对其进行的一些功能上的增强或者优化，或许对正在使用的一些朋友能作一个参考或者帮助。

说明

这些改造是在去年春夏那期间做的一些开发，一直到现在才想起来落地成文。这期间所有涉及的开发虽然都是我自己一个人做的，但是过了这么久，描述中可能会遗漏某些细节说明。

另外，在那之前我没有接触过skywalking，在那之后也没有再过多接触，所以也谈不上对skywalking有多熟悉，我也只是对其中涉及到相关改造功能的部分，对它的源码分析过，这些地方可能了解的多一点，很多地方不太深入，如果下面流程中有描述的不合理的地方，也请提出。

本次改造主要有两部分：

1. 功能上的增加
2. 性能上的优化

当时改造时的版本是8.5.0，后来夏天的时候出到了8.6.0，所以主要是这两个版本，后面的版本现在是个什么情形，我也不太清楚了。

功能加强

主要是在监控页面增加了一个Http请求的调用报表，如下：

这个“调用”页面是我在我们本地上加的，原生的skywalking当时只有前几个菜单。

主要是查询当前所有http请求的链路信息形成一个报表。 

追踪菜单下可以看到所有请求的链路信息，包括各类中间件等，当时TL提出建议是否可以增加一个类似的报表，我就做了这样一个功能，只展示它的http请求，一般公司项目的入口基本都是Http请求，于是就可以把这样的一条链路以报表的形式全部展示出来，过滤掉中间件类的请求信息。

详细轨迹信息点击全链路下面就会显示了。

上面截图中下面显示的是系统轨迹，其实是对链路信息作了个优化，只展示系统节点，可以直白的看到经过哪些系统。

这些信息的展示其实都是对已经采集存储的链路信息重新解析整理出来的，我也没有新增存储表结构之类的。

skywalking存储链路信息的时候，是把链路信息以字节格式存储的，所以查询的时候只能以固定的几个字段过滤，无法通过链路信息的关键字过滤（存储在es中也不行的，因为不是原生的字符串）。关于这个，当时有个想法就是把这些信息重新解析出来，整理之后存到新的索引中，这样在前端页面中可以增加更多的查询选项，比如根据url，之后也没再做过，这事就搁下来了。

当时接这个需求的时候，我之前还不了解skywalking，为了做这个东西，花了3天学了下vue（前端用的vue+ts），看了1天GraphQL的官方文档（用的GraphQL不是用的restful），然后花了两天时间把源码下载下来，把它的所有索引结构查出来，分析一遍，看着源码搞了一周多，终于把这个功能搞出来了，当时对我来说也算是一个小挑战了。

性能优化

skywalking的轻量化改造应该也属无奈之举了。

当时接入skywalking的业务增多，skywalking也暴露出了不少性能问题，，主要问题表象有如下几种：

1. go客户端轨迹上报出现限流，客户端一直打印相关日志，数据上报吞吐量不高
2. 服务端的es负载特别高，16核的CPU，各节点负载高达30多
3. skywalking web端无法正常查询链路信息，一直加载，业务侧吐槽无法用

如何通过配置优化，我对这个也不太熟悉，其它同事经过相关测试后发现不太好解决。没有办法，这种情况下除非横向扩展，加大量的机器资源才能很好的解决，但是苦于成本有限，机器有限，只能在代码层面进行轻量化改造。我对这块不怎么了解，但也只能“临危受命”，硬上看源码进行开发。

改造位置：主要针对oap server端改造，对客户端透明，不影响客户端使用。

改造的地方主要有如下几点：

部分上报信息不处理

有一部分上报数据，如jvm状态信息（每个实例每秒上报一次），他们不通过skywalking进行监控分析，有其它的监控平台。诸如此类数据，优化掉，如果客户端代理上报这类数据，服务端不处理，让客户端也快速返回，减少双方的资源占用与等待时间。

同步转异步

上报信息中，轨迹信息的数据量占比最重。

客户端在上报轨迹信息的时候，至少要与服务端进行2次rpc调用，并且是同步阻塞（这也是客户端上报吞吐量上不来，一直报限流日志的原因）。

当客户端将轨迹信息上报之后，服务端会进行各项指标计算并涉及与其它服务端的一些通信计算，最终写入不同的指标索引及链路索引中，整个过程耗时且延迟较高，导致客户端上报吞吐量上不来

客户端代理在最后一步会阻塞，等待服务端处理完成。整个过程同步且耗时，因此将上报部分转换为异步。

调整方案如下，采用二级队列，第一级队列缓存所有轨迹信息，按默认的指标分析流程处理，如果第一队列满了，说明服务端处理速度跟不上，将新上报的轨迹信息直接写入。都处理不了，就只能丢掉了。

对相关配置参数优化，增大es写入的批次和数据量大小。

经过这些优化后，客户端的限流问题完全解决，上报的数据量也成倍数增长。

此时，上报数据比原来更多的时候，es的压力更大，skywalking查询更糟糕了，继续优化。

大索引切割

大索引指的是轨迹信息的索引，每天只有一个索引，如果数据量超过3T，每个ES节点上该索引就将近1T，查询太慢，查询的时候es IO也特别高，负载达到30多，查询结果慢。

将索引切分为10分钟1个，10分钟数据量最多也就七八十G（目前有看见过的），一般50G左右，业务量高的时候能有60多G。

改造 oap的写入和查询以及web端部分，整个查询时间大大降低，解决查询不出来的问题，es的整体负载也彻底降了下来。

这一块是通过对内存及IO、CPU利用率各个指标分析后，优化的目标是在查询链路的时候避免ES所在节点负载过高，提升查询性能。

优化效果

最初oap server和es应该都是3个节点，数据量只保存1天，3T左右，skywalking的管理台上查询链路几乎就不可用。即使节点加倍，还是几乎不可用状态，es负载特别高。实际要上报的数据量肯定是要大于3T的，因为oap这里处理能力有限，客户端代理这里上报的时候就进行了限流，所以实际上报的数据是不足，查询链路的时候也能看到有很多虚拟节点。

优化之后，同等集群规模的情况下，客户端的限流基本没有了，代理侧数据都尽全力上报，oap这边加了二级队列，一级队列能处理的尽量处理，处理不动的在二级队列直接写入es的索引中。最后还有来不及处理的，就直接丢弃了。

优化后，写入性能提升，整体写入数据量直接翻倍，链路查询也能在几秒内查询出来，es所在节点的负载由原来的30多降到15以内，查询性能提升很多。

数据量增长到保存2天，12T左右，skywalking的管理台依然正常使用，es的负载在16以内，负载方面大大降低。