随着企业经营规模的扩大,以及对内快速诊断效率和对外SLA(服务品质协议,service-level agreement)的追求,对于业务系统的掌控度的要求越来越高,主要体现在:
同时,对于企业来说,能够更精确的了解资源的使用情况,对于成本核算和控制也有非常大的裨益。
在这种情况下,一般都会引入APM(Application Performance Management & Monitoring)系统,通过各种探针采集数据,收集关键指标,同时搭配数据呈现和监控告警,能够解决上述的大部分问题。
然而随着RPC框架、微服务、云计算、大数据的发展,同时业务的规模和深度相比过往也都增加了很多,一次业务可能横跨多个模块/服务/容器,依赖的中间件也越来越多,其中任何一个节点出现异常,都可能导致业务出现波动或者异常,这就导致服务质量监控和异常诊断/定位变得异常复杂,于是催生了新的业务监控模式:调用链跟踪
APM和调用链跟踪均不是新诞生事务,很多公司已经有了大量的实践,不过开源的并且能够开箱即用的产品并不多,这里主要选取了Pinpoint,Skywalking,CAT来进行对比(当然也有其他的例如Zipkin,Jaeger等产品,不过总体来说不如前面选取的3个完成度高),了解一下APM和调用链跟踪在开源方面的发展状态。
Pinpoint是一个比较早并且成熟度也非常高的APM+调用链监控的项目,在全世界范围内均有用户使用,支持Java和PHP的探针,数据容器为HBase,其界面参考:
Skywalking是一个新晋的项目,最近一两年发展非常迅猛,本身支持OpenTracing规范,优秀的设计提供了良好的扩展性,支持Java、PHP、.Net、NodeJs探针,数据容器为ElasticSearch,其界面参考:
CAT是由美团开源的一个APM项目,也历经了多年的迭代升级,拥有大量的企业级用户,对于监控和报警整合比较紧密,支持Java、C/C++、.Net、Python、Go、NodeJs,不过CAT目前主要通过侵入性的方式接入,数据容器包括HDFS(存储原始数据)和mysql(二次统计),其界面参考:
上面只是做了一个简介,那这三个项目各自有什么特色或者优势/劣势呢(三者的主要产品均针对Java,这里也主要针对Java的特性)?
如果分别去看Pinpoint/Skywalking/CAT的整体设计,我们会发现三者更像是一个规范的三种实现,虽然各自有不同的机制和特性,但是从模块划分和功能基本是一致的:
当然也有一些微小的区别:
前戏这么多,终于开始进入主题,介绍今天的主角:Skywalking,不过通过之前的铺垫,我们基本都知道了Skywalking期望解决的问题以及总体的结构,下面我们则从细节来看Skywalking是怎么一步一步实现的。
首先,Skywalking进行了精准的领域模型划分:
整个系统分为三部分:
而整个Skywalking(包括agent和OAP,而webapp后端业务非常简单主要就是认证和请求转发)均通过微内核+插件式的模式进行编码,代码结构和扩展性均非常强,具体设计可以参考: 从Skywalking看如何设计一个微核+插件式扩展的高扩展框架 ,Spring Cloud Gateway的GatewayFilterFactory的扩展也是通过这种plugin define的方式来实现的。
Skywalking也提供了其他的一些特性:
由于Skywalking并没有自己定制的数据容器或者使用多种数据容器增加复杂度,而是主要使用ElasticSearch(当然开源的基本上都是这样来保持简洁,例如Pinpoint也只使用了HBase),所以数据容器的特性以及自己数据结构基本上就限制了业务的上限,以ES为例:
总体来说,Skywalking尽量使用ES在大数据和查询方面的优势,同时尽量减少ES数据密度低的劣势带来的影响,从目前来看,ES在调用链跟踪方面是不二的数据容器,而在数据指标方面,ES也能中规中矩的完成业务,虽然和时序数据库相比要弱一些,但在PB级以下的数据支持也不会有太大问题。
如果说数据容器决定了上限,那么数据结构则决定了实际到达的高度。Skywalking的数据结构主要为:
其中数量占比最大的就是调用链跟踪数据和各种指标,而这些数据均可以通过OAP设置过期时间,以降低历史数据的对磁盘占用和查询效率的影响。
作为Skywalking的核心数据,调用链跟踪数据(skywalking_segment)基本上奠定了整个系统的基础,而如果要详细的了解调用链跟踪的话,就不得不提到openTracing。
openTracing基本上是目前开源调用链跟踪系统的一个事实标准,它制定了调用链跟踪的基本流程和基本的数据结构,同时也提供了各个语言的实现。如果用一张图来表现openTracing,则是如下:
其中:
以一个Trace为例:
首先是外部请求调用A,然后A依次同步调用了B和C,而B被调用时会去同步调用D,C被调用的时候会依次同步调用E和F,F被调用的时候会通过异步调用G,G则会异步调用H,最终完成一次调用。
上图是通过Span之间的依赖关系来表现一个Trace,而在时间线上,则可以有如下的表达:
当然,如果是同步调用的话,父Span的时间占用是包括子Span的时间消耗的。
而落地到Skywalking中,我们以一条skywalking_segment的记录为例:
{ "trace_id": "52.70.15530767312125341", "endpoint_name": "Mysql/JDBI/Connection/commit", "latency": 0, "end_time": 1553076731212, "endpoint_id": 96142, "service_instance_id": 52, "version": 2, "start_time": 1553076731212, "data_binary": "CgwKCjRGnPvp5eikyxsSXhD///////////8BGMz62NSZLSDM+tjUmS0wju8FQChQAVgBYCF6DgoHZGIudHlwZRIDc3FsehcKC2RiLmluc3RhbmNlEghyaXNrZGF0YXoOCgxkYi5zdGF0ZW1lbnQYAiA0", "service_id": 2, "time_bucket": 20190320181211, "is_error": 0, "segment_id": "52.70.15530767312125340" }
其中:
这里可以看到,目前Skywalking虽然相较于Pinpoint来说查询的维度要多一些,但是也很有限,而且除了endPoint,并没有和业务有关联的字段,只能通过时间/服务/实例/接口/成功标志/耗时来进行非业务相关的查询,如果后续要增强业务相关的搜索查询的话,应该还需要增加一些用于保存动态内容(如messageId,orderId等业务关键字)的字段用于快速定位。
指标数据相对于Tracing则要简单得多了,一般来说就是指标标志、时间戳、指标值,而Skywalking中的指标有两种:一种是采集的原始指标值,例如jvm的各种运行时指标(例如cpu消耗、内存结构、GC信息等);一种是各种二次统计指标(例如tp性能指标、SLA等,当然也有为了便于查询的更高时间维度的指标,例如基于分钟、小时、天、周、月)
例如以下是索引skywalking_endpoint_cpm_hour中的一条记录,用于标志一个小时内某个接口的cpm指标:
{ "total": 8900, "service_id": 5, "time_bucket": 2019031816, "service_instance_id": 5, "entity_id": "7", "value": 148 }
各个字段的释义如下:
Skywalking的工程实现堪比Dubbo,框架设计和代码质量都达到非常高的水准,以dubbo为例,即使2012年发布的老版本放到当今,其设计和编码看起来也依然赏心悦目,设计简洁但是覆盖了所有的核心需求,同时又具备非常强的扩展性,二次开发非常简单,然而却又不会像Spring那样过度封装(当然Spring作为一个更加高度通用的框架,更高的封装也是有必要的)导致代码阅读异常困难。
agent(apm-sniffer)是Skywalking的Java探针实现,主要负责:
当然,agent还实现了客户端采样,不过在APM监控系统里进行客户端数据采样都是没有灵魂的,所以这里就不再赘述了。
首先,agent通过 org.apache.skywalking.apm.agent.core.boot.BootService 实现了整体的插件化,agent启动会加载所有的BootService实现,并通过 ServiceManager 来管理这些插件的生命周期,采集jvm指标、gRPC连接管理、调用链数据维护、数据上报OAP这些服务均是通过这种方式扩展。
然后,agent还通过bytebuddy以javaagent的模式,通过字节码增强的机制来构造AOP环境,再提供PluginDefine的规范方便探针的开发,最终实现非侵入性的数据埋点,采集调用链数据。
最终落地到代码上则异常清晰:
//通过bytebuddy的AgentBuilder构造javaagent增强classLoader new AgentBuilder.Default(byteBuddy) .ignore( //忽略这些包的内容,不进行增强 nameStartsWith("net.bytebuddy.") .or(nameStartsWith("org.slf4j.")) .or(nameStartsWith("org.apache.logging.")) .or(nameStartsWith("org.groovy.")) .or(nameContains("javassist")) .or(nameContains(".asm.")) .or(nameStartsWith("sun.reflect")) .or(allSkyWalkingAgentExcludeToolkit()) .or(ElementMatchers.<TypeDescription>isSynthetic())) //通过pluginFinder加载所有的探针扩展,并获取所有可以增强的class .type(pluginFinder.buildMatch()) //按照pluginFinder的实现,去改变字节码增强类 .transform(new Transformer(pluginFinder)) //通过listener订阅增强的操作记录,方便调试 .with(new Listener()) .installOn(instrumentation); try { //加载所有的service实现并启动 ServiceManager.INSTANCE.boot(); } catch (Exception e) { logger.error(e, "Skywalking agent boot failure."); }
agent也提供了非常简单的扩展实现机制,以增强一个普通类的方法为例,首先你需要定义一个切向点:
public interface InstanceMethodsInterceptPoint { //定义切向方法的适配器,符合适配器的class将被增强 ElementMatcher<MethodDescription> getMethodsMatcher(); //增强的具体实现类,classReference String getMethodsInterceptor(); //是否重写参数 boolean isOverrideArgs(); }
然后你还需要一个增强的实现类:
public interface InstanceMethodsAroundInterceptor { //方法真正执行前执行 void beforeMethod(EnhancedInstance objInst, Method method, Object[] allArguments, Class<?>[] argumentsTypes, MethodInterceptResult result) throws Throwable; //方法真正执行后执行 Object afterMethod(EnhancedInstance objInst, Method method, Object[] allArguments, Class<?>[] argumentsTypes, Object ret) throws Throwable; //当异常发生时执行 void handleMethodException(EnhancedInstance objInst, Method method, Object[] allArguments, Class<?>[] argumentsTypes, Throwable t); }
一般在执行前和执行后进行数据埋点,就可以采集到想要的数据,当然实际编程要稍微复杂一点,不过官方也实现了对应的abstract类和数据埋点工具类,所以探针的二次开发在Skywalking这个级别确实是非常简单,只需要处理好资源占用和并发问题即可。真正的难点是要对需要增强的对象非常了解,熟悉其运作机制,才能找准切向点,既要所有的流程都需要经过这个点,又可以抓取到期望抓取的上下文信息。同时,多版本的适配和测试也是非常大的工作量,官方虽然提供witness的机制(通过验证某个class是否存在来验证版本),但是作为影响全局的探针,开发和测试都是需要慎之又慎的。
同agent类似,OAP作为Skywalking最核心的模块,也实现了自己的扩展机制,不过在这里叫做Module,具体可以参考library-module,在module的机制下,Skywalking实现了自己必须核心组件:
以及一个可选组件:
而前面提到的OAP的高扩展性则体现在核心业务的规范均定义在了core中,如果有需要自己扩展的,只需要自己单独做自己的实现,而不需要做侵入式的改动,最典型的示例则是官方支持的storage,不仅支持单机demo的内存数据库H2和经典的ES,连目前开源的Tidb都可以接入。
对于Skywalking的实践我们经历了三个阶段
由于是线下测试,所以我们直接使用物理机(E5-2680v2 x2, 128G)虚拟了一个集群(实际性能相比云服务器应该偏好一些):
拓扑图:
OAP机器监控:
ES机器监控:
服务监控面板:
其中一个调用链记录:
可以看出,Skywalking非常依赖CPU(不论是OAP还是ES),同时对于网络IO也有一定的要求,至于ES的文件IO在可接受范围内,毕竟确实有大量内容需要持久化。测试结果也基本达到预期要求,调用链和各个指标的监控都工作良好。
在线下测试之后,我们再进行了一次基于实际业务针对探针的测试,测试没有发现探针的异常问题,也没有影响业务的正常运作,同时对于jvm实例影响也不是很大,CPU大概提高了5%左右,并不很明显。在这个基础上我们选择了线上的一台服务器,进行了我们第一次生产环境的测试。
测试时间:03.11-03.16
业务机器负载情况:
从最敏感的CPU指标上来看,增加agent并没有导致可见的CPU使用率的变化,而其他的内存、网络IO、连接数也基本没有变化。
OAP负载情况:
可以看到机器的CPU和网络均有较大的波动,但是也都没有真正打爆服务器,但是我们的实例却经常出现两种日志:
One trace segment has been abandoned, cause by buffer is full.
Collector traceSegment service doesn't response in xxx seconds.
通过阅读源码发现:
而导致OAP没有及时响应的一方面是OAP本身性能不够(OAP需要承担大量的二次统计工作,通过Jstack统计,长期有超过几十个线程处于RUNNABLE状态,据吴晟描述目前OAP都是高性能模式,后续将会提供配置来支持低性能模式),另一方面可能是ES批量插入效率不够,因此我们修改了OAP的批量插入参数来增加插入频率,降低单次插入数量:
虽然 service doesn't response 出现的频率明显降低,但是依然还是会偶尔出现,而每一次出现都会伴随大量的 trace segment has been abandoned ,推测OAP和ES可能都存在性能瓶颈(应该进行更进一步的诊断确定问题,不过当时直接和吴晟沟通,确认确实OAP非常消耗CPU资源,考虑到当时部署只是2C,并且还部署有其他业务,就没有进一步的测试)。
同时,在频繁的数据丢弃过程中,也偶发了一个bug:当agent上报数据超时并且大量丢弃数据之后,即使后续恢复正常也能通过日志看到数据正常上报,在查询界面查询的时候,会查不到这个实例上报的数据,不过在重启OAP和agent之后,之前上报的数据又能查询到,这个也和吴晟沟通过,没有其他的案例,后续想重现却也一直没有成功。
而同时还发现两个更加严重的问题:
在这一次测试中,我们基本确认了agent对于应用的影响,同时也发现了一些我们和Skywalking的一些问题,留待后续测试确认。
为了排除性能和ES版本的影响,测试Skywalking本身的可用性,参考吴晟的建议(这也是在最初技术选型的时候没有选择Pinpoint和CAT的部分原因:一方面Skywalking的功能符合我们的要求,更重要的是有更加直接和效率的和项目维护者直接沟通的渠道),所以这一次我们新申请了ES集群和OAP机器。
测试时间:03.18-至今
OAP负载情况:
ES集群负载:
测试过程中,我们先接入了一台机器上的两个实例,完全没有遇到一测中的延迟或者数据丢弃的问题,三天后我们又接入了另外两台机器的4个实例,这之后两天我们又接入了另外两台机器的2个实例。依然没有遇到一测中的延迟或者数据丢弃的问题。
而ES负载的监控也基本验证了一测延迟的问题,Skywalking由于较高的并发插入,对于ES的性能压力很大(批量插入时需要针对每条数据分析并且构建查询索引),大概率是ES批量插入性能不够导致延迟,考虑到我们仅仅接入了8个实例,日均segment插入量大概5000万条(即日均5000万次独立调用),如果想支持更大规模的监控,对于ES容量规划势必要留够足够的冗余。同时OAP和ES集群的网络开销也不容忽视,在支撑大规模的监控时,需要集群并且receiver和aggregattor分离部署来分担网络IO的压力。
而在磁盘容量占用上,我们设置的原始数据7天过期,目前刚刚开始滚动过期,目前segment索引已经累计了314757240条记录总计158G数据,当然我们目前异常记录较少,如果异常记录较多的话,其磁盘开销将会急剧增加(span中会记录异常堆栈信息)。而由于选择的SSD,磁盘的写入和查询性能都很高,即使只有3个节点,也完全没有任何压力。
而在新版本的ES集群下,Skywalking的所有查询功能都变得可用,和我们之前自己的单独编写的异常指标监控都能完美对照。当然我们也遇到一个问题:Skywalking仅采集了调用记录,但是对于调用过程中的过程数据,除了异常堆栈其他均没有采集,导致真的出现异常也缺少充足的上下文信息还原现场,于是我们扩展了Skywalking的两个探针(我们项目目前重度依赖的组件):OkHttp(增加对requestBody和responseBody的采集)和SpringMVC(增加了对requestBody的采集),目前工作正常,如果进一步的增加其他的探针,采集到足够的数据,那么我们基本可以脱离ELK了。
而OAP方面,CPU和内存的消耗远远低于预期的估计,CPU占用率一直较低,而分配的24G内存也仅使用了10+G,完全可以支持更大规模的接入量,不过在网络IO方面可能存在一定的风险,推测应该8C16G的容器就足以支持十万CPM级别的数据接入。
当然我们在查询也遇到了一些瓶颈,最大的问题就是无法精确的命中某一条调用记录,就如前面的分析,因为segment的数据结构问题,无法进行面向业务的查询(例如messageId、requestId、orderId等),所以如果想精确匹配某一次调用请求,需要通过各个维度的条件约束慢慢缩小范围最后定位。
通过上述对Skywalking的剖析和实践,Skywalking确实是一个优秀的APM+调用链跟踪监控系统,能够覆盖大部分使用场景,让研发和运维能够更加实时/准实时的了解线上服务的运行情况。当然Skywailking也不是尽善尽美,例如下面就是个人觉得目前可见的不满足我们期望的:
而作为一个初级的使用者,个人觉得我们可以使用有限的人力在以下方向进行扩展: