关于后端:牛逼哄哄的全链路监控系统搭建起来也没有想象中的那么难啊

41次阅读

共计 10563 个字符,预计需要花费 27 分钟才能阅读完成。

问题背景

随着微服务架构的风行,服务依照不同的维度进行拆分,一次申请往往须要波及到多个服务。互联网利用构建在不同的软件模块集上,这些软件模块,有可能是由不同的团队开发、可能应用不同的编程语言来实现、有可能布在了几千台服务器,横跨多个不同的数据中心。因而,就须要一些能够帮忙了解零碎行为、用于剖析性能问题的工具,以便产生故障的时候,可能疾速定位和解决问题。

全链路监控组件就在这样的问题背景下产生了。最闻名的是谷歌公开的论文提到的 Google Dapper。想要在这个上下文中了解分布式系统的行为,就须要监控那些横跨了不同的利用、不同的服务器之间的关联动作。

所以,在简单的微服务架构零碎中,简直每一个前端申请都会造成一个简单的分布式服务调用链路。一个申请残缺调用链可能如下图所示:

一个申请残缺调用链

那么在业务规模一直增大、服务一直增多以及频繁变更的状况下,面对简单的调用链路就带来一系列问题:

  • 如何疾速发现问题?
  • 如何判断故障影响范畴?
  • 如何梳理服务依赖以及依赖的合理性?
  • 如何剖析链路性能问题以及实时容量布局?

同时咱们会关注在申请解决期间各个调用的各项性能指标,比方:吞吐量(TPS)、响应工夫及谬误记录等。

  • 吞吐量,依据拓扑可计算相应组件、平台、物理设施的实时吞吐量。
  • 响应工夫,包含整体调用的响应工夫和各个服务的响应工夫等。
  • 谬误记录,依据服务返回统计单位工夫异样次数。

全链路性能监控 从整体维度到部分维度展现各项指标,将跨利用的所有调用链性能信息集中展示,可不便度量整体和部分性能,并且不便找到故障产生的源头,生产上可极大缩短故障排除工夫。

有了全链路监控工具,咱们可能达到

  • 申请链路追踪,故障疾速定位:能够通过调用链联合业务日志疾速定位错误信息。
  • 可视化:各个阶段耗时,进行性能剖析。
  • 依赖优化:各个调用环节的可用性、梳理服务依赖关系以及优化。
  • 数据分析,优化链路:能够失去用户的行为门路,汇总剖析利用在很多业务场景。

指标要求

如上所述,那么咱们抉择全链路监控组件有哪些指标要求呢?Google Dapper 中也提到了,总结如下:

探针的性能耗费

APM 组件服务的影响应该做到足够小。服务调用埋点自身会带来性能损耗,这就须要调用跟踪的低损耗,理论中还会通过配置采样率的形式,抉择一部分申请去剖析申请门路。在一些高度优化过的服务,即便一点点损耗也会很容易察觉到,而且有可能迫使在线服务的部署团队不得不将跟踪零碎关停。

代码的侵入性

即也作为业务组件,该当尽可能少入侵或者无入侵其余业务零碎,对于应用方通明,缩小开发人员的累赘。

对于利用的程序员来说,是不须要晓得有跟踪零碎这回事的。如果一个跟踪零碎想失效,就必须须要依赖利用的开发者被动配合,那么这个跟踪零碎也太软弱了,往往因为跟踪零碎在利用中植入代码的 bug 或忽略导致利用出问题,这样才是无奈满足对跟踪零碎“无所不在的部署”这个需要。

可扩展性

一个优良的调用跟踪零碎必须反对分布式部署,具备良好的可扩展性。可能反对的组件越多当然越好。或者提供便捷的插件开发 API,对于一些没有监控到的组件,利用开发者也能够自行扩大。

数据的剖析

数据的剖析要快,剖析的维度尽可能多。跟踪零碎能提供足够快的信息反馈,就能够对生产环境下的异样情况做出快速反应。剖析的全面,可能防止二次开发。

