1、开篇

自从Skywaling开端在公司推行，时不时会在排查问题的人群中听到这样的话：“你咋还没接Skywalking？接入后，一眼就看出是哪儿的问题了…”，正如搭档所说的，在许多状况下，Skywalking便是这么秀。作为实践者，我十分感谢Skywalking，由于这款国产全链路监控产品给公司的同伴们带来了实实在在的协助；也特别感谢公司的领导和搭档们，正由于他们的支撑和协助，才让这套Skywalking体系从起先的有用进化到现在的好用；从几十亿的Segment储能上限、几十秒的查询耗时，优化到千亿级的Segment储能、毫秒级的查询耗时。

小提示：

  • 咱们运用的是V8.5.0，根据最新社区通告，V8系列行将下线，进入全新的V9时代，新版别，功用、功用都会更好。
  • Segment是Skywalking中提出的概念，表明一次恳求在某个服务内的履行链路片段的合集，一个恳求在多个服务中先后发生的Segment串起来构成一个完整的Trace，如下图所示：
    Skywalking on the way-千亿级的数据储能、毫秒级的查询耗时

Skywalking的这次实践，截止到现在有一年多的时刻，回顾总结一下这段进程中的些许积累和收成，愿能反哺社区，给有需求的道友供给个案例学习；也希望能收成到专家们的辅导主张，把项目做得更好。由于某某约束吧，把有些内容先调和掉，但也努力把这段进程中那些靓丽的景色， 尽或许完整的呈现给我们。

2、为什么需求全链路监控

跟着微服务架构的演进，单体运用依照服务维度进行拆分，安排架构也随之演进以横向、纵向维度拆分；一个事务恳求的履行轨道，也从单体运用时期一个运用实例内一个接口，变成多个服务实例的多个接口；对应到安排架构，或许跨过多个BU、多个Owner。虽然微服务架构高内聚低耦合的优势是不言而喻的，但是低耦合也有显着的副作用，它在现实中给跨部门沟通、协作带来额外的不可控的开支；因此开发者尤其是终端事务侧的架构师、办理者，特别需求一些能够协助了解体系拓扑和用于剖析功用问题的工具，便于在架构调整、功用检测和发生毛病时，减缩沟通协作方面的精力和时刻消耗，快速定位并解决问题。

我所在公司是微服务架构的深度实践者，为了进一步降低机器本钱、进步服务质量、提高问题响应功率，部门在21年结合本身的一些状况，决议对现行的全链路监控体系进行晋级，目的与以下网络中常见的描绘根本一致：

  • 快速发现问题
  • 判断毛病影响规划
  • 整理服务依靠并判断依靠的合理性
  • 剖析链路功用并实施容量规划

3、为什么挑选Skywalking

在做技能选型时，网络中收集的材料显示，谷歌的 Dapper体系，算是链路追寻范畴的鼻祖。受其公开论文中提出的概念和理念的影响，一些优秀的企业、个人先后做出不少十分nice的产品，有些还在社区开源共建，如：韩国的Pinpoint，Twitter的Zipkin，Uber的Jaeger及我国的Skywalking 等，我司选型立项的进程中综合考虑的要素较多，这儿只概括一下Skywalking招引咱们的2个优势：

  1. 产品的完善度高：
  • java生态，功用丰厚
  • 社区活跃，迭代敏捷
  1. 链路追寻、拓扑剖析的才能强：
  • 插件丰厚，探针无侵入。
  • 先进的流式拓扑剖析

“好东西不需求多说,实际行动告诉你“，这句话我个人十分喜欢，关于Skywalking的许多的长处，网络上能够找到许多，此处先不逐个比较、赘述了。

4、预研阶段

其时最新版别8.5.0，整理剖析8.x的发布记录后，评价此版别的中心功用是蛮安稳的，所以根据此版别开端了Skywalking的探索之旅。其时的认知是有限的，串行思维模型唆使我将重视的问题聚集在架构原理是怎样、有什么副作用这两个方面：

  1. 架构和原理：
    • agent端 首要重视 Java Agent的机制、Skywalking Agent端的装备、插件的工作机制、数据收集及上报的机制。
    • 服务端 首要重视 人物和责任、模块和装备、数据接纳的机制、方针构建的机制、方针聚合的机制及方针存储的机制。
    • 存储端 首要重视 数据量，存储架构要求以及资源评价。
  3. 副作用：
    • 功用搅扰
    • 功用损耗
4.1 架构和原理

