1。自从开始在公司推广SkyWalking，排查问题的人时不时会听到这样的话：“怎么还没连上SkyWalking呢？连上之后，问题出在哪里一目了然。””，正如同事所说，SkyWalking在很多情况下只是那个节目。作为从业者，非常感谢SkyWalking，因为这款国产全链路监控产品给公司的合作伙伴带来了实实在在的帮助；也特别感谢公司的领导和同事们，正是因为他们的支持和帮助，才让这套SkyWalking（V8.5.0）系统从当初好用到现在好用；从亿级Segment储能上限和几十秒的查询时间，到千亿级Segment储能，查询耗时毫秒级。Tips：SkyWalking迭代速度很快，公司使用的是8.5.0版本，新版本性能有待提升。Segment是SkyWalking中提出的一个概念。它代表了一个请求在某个服务中的执行链接片段的集合。一个请求中多个服务依次产生的Segment，串起来形成一个完整的trace，如下图所示：SkyWalking的这个实践，到现在已经有一年多了。我会回顾和总结这个过程中的一些积累和收获。希望回馈社会，为有需要的道友提供案例参考；也希望得到专家的一些反馈。指导和建议，使项目更好。由于安全原因，有些内容需要统一，但我们也尽量把旅途中的美景尽可能完整的呈现给大家。2、为什么要进行全链路监控？随着微服务架构的演进，单体应用按照服务维度进行拆分，组织结构也演化为横向拆分和纵向拆分。一个业务请求的执行轨迹也是从单批量应用时期开始，一个应用实例中的一个接口变成了多个服务实例的多个接口；对应组织架构，可能跨越多个BU，多个Owner。虽然微服务架构高内聚低耦合的优势不言而喻，但低耦合也有明显的副作用。实际上，它给跨部门的沟通和协作带来了额外的不可控制的开销；因此，开发人员尤其是终端业务端的架构师和管理者尤其需要一些能够帮助理解系统拓扑和分析性能问题的工具，以减少在架构调整、性能检测和故障时的沟通协作所耗费的精力和时间，快速定位并修复问题。我所在的平安健康互联网有限公司（以下简称公司）是微服务架构的深度践行者。公司利用互联网技术搭建医疗服务平台，致力于搭建专业的医患桥梁，提供专业、全面、优质、一站式的企业健康管理服务。为进一步提升系统服务质量，提高问题响应效率，21年该部门结合自身情况，决定对现有全链路监控系统进行升级。目的与网络中常见的以下描述基本一致：快速发现问题，判断故障影响范围梳理服务依赖关系，判断依赖合理性分析链路性能，实施容量规划3.为什么选择SkyWalking在进行技术选型时，网络中收集的数据表明，Google的Dapper系统是链接跟踪领域的鼻祖。一些优秀的公司和个人受其公开论文中提出的概念和理念的影响，相继做出了很多非常不错的产品，其中一些产品还是开源的，由社区共同打造的，比如：韩国的Pinpoint，Twitter的Zipkin，以及Uber的Jaeger和中国的SkyWalking等，我们公司在项目选择和审批的过程中考虑了很多因素。这里只总结一下SkyWalking吸引我们的两大优势：1）产品完善度高：java生态，功能丰富，社区活跃，迭代快2）链接跟踪和拓扑分析能力强：插件丰富，非侵入式探针和先进的流式拓扑分析设计“好东西不用说，实际行动会告诉你”，我个人很喜欢这句话，SkyWalking的优点有很多可以在网上找到，所以我在此不再一一比较，也不再赘述。4、预研阶段，最新版本为8.5.0。梳理和分析了8.x的发布记录，估计这个版本的核心功能还是比较稳定的，所以SkyWalking的探索之旅就是从这个版本开始的。当时认知有限，串行的思维模型驱使我关注两个方面：架构原理是什么，副作用是什么：1）架构和原理：代理端主要关注Java的机制Agent、SkyWalkingAgent终端配置、插件工作机制、数据采集和上报机制。服务器端主要关注角色与职责、模块与配置、数据接收机制、指标构建机制、指标聚合机制、指标存储机制。存储端主要关注数据量、存储架构需求、资源评估。2）副作用：功能干扰和性能损失1.架构和原理SkyWalking社区很棒。官网文档和官方出版的书籍都有比较系统的解释，因为我有一些APM系统和JavaAgents的相关经验。通过这两个渠道的学习，我很快对Agent端和OAP（服务器端）有了更系统的认识。在选择系统架构时，评估数据量会比较大（几千个JVM实例，每天采集的segment数可能在50亿到100亿级别），所以传输通道选择Kafka，Elasticsearch做存储，so简单版的结构和数据流如下图所示：这里说明几点：Agent上报数据给OAP端，有grpc通道和kafka通道，当时我瞎猜测是grpc通道可能支持不了，所以选择了kafka通道进行Peakclipping；kafka通道是在8.x中添加的。用ES存储千亿级数据肯定是可以的。图中L1聚合的意思是：SkyWalkingOAP服务器收到数据后，构造一个metric，完成metric的Level-1聚合，这里简称为L1聚合。图中L2聚合的含义是：服务端根据metric的Level-1聚合结果再进行一次聚合，即Level-2聚合，这里简称为L2聚合。随后，纯混合角色集群被拆分为两个集群。2.副作用对于质量团队和接入方来说，他们最关心的是接入SkyWalking后：是否会对应用产生功能干扰，在运行时会造成怎样的性能损失。这两个问题从三个维度来分析。得到答案：1）网络数据显示：Agent造成的性能损失在5%以内，没有找到功能干扰相关的信息（盲猜没有这个问题）2）实现机制评估：字节码增强机制是由JVM提供的机制，SkyWalking使用的字节码操作框架ByteBuddy也很成熟稳定；通过自定义ClassLoader来加载管理插件类，不会有冲突和污染。Agent插件化开发采用的AOP机制基于模板方法模式实现，风险控制到位。即使插件实现逻辑出现异常，也不会影响用户逻辑的执行。一个轻量级的无锁循环队列用于插件采集数据和上报逻辑的解耦，可以看作是一种保护机制；这个队列在MPSC场景下的表现还不错；队列采用满了就丢弃的策略，不会出现Backlog阻塞和OOM。3）性能测试验证：测试老师对dubbo和http两种常规RPC通信场景进行了压力测试和稳定性测试，结果与网络数据描述一致，达到预期。5.POC阶段在POC阶段接入数十个种子应用，以非生产环境为试点进行观察，同时完善插件完成环节，对接公司配置中心，对接发布制度，完善自我监控，做好推广准备。状态。1、对接发布系统为了对接公司的发布系统，方便发布系统，SkyWalking应用拆分成4个子应用：这里有一个考虑，暂定使用单一集群，纯混合角色，以及有性能问题的时候试试Receiver+Aggregator双角色集群模式，选择哪个看效果。SkyWalkingAgent基于JavaAgent机制实现，采用启动挂载方式；启动脚本需要在启动脚本中加入挂载JavaAgent的逻辑，发布系统实现该功能需要注意两点：启动脚本挂载SkyWalkingAgent链接中，尽量让用户察觉不到.发布系统挂载Agent时，会为Agent指定应用名称和组信息。SkyWalkingAgent的发布和升级也由发布系统负责；Agent的升级采用灰度控制方案，控制的粒度有应用级和实例级两种：根据应用的灰度，可以为应用指定Agent的版本根据灰度应用实例，可以指定应用的多个实例使用哪个版本的Agent2，完善插件补全链接。针对公司的OLTP技术栈，量身定做插件集，大部分在开源社区的插件库中都有，缺失的部分通过自研快速补齐。这些插件埋下了各个组件的核心环节。收集到的数据上报给SkyWalking后，Web端的【Tracking】页面可以勾勒出一个完整完善的请求执行环节；分析性能损失和查明问题对开发人员非常有帮助。这里是官方在线demo的截图（对不起后端程序员，五分钱的特效没做出来，丰满的画面请自行补上）友情提示：去掉不用的插件编译和打包程序对减少应用程序启动耗时非常有帮助。3、压力测试和稳定性测试老师为SkyWalkingAgent的插件集设计了丰富的用例。压力测试和稳定性测试结果符合预期；每个公司的标准都不一样，这里不再赘述。4、非常有必要对接自研的配置中心，将应用中的复杂配置交给配置中心管理。配置中心不仅可以提供启动时的静态配置，还可以管理运行时的动态配置，外化配置机制特别容易满足容器场景下应用的无状态需求。啰嗦，举两个例子：调优时，修改参数的值不需要开发测试再发布到生产。无需经过开发、测试和生产发布，即可观察系统状态并修改日志配置。Skywaling在外部配置中心方面适配了市场上主流的配置中心产品。公司配置中心是自研的，需要对接。得益于SkyWalking提供的模块化管理机制，只需扩展一个模块即可。在POC阶段，梳理了server端各个模块的功能，可以感觉到它的配置做得很好，配置项丰富，控制的粒度也很细；除了Webapp模块的外部配置外，POC阶段几乎没有任何变化。改造用配置中心打通，在配置中心的Webapp模块管理Ribbon和Hystrix的配置。5、完善自监控自监控是指监控SkyWalking系统中各个模块的运行情况：完善自监控后的结构如下图所示：6、自研Native-endSDK公司移动端application是很核心的，同时也用到了linktracking社区缺少这个功能，所以基于SkyWalking协议，移动端的小伙伴开发了一套SDK来弥补Native端link数据的不足，以及也起到了后续二次打开页面指标统计的作用。伴随着口口相传，团队不断提出需求，参与建设，所以也在不断迭代；内容很多，这里就不展开了。7.总结POC阶段的数据量并不大，主要是发现系统的各种功能问题，查漏补缺。6、优化阶段，SkyWalking官方推广采用城市包围农村的策略；公司核心应用首批接入。这种策略有几个好处：核心应用的监管是重中之重，默认优先级最高。.随着大家对SkyWalking的依赖加深，核心应用的上下游应用将逐步独立连接起来。当然，安全是第一位的。无论新系统有多好、多强大，其引入都必须符合安全稳定的前提要求。它需要安全、快速和方便。因此，在之前Agent的灰度接入能力的基础上，在发布系统中增加了应用所有者的自助灰度接入和快速卸载SkyWalkingAgent的能力，即应用所有者可以选择一个独立使用。应用访问，访问多个实例，遇到问题只需重启即可快速卸载；这种能力在推广初期起到了巨大的作用；毕竟安全是第一位的，信任是需要逐渐建立起来的。随着应用的接入和使用，我们也逐渐遇到了一些问题。下面我们按照时间递增的顺序，快速向大家介绍问题和优化效果。更多技术原理计划在公众号《建筑染》专辑【SkyWalking调音系列】补充。开始前先说明几点：以下数字仅代表我司情况，标出的段数为处理该问题期间的情况，不代表该现象当达到这个数字时开始发生。这些值和当时的现象受主机配置、段数据大小、存储处理能力等多种因素的影响，请注意调整过程和效果，不需要检查数字和现象.1、启动耗时1）有同事反馈应用启动慢。调查发现，容器中大部分应用的总耗时在连接SkyWalking前是2秒，连接后变成了16秒以上。公司中很多核应用的实例数量很大，这样的启动丢失对它们的发布影响太大。2)优化记录启动时间，与其他启动数据一起上报给服务器，方便查看对比。优化KafkaReporter的启动流程，减少启动时间3-4秒。在优化了类匹配和增强环节（关键点）后，容器内启动应用的总耗时从16多秒减少到3秒以内。在整理Kafka启动和上报的过程中，顺便调整了Agent端数据上报给Kafka的分区选择策略，将一个JVM实例中的所有数据发送到同一个分区，这样聚合在L1层完成JVM实例级别的metric聚合，需要注意调整Kafka分片数量，保证负载均衡。2.Kafkabacklog-6亿个segments/day1）问题是SkyWalkingOAP消费慢，导致Kafka中segments积压。未能实现可用目标。2)优化SkyWalkingOAP端监控指标无法识别链路的问题，将server端单集群拆分为双集群，即将角色为Mixed的集群改为角色为角色的集群Receiver的（接收和L1聚合），以及加入聚合（L2聚合）角色的集群调整为双集群模式，数据流向如下图所示：3.Kafkabacklog-8亿segments/day1)问题SkyWalkingOAP端消费慢，导致Kafka中有segment积压，监控指标可见ES存储链路慢，未能达到可用的目的。2)优化segment保存到ES的批处理，调整BulkProcessor的线程数和batchsize。优化将metrics保存到ES的批处理过程，调整批处理间隔、线程数、批大小、刷盘时间。4.Kafkabacklog-20亿段/天1）问题Aggregation集群实例持续FullGC，Receiver集群无法通过grpc向Aggregation集群发送metrics。未能实现可用目标。2）优化添加ES节点和分片，但效果不明显。ES集群压力大，但无法准确定位是哪个数据操作导致的。采用分而治之的策略，尝试对数据进行拆分，从OAP服务器调整读写逻辑，将ES单集群拆分为trace集群和metric集群；对比了ES的监控指标，很明显是metric集群的读写压力过高。优化Receiver集群指标的L1聚合。完成1分钟的数据聚合后，提交给Aggregation集群进行L2聚合。Aggregationclustermetric的L2聚合是基于db实现的。会有空读-写-重读-累加-更新写等逻辑。每次写入都会有一次读取。调整逻辑是提高读性能，优化缓存机制，减少Read触发；调整间隔以避免触发累积和更新。调整metric批量写入ES操作到BulkProcessor。ES的metriccluster使用SSD存储来增加节点数和分片数。这次的持续优化是一个里程碑。Kafka消费很快，各个OAP机器的FullGC都没了，ES各方面指标也稳定。接下来，我们将开始优化查询并提高可用性。5、trace查询慢——25亿段/天1）问题是web端【Trace】页面查询很慢，只保存了15天的数据。根据traceId查询需要20多秒，根据条件查询trace列表耗时更差；这给人以“墨水出不来”的感觉，没有达到好用的目的。2）优化ES查询优化的资料很多，但是通过百度就可以找到解决这个问题的有效方法。这取决于我们的宠物狗的类别。还好偶遇，结论是外貌不靠谱。言归正传，影响读写性能的三个基本要素：读写频率、数据规模、硬件性能；痕迹的情况从这三个维度设置了一套模板：本次分析并未得出指导性结论。这里频率的粒度太粗了，用户的使用也和时间密切相关。情况大致是：当天的数据读多写多（当天不断写入新数据，基于应急响应的需要，当问题出现时，可能是接近实时的排查处理）.前一天的数据读多写少（一般第二天会有密集的问题汇报，0:00后前一天的数据会有延迟到达）。不管多早，都没有写入新的数据，越早读取数据的可能性就越小。基于以上分析，加入时间维度，提炼出更多的参考因素后，分析模型变成了这样：从上表可以看出，热温数据架构整体需求呈1-2天。热数据，上一个是暖数据；正好ES7提供了hot-warm架构支持，hot-warm改造后的架构如下图所示：恰逢ES公司发布ES中调版本，内置ZSTD压缩算法空间压缩效果非常显着。调整trace集群的hot-warm架构后，查询时间从20多秒变成了2-3秒，效果非常明显。进一步调整查询逻辑，充分利用ES的数据分片和路由机制，将全量检索调整为精准检索，即减少检索时需要扫描的数据量，优化2-3秒到毫秒。这里我们要炫耀一下5毛钱的特效。在这种机制下，即使Segment数据保存半年，根据TraceId查询也需要毫秒级的时间。至此，查询千亿Trace数据只需毫秒级的阶段性优化就完成了。6、dashboard和topology查询慢1）问题web端的【Topology】页面，虽然一开始只有几十个应用很慢，但是还是可以看到数据的。随着应用数量的增加，[Topology]页面数据请求一直超时（配置60s超时），能量有限。一、功能降级为隐藏本页；【dashboard】的指标查询也很慢，没有达到易用的目的。2)优化Web端【Dashboard】页面和【Topology】页面，显示SkyWalking中的metric数据。metric数据与trace数据一样满足热温特性。①metric集群采用hot-warm架构调整，然后dashboard中的查询时间也降低到毫秒级。②【拓扑】页面界面依旧超时（60s），针对拓扑做了几处针对性调整：合并内部循环调用，压缩调用次数。删除不必要的查询。对公共索引中的数据进行拆分和隔离，避免相互干扰。全量搜索调整为精确搜索，即减少搜索时需要扫描的数据量。至此，拓扑页面数据毫秒级查询耗时的阶段性优化已经完成。7.总结SkyWalking调优阶段恰逢上海因疫情封城。既要抢粮求生，又要阅读和学习各种ES原理和调优文档，对SkyWalking相关的源码一行一行地品味和思考。尝试各种解决方案对其进行优化，Dream正在努力提高其性能。疫情让很多人焦虑、烦躁，但在我看来，在系统的性能压力下，疫情不值一提。凡事最重要的是坚持，时间解决了很多困难，调优效果非常显着。或许在商业价值驱动的价值中，这些技术优化并不能产生直接的商业价值，顶多是50美分的特殊效果，但从其他维度来说是有显着价值的：对个人来说，技术提升了。对于团队，实战训练提高战斗力，团队合作加深友谊；特别感谢ES众泰在此期间的支持！对于公司而言，易用性的提升将充分发挥SkyWalking的价值。出现问题时，为同事提供切实有效的帮助，使问题得到快速响应；必须知道，战争是关于保证的。期间其实也考虑过另外两种方案：采用自下而上的方案降低采样率；但为了获得更准确的指标数据和其他后续计划，我坚持全抽样。使用ClickHouse优化存储；因为公司有定制优化过的ES版本，所以在ES上继续优化存储，正好借此机会验证一下。ClickHouse将用于后续存储【全链路结构化日志】。本章重点介绍落地推广期间技术层面的准备和调优，不描述团队协同、推广等情况；因为每个公司的情况不同，就不一一列举了；但事实上，对于大多数公司来说，一些项目的推广可能比技术本身还要困难。这个项目也遇到了一些困难。PM的晋升既要看能力，也要看颜值。有机会我会和你讨论的。7、未来规划H5，Native和后台应用不断打通，对应的SDK也在不断迭代；目前，在已建立的链接通道的基础上，正在完善【全链路业务状态跟踪】和【全链路业务状态跟踪】。RoadStructuredLogTracking】旨在为运营、客服、运维、开发等服务的一线同仁提供一个多视角的一站式观察平台，及时提升系统服务质量和问题响应速度全方位的方式。