功能模块

个别的全链路监控零碎,大抵可分为四大功能模块:

埋点与生成日志

埋点即零碎在以后节点的上下文信息,能够分为 客户端埋点、服务端埋点,以及客户端和服务端双向型埋点。埋点日志通常要蕴含以下内容 traceId、spanId、调用的开始工夫,协定类型、调用方 ip 和端口,申请的服务名、调用耗时,调用后果,异样信息等,同时预留可扩大字段,为下一步扩大做筹备;

  • 不能造成性能累赘:一个价值未被验证,却会影响性能的货色,是很难在公司推广的!
  • 因为要写 log,业务 QPS 越高,性能影响越重。通过采样和异步 log 解决。
收集和存储日志

次要反对分布式日志采集的计划,同时减少 MQ 作为缓冲;

  • 每个机器上有一个 deamon 做日志收集,业务过程把本人的 Trace 发到 daemon,daemon 把收集 Trace 往上一级发送;
  • 多级的 collector,相似 pub/sub 架构,能够负载平衡;
  • 对聚合的数据进行 实时剖析和离线存储;
  • 离线剖析 须要将同一条调用链的日志汇总在一起;
剖析和统计调用链路数据,以及时效性

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

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

依赖度量:

  • 离线剖析:按 TraceID 汇总,通过 Span 的 ID 和 ParentID 还原调用关系,剖析链路状态。
  • 实时剖析:对单条日志间接剖析,不做汇总,重组。失去以后 QPS,提早。
  • 强依赖:调用失败会间接中断主流程
  • 高度依赖:一次链路中调用某个依赖的几率高
  • 频繁依赖:一次链路调用同一个依赖的次数多
  • 展示以及决策反对

Google Dapper

Span

根本工作单元,一次链路调用(能够是 RPC,DB 等没有特定的限度)创立一个 span,通过一个 64 位 ID 标识它,uuid 较为不便,span 中还有其余的数据,例如形容信息,工夫戳,key-value 对的(Annotation)tag 信息,parent_id 等, 其中 parent-id 能够示意 span 调用链路起源。

上图阐明了 span 在一次大的跟踪过程中是什么样的。Dapper 记录了 span 名称,以及每个 span 的 ID 和父 ID,以重建在一次追踪过程中不同 span 之间的关系。如果一个 span 没有父 ID 被称为 root span。所有 span 都挂在一个特定的跟踪上,也共用一个跟踪 id。

Span 数据结构:

type Span struct {
    TraceID    int64 // 用于标示一次残缺的申请 id
    Name       string
    ID         int64 // 以后这次调用 span_id
    ParentID   int64 // 下层服务的调用 span_id  最上层服务 parent_id 为 null
    Annotation []Annotation // 用于标记的工夫戳
    Debug      bool
}
Trace

相似于 树结构的 Span 汇合,示意一次残缺的跟踪,从申请到服务器开始,服务器返回 response 完结,跟踪每次 rpc 调用的耗时,存在惟一标识 trace_id。比方:你运行的分布式大数据存储一次 Trace 就由你的一次申请组成。

每种色彩的 note 标注了一个 span,一条链路通过 TraceId 惟一标识,Span 标识发动的申请信息。树节点是整个架构的根本单元,而每一个节点又是对 span 的援用。节点之间的连线示意的 span 和它的父 span 间接的关系。尽管 span 在日志文件中只是简略的代表 span 的开始和完结工夫,他们在整个树形构造中却是绝对独立的。

Annotation

注解,用来记录申请特定事件相干信息(例如工夫),一个 span 中会有多个 annotation 注解形容。通常蕴含四个注解信息:

(1) cs:Client Start,示意客户端发动申请 (2) sr:Server Receive,示意服务端收到申请 (3) ss:Server Send,示意服务端实现解决,并将后果发送给客户端 (4) cr:Client Received,示意客户端获取到服务端返回信息