Skywalking社区很棒，官网文档和官方出版的书本有较体系化的讲解，由于自己在APM体系以及Java Agent方面有一些相关的经验沉积，经过在这两个渠道的学习，对Agent端和OAP(服务端)很快便有了较体系化的认知。在做体系架构选型时，评价数据量会比较大（不计其数的JVM实例数，每天收集的Segment数量或许是50-100亿的等级），所以传输通道挑选Kafka、存储挑选Elasticsearch，如此简易版的架构以及数据流转如下图所示：

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

Mixed人物形式的数据流转.png

这儿有几处要解释一下：

  1. Agent上报数据给OAP端，有grpc通道和kafka通道，其时就盲猜grpc通道或许撑不住，所以挑选kafka通道来削峰；kafka通道是在8.x里参加的。
  2. 千亿级的数据用ES来做存储肯定是能够的（究竟前东家中通科技的ES日志集群算是PB级的，最近换成clickhouse后也是6的飞起）。
  3. 图中L1聚合的意思是：Skywalking OAP服务端 接纳数据后，构建metric并完结metric 的Level-1聚合，这儿简称L1聚合。
  4. 图中L2聚合的意思是：服务端 根据metric的Level-1聚合成果，再做一次聚合，即Level-2聚合，这儿简称L2聚合。后续把纯Mixed人物的集群拆成了两个集群。
4.2 副作用

对于质量团队和接入方来说，他们最重视的问题是，接入Skywalking后：

  • 是否对运用有功用性搅扰
  • 在运行期能带来哪些功用损耗

这两个问题从3个维度来得到答案：

  1. 网络材料显示：
    • Agent带来的功用损耗在5%以内
    • 未搜到功用性搅扰相关的材料（盲猜没有这方面问题）
  3. 完成机制评价：
    • 字节码增强机制是JVM供给的机制，Skywalking运用的字节码操控框架ByteBuddy也是老练安稳的；经过自定义ClassLoader来加载办理插件类，不会发生冲突和污染。
    • Agent内插件开发所运用的AOP机制是根据模板方法形式完成的，风控很到位，即使插件的完成逻辑有反常也不影响用户逻辑的履行；
    • 插件收集数据跟上报逻辑之间用了一个轻量级的无锁环形行列进行解耦，算是一种维护机制；这个行列在MPSC场景下功用还不错；行列选用满时丢掉的战略，不会有积压阻塞和OOM。
  5. 功用测验验证
    • 测验的教师针对dubbo、http 这两种惯例RPC通讯场景，进行压力测验和安稳性测验，成果与网络材料描绘一致，符合预期。

5、POC阶段

在POC阶段，接入几十个种子运用，在非出产环境试点调查，同时完善插件补全链路，对接公司的装备中心，对接发布体系，完善自监控…全面预备抵达推行就绪状况。

5.1 对接发布体系

为了对接公司的发布体系，方便体系的发布，将Skywalking运用拆分为4个子运用：

运用 介绍
Webapp Skywalking的web端
Agent Skywalking的Agent端
OAP-Receiver skywakling的服务端，人物是Mixed或Receiver
OAP-Aggregator skywalking的服务端，人物是Aggregator

这儿有个考虑，暂定先运用纯Mixed人物的单集群，不够用的话就试试 Receiver+Aggregator双人物集群形式，终究选哪种视作用而定。

Skywalking Agent端是根据Java Agent机制完成的，选用的是发动挂载形式；发动挂载需在发动脚本里参加挂载Java Agent的逻辑，发布体系完成这个功用需求留意2点：

  1. 发动脚本挂载Skywalking Agent的环节，尽量让用户无感知。
  2. 发布体系在挂载Agent的时分，给Agent指定运用名称和所属分组信息。

Skywalking Agent的发布和晋级也由发布体系来负责；Agent的晋级选用了灰度管控的计划，操控的粒度是运用级和实例级两种：

  1. 依照运用灰度，可给运用指定运用什么版别的Agent
  2. 依照运用的实例灰度，可给运用指定其若干实例运用什么版别的Agent
5.2 完善插件补全链路

针对公司OLTP技能栈，量身定制了插件套，其间大部分在开源社区的插件库中有，缺失的部分经过自研快速补齐。

这些插件给各组件的中心环节埋点，收集数据上报给Skywalking后，Webapp端的【追寻】页面就能勾勒出饱满完美的恳求履行链路；这对架构师了解真实架构，测验同学验证逻辑改变和剖析功用损耗，开发同学精准定位问题都十分的有协助。这儿借官方在线Demo的截图一用（抱歉后端程序员，五毛特效都没做出来，饱满画面还请自行脑补）

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

