cat全链路监控_全链路监控选型

实现全链路监控

SkyWalking

SkyWalking是apache基金会下面的一个开源APM项目，为微服务架构和云原生架构系统设计。它通过探针自动收集所需的指标，并进行分布式追踪。通过这些调用链路以及指标，Skywalking APM会感知

应用间关系和服务间关系，并进行相应的指标统计。Skywalking支持链路追踪和监控应用组件基本涵盖

主流框架和容器，如国产RPC Dubbo和motan等，国际化的spring boot，spring cloud。SkyWalking 是针对分布式系统的 APM 系统，也被称为分布式追踪系统

支持手动探针监控, 提供了支持 OpenTracing 标准的SDK。覆盖范围扩大到 OpenTracing-Java 支持的组件。查看OpenTracing组件支持列表：https://github.com/opentracing-contrib/meta

自动监控和手动监控可以同时使用，使用手动监控弥补自动监控不支持的组件，甚至私有化组件。

纯 Java 后端分析程序，提供 RESTful 服务，可为其他语言探针提供分析能力。

高性能纯流式分析

支持多种插件，UI功能较强，接入端无代码侵入。

Zipkin

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

Pinpoint

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

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://blog.csdn.net/weixin_31664931/article/details/112035464