Annotation 数据结构:

type Annotation struct {
    Timestamp int64
    Value     string
    Host      Endpoint
    Duration  int32
}
调用示例
  • 申请调用示例

当用户发动一个申请时,首先达到前端 A 服务,而后别离对 B 服务和 C 服务进行 RPC 调用;
B 服务解决完给 A 做出响应,然而 C 服务还须要和后端的 D 服务和 E 服务交互之后再返还给 A 服务,最初由 A 服务来响应用户的申请;

  • 调用过程追踪

整个调用过程追踪

  • 申请到来生成一个全局 TraceID,通过 TraceID 能够串联起整个调用链,一个 TraceID 代表一次申请。
  • 除了 TraceID 外,还须要 SpanID 用于记录调用父子关系。每个服务会记录下 parent id 和 span id,通过他们能够组织一次残缺调用链的父子关系。
  • 一个没有 parent id 的 span 成为 root span,能够看成调用链入口。
  • 所有这些 ID 可用全局惟一的 64 位整数示意;
  • 整个调用过程中每个申请都要透传 TraceID 和 SpanID。
  • 每个服务将该次申请附带的 TraceID 和附带的 SpanID 作为 parent id 记录下,并且将本人生成的 SpanID 也记录下。
  • 要查看某次残缺的调用则 只有依据 TraceID 查出所有调用记录,而后通过 parent id 和 span id 组织起整个调用父子关系。
  • 调用链外围工作

    • 调用链数据生成,对整个调用过程的所有利用进行埋点并输入日志。
    • 调用链数据采集,对各个利用中的日志数据进行采集。
    • 调用链数据存储及查问,对采集到的数据进行存储,因为日志数据量个别都很大,不仅要能对其存储,还须要能提供疾速查问。
    • 指标运算、存储及查问,对采集到的日志数据进行各种指标运算,将运算后果保存起来。
    • 告警性能,提供各种阀值正告性能。
  • 整体部署架构

  • 通过 AGENT 生成调用链日志。
  • 通过 logstash 采集日志到 kafka。
  • kafka 负责提供数据给上游生产。
  • storm 计算汇聚指标后果并落到 es。
  • storm 抽取 trace 数据并落到 es,这是为了提供比较复杂的查问。比方通过工夫维度查问调用链,能够很快查问出所有合乎的 traceID,依据这些 traceID 再去 Hbase 查数据就快了。
  • logstash 将 kafka 原始数据拉取到 hbase 中。hbase 的 rowkey 为 traceID,依据 traceID 查问是很快的。
  • AGENT 无侵入部署

通过 AGENT 代理无侵入式部署,将性能测量与业务逻辑齐全拆散,能够测量任意类的任意办法的执行工夫,这种形式大大提高了采集效率,并且缩小运维老本。依据服务跨度次要分为两大类 AGENT:

服务内 AGENT,这种形式是通过 Java 的 agent 机制,对服务外部的办法调用档次信息进行数据收集,如办法调用耗时、入参、出参等信息。

跨服务 AGENT,这种状况须要对支流 RPC 框架以插件模式提供无缝反对。并通过提供规范数据标准以适应自定义 RPC 框架:

  • (1)Dubbo 反对;
  • (2)Rest 反对;
  • (3)自定义 RPC 反对;

调用链监控益处

  • 精确把握生产一线利用部署状况;
  • 从调用链全流程性能角度,辨认对要害调用链,并进行优化;
  • 提供可追溯的性能数据,量化 IT 运维部门业务价值;
  • 疾速定位代码性能问题,帮助开发人员持续性的优化代码;
  • 帮助开发人员进行白盒测试,缩短零碎上线稳定期;

计划比拟

