美文网首页
全链路监控选型

全链路监控选型

作者: Java及SpringBoot | 来源:发表于2020-03-06 13:46 被阅读0次

    个人专题目录


    实现全链路监控

    SkyWalking

    https://github.com/apache/skywalking

    SkyWalking是apache基金会下面的一个开源APM项目,为微服务架构和云原生架构系统设计。它通过探针自动收集所需的指标,并进行分布式追踪。通过这些调用链路以及指标,Skywalking APM会感知
    应用间关系和服务间关系,并进行相应的指标统计。Skywalking支持链路追踪和监控应用组件基本涵盖
    主流框架和容器,如国产RPC Dubbo和motan等,国际化的spring boot,spring cloud。SkyWalking 是针对分布式系统的 APM 系统,也被称为分布式追踪系统

    • 全自动探针监控,不需要修改应用程序代码。查看支持的中间件和组件库列表:https://github.com/apache/incubator-skywalking
    • 支持手动探针监控, 提供了支持 OpenTracing 标准的SDK。覆盖范围扩大到 OpenTracing-Java 支持的组件。查看OpenTracing组件支持列表:https://github.com/opentracing-contrib/meta
    • 自动监控和手动监控可以同时使用,使用手动监控弥补自动监控不支持的组件,甚至私有化组件。
    • 纯 Java 后端分析程序,提供 RESTful 服务,可为其他语言探针提供分析能力。
    • 高性能纯流式分析
    • 支持多种插件,UI功能较强,接入端无代码侵入。

    Zipkin

    https://zipkin.io/

    https://github.com/openzipkin/zipkin

    由Twitter公司开源,开放源代码分布式的跟踪系统,用于收集服务的定时数据,以解决微服务架构中的延迟问题,包括:数据的收集、存储、查找和展现。特点是轻量,使用部署简单。通过Java程序中引入客户端,可隐式拦截Http、Thrift等形式服务调用。通过Http、Kafka、Scribe等方式同步监控数据到服务端,ZipKin带有Web UI,但没有告警功能。

    Pinpoint

    https://github.com/naver/pinpoint

    一款对Java编写的大规模分布式系统的APM工具,由韩国人开源的分布式跟踪组件。特点是支持多种插件,UI功能强大,接入端无代码侵入。

    CAT

    https://github.com/dianping/cat

    CAT是大众点评开源的基于编码和配置的调用链分析,应用监控分析,日志采集,监控报警等一系列的监控平台工具。支持JVM性能数据采集、服务Trace、告警等功能,但需要写监控代码。

    维度 Cat Zipkin PinPoint Skywalking
    实现方式 代码埋点(拦截器,注解,过滤器等) 拦截请求,发送(HTTP,MQ)数据至Zipkin服务 Java探针,字节码增强 Java探针,字节码增强
    接入方式 代码侵入 基于Linkerd或者Sleuth方式,引入配置即可 JavaAgent字节码,高并发情况下,代理对吞吐量的影响比skywalking和zipkin都大 JavaAgent字节码,支持20+的中间件、框架、类库
    agent到collector的协议 http/tcp http,MQ thrift gRPC
    可扩展性 水平扩展服务端 多个zipkin-Server实例进行异步消费mq中的监控信息 collector+web+agent+存储,使得能够水平扩展以便支持大规模服务器集群。 OAP(skywalking6.x才有OAP这个概念,skywalking5.x叫collector)+Web+agent+存储+zk,使得能够水平扩展以便支持大规模服务器集群。
    数据存储 Mysql,Hdfs ES,mysql,Cassandra Hbase(RowKey精确查找,SCAN范围查找,全表扫描),Mysql ES,H2,Mysql,TiDB,Sharding-Sphere
    分析粒度 代码级,全局调用统计,报警,JVM监控 接口级,支持traceid查询 方法级,全局调用统计、报警 方法级,全局调用统计、traceid查询,报警,JVM监控
    调用链可视化
    报表 丰富
    调用链应用拓扑 简单,仅限于服务与服务之间 简单,仅限于服务与服务之间
    埋点方式 侵入 侵入 无侵入 无侵入
    Heartbeat支持
    Metric支持
    是否支持webflux
    客户端支持 Java、C/C++、Node.js、Python java Java,php Java, C#, PHP, Node.js, Go
    中文支持
    社区支持 一般
    国内案例 美团、携程、陆金所等等 京东,阿里定制后不开源 暂无 阿里,小米,滴滴,华为、当当等等
    社区活跃度(截止2020-2) 12.7k 12.5k 9.9k 12.3k
    社区活跃度(截止2019-12 12.3K 12.2K 11.8K
    社区活跃度(截止2018-5) 4.9k 8.4k 5.9k 3.3k

    字节码注入 vs API 调用

    Pinpoint 实现了基于字节码注入的 Java Agent 探针,而 Zipkin 的 Brave 框架仅仅提供了应用层面的 API,但是细想问题远不那么简单。字节码注入是一种简单粗暴的解决方案,理论上来说无论任何方法调用,都可以通过注入代码的方式实现拦截,也就是说没有实现不了的,只有不会实现的。但 Brave 则不同,其提供的应用层面的 API 还需要框架底层驱动的支持,才能实现拦截

    全链路监控大数据解决方案

    image-20200225100520627.png

    全链路监控特质

    低侵入性

    监控系统应尽可能减少对业务系统的侵入,保持对使用方的透明性,减少开发人员的负担,降低接入门槛和难度。对于应用的程序员来说,是不需要知道有跟踪系统这回事的。如果一个跟踪系统想生效,就必须需要依赖应用的开发者主动配合,那么这个跟踪系统也太脆弱了,往往由于跟踪系统在应用中植入代码的bug或疏忽导致应用出问题,这样才是无法满足对跟踪系统“无所不在的部署”这个需求。

    低性能影响

    由于全链路监控系统需要对各种应用中间件进行日志数据采集,大多都需要在业务系统内进行“埋点”或放置agent,一般都是在核心业务流程。在一些高度优化过的服务,即使一点点损耗也会很容易察觉到,而且有可能迫使在线服务的部署团队不得不将跟踪系统关停。

    因此应尽可能降低对业务系统造成的性能影响,一般来说,对CPU的耗用低于2%可以作为一个参考阈值。

    灵活全面的接入策略

    为了尽可能降低接入成本,应该提供灵活的监控配置策略,让业务方决定是否接入,以及收集数据的范围和粒度,并提供对应的技术方案保障监控策略生效。

    时效性

    实时有效的监控数据展示功能,帮助相关人员理解系统行为,为流程、架构、代码优化,以及扩容缩容、服务限流降级提供正确客观的数据参考。

    可扩展性

    一个优秀的调用跟踪系统必须支持分布式部署,具备良好的可扩展性。能够支持的组件越多当然越好。或者提供便捷的插件开发API,对于一些没有监控到的组件,应用开发者也可以根据需要自行扩展。

    全链路监控功能模块

    一般的全链路监控系统,大致可分为四大功能模块:

    埋点与生成日志

    埋点即系统在当前节点的上下文信息,可以分为 客户端埋点、服务端埋点,以及客户端和服务端双向型埋点。埋点日志通常要包含以下内容traceId、spanId、调用的开始时间,协议类型、调用方ip和端口,请求的服务名、调用耗时,调用结果,异常信息等,同时预留可扩展字段,为下一步扩展做准备;

    收集和存储日志

    主要支持分布式日志采集的方案,同时增加MQ作为缓冲;

    每个机器上有一个 deamon 做日志收集,业务进程把自己的Trace发到daemon,daemon把收集Trace往上一级发送;

    多级的collector,类似pub/sub架构,可以负载均衡;

    对聚合的数据进行 实时分析和离线存储;

    离线分析 需要将同一条调用链的日志汇总在一起;

    分析和统计调用链路数据,以及时效性

    调用链跟踪分析:把同一TraceID的Span收集起来,按时间排序就是timeline。把ParentID串起来就是调用栈。

    抛异常或者超时,在日志里打印TraceID。利用TraceID查询调用链情况,定位问题。

    依赖度量:

    • 强依赖:调用失败会直接中断主流程
    • 高度依赖:一次链路中调用某个依赖的几率高
    • 频繁依赖:一次链路调用同一个依赖的次数多

    离线分析:按TraceID汇总,通过Span的ID和ParentID还原调用关系,分析链路形态。

    实时分析:对单条日志直接分析,不做汇总,重组。得到当前QPS,延迟。

    全链路监控系统希望达到的效果

    请求链路追踪,故障快速定位

    可以通过调用链结合业务日志快速定位错误原因。

    可视化

    记录各个阶段耗时,进行性能分析。

    依赖优化

    统计各个调用环节的可用性、梳理服务依赖关系以及优化。

    数据分析,链路梳理和优化

    分析用户的行为路径,梳理和优化整体调用链路。

    本文参考:

    (一文搞懂全链路监控:方案概述与比较)https://cloud.tencent.com/developer/article/1501891

    (APM巅峰对决:skywalking P.K. Pinpoint)https://skywalking.apache.org/zh/blog/2019-02-24-skywalking-pk-pinpoint.html

    (开源APM之Skywalking和Pinpoint的实测对比)http://blog.zollty.com/b/archive/apm-comparison-of-skywalking-and-pinpiont.html

    《OpenTracing 官方标准 —— 中文版》

    Google 论文 《Dapper,大规模分布式系统的跟踪系统》

    相关文章

      网友评论

          本文标题:全链路监控选型

          本文链接:https://www.haomeiwen.com/subject/pqqirhtx.html