目录1.

过去一段时间#xff0c;接手了一个迭代了数年的基于微服务架构搭建的产品。

目录1.

为原有的日志框架输出增加traceId以实现最基础的人肉链路追踪功能。

基于SpringBoot的Actuator特性来对外提供符合我们内部规范的日志级别切换接口。

基于linux命令awk,

sed等实现的日志精确查询功能。

为以上功能提供前端操作页面最大化避免需要登录服务器进行问题排查这一耗时耗神的上世纪操作习惯。

在宣传和推广上投入的时间和精力不足。

相关人员的旧有习惯作祟。

不过这也说明上面方式带来的好处在当事人看到还没有达到让其主动脱离舒适区的程度

基于以上现状我们决定再进一步重新捡起过往曾经动过但受限于思路过于新奇而主动选择回避的念头“扩展skywalking实现对于系统进行链路追踪功能的动态开启和关闭”。

该产品的大部分业务场景其体量远远未达到需要上微服务架构的情况。

但现有的系统架构已经是微服务的模式。

于是矛盾就出现了业务体量不是必须得微服务那么用户势必不愿意在日常运维上投入太多的成本但微服务架构经过多年的争论终于用残酷的现实教育了所有将它当作马良神笔的从业者——别以为复杂度消失了。

微服务只是将复杂度转移到基础设施上。

CI/CD你没有遭罪的是你自己打碎牙你能自己咽但链路追踪你要是没有客户报告问题一般都是火急火燎赶deadline的时候你猜他会不会和颜悦色跟你这演练和人交流要讲礼貌。

截止写下此文的当下我们交出的答卷如标题所示通过skywalking提供的扩展来增加我们自己的自定义逻辑主动控制Agent端向Server端推送监控数据的方式最小化监控这一块的运维成本进而增加监控在团队里的落地范围和深度尽可能地让其能够被绝大部分人作为日常工作中的一部分。

需求描述

让我们用专门的小节描述下需求细节也算是目标达成之后的操作流程。

默认情况下Server端不启动Agent端正常开启。

不过Agent端基于我们的扩展配置默认会直接丢弃所收集来的监控数据不进行上报毕竟你上报也没地方接收。

发现问题时开启Server端和开启agent端自定义配置进入正常的链路追踪排错流程。

解决问题之后关闭Server和Agent端自定义配置。

这一步为了确保执行可在第二步的准备阶段启动一个一次性定时任务。

Server端启动时采用的存储是默认的h2数据库这是为了减少在Server维护上的成本。

也是因为使用h2数据库注定了Server端不能常驻或者说不能接收大量Agent端上报的数据这就回到了本文出现的缘由。

我们过往在【CAT魔改】独立化cat-client的优势里所陈述的一系列诸如站在巨人的肩膀上更大的灵活性等优势同样适合于这里。

除此之外本次我们之所以接受这个魔改根本目的是为了让团队尽早开始积累使用Skywalking的经验。

一个产品想要长远发展其所依赖的基础设施最好是稳固经过千锤百炼的。

毕竟你没有那么多的资源来将你的依赖项全部从零开发一遍尽早确定一个稳定的基础依赖不断对其精研好过从零开始自己摸也好过看见这个觉得不错看见那个好像更好的狗熊掰棒子式地尝鲜式技术选型。

得益于Skywalking其所提供的强大扩展性本次扩展功能实现过程异常地顺利。

在没有系统阅读完Skywalking主体流程逻辑的前提下只是通过借鉴Skywalking自身内置针对各个第三方组件的插件实现编写个自定义Agent插件就完成了本次需求。

不得不说Skywalking的扩展性确实好太多了。

在以上实现自定义Agent插件过程中笔者脑海里不时会回想起那句本以遗忘的经典教导

“对扩展开放对修改关闭”。

相较于笔者在过往迫不得已最终还是构建了分支版本的【CAT魔改】CAT-LOCAL项目的诞生Skywalking真正做到了完全没有修改既有代码真正采用扩展的方式实现。

果然社区强大才是一切。

4.1

以下直接列出需要被扩展的类型具体的实现细节可以参见底部给出的gitee仓库。

扩展点说明TraceSegmentServiceClientSkywalking在其中进行收集来的监控链路数据上报。

GRPCChannelManagerSkywalking在其中进行Server端的grpc验活。

默认间隔30秒。

LogReportServiceClientSkywalking在其中进行收集来的监控日志数据上报。

JVMServiceSkywalking在其中实现定期地JVM状态数据上报。

EventReportServiceClientSkywalking在其中实现Java应用的启停等事件的上报。

4.2

针对上面的扩展我们还需要一些skywalking提供的配置项进行支持。

-Dskywalking.collector.backend_service{SW_IP}:11800

-Dskywalking.plugin.toolkit.log.grpc.reporter.server_host{SW_IP}

-Dskywalking.trace.ignore_path**/acutator/**,**/swCustomPlugin/**

同时该配置项对于本次扩展也提供支持,

-Dskywalking.agent.keep_tracingtrue5.

只限制特定的链路进行上报。

这一步在底部的gitee项目里也给出了相应的示例类TraceCaptureSpecialSamplingService。

提供组件的可观测性。

dynamic-debug-runtime其中的DynamicEnableRuntimeInstrumentation是主要逻辑实现位置。

注意该项目不是必须你完全可以将其中的实现迁移到Gitee

本文这种方式下对于Skywalking的使用就只限于可观测性三支柱的Tracing和Logging就别奢望剩下的那条支柱的Metrics也生效了。

本文需求出现的前提条件是业务特点决定的。

毕竟所有的技术上的决策实际都是政治上的决策我们必须面对这个现实。

我们对系统有监控的理解是平时自己人排错的时候会不会用到这些毕竟按照产品设计的基本理念之吃自己的狗粮如果你自己都不用自己构建的监控体系那这个叫做系统有监控吗现实的矛盾就是最小化运维和基础设施成本与系统微服务架构之间的矛盾。

不要说什么这个玩意搭建起来花不了多少时间。

运维这个职业存在多年区分出不同的等级要求还越来越高是因为把这些玩意搭建起来很难吗

关于微服务

过往我尝试总结了微服务的一些怪现象也收集了不少相关的讨论具体参见下面的链接。

“除非系统体量达到必须微服务否则业务方绝对不会愿意在基础设施和运维上投入成本只希望越少越好。

即使是他将微服务的要求写在了招标文件里。

你有一千条一万条理由痛诉对方多么不专业多么坑爹但回到现实你依然还得解决这个问题当然相较之下有个选择更简单**客户**公司劳*不伺候了。

”

skywalking官网吴晟

《SkyWalking的发展之路;从无名小卒到拥抱全球》专访吴晟开源没有黑魔法两年后泡沫将会破灭【CAT魔改】CAT-LOCAL项目的诞生微服务了个寂寞如何做好既有产品技术架构的升级改造Gitee