市面上的全链路监控实践模型大多都是借鉴 Google Dapper 论文,本文重点关注以下三种 APM 组件:

  • Zipkin:由 Twitter 公司开源,凋谢源代码分布式的跟踪零碎,用于收集服务的定时数据,以解决微服务架构中的提早问题,包含:数据的收集、存储、查找和展示。
  • Pinpoint:一款对 Java 编写的大规模分布式系统的 APM 工具,由韩国人开源的分布式跟踪组件。
  • Skywalking:国产的优良 APM 组件,是一个对 JAVA 分布式应用程序集群的业务运行状况进行追踪、告警和剖析的零碎。

以上三种全链路监控计划须要比照的项提炼进去:

探针的性能

次要是 agent 对服务的吞吐量、CPU 和内存的影响。微服务的规模和动态性使得数据收集的老本大幅度提高。

collector 的可扩展性

可能程度扩大以便反对大规模服务器集群。

全面的调用链路数据分析

提供代码级别的可见性以便轻松定位失败点和瓶颈。

对于开发通明,容易开关

增加新性能而无需批改代码,容易启用或者禁用。

残缺的调用链利用拓扑

自动检测利用拓扑,帮忙你搞清楚利用的架构

探针的性能

比拟关注探针的性能,毕竟 APM 定位还是工具,如果启用了链路监控组建后,间接导致吞吐量升高过半,那也是不能承受的。对 skywalking、zipkin、pinpoint 进行了压测,并与基线(未应用探针)的状况进行了比照。

选用了一个常见的基于 Spring 的应用程序,他蕴含 Spring Boot, Spring MVC,redis 客户端,mysql。监控这个应用程序,每个 trace,探针会抓取 5 个 span(1 Tomcat, 1 SpringMVC, 2 Jedis, 1 Mysql)。这边根本和 skywalkingtest 的测试利用差不多。

模仿了三种并发用户:500,750,1000。应用 jmeter 测试,每个线程发送 30 个申请,设置思考工夫为 10ms。应用的采样率为 1,即 100%,这边与生产可能有差异。pinpoint 默认的采样率为 20,即 50%,通过设置 agent 的配置文件改为 100%。zipkin 默认也是 1。组合起来,一共有 12 种。上面看下汇总表:

探针性能比照

从上表能够看出,在三种链路监控组件中,skywalking 的探针对吞吐量的影响最小,zipkin 的吞吐量居中。pinpoint 的探针对吞吐量的影响较为显著,在 500 并发用户时,测试服务的吞吐量从 1385 升高到 774,影响很大。而后再看下 CPU 和 memory 的影响,在外部服务器进行的压测,对 CPU 和 memory 的影响都差不多在 10% 之内。

collector 的可扩展性

collector 的可扩展性,使得可能程度扩大以便反对大规模服务器集群。

  • zipkin

开发 zipkin-Server(其实就是提供的开箱即用包),zipkin-agent 与 zipkin-Server 通过 http 或者 mq 进行通信,http 通信会对失常的拜访造成影响,所以还是举荐基于 mq 异步形式通信,zipkin-Server 通过订阅具体的 topic 进行生产。这个当然是能够扩大的,多个 zipkin-Server 实例进行异步生产 mq 中的监控信息。

  • skywalking

skywalking 的 collector 反对两种部署形式:单机和集群模式。collector 与 agent 之间的通信应用了 gRPC。

  • pinpoint

同样,pinpoint 也是反对集群和单机部署的。pinpoint agent 通过 thrift 通信框架,发送链路信息到 collector。

全面的调用链路数据分析

全面的调用链路数据分析,提供代码级别的可见性以便轻松定位失败点和瓶颈。

  • zipkin

zipkin 链路调用剖析

zipkin 的链路监控粒度绝对没有那么细,从上图能够看到调用链中具体到接口级别,再进一步的调用信息并未波及。

  • skywalking

skywalking 链路调用剖析

skywalking 还反对 20+ 的中间件、框架、类库,比方:支流的 dubbo、Okhttp,还有 DB 和消息中间件。上图 skywalking 链路调用剖析截取的比较简单,网关调用 user 服务,因为反对泛滥的中间件,所以 skywalking 链路调用剖析比 zipkin 齐备些。

  • pinpoint

