简介: 当前的系统在数字化转型需求以及互联网架构实施的影响下,越来越普遍地使用了微服务架构,我们在享受微服务带来的好处(开发效率高, 独立部署, 水平扩展, 故障与资源隔离等等)外,也带来测试,事务,应用监控等各方面的困难。
前言
当前的系统在数字化转型需求以及互联网架构实施的影响下,越来越普遍地使用了微服务架构,我们在享受微服务带来的好处(开发效率高, 独立部署, 水平扩展, 故障与资源隔离等等)外,也带来测试,事务,应用监控等各方面的困难。
从上图可以看出,在以分布式为主的互联网架构下,应用间的调用变得越来越复杂,我们传统使用的开发工程师主动埋点,运维人员到主机上查日志,组合调用链,监控应用的运行情况,显得越来越力不从心。
为了更好地做到应用层面的监控,包括应用运行环境的基础设施数据,系统业务调用情况,性能消耗分析,在发生性能,异常与故障问题时,能够快速定位和解决问题,诞生了很多优秀的APM(Application Performance Management)工具。
这些APM工具都提供了包括指标统计信息与调用链路跟踪信息。
常见的APM工具
APM工具包括指标收集与调用链收集。指标收集例如在某一段时间的请求数,异常数,错误数,响应时间RT, IAAS层的资源使用情况(例如cpu, memory, IO, load, 网络), 也包括JVM的各种运行参数(例如 各内存分区情况,gc情况)。调用链收集包括业务请求中访问过的各应用,类,方式,在每个运行节点/方法上的时间消耗情况。
常见的APM工具有:
1、ARMS:由阿里巴巴自研开发的一款APM工具。由于分布式微服务框架以阿里为主体的企业很早就开始探索,阿里集团内很早就有配套的鹰眼系统做相关的应用监控,为适应产品上云输出,阿里在2016-08-04的时间就以ARMS的产品形式正式对外提供应用监控服务。
2、开源系的APM
u Pinpoint:基于java编写的开源APM工具,由韩国人开发贡献,功能完善,发展快,影响了很多其它的APM工具实现,在国内外使用比较广泛。
u Skywalking:支持open tracing标准,由我国的吴晟主导开发的分布式追踪,分析,告警的开源工具,当前是Apache旗下的开源项目,发展非常迅速,在各类开源APM工具里国内的使用比较广泛。
u ZipKin:支持open tracing标准,由Twitter公司开发贡献,于2012年的时候就开始开源发展,是比较成熟的开源APM工具。
u Jaeger:支持open tracing标准,由Uber公司开发贡献,是比较成熟的开源APM工具。
APM工具原理
尽管这些APM工具功能与实现各有不同,但基本上原理都是一样的,这个原理基于google dapper的分布式追踪技术论文,把APM工具实现总体上分为两大部分:
1、对应用运行节点上进行应用埋点,在业务运行期间进行埋点数据的生成;
2、通过APM的后端服务日志收集,数据清洗与聚合,把相应的处理结果持久化,并且提供丰富的可视化控制台。
在这个调用链追踪技术里,还原调用链的功能主要依赖于两个ID.
第一个ID是TraceID, 这个代表一个业务调用,就好像在电商系统里发起的一个下单结算; 在线教育里的一个选课流程; 物流系统里的揽收; 这些业务从客户触发到获得响应结果就是一个完整的请求,就是一次业务调用,它每一次的业务请求的都会获得维一的TraceID;
第二个ID是RpcID (或者称为SpanID), 在一次业务请求中,可能经过的应用会有多过,以一个电商下单业务为例: 它需要经过订单系统创建订单; 支付系统接受支付;库存系统扣减产品库存;会员系统给买家进行积分处理; 购物车系统会清理购物清单。这样对于业务流经的每一个应用,都有一个有层次的RpcID, 这个RpcID可以认为是使用目录层级记录的,从这个RpcID来看,那怕它在同一个业务中被调用了多次,它的每一次进入的RpcID都是一样的。
依赖于TraceID & RpcID,我们可以很方便地还原整个调用链。
ARMS功能上的优势:
客观来说, 优秀的APM工具发展到现在,基础功能上的差异都不大。例如以前开源APM比较薄弱的自动埋点功能也跟进了ARMS这些先发的产品; 在异步产品如各类MQ的支持上也慢慢拉平;SQL/API参数抓取的功能方面也是补足。我们再来列一下ARMS的优点:
1、指标数据的准确性
ARMS的agent把指标数据与调用链数据是分开两种类型来采集统计的, 相应的指标数据不受调用链的采样率的影响,会在具体的运行节点进行完完全全的统计后,精准到上传加载到ARMS后端。(而有些优秀的APM工具是通过采样上来的调用链进行加工处理,再来产出相应的指标,这在准确性上会有一定的丢失。)
2、线程栈捕获
因为是JAVA自动埋点的原理是对已知的框架进行字节码加强,当某框架不在已支持的范围内,那么这段访问的信息就不会被记录下来。ARMS可以通过设定调用超过一定时长后,可以通把整个线程栈捕获下来,这样我们就可以通过线程栈的分析进行补充定位。
3、线程分析
ARMS可以通过线程分析页签,清淅地看到各类线程的资源占用情况。例如可以知道当前的某线程池线程数是多少, 占用cpu最多的线程是那个, 占用的百分比情况,并且可以看到线程的运行状态。
4、业务关联日志
ARMS这边可以通过给合传统的log4j等技术,在输出业务日志上可以把相应的TraceID 就像线程ID那样通过方便的配置就可以与业务日志同时输出。另外,ARMS与阿里云的SLS进行整合,可以通过ARMS的页面方便地根据调用链的TraceID查找到关联的业务日志,这样需要结合业务日志定位时,更方便实用。
5、智能合并能力
ARMS对于相同的调用,例如递当,循环会进行智能合并,显示循环的次数,执行的最大时长,最小时长,平均时长。
6、主动诊断能力
ARMS提供了主动诊断能力,可以通过选定具体的时间,执行主动诊断,ARMS会分析这一段时间内的应用运行情况,自动总结这一段时间内的问题,并且结合阿里的经验,产出具体的报表。我们依据这个报表,可以加速我们的定位与优化。
7、丰富的报警能力
完善报警体系,ARMS提供了丰富的报警规则,我们可以对相应的规则进行开启/关停,编辑,这样可以快速搭建报警体系。在报警通道方面,可以直接发对接钉钉/WebHook/Email/短信网关等。
运维能力上的优势
1、 按需监控启停管理
通过ARMS的管理控制台,我们可以批量在管理应用的启停,可以一键停止所有的ARMS监控,也可以一键启动相关应用的监控。非常符合上云的按需要使用观念。
2、动态采样率变更
在面对特殊的时间点或者异常出现机率的时候,我们希望动态调整采样率,例如通过调大采样率来捕获这些概率极少的调用链,借助ARMS的配置管理,我们可以非常方便地把更齐全的调用链收集起来;通过调小采样率来保证存储空间的合理使用(其它的APM工具在做采样率的变更时,需要应用的重新配置,启动,这不但处理起来麻烦,并且影响业务的边续性,在实际操作上很难下定决心去在运行期间中断业务去做改变采样率的变更。)
3、 绑定参数的开关
虽然很多APM工具都可以提供绑定参数的功能。但很多时候,如果对于业务数据敏感的系统,并不希望这类APM工具在非必要的时候采集SQL/API的运行参数。所以ARMS在它的配置管理里提供这么一个功能非常有意义,也就是当需要收集这些运行的业务参数进行问题定位分析的时候,那么只要打开就可以了,使用完毕后,再通过把这些开关关上,那么就可以保护我们的业务数据不外泄漏出去了。
4、接入简易
可通过更简易的方式如阿里容器ACK/EDAS/SAE等各种非常便捷的接入方式,只需要简单的YAML注解或按钮即可完成接入。
5、 组件稳定免运维
因为ARMS是商业化的产品,所以所有的组件都是不需要我们使用方运维的。如果使用开源自建,那么我们就需要对日志收集,计算清洗服务,存储产品本身进行运维,包括相应的集群规模,清理处理,扩容处理,如果在峰值过后,不进行资源回收,也会产生额外的使用浪费。
成本使用上的优势
1、 ARMS是按接入节点,接入的小时(时长)计费的,这样可以充分发挥云上产品的优势。按需要使用,按需要的应用节点付费。另外ARMS单纯地按照节点数来计算,并不受采样率的变动而产生变化,这样对于大采样率的应用是有一定的优势。
2、 ARMS有相应的资源包,可以通过购买资源包的方式进一步节省费用。
3、 因为产品的组合因素,ARMS如果搭配阿里云的容器(ACK)使用,计费会自动5折。
最后,这里列一下开源与ARMS的一个成本的比较供大家参考:
备注
1、开源的按照统一统计数据存15天,全量明细数据存3天计算(ARMS的数据是全天24小时使用,存储60天,在非容器下按年包折下来的月费用。)
2、人力成本以具有开发能力的运维人员月薪3万计算。人力成本,主要参数变动带来的发布,后端系统的不稳定带来的效率损失,后端系统的维护操作。中大型的会做一些定制的开发(例如采样的动态配置化生效)
综述
在阿里云上,ARMS在APM层面提供了足够丰富的功能;可以友好地运维操作;另外通过合理地按需使用,结合资源包,以及容器的方式运行,使用起来还高效与节省。作为基础设施的实用监控,不重复发明轮子,不重人力资源投入,综合考虑各方面因素,最终选择使用ARMS。
原文链接
本文为阿里云原创内容,未经允许不得转载。