随着微服务架构的流行&＃xff0c;服务按照不同的维度进行拆分&＃xff0c;一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上&＃xff0c;这些软件模块&＃xff0c;有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器&＃xff0c;横跨多个不同的数据中心。因此&＃xff0c;就需要一些可以帮助理解系统行为、用于分析性能问题的工具&＃xff0c;以便发生故障的时候&＃xff0c;能够快速定位和解决问题。
全链路监控组件就在这样的问题背景下产生了。最出名的是谷歌公开的论文提到的 Google Dapper。想要在这个上下文中理解分布式系统的行为&＃xff0c;就需要监控那些横跨了不同的应用、不同的服务器之间的关联动作。
所以&＃xff0c;在复杂的微服务架构系统中&＃xff0c;几乎每一个前端请求都会形成一个复杂的分布式服务调用链路。一个请求完整调用链可能如下图所示&＃xff1a;
一个请求完整调用链
那么在业务规模不断增大、服务不断增多以及频繁变更的情况下&＃xff0c;面对复杂的调用链路就带来一系列问题&＃xff1a;
如何快速发现问题&＃xff1f;
如何判断故障影响范围&＃xff1f;
如何梳理服务依赖以及依赖的合理性&＃xff1f;
如何分析链路性能问题以及实时容量规划&＃xff1f;
同时我们会关注在请求处理期间各个调用的各项性能指标&＃xff0c;比如&＃xff1a;吞吐量&＃xff08;TPS&＃xff09;、响应时间及错误记录等。
吞吐量&＃xff0c;根据拓扑可计算相应组件、平台、物理设备的实时吞吐量。
响应时间&＃xff0c;包括整体调用的响应时间和各个服务的响应时间等。
错误记录&＃xff0c;根据服务返回统计单位时间异常次数。
全链路性能监控 从整体维度到局部维度展示各项指标&＃xff0c;将跨应用的所有调用链性能信息集中展现&＃xff0c;可方便度量整体和局部性能&＃xff0c;并且方便找到故障产生的源头&＃xff0c;生产上可极大缩短故障排除时间。
有了全链路监控工具&＃xff0c;我们能够达到&＃xff1a;
请求链路追踪&＃xff0c;故障快速定位&＃xff1a;可以通过调用链结合业务日志快速定位错误信息。
可视化&＃xff1a;各个阶段耗时&＃xff0c;进行性能分析。
依赖优化&＃xff1a;各个调用环节的可用性、梳理服务依赖关系以及优化。
数据分析&＃xff0c;优化链路&＃xff1a;可以得到用户的行为路径&＃xff0c;汇总分析应用在很多业务场景。
如上所述&＃xff0c;那么我们选择全链路监控组件有哪些目标要求呢&＃xff1f;Google Dapper中也提到了&＃xff0c;总结如下&＃xff1a;
探针的性能消耗
APM组件服务的影响应该做到足够小。服务调用埋点本身会带来性能损耗&＃xff0c;这就需要调用跟踪的低损耗&＃xff0c;实际中还会通过配置采样率的方式&＃xff0c;选择一部分请求去分析请求路径。在一些高度优化过的服务&＃xff0c;即使一点点损耗也会很容易察觉到&＃xff0c;而且有可能迫使在线服务的部署团队不得不将跟踪系统关停。
代码的侵入性
即也作为业务组件&＃xff0c;应当尽可能少入侵或者无入侵其他业务系统&＃xff0c;对于使用方透明&＃xff0c;减少开发人员的负担。
对于应用的程序员来说&＃xff0c;是不需要知道有跟踪系统这回事的。如果一个跟踪系统想生效&＃xff0c;就必须需要依赖应用的开发者主动配合&＃xff0c;那么这个跟踪系统也太脆弱了&＃xff0c;往往由于跟踪系统在应用中植入代码的bug或疏忽导致应用出问题&＃xff0c;这样才是无法满足对跟踪系统“无所不在的部署”这个需求。
可扩展性
一个优秀的调用跟踪系统必须支持分布式部署&＃xff0c;具备良好的可扩展性。能够支持的组件越多当然越好。或者提供便捷的插件开发API&＃xff0c;对于一些没有监控到的组件&＃xff0c;应用开发者也可以自行扩展。
数据的分析
数据的分析要快 &＃xff0c;分析的维度尽可能多。跟踪系统能提供足够快的信息反馈&＃xff0c;就可以对生产环境下的异常状况做出快速反应。分析的全面&＃xff0c;能够避免二次开发。
一般的全链路监控系统&＃xff0c;大致可分为四大功能模块&＃xff1a;
埋点与生成日志
埋点即系统在当前节点的上下文信息&＃xff0c;可以分为 客户端埋点、服务端埋点&＃xff0c;以及客户端和服务端双向型埋点。埋点日志通常要包含以下内容traceId、spanId、调用的开始时间&＃xff0c;协议类型、调用方ip和端口&＃xff0c;请求的服务名、调用耗时&＃xff0c;调用结果&＃xff0c;异常信息等&＃xff0c;同时预留可扩展字段&＃xff0c;为下一步扩展做准备&＃xff1b;
不能造成性能负担&＃xff1a;一个价值未被验证&＃xff0c;却会影响性能的东西&＃xff0c;是很难在公司推广的&＃xff01;
因为要写log&＃xff0c;业务QPS越高&＃xff0c;性能影响越重。通过采样和异步log解决。
收集和存储日志
主要支持分布式日志采集的方案&＃xff0c;同时增加MQ作为缓冲&＃xff1b;
每个机器上有一个 deamon 做日志收集&＃xff0c;业务进程把自己的Trace发到daemon&＃xff0c;daemon把收集Trace往上一级发送&＃xff1b;
多级的collector&＃xff0c;类似pub/sub架构&＃xff0c;可以负载均衡&＃xff1b;
对聚合的数据进行 实时分析和离线存储&＃xff1b;
离线分析 需要将同一条调用链的日志汇总在一起&＃xff1b;
分析和统计调用链路数据&＃xff0c;以及时效性
调用链跟踪分析&＃xff1a;把同一TraceID的Span收集起来&＃xff0c;按时间排序就是timeline。把ParentID串起来就是调用栈。
抛异常或者超时&＃xff0c;在日志里打印TraceID。利用TraceID查询调用链情况&＃xff0c;定位问题。
依赖度量&＃xff1a;
离线分析&＃xff1a;按TraceID汇总&＃xff0c;通过Span的ID和ParentID还原调用关系&＃xff0c;分析链路形态。
实时分析&＃xff1a;对单条日志直接分析&＃xff0c;不做汇总&＃xff0c;重组。得到当前QPS&＃xff0c;延迟。
强依赖&＃xff1a;调用失败会直接中断主流程
高度依赖&＃xff1a;一次链路中调用某个依赖的几率高
频繁依赖&＃xff1a;一次链路调用同一个依赖的次数多
展现以及决策支持
基本工作单元&＃xff0c;一次链路调用&＃xff08;可以是RPC&＃xff0c;DB等没有特定的限制&＃xff09;创建一个span&＃xff0c;通过一个64位ID标识它&＃xff0c;uuid较为方便&＃xff0c;span中还有其他的数据&＃xff0c;例如描述信息&＃xff0c;时间戳&＃xff0c;key-value对的&＃xff08;Annotation&＃xff09;tag信息&＃xff0c;parent_id等,其中parent-id可以表示span调用链路来源。
Span
上图说明了span在一次大的跟踪过程中是什么样的。Dapper记录了span名称&＃xff0c;以及每个span的ID和父ID&＃xff0c;以重建在一次追踪过程中不同span之间的关系。如果一个span没有父ID被称为root span。所有span都挂在一个特定的跟踪上&＃xff0c;也共用一个跟踪id。
Span数据结构&＃xff1a;
type Span struct {TraceID int64 // 用于标示一次完整的请求idName stringID int64 // 当前这次调用span_idParentID int64 // 上层服务的调用span_id 最上层服务parent_id为nullAnnotation []Annotation // 用于标记的时间戳Debug bool
}
类似于 树结构的Span集合&＃xff0c;表示一次完整的跟踪&＃xff0c;从请求到服务器开始&＃xff0c;服务器返回response结束&＃xff0c;跟踪每次rpc调用的耗时&＃xff0c;存在唯一标识trace_id。比如&＃xff1a;你运行的分布式大数据存储一次Trace就由你的一次请求组成。
Trace
每种颜色的note标注了一个span&＃xff0c;一条链路通过TraceId唯一标识&＃xff0c;Span标识发起的请求信息。树节点是整个架构的基本单元&＃xff0c;而每一个节点又是对span的引用。节点之间的连线表示的span和它的父span直接的关系。虽然span在日志文件中只是简单的代表span的开始和结束时间&＃xff0c;他们在整个树形结构中却是相对独立的。
注解&＃xff0c;用来记录请求特定事件相关信息&＃xff08;例如时间&＃xff09;&＃xff0c;一个span中会有多个annotation注解描述。通常包含四个注解信息&＃xff1a;
(1) cs&＃xff1a;Client Start&＃xff0c;表示客户端发起请求 (2) sr&＃xff1a;Server Receive&＃xff0c;表示服务端收到请求 (3) ss&＃xff1a;Server Send&＃xff0c;表示服务端完成处理&＃xff0c;并将结果发送给客户端 (4) cr&＃xff1a;Client Received&＃xff0c;表示客户端获取到服务端返回信息
Annotation数据结构&＃xff1a;
type Annotation struct {Timestamp int64Value stringHost EndpointDuration int32
}
请求调用示例
请求调用示例
当用户发起一个请求时&＃xff0c;首先到达前端A服务&＃xff0c;然后分别对B服务和C服务进行RPC调用&＃xff1b;
B服务处理完给A做出响应&＃xff0c;但是C服务还需要和后端的D服务和E服务交互之后再返还给A服务&＃xff0c;最后由A服务来响应用户的请求&＃xff1b;
调用过程追踪
整个调用过程追踪
请求到来生成一个全局TraceID&＃xff0c;通过TraceID可以串联起整个调用链&＃xff0c;一个TraceID代表一次请求。
除了TraceID外&＃xff0c;还需要SpanID用于记录调用父子关系。每个服务会记录下parent id和span id&＃xff0c;通过他们可以组织一次完整调用链的父子关系。
一个没有parent id的span成为root span&＃xff0c;可以看成调用链入口。
所有这些ID可用全局唯一的64位整数表示&＃xff1b;
整个调用过程中每个请求都要透传TraceID和SpanID。
每个服务将该次请求附带的TraceID和附带的SpanID作为parent id记录下&＃xff0c;并且将自己生成的SpanID也记录下。
要查看某次完整的调用则 只要根据TraceID查出所有调用记录&＃xff0c;然后通过parent id和span id组织起整个调用父子关系。
调用链核心工作
调用链数据生成&＃xff0c;对整个调用过程的所有应用进行埋点并输出日志。
调用链数据采集&＃xff0c;对各个应用中的日志数据进行采集。
调用链数据存储及查询&＃xff0c;对采集到的数据进行存储&＃xff0c;由于日志数据量一般都很大&＃xff0c;不仅要能对其存储&＃xff0c;还需要能提供快速查询。
指标运算、存储及查询&＃xff0c;对采集到的日志数据进行各种指标运算&＃xff0c;将运算结果保存起来。
告警功能&＃xff0c;提供各种阀值警告功能。
整体部署架构
整体部署架构
通过AGENT生成调用链日志。
通过logstash采集日志到kafka。
kafka负责提供数据给下游消费。
storm计算汇聚指标结果并落到es。
storm抽取trace数据并落到es&＃xff0c;这是为了提供比较复杂的查询。比如通过时间维度查询调用链&＃xff0c;可以很快查询出所有符合的traceID&＃xff0c;根据这些traceID再去 Hbase 查数据就快了。
logstash将kafka原始数据拉取到hbase中。hbase的rowkey为traceID&＃xff0c;根据traceID查询是很快的。
AGENT无侵入部署
通过AGENT代理无侵入式部署&＃xff0c;将性能测量与业务逻辑完全分离&＃xff0c;可以测量任意类的任意方法的执行时间&＃xff0c;这种方式大大提高了采集效率&＃xff0c;并且减少运维成本。根据服务跨度主要分为两大类AGENT&＃xff1a;
服务内AGENT&＃xff0c;这种方式是通过 Java 的agent机制&＃xff0c;对服务内部的方法调用层次信息进行数据收集&＃xff0c;如方法调用耗时、入参、出参等信息。
跨服务AGENT&＃xff0c;这种情况需要对主流RPC框架以插件形式提供无缝支持。并通过提供标准数据规范以适应自定义RPC框架&＃xff1a;
&＃xff08;1&＃xff09;Dubbo支持&＃xff1b;&＃xff08;2&＃xff09;Rest支持&＃xff1b;&＃xff08;3&＃xff09;自定义RPC支持&＃xff1b;
调用链监控好处
准确掌握生产一线应用部署情况&＃xff1b;
从调用链全流程性能角度&＃xff0c;识别对关键调用链&＃xff0c;并进行优化&＃xff1b;
提供可追溯的性能数据&＃xff0c;量化 IT 运维部门业务价值&＃xff1b;
快速定位代码性能问题&＃xff0c;协助开发人员持续性的优化代码&＃xff1b;
协助开发人员进行白盒测试&＃xff0c;缩短系统上线稳定期&＃xff1b;
市面上的全链路监控理论模型大多都是借鉴Google Dapper论文&＃xff0c;本文重点关注以下三种APM组件&＃xff1a;
Zipkin&＃xff1a;由Twitter公司开源&＃xff0c;开放源代码分布式的跟踪系统&＃xff0c;用于收集服务的定时数据&＃xff0c;以解决微服务架构中的延迟问题&＃xff0c;包括&＃xff1a;数据的收集、存储、查找和展现。
Pinpoint&＃xff1a;一款对Java编写的大规模分布式系统的APM工具&＃xff0c;由韩国人开源的分布式跟踪组件。
Skywalking&＃xff1a;国产的优秀APM组件&＃xff0c;是一个对JAVA分布式应用程序集群的业务运行情况进行追踪、告警和分析的系统。
以上三种全链路监控方案需要对比的项提炼出来&＃xff1a;
探针的性能
主要是agent对服务的吞吐量、CPU和内存的影响。微服务的规模和动态性使得数据收集的成本大幅度提高。
collector的可扩展性
能够水平扩展以便支持大规模服务器集群。
全面的调用链路数据分析
提供代码级别的可见性以便轻松定位失败点和瓶颈。
对于开发透明&＃xff0c;容易开关
添加新功能而无需修改代码&＃xff0c;容易启用或者禁用。
完整的调用链应用拓扑
自动检测应用拓扑&＃xff0c;帮助你搞清楚应用的架构
比较关注探针的性能&＃xff0c;毕竟APM定位还是工具&＃xff0c;如果启用了链路监控组建后&＃xff0c;直接导致吞吐量降低过半&＃xff0c;那也是不能接受的。对skywalking、zipkin、pinpoint进行了压测&＃xff0c;并与基线&＃xff08;未使用探针&＃xff09;的情况进行了对比。
选用了一个常见的基于Spring的应用程序&＃xff0c;他包含Spring Boot, Spring MVC&＃xff0c;redis客户端&＃xff0c;mysql。监控这个应用程序&＃xff0c;每个trace&＃xff0c;探针会抓取5个span(1 Tomcat, 1 SpringMVC, 2 Jedis, 1 Mysql)。这边基本和 skywalkingtest 的测试应用差不多。
模拟了三种并发用户&＃xff1a;500&＃xff0c;750&＃xff0c;1000。使用jmeter测试&＃xff0c;每个线程发送30个请求&＃xff0c;设置思考时间为10ms。使用的采样率为1&＃xff0c;即100%&＃xff0c;这边与生产可能有差别。pinpoint默认的采样率为20&＃xff0c;即50%&＃xff0c;通过设置agent的配置文件改为100%。zipkin默认也是1。组合起来&＃xff0c;一共有12种。下面看下汇总表&＃xff1a;
探针性能对比
从上表可以看出&＃xff0c;在三种链路监控组件中&＃xff0c;skywalking的探针对吞吐量的影响最小&＃xff0c;zipkin的吞吐量居中。pinpoint的探针对吞吐量的影响较为明显&＃xff0c;在500并发用户时&＃xff0c;测试服务的吞吐量从1385降低到774&＃xff0c;影响很大。然后再看下CPU和memory的影响&＃xff0c;在内部服务器进行的压测&＃xff0c;对CPU和memory的影响都差不多在10%之内。
collector的可扩展性&＃xff0c;使得能够水平扩展以便支持大规模服务器集群。
zipkin
开发zipkin-Server&＃xff08;其实就是提供的开箱即用包&＃xff09;&＃xff0c;zipkin-agent与zipkin-Server通过http或者mq进行通信&＃xff0c;http通信会对正常的访问造成影响&＃xff0c;所以还是推荐基于mq异步方式通信&＃xff0c;zipkin-Server通过订阅具体的topic进行消费。这个当然是可以扩展的&＃xff0c;多个zipkin-Server实例进行异步消费mq中的监控信息。
zipkin
skywalking
skywalking的collector支持两种部署方式&＃xff1a;单机和集群模式。collector与agent之间的通信使用了gRPC。
pinpoint
同样&＃xff0c;pinpoint也是支持集群和单机部署的。pinpoint agent通过thrift通信框架&＃xff0c;发送链路信息到collector。
全面的调用链路数据分析&＃xff0c;提供代码级别的可见性以便轻松定位失败点和瓶颈。
zipkin
zipkin链路调用分析
zipkin的链路监控粒度相对没有那么细&＃xff0c;从上图可以看到调用链中具体到接口级别&＃xff0c;再进一步的调用信息并未涉及。
skywalking
skywalking链路调用分析
skywalking 还支持20&＃43;的中间件、框架、类库&＃xff0c;比如&＃xff1a;主流的dubbo、Okhttp&＃xff0c;还有DB和消息中间件。上图skywalking链路调用分析截取的比较简单&＃xff0c;网关调用user服务&＃xff0c;由于支持众多的中间件&＃xff0c;所以skywalking链路调用分析比zipkin完备些。
pinpoint
pinpoint链路调用分析
pinpoint应该是这三种APM组件中&＃xff0c;数据分析最为完备的组件。提供代码级别的可见性以便轻松定位失败点和瓶颈&＃xff0c;上图可以看到对于执行的sql语句&＃xff0c;都进行了记录。还可以配置报警规则等&＃xff0c;设置每个应用对应的负责人&＃xff0c;根据配置的规则报警&＃xff0c;支持的中间件和框架也比较完备。
对于开发透明&＃xff0c;容易开关&＃xff0c;添加新功能而无需修改代码&＃xff0c;容易启用或者禁用。我们期望功能可以不修改代码就工作并希望得到代码级别的可见性。
对于这一点&＃xff0c;Zipkin 使用修改过的类库和它自己的容器(Finagle)来提供分布式事务跟踪的功能。但是&＃xff0c;它要求在需要时修改代码。skywalking和pinpoint都是基于字节码增强的方式&＃xff0c;开发人员不需要修改代码&＃xff0c;并且可以收集到更多精确的数据因为有字节码中的更多信息。
自动检测应用拓扑&＃xff0c;帮助你搞清楚应用的架构。
pinpoint链路拓扑
skywalking链路拓扑
zipkin链路拓扑
上面三幅图&＃xff0c;分别展示了APM组件各自的调用拓扑&＃xff0c;都能实现完整的调用链应用拓扑。相对来说&＃xff0c;pinpoint界面显示的更加丰富&＃xff0c;具体到调用的DB名&＃xff0c;zipkin的拓扑局限于服务于服务之间。
Pinpoint 是一个完整的性能监控解决方案&＃xff1a;有从探针、收集器、存储到 Web 界面等全套体系&＃xff1b;而 Zipkin 只侧重收集器和存储服务&＃xff0c;虽然也有用户界面&＃xff0c;但其功能与 Pinpoint 不可同日而语。反而 Zipkin 提供有 Query 接口&＃xff0c;更强大的用户界面和系统集成能力&＃xff0c;可以基于该接口二次开发实现。
Zipkin 官方提供有基于 Finagle 框架&＃xff08;Scala 语言&＃xff09;的接口&＃xff0c;而其他框架的接口由社区贡献&＃xff0c;目前可以支持 Java、Scala、Node、Go、Python、Ruby 和 C# 等主流开发语言和框架&＃xff1b;但是 Pinpoint 目前只有官方提供的 Java Agent 探针&＃xff0c;其他的都在请求社区支援中&＃xff08;请参见 #1759 和 #1760&＃xff09;。
Pinpoint 提供有 Java Agent 探针&＃xff0c;通过字节码注入的方式实现调用拦截和数据收集&＃xff0c;可以做到真正的代码无侵入&＃xff0c;只需要在启动服务器的时候添加一些参数&＃xff0c;就可以完成探针的部署&＃xff1b;而 Zipkin 的 Java 接口实现 Brave&＃xff0c;只提供了基本的操作 API&＃xff0c;如果需要与框架或者项目集成的话&＃xff0c;就需要手动添加配置文件或增加代码。
Pinpoint 的后端存储基于 HBase&＃xff0c;而 Zipkin 基于 Cassandra。
Pinpoint 与 Zipkin 都是基于 Google Dapper 的那篇论文&＃xff0c;因此理论基础大致相同。两者都是将服务调用拆分成若干有级联关系的 Span&＃xff0c;通过 SpanId 和 ParentSpanId 来进行调用关系的级联&＃xff1b;最后再将整个调用链流经的所有的 Span 汇聚成一个 Trace&＃xff0c;报告给服务端的 collector 进行收集和存储。
即便在这一点上&＃xff0c;Pinpoint 所采用的概念也不完全与那篇论文一致。比如他采用 TransactionId 来取代 TraceId&＃xff0c;而真正的 TraceId 是一个结构&＃xff0c;里面包含了 TransactionId, SpanId 和 ParentSpanId。而且 Pinpoint 在 Span 下面又增加了一个 SpanEvent 结构&＃xff0c;用来记录一个 Span 内部的调用细节&＃xff08;比如具体的方法调用等等&＃xff09;&＃xff0c;因此 Pinpoint 默认会比 Zipkin 记录更多的跟踪数据。但是理论上并没有限定 Span 的粒度大小&＃xff0c;所以一个服务调用可以是一个 Span&＃xff0c;那么每个服务中的方法调用也可以是个 Span&＃xff0c;这样的话&＃xff0c;其实 Brave 也可以跟踪到方法调用级别&＃xff0c;只是具体实现并没有这样做而已。
Pinpoint 实现了基于字节码注入的 Java Agent 探针&＃xff0c;而 Zipkin 的 Brave 框架仅仅提供了应用层面的 API&＃xff0c;但是细想问题远不那么简单。字节码注入是一种简单粗暴的解决方案&＃xff0c;理论上来说无论任何方法调用&＃xff0c;都可以通过注入代码的方式实现拦截&＃xff0c;也就是说没有实现不了的&＃xff0c;只有不会实现的。但 Brave 则不同&＃xff0c;其提供的应用层面的 API 还需要框架底层驱动的支持&＃xff0c;才能实现拦截。比如&＃xff0c;MySQL 的 JDBC 驱动&＃xff0c;就提供有注入 interceptor 的方法&＃xff0c;因此只需要实现 StatementInterceptor 接口&＃xff0c;并在 Connection String 中进行配置&＃xff0c;就可以很简单的实现相关拦截&＃xff1b;而与此相对的&＃xff0c;低版本的 MongoDB 的驱动或者是 Spring Data MongoDB 的实现就没有如此接口&＃xff0c;想要实现拦截查询语句的功能&＃xff0c;就比较困难。
因此在这一点上&＃xff0c;Brave 是硬伤&＃xff0c;无论使用字节码注入多么困难&＃xff0c;但至少也是可以实现的&＃xff0c;但是 Brave 却有无从下手的可能&＃xff0c;而且是否可以注入&＃xff0c;能够多大程度上注入&＃xff0c;更多的取决于框架的 API 而不是自身的能力。
经过简单阅读 Pinpoint 和 Brave 插件的代码&＃xff0c;可以发现两者的实现难度有天壤之别。在都没有任何开发文档支撑的前提下&＃xff0c;Brave 比 Pinpoint 更容易上手。Brave 的代码量很少&＃xff0c;核心功能都集中在 brave-core 这个模块下&＃xff0c;一个中等水平的开发人员&＃xff0c;可以在一天之内读懂其内容&＃xff0c;并且能对 API 的结构有非常清晰的认识。
Pinpoint 的代码封装也是非常好的&＃xff0c;尤其是针对字节码注入的上层 API 的封装非常出色&＃xff0c;但是这依然要求阅读人员对字节码注入多少有一些了解&＃xff0c;虽然其用于注入代码的核心 API 并不多&＃xff0c;但要想了解透彻&＃xff0c;恐怕还得深入 Agent 的相关代码&＃xff0c;比如很难一目了然的理解 addInterceptor 和 addScopedInterceptor 的区别&＃xff0c;而这两个方法就是位于 Agent 的有关类型中。
因为 Brave 的注入需要依赖底层框架提供相关接口&＃xff0c;因此并不需要对框架有一个全面的了解&＃xff0c;只需要知道能在什么地方注入&＃xff0c;能够在注入的时候取得什么数据就可以了。就像上面的例子&＃xff0c;我们根本不需要知道 MySQL 的 JDBC Driver 是如何实现的也可以做到拦截 SQL 的能力。但是 Pinpoint 就不然&＃xff0c;因为 Pinpoint 几乎可以在任何地方注入任何代码&＃xff0c;这需要开发人员对所需注入的库的代码实现有非常深入的了解&＃xff0c;通过查看其 MySQL 和 Http Client 插件的实现就可以洞察这一点&＃xff0c;当然这也从另外一个层面说明 Pinpoint 的能力确实可以非常强大&＃xff0c;而且其默认实现的很多插件已经做到了非常细粒度的拦截。
针对底层框架没有公开 API 的时候&＃xff0c;其实 Brave 也并不完全无计可施&＃xff0c;我们可以采取 AOP 的方式&＃xff0c;一样能够将相关拦截注入到指定的代码中&＃xff0c;而且显然 AOP 的应用要比字节码注入简单很多。
以上这些直接关系到实现一个监控的成本&＃xff0c;在 Pinpoint 的官方技术文档中&＃xff0c;给出了一个参考数据。如果对一个系统集成的话&＃xff0c;那么用于开发 Pinpoint 插件的成本是 100&＃xff0c;将此插件集成入系统的成本是 0&＃xff1b;但对于 Brave&＃xff0c;插件开发的成本只有 20&＃xff0c;而集成成本是 10。从这一点上可以看出官方给出的成本参考数据是 5:1。但是官方又强调了&＃xff0c;如果有 10 个系统需要集成的话&＃xff0c;那么总成本就是 10 * 10 &＃43; 20 &＃61; 120&＃xff0c;就超出了 Pinpoint 的开发成本 100&＃xff0c;而且需要集成的服务越多&＃xff0c;这个差距就越大。
很显然&＃xff0c;这一点上 Pinpoint 完全处于劣势&＃xff0c;从社区所开发出来的集成接口就可见一斑。
Pinpoint 的数据接口缺乏文档&＃xff0c;而且也不太标准&＃xff08;参考论坛讨论帖&＃xff09;&＃xff0c;需要阅读很多代码才可能实现一个自己的探针&＃xff08;比如 Node 的或者 PHP 的&＃xff09;。而且团队为了性能考虑使用了 Thrift 作为数据传输协议标准&＃xff0c;比起 HTTP 和 JSON 而言难度增加了不少。
这一点也不必多说&＃xff0c;Zipkin 由 Twitter 开发&＃xff0c;可以算得上是明星团队&＃xff0c;而 Naver 的团队只是一个默默无闻的小团队&＃xff08;从 #1759 的讨论中可以看出&＃xff09;。虽然说这个项目在短期内不太可能消失或停止更新&＃xff0c;但毕竟不如前者用起来更加放心。而且没有更多社区开发出来的插件&＃xff0c;让 Pinpoint 只依靠团队自身的力量完成诸多框架的集成实属困难&＃xff0c;而且他们目前的工作重点依然是在提升性能和稳定性上。
Pinpoint 在实现之初就考虑到了性能问题&＃xff0c;www.naver.com 网站的后端某些服务每天要处理超过 200 亿次的请求&＃xff0c;因此他们会选择 Thrift 的二进制变长编码格式、而且使用 UDP 作为传输链路&＃xff0c;同时在传递常量的时候也尽量使用数据参考字典&＃xff0c;传递一个数字而不是直接传递字符串等等。这些优化也增加了系统的复杂度&＃xff1a;包括使用 Thrift 接口的难度、UDP 数据传输的问题、以及数据常量字典的注册问题等等。
相比之下&＃xff0c;Zipkin 使用熟悉的 Restful 接口加 JSON&＃xff0c;几乎没有任何学习成本和集成难度&＃xff0c;只要知道数据传输结构&＃xff0c;就可以轻易的为一个新的框架开发出相应的接口。
另外 Pinpoint 缺乏针对请求的采样能力&＃xff0c;显然在大流量的生产环境下&＃xff0c;不太可能将所有的请求全部记录&＃xff0c;这就要求对请求进行采样&＃xff0c;以决定什么样的请求是我需要记录的。Pinpoint 和 Brave 都支持采样百分比&＃xff0c;也就是百分之多少的请求会被记录下来。但是&＃xff0c;除此之外 Brave 还提供了 Sampler 接口&＃xff0c;可以自定义采样策略&＃xff0c;尤其是当进行 A/B 测试的时候&＃xff0c;这样的功能就非常有意义了。
从短期目标来看&＃xff0c;Pinpoint 确实具有压倒性的优势&＃xff1a;无需对项目代码进行任何改动就可以部署探针、追踪数据细粒化到方法调用级别、功能强大的用户界面以及几乎比较全面的 Java 框架支持。但是长远来看&＃xff0c;学习 Pinpoint 的开发接口&＃xff0c;以及未来为不同的框架实现接口的成本都还是个未知数。相反&＃xff0c;掌握 Brave 就相对容易&＃xff0c;而且 Zipkin 的社区更加强大&＃xff0c;更有可能在未来开发出更多的接口。在最坏的情况下&＃xff0c;我们也可以自己通过 AOP 的方式添加适合于我们自己的监控代码&＃xff0c;而并不需要引入太多的新技术和新概念。而且在未来业务发生变化的时候&＃xff0c;Pinpoint 官方提供的报表是否能满足要求也不好说&＃xff0c;增加新的报表也会带来不可以预测的工作难度和工作量。
Monitor可分为系统监控和应用监控。系统监控比如CPU&＃xff0c;内存&＃xff0c;网络&＃xff0c;磁盘等等整体的系统负载的数据&＃xff0c;细化可具体到各进程的相关数据。这一类信息是直接可以从系统中得到的。应用监控需要应用提供支持&＃xff0c;暴露了相应的数据。比如应用内部请求的QPS&＃xff0c;请求处理的延时&＃xff0c;请求处理的error数&＃xff0c;消息队列的队列长度&＃xff0c;崩溃情况&＃xff0c;进程垃圾回收信息等等。Monitor主要目标是发现异常&＃xff0c;及时报警。
Tracing的基础和核心都是调用链。相关的metric大多都是围绕调用链分析得到的。Tracing主要目标是系统分析。提前找到问题比出现问题后再去解决更好。
Tracing和应用级的Monitor技术栈上有很多共同点。都有数据的采集&＃xff0c;分析&＃xff0c;存储和展式。只是具体收集的数据维度不同&＃xff0c;分析过程不一样。
作者&＃xff1a;七寸知架构
来源&＃xff1a;https://www.jianshu.com/p/92a12de11f18
京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有 