pinpoint 链路调用剖析

pinpoint 应该是这三种 APM 组件中,数据分析最为齐备的组件。提供代码级别的可见性以便轻松定位失败点和瓶颈,上图能够看到对于执行的 sql 语句,都进行了记录。还能够配置报警规定等,设置每个利用对应的负责人,依据配置的规定报警,反对的中间件和框架也比拟齐备。

对于开发通明,容易开关

对于开发通明,容易开关,增加新性能而无需批改代码,容易启用或者禁用。咱们冀望性能能够不批改代码就工作并心愿失去代码级别的可见性。

对于这一点,Zipkin 应用批改过的类库和它本人的容器 (Finagle) 来提供分布式事务跟踪的性能。然而,它要求在须要时批改代码。skywalking 和 pinpoint 都是基于字节码加强的形式,开发人员不须要批改代码,并且能够收集到更多准确的数据因为有字节码中的更多信息。

残缺的调用链利用拓扑

自动检测利用拓扑,帮忙你搞清楚利用的架构。

pinpoint 链路拓扑

skywalking 链路拓扑

zipkin 链路拓扑

下面三幅图,别离展现了 APM 组件各自的调用拓扑,都能实现残缺的调用链利用拓扑。相对来说,pinpoint 界面显示的更加丰盛,具体到调用的 DB 名,zipkin 的拓扑局限于服务于服务之间。