友谊小提示：移除不用的插件对程序编译打包和削减运用发动耗时很有协助。

5.3压测稳测

测验的教师，针对Skywalking Agent端的插件套，规划了丰厚的用例，压力测验和安稳性测验的成果都符合预期；每家公司的标准不尽一致，此处不再赘述。

5.4 对接自研的装备中心

把运用中繁杂的装备交给装备中心来办理是十分必要的，装备中心既能供给发动时的静态装备，又能办理运行期的动态装备，而且外部化装备的机制特别简单满足容器场景下运用的无状况化要求。烦琐一下，举2个比如：

  1. 调优时，修改参数的值不用来一遍开发到测验再到出产的发布。
  2. 观测体系状况，修改日志装备后不需求来一遍开发到测验再到出产的发布。

Skywaling在外接装备中心这块儿，适配了市道中主流的装备中心产品，其间有个人偏爱的Apollo。而公司的装备中心是自研的，需求对接一下，得益于Skywalking供给的模块化办理机制，只用扩展一个模块即可。

在POC阶段，整理服务端各模块的功用，能感遭到其装备化做的不错，装备项很丰厚，管控的粒度也很细；在POC阶段几乎没有变动，除了对Webapp模块的外部化装备稍作改造，与装备中心打通以便在装备中心办理 Webapp模块中Ribbon和Hystrix的相关装备。

5.5完善自监控

自监控是说监控Skywalking体系内各模块的运转状况：

组件 监控计划 说明
kafka kafka-manager 它俩是老搭档了
Agent端 Skywalking Agent端会发心跳信息给服务端，可在Web中看到Agent的信息
OAP集群 prometheus 方针还算丰厚，感觉缺的能够自己弥补
ES集群 prometheus 方针还算丰厚

完善自监控后的架构如下图所示：

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

自监控.png

5.6 自研Native端SDK

公司移动端的运用很中心，也要运用链路追寻的功用，社区缺了这块，所以根据Skywalking的协议，移动端的同伴们自研了一套SDK，弥补了Native端链路数据的缺失，也在后来的秒开页面方针计算中发挥了作用。跟着口口相传，不断有团队提出需求、参加建设，所以也在继续迭代中；内容许多，这儿先不展开。

5.7 小结

POC阶段数据量不大，首要是发现体系的各种功用性问题，查缺补漏。

6、推行和优化阶段

Skywalking的正式推行选用的是城市包围农村的战略；公司的中心运用作为第一批次接入，这个战略有几个好处：

  1. 中心运用的监管是重中之重，优先级默认最高。
  2. 中心运用的上下游运用，会跟着我们对Skywalking依靠的加深，而逐渐自主接入。

当然安全是第一位的，无论新体系多好、多凶猛，其引进都需恪守安全安稳的条件要求。既要安全又要快速还要方便，兴总提出了解决计划，在之前的Agent灰度接入的才能之上，发布体系添加了运用Owner自助式灰度接入和快速卸载Skywalking Agent的才能，即运用负责人可自主挑选哪个运用接入，接入几个实例，倘若遇到问题仅经过重启即可完结快速卸载；这个才能在推行的前期发挥了巨大的作用；究竟安全第一，信任也需逐渐建立。

跟着运用的接入、运用，咱们也逐渐遇到了一些问题，这儿依照时刻递加的次序将问题和优化作用快速的介绍给我们，更多的细节计划在【Skywalking(v8.5.0)优化系列汇总】弥补。开端之前有几个事项要说明：

  1. 下文中说到的数字仅代表我司的状况，标示的Segment数量是处理这个问题的那段时刻的状况，并不是说抵达这个数量才开端呈现这个现象。
  2. 这些数值以及其时的现象，遭到宿主机装备、Segment数据的大小、存储处理才能等多种要素的影响；请重视调整的进程和作用，无需把数字和现象对号入座哈。

6.1 发动耗时：

问题：

有搭档反应运用发动变慢，排查发现容器中多数运用发动的总耗时，在接入Skywalking前是2秒，接入后变成了16秒以上，公司许多中心运用的实例数许多，这样的发动损耗对它们的发布影响太大。

优化：
  1. 记录发动耗时并跟着其他发动数据上签到服务端，方便检查比照。
  2. 优化Kafka Reporter的发动进程，将发动耗时削减了3-4秒。
  3. 优化类匹配和增强环节（重点）后，容器中的运用发动总耗时从之前16秒以上降低到了3秒内。
  4. 整理Kafka 发动和上报的进程中，顺带调整了Agent端的数据上签到kafka的分区挑选战略，将一个JVM实例中的数据悉数发送到同一个的分区中，如此在L1层的聚合就完结了JVM实例级的Metric聚合，需留意调整Kafka分片数来保证负载均衡。

6.2 kafka积压-6亿segment/天

问题：

Skywalking OAP端消费慢，导致Kafka中Segment积压。未能抵达能用的方针。

优化：

从Skywalking OAP端的监控方针中没有定位出哪个环节的问题，把服务端单集群拆为双集群，即把 Mixed人物的集群 ，修改为 Receiver 人物（接纳和L1聚合）的集群 ，并参加 Aggregation人物（L2聚合）的集群，调整成了双集群形式，数据撒播如下图所示：

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

Receiver人物+Aggregation人物形式的数据流转.png

6.3 kafka积压-8亿segment/天

问题：

Skywalking OAP端消费慢，导致Kafka中Segment积压，监控方针能看出是在ES存储环节慢，未能抵达能用的方针。

优化：
  1. 优化segment保存到ES的批处理进程，调整BulkProcessor的线程数和批处理大小。
  2. 优化metrics保存到ES的批处理进程，调整批处理的时刻距离、线程数、批处理大小以及刷盘时刻。

6.4 kafka积压-20亿segment/天

问题：

Aggregation集群的实例继续Full GC，Receiver集群经过grpc 给Aggregation集群发送metric失利。未能抵达能用的方针。

优化：

  1. 添加ES节点、分片，作用不显着。

  2. ES集群有压力，但无法精准定位出是什么数据的什么操作引发的。选用分治战略，测验将数据拆分，从OAP服务端读写逻辑调整，将ES单集群拆分为 trace集群 和 metric集群；之后，ES的监控方针清晰看出是metric集群读写压力太大。

  3. 优化Receiver集群metric的L1聚合，完结1分钟的数据聚合后，再提交给Aggregation集群做L2聚合。

  4. Aggregation集群metric的L2 聚合是根据db完成的，会有 空读-写-再读-累加-更新写 这样的逻辑，每次写都会有读，调整逻辑是：提高读的功用，优化缓存机制削减读的触发；调整距离，防止触发累加和更新。

  5. 将metric批量写ES操作调整成BulkProcessor。

  6. ES的metric集群 运用SSD存储，添加节点数和分片数。

这一次的继续优化具有里程碑式的意义，Kafka消费很快，OAP各机器的Full GC没了，ES的各方面方针也很安稳；接下来开端优化查询，提高易用性。

6.5 trace查询慢-25亿segment/天

问题：

Webapp的【追寻】页中查询都很慢，保存了15天的数据，依照traceId查询耗时要20多秒，依照条件查询trace列表的耗时更糟糕；这给人的感受便是“一肚子墨水倒不出来”，未能抵达好用的方针。

优化：

ES查询优化方面的信息挺多，但经过百度筛选出解决此问题的有用计划，就要看咱家爱犬的品种了；其时收集整理了并测验了N多优化条款，可惜没有跟好运偶遇，定论是颜值不可靠。言归正传，影响读写功用的根本要素有3个：读写频率，数据规划，硬件功用；trace的状况从这三个维度来套一套模板：

要素 trace的状况 补白
读写频率 宏观来看是写多读少的状况
数据规划 依照每天50亿个segment来算，半个月是750亿，1个月是1500亿。
硬件功用 一般硬盘速度一般

这个剖析没有得出具有辅导意义的定论，读写频率这儿粒度太粗，用户的运用状况跟时刻也有紧密的联系，状况大概是：

  1. 当天的数据是读多写多（当天不断有新数据写入，根据紧迫响应的需求，问题呈现时或许是近实时的排查处理）。
  2. 前一天的数据是读多写少（一般也会有问题隔天密集上报的状况，0点后会有前一天数据延迟抵达的状况）。
  3. 再早的话无新数据写入，数据越早被读的概率也越小。

根据以上剖析，添加时刻维度并细化更多的参考要素后，剖析模型变成了这样：

要素 当天 当天-1 当天-2 ~ 当天-N
写频率 多 少 无
读（查询）频率 多 多 少
读响应速度要求 快 快 慢点也行
数据规划 50亿 50亿 50亿* (N-2)
宿主机功用要求 高 高 次高
硬盘速度要求 高(SSD) 高(SSD) 次高(机械)
硬件本钱 高 高 次高
期望本钱 低 低 低