Pinpoint 与 Zipkin 细化比拟
  • Pinpoint 与 Zipkin 差异性

    • Pinpoint 是一个残缺的性能监控解决方案:有从探针、收集器、存储到 Web 界面等全套体系;而 Zipkin 只偏重收集器和存储服务,尽管也有用户界面,但其性能与 Pinpoint 不可同日而语。反而 Zipkin 提供有 Query 接口,更弱小的用户界面和系统集成能力,能够基于该接口二次开发实现。
    • Zipkin 官网提供有基于 Finagle 框架(Scala 语言)的接口,而其余框架的接口由社区奉献,目前能够反对 Java、Scala、Node、Go、Python、Ruby 和 C# 等支流开发语言和框架;然而 Pinpoint 目前只有官网提供的 Java Agent 探针,其余的都在申请社区声援中(请参见 #1759 和 #1760)。
    • Pinpoint 提供有 Java Agent 探针,通过字节码注入的形式实现调用拦挡和数据收集,能够做到真正的代码无侵入,只须要在启动服务器的时候增加一些参数,就能够实现探针的部署;而 Zipkin 的 Java 接口实现 Brave,只提供了根本的操作 API,如果须要与框架或者我的项目集成的话,就须要手动增加配置文件或减少代码。
    • Pinpoint 的后端存储基于 HBase,而 Zipkin 基于 Cassandra。
  • Pinpoint 与 Zipkin 相似性

    • Pinpoint 与 Zipkin 都是基于 Google Dapper 的那篇论文,因而实践根底大致相同。两者都是将服务调用拆分成若干有级联关系的 Span,通过 SpanId 和 ParentSpanId 来进行调用关系的级联;最初再将整个调用链流经的所有的 Span 汇聚成一个 Trace,报告给服务端的 collector 进行收集和存储。
    • 即使在这一点上,Pinpoint 所采纳的概念也不齐全与那篇论文统一。比方他采纳 TransactionId 来取代 TraceId,而真正的 TraceId 是一个构造,外面蕴含了 TransactionId, SpanId 和 ParentSpanId。而且 Pinpoint 在 Span 上面又减少了一个 SpanEvent 构造,用来记录一个 Span 外部的调用细节(比方具体的办法调用等等),因而 Pinpoint 默认会比 Zipkin 记录更多的跟踪数据。然而实践上并没有限定 Span 的粒度大小,所以一个服务调用能够是一个 Span,那么每个服务中的办法调用也能够是个 Span,这样的话,其实 Brave 也能够跟踪到办法调用级别,只是具体实现并没有这样做而已。
  • 字节码注入 vs API 调用

    • Pinpoint 实现了基于字节码注入的 Java Agent 探针,而 Zipkin 的 Brave 框架仅仅提供了利用层面的 API,然而细想问题远不那么简略。字节码注入是一种简略粗犷的解决方案,实践上来说无论任何办法调用,都能够通过注入代码的形式实现拦挡,也就是说没有实现不了的,只有不会实现的。但 Brave 则不同,其提供的利用层面的 API 还须要框架底层驱动的反对,能力实现拦挡。比方,MySQL 的 JDBC 驱动,就提供有注入 interceptor 的办法,因而只须要实现 StatementInterceptor 接口,并在 Connection String 中进行配置,就能够很简略的实现相干拦挡;而与此绝对的,低版本的 MongoDB 的驱动或者是 Spring Data MongoDB 的实现就没有如此接口,想要实现拦挡查问语句的性能,就比拟艰难。
    • 因而在这一点上,Brave 是硬伤,无论应用字节码注入如许艰难,但至多也是能够实现的,然而 Brave 却有无从下手的可能,而且是否能够注入,可能多大程度上注入,更多的取决于框架的 API 而不是本身的能力。
  • 难度及老本

    • 通过简略浏览 Pinpoint 和 Brave 插件的代码,能够发现两者的实现难度有天壤之别。在都没有任何开发文档撑持的前提下,Brave 比 Pinpoint 更容易上手。Brave 的代码量很少,外围性能都集中在 brave-core 这个模块下,一个中等水平的开发人员,能够在一天之内读懂其内容,并且能对 API 的构造有十分清晰的意识。
    • Pinpoint 的代码封装也是十分好的,尤其是针对字节码注入的下层 API 的封装十分杰出,然而这仍然要求浏览人员对字节码注入多少有一些理解,尽管其用于注入代码的外围 API 并不多,但要想理解透彻,恐怕还得深刻 Agent 的相干代码,比方很难高深莫测的了解 addInterceptor 和 addScopedInterceptor 的区别,而这两个办法就是位于 Agent 的无关类型中。
    • 因为 Brave 的注入须要依赖底层框架提供相干接口,因而并不需要对框架有一个全面的理解,只须要晓得能在什么中央注入,可能在注入的时候获得什么数据就能够了。就像下面的例子,咱们基本不须要晓得 MySQL 的 JDBC Driver 是如何实现的也能够做到拦挡 SQL 的能力。然而 Pinpoint 就不然,因为 Pinpoint 简直能够在任何中央注入任何代码,这须要开发人员对所需注入的库的代码实现有十分深刻的理解,通过查看其 MySQL 和 Http Client 插件的实现就能够洞察这一点,当然这也从另外一个层面阐明 Pinpoint 的能力的确能够十分弱小,而且其默认实现的很多插件曾经做到了十分细粒度的拦挡。
    • 针对底层框架没有公开 API 的时候,其实 Brave 也并不齐全机关用尽,咱们能够采取 AOP 的形式,一样可能将相干拦挡注入到指定的代码中,而且显然 AOP 的利用要比字节码注入简略很多。
    • 以上这些间接关系到实现一个监控的老本,在 Pinpoint 的官网技术文档中,给出了一个参考数据。如果对一个系统集成的话,那么用于开发 Pinpoint 插件的老本是 100,将此插件集成入零碎的老本是 0;但对于 Brave,插件开发的老本只有 20,而集成老本是 10。从这一点上能够看出官网给出的老本参考数据是 5:1。然而官网又强调了,如果有 10 个零碎须要集成的话,那么总成本就是 10 * 10 + 20 = 120,就超出了 Pinpoint 的开发成本 100,而且须要集成的服务越多,这个差距就越大。
  • 通用性和扩展性

    • 很显然,这一点上 Pinpoint 齐全处于劣势,从社区所开发进去的集成接口就可见一斑。
    • Pinpoint 的数据接口不足文档,而且也不太规范(参考论坛探讨帖),须要浏览很多代码才可能实现一个本人的探针(比方 Node 的或者 PHP 的)。而且团队为了性能思考应用了 Thrift 作为数据传输协定规范,比起 HTTP 和 JSON 而言难度减少了不少。
  • 社区反对

    • 这一点也不用多说,Zipkin 由 Twitter 开发,能够算得上是明星团队,而 Naver 的团队只是一个石破天惊的小团队(从 #1759 的探讨中能够看出)。尽管说这个我的项目在短期内不太可能隐没或进行更新,但毕竟不如前者用起来更加释怀。而且没有更多社区开发进去的插件,让 Pinpoint 只依附团队本身的力量实现诸多框架的集成实属艰难,而且他们目前的工作重点仍然是在晋升性能和稳定性上。
  • 其余

    • Pinpoint 在实现之初就思考到了性能问题,www.naver.com 网站的后端某些服务每天要解决超过 200 亿次的申请,因而他们会抉择 Thrift 的二进制变长编码格局、而且应用 UDP 作为传输链路,同时在传递常量的时候也尽量应用数据参考字典,传递一个数字而不是间接传递字符串等等。这些优化也减少了零碎的复杂度:包含应用 Thrift 接口的难度、UDP 数据传输的问题、以及数据常量字典的注册问题等等。
    • 相比之下,Zipkin 应用相熟的 Restful 接口加 JSON,简直没有任何学习老本和集成难度,只有晓得数据传输构造,就能够轻易的为一个新的框架开发出相应的接口。
    • 另外 Pinpoint 不足针对申请的采样能力,显然在大流量的生产环境下,不太可能将所有的申请全副记录,这就要求对申请进行采样,以决定什么样的申请是我须要记录的。Pinpoint 和 Brave 都反对采样百分比,也就是百分之多少的申请会被记录下来。然而,除此之外 Brave 还提供了 Sampler 接口,能够自定义采样策略,尤其是当进行 A/B 测试的时候,这样的性能就十分有意义了。
  • 总结

    • 从短期指标来看,Pinpoint 的确具备压倒性的劣势:无需对我的项目代码进行任何改变就能够部署探针、追踪数据细粒化到办法调用级别、功能强大的用户界面以及简直比拟全面的 Java 框架反对。然而久远来看,学习 Pinpoint 的开发接口,以及将来为不同的框架实现接口的老本都还是个未知数。相同,把握 Brave 就绝对容易,而且 Zipkin 的社区更加弱小,更有可能在将来开发出更多的接口。在最坏的状况下,咱们也能够本人通过 AOP 的形式增加适宜于咱们本人的监控代码,而并不需要引入太多的新技术和新概念。而且在将来业务发生变化的时候,Pinpoint 官网提供的报表是否能满足要求也不好说,减少新的报表也会带来不能够预测的工作难度和工作量。

Tracing 和 Monitor 区别

Monitor 可分为系统监控和利用监控。系统监控比方 CPU,内存,网络,磁盘等等整体的零碎负载的数据,细化可具体到各过程的相干数据。这一类信息是间接能够从零碎中失去的。利用监控须要利用提供反对,裸露了相应的数据。比方利用外部申请的 QPS,申请解决的延时,申请解决的 error 数,音讯队列的队列长度,解体状况,过程垃圾回收信息等等。Monitor 次要指标是发现异常,及时报警。

Tracing 的根底和外围都是调用链。相干的 metric 大多都是围绕调用链分析失去的。Tracing 次要指标是系统分析。提前找到问题比呈现问题后再去解决更好。

Tracing 和利用级的 Monitor 技术栈上有很多共同点。都有数据的采集,剖析,存储和展式。只是具体收集的数据维度不同,剖析过程不一样。

作者:七寸知架构
起源:https://www.jianshu.com/p/92a…

正文完
 0