从上表能够看出，全体呈现出hot-warm数据架构的需求之势，近1-2天为hot数据，之前的为warm数据；恰好ES7供给了hot-warm架构支撑，依照hot-warm改造后架构如下图所示：

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

hot-warm架构.png

  1. 对 trace集群进行hot-warm架构调整，查询耗时从20多秒变成了2-3秒，作用是十分显着的。

  2. ES启用公司出品的ZSTD紧缩算法，空间紧缩作用不错。

  3. 从查询逻辑进一步调整，充分利用ES的数据分片、路由机制，把全量检索调整为精准检索，即降低检索时需求扫描的数据量，把2-3秒优化到毫秒。

这儿要炫一个5毛特效，这套机制下，Segment数据即使是保存半年的，依照TraceId查询的耗时也是毫秒。

至此完结了查询千亿级Trace数据只要毫秒级耗时的阶段性优化。

6.6 仪表盘和拓扑查询慢

问题：

Webapp中的【拓扑】页，在开端只要几十个运用的时分，虽然很慢，但还是能看到数据，跟着运用增多后，【拓扑】页面数据恳求一直是超时(装备的60s超时)的，精力有限，先经过功用降级把这个页面隐藏了；【仪表盘】的方针查询也十分的慢，未能抵达好用的方针。

优化：

Webapp中的【仪表盘】页和【拓扑】页是对Skywalking里metric数据的展现，metric数据同trace数据一样满足hot-warm的特征。

  1. metric集群选用hot-warm架构调整，之后仪表盘中的查询耗时也都减小为毫秒级。
  2. 【拓扑】页接口依然是超时(60s)，对拓扑这儿做了几个针对性的调整：

  • 把内部的循环调用合并，紧缩调用次数。

  • 去除非必要的查询。

  • 拆分阻隔通用索引中的数据，防止相互搅扰。

  • 全量检索调整为精准检索，即降低检索时需求扫描的数据量。

至此完结了 【拓扑】页数据查询毫秒级耗时的阶段性优化。

6.7 小结

Skywalking调优这个阶段，恰逢上海疫情封城，既要为生存抢菜，又要翻阅学习着各种ES原理、调优的文档材料，一行一行反复的品味考虑Skywalking相关的源码，测验各种计划去优化它，梦中都在努力提高它的功用。疫情让许多人变得焦虑烦躁，但以我的感受来看在体系的功用压力下疫情何足挂齿。凡事贵在坚持，时刻搞定了诸多困难，调优的作用是很明显的。

或许在在事务价值驱动的价值观中这些技能优化不发生直接事务价值，顶多是五毛特效，但从其他维度来看它价值明显：

  • 对个人来说，技能有提高。
  • 对团队来说，练兵加强配合，协作加深友谊；尤其要感谢科科教师这段时刻的鼎力支撑！
  • 对公司来说，易用性的提高将充分发挥Skywalking的价值，在问题发生时，给到搭档们实在、高效的协助，使得问题能够被快速响应。须知战役拼的是保障。

上一段让我回想起上海疫情那段缺吃少喝、压力很大的时光，确实是有点上头式的真情流露，保存下来就当对上海封城的见证吧。这期间其实也是有考虑过其他的2个计划的：

  1. 运用降低采样率的兜底计划；但为了得到更准确的方针数据，以及后续其他的规划而坚持了全采样。
  2. 选用ClickHouse优化存储；由于公司有定制优化的ES版别，所以就继续在ES上做存储优化，刚好借此时机验证一下。后续【全链路结构化日志】的存储会运用ClickHouse。

这个章节将内容聚集在落地推行时期技能层面的预备和调优，未描绘团队协调、推行等方面的状况；因每个公司状况不同，所以并未提及；但其实对多数公司来说，有时项目的推行比技能本身或许难度更大，这个项目也遇到过一些困难，推行是既靠才能又靠颜值，比如咱家的PM-中英教师的脸都快刷秃噜皮儿了

Skywalking on the way-千亿级的数据储能、毫秒级的查询耗时
…今后有时机再跟我们探讨吧。

7、Skywalking的后续规划

H5、Native以及后端运用还在继续接入中，相应的SDK也在继续的迭代；目前正在规划规划【全链路事务状况追寻】和【全链路结构化日志追寻】，感兴趣的同学能够重视加老友讨论。

最终说一句(求重视，莫错过)

假如这篇文章对您有所协助，或者有所启发的话，帮忙扫描下发二维码重视一下，重视公众号：「架构染色」，进行交流和学习。您的支撑是我坚持写作最大的动力。

求一键三连：点赞、收藏、转发。

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

长按可订阅