Zipkin

随着微服务架构的风行，服务依照不同的维度进行拆分，一次申请往往须要波及到多个服务。互联网利用构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发、可能应用不同的编程语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心。因而，就须要一些能够帮忙了解零碎行为、用于剖析性能问题的工具，以便产生故障的时候，可能疾速定位和解决问题。在简单的微服务架构零碎中，简直每一个前端申请都会造成一个简单的分布式服务调用链路。一个申请残缺调用链可能如下图所示： 随着服务的越来越多，对调用链的剖析会越来越简单。它们之间的调用关系兴许如下： 随着业务规模一直增大、服务一直增多以及频繁变更的状况下，面对简单的调用链路就带来一系列问题： 如何疾速发现问题？如何判断故障影响范畴？如何梳理服务依赖以及依赖的合理性？如何剖析链路性能问题以及实时容量布局？而链路追踪的呈现正是为了解决这种问题，它能够在简单的服务调用中定位问题，还能够在新人退出后盾团队之后，让其分明地晓得本人所负责的服务在哪一环。除此之外，如果某个接口忽然耗时减少，也不用再一一服务查问耗时状况，咱们能够直观地剖析出服务的性能瓶颈，不便在流量激增的状况下精准正当地扩容。 什么是链路追踪“链路追踪”一词是在 2010 年提出的，过后谷歌公布了一篇 Dapper 论文：Dapper，大规模分布式系统的跟踪零碎，介绍了谷歌自研的分布式链路追踪的实现原理，还介绍了他们是怎么低成本实现对利用通明的。 单纯的了解链路追踪，就是指一次工作的开始到完结，期间调用的所有零碎及耗时（时间跨度）都能够残缺记录下来。其实 Dapper 一开始只是一个独立的调用链路追踪零碎，起初逐步演化成了监控平台，并且基于监控平台孕育出了很多工具，比方实时预警、过载爱护、指标数据查问等。 除了谷歌的 Dapper，还有一些其余比拟有名的产品，比方阿里的鹰眼、公众点评的 CAT、Twitter 的 Zipkin、Naver（驰名社交软件LINE的母公司）的 PinPoint 以及国产开源的 SkyWalking（已奉献给 Apache） 等。 什么是 SleuthSpring Cloud Sleuth 为 Spring Cloud 实现了分布式跟踪解决方案。兼容 Zipkin，HTrace 和其余基于日志的追踪零碎，例如 ELK（Elasticsearch 、Logstash、 Kibana）。 Spring Cloud Sleuth 提供了以下性能： 链路追踪：通过 Sleuth 能够很分明的看出一个申请都通过了那些服务，能够很不便的理清服务间的调用关系等。性能剖析：通过 Sleuth 能够很不便的看出每个采样申请的耗时，剖析哪些服务调用比拟耗时，当服务调用的耗时随着申请量的增大而增大时， 能够对服务的扩容提供肯定的揭示。数据分析，优化链路：对于频繁调用一个服务，或并行调用等，能够针对业务做一些优化措施。可视化谬误：对于程序未捕捉的异样，能够配合 Zipkin 查看。专业术语Span根本工作单位，一次独自的调用链能够称为一个 Span，Dapper 记录的是 Span 的名称，以及每个 Span 的 ID 和父 ID，以重建在一次追踪过程中不同 Span 之间的关系，图中一个矩形框就是一个 Span，前端从发出请求到收到回复就是一个 Span。 开始跟踪的初始跨度称为root span。该跨度的 ID 的值等于跟踪 ID。Dapper 记录了 span 名称，以及每个 span 的 ID 和父 span ID，以重建在一次追踪过程中不同 span 之间的关系。如果一个 span 没有父 ID 被称为 root span。所有 span 都挂在一个特定的 Trace 上，也共用一个 trace id。 ...

sleuth 链路跟踪随着零碎规模越来越大，微服务之间调用关系变得盘根错节，一条调用链路中可能调用多个微服务，任何一个微服务不可用都可能造整个调用过程失败 spring cloud sleuth 能够跟踪调用链路，剖析链路中每个节点的执行状况 微服务中增加 spring cloud sleuth 依赖批改以下微服务的 pom.xml，增加 sleuth 依赖 sp02-item-servicesp03-user-servicesp04-order-servicesp11-zuul编辑起步依赖，别离 sleuth 依赖 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-sleuth</artifactId></dependency>在控制台查看链路跟踪日志通过 zuul 网关，拜访 order-servicehttp://localhost:3001/order-service/112233四个微服务的控制台日志中，能够看到以下信息：[服务id,申请id,span id,是否发送到zipkin] 申请id：申请达到第一个微服务时生成一个申请id，该id在调用链路中会始终向前面的微服务传递span id：链路中每一步微服务调用，都生成一个新的id[zuul,6c24c0a7a8e7281a,6c24c0a7a8e7281a,false][order-service,6c24c0a7a8e7281a,993f53408ab7b6e3,false][item-service,6c24c0a7a8e7281a,ce0c820204dbaae1,false][user-service,6c24c0a7a8e7281a,fdd1e177f72d667b,false] sleuth + zipkin 链路剖析sleuth生成链路跟踪日志的工具 zipkin能够收集链路跟踪数据，提供可视化的链路剖析 增加 sleuth 只须要增加它的依赖，它是主动配置的增加 zipkin 客户端依赖、amqp依赖yml 增加rabbitmq的连贯信息yml配置日志发送形式：rabbitmq链路数据抽样比例默认 10% 的链路数据会被发送到 zipkin 服务。能够配置批改抽样比例 spring: sleuth: sampler: probability: 0.1zipkin 服务下载 zipkin 服务器https://github.com/openzipkin/zipkin 启动 zipkin 时，连贯到 rabbitmqjava -jar zipkin-server-2.12.9-exec.jar --zipkin.collector.rabbitmq.uri=amqp://admin:admin@192.168.64.140:5672 http://localhost:9411/zipkin 微服务增加 zipkin 起步依赖批改以下微服务 sp02-item-servicesp03-user-servicesp04-order-servicesp11-zuul<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zipkin</artifactId></dependency>如果没有配置过 spring cloud bus，还须要增加 rabbitmq 依赖和连贯信息 ...

前言???????????? 本次分享 SpringCloud Zipkin - 链路追踪。简介Zipkin：是一个开源的分布式跟踪零碎，基于 Google Dapper 的论文设计而来，由 Twitter 公司开发奉献。其次要性能是汇集来自各个异构零碎的实时监控数据，用来追踪微服务架构下的零碎延时问题。剖析解决延时，能够帮忙改良零碎性能和故障定位。利用零碎须要进行配备（instrument）以向 Zipkin 报告数据。Zipkin 的用户界面能够出现一幅关联图表，以显示有多少被追踪的申请通过了每一层利用。疾速开始下载Jar包Zipkin-下载链接 如下图，依据须要抉择对应的形式下载 Maven依赖 <!-- zipkin --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zipkin</artifactId> </dependency>application.yml配置 spring: zipkin: # zipkin - 服务端地址 base-url: http://127.0.0.1:9411 # zipkin 采样比例，0 - 1.0 sleuth: sampler: percentage: 1.0启动验证 启动Zipkin-Server java -jar zipkin-xxx.jar &启动Zipkin-Client向Zipkin-Client发送申请测试应用两个服务 Gateway、Template 通过Gateway -> Template 浏览器拜访 http://127.0.0.1:9411Zipkin-链路追踪 Zipkin-服务依赖 结束语以上就是 SpringCloud - Zipkin 的示例，对于Zipkin更多功能，可自行体验。Zipkin的更多具体介绍，官网可点击 Zipkin 自行理解。Zipkin数据长久化 STORAGE_TYPE=mysql MYSQL_USER=数据库用户名 MYSQL_PASS=数据库明码 MYSQL_HOST=数据库 URL MYSQL_TCP_PORT=数据库端口 nohup java -jar zipkin-xxx.jar &✔ END ...

https://github.com/laravelclo...Laravel Version CompatibilityLaravel 5.x.x is supported in the most recent version (composer require laravelcloud/lar-trace)Installation安装 Laravel 5.x安装laravelcloud/lar-trace包:$ composer require laravelcloud/lar-trace在 config/app.php 中做如下配置’providers’ => array( /* * Package Service Providers… */ LaravelCloud\Trace\TraceLaravel\TracingServiceProvider::class,)创建Trace的配置文件(config/trace.php)$ php artisan vendor:publish –provider=“LaravelCloud\Trace\TraceLaravel\TracingServiceProvider"添加变量至.envTRACE_ENABLED=1TRACE_ENDPOINT_URL=http://127.0.0.1:9411/api/v2/spansTRACE_RATE=1.0TRACE_SERVICE_NAME=lar-examplesTRACE_SQL_BINDINGS=falseLumen 5.x…链路追踪系统阿里云-链路追踪zipkinContributingDependencies are managed through composer:$ composer installTests can then be run via phpunit:$ vendor/bin/phpunitCommunityBug TrackerCode

主要问题 由于springboot新版本(2.1.0)、springcloud新版本(Greenwich.M1)实现链路追踪sleuth+zipkin的一些“新特性”，使得我在实现sleuth+zipkin的过程上踩了不少坑。 在springboot1.X版本的时候，实现链路追踪服务需要用户自己实现client以及server，通常在server服务端需要引入各种各样的包(spring-cloud-sleuth-stream，以及支持zipkin的一些相关依赖包等等)； 但在spring cloud新版本实现链路追踪sleuth+zipkin的方式上已经不再需要自己再去实现一个server服务端（集成sleuth+zipkin），而是由zinkin官方提供了一个现成的zipkin-server.jar，或者是一个docker镜像，用户可以下载并通过命令进行启动它，用户可以通一些配置来确定sleuth收集到信息后传输到zipkin之间采用http,还是通过rabbit/kafka的方式。在新的版本下，用户只需要关注slenth-client选用何种传输方式（http或mq（rabbit/kafka），如果选择http,则在配置中指明base-url；如果选择mq,则在配置指明相关消息中间件的相关信息host/port/username/password…），至于zipkin的信息storage问题,则由zipkin-server要负责，可以通过zipkin-server.jar 配置一些具体的参数来启动。（下面会细讲）ps:这不是教程贴，这主要是解决一些问题的一些方法，不会有详细的实现过程，但为了简明我会贴上部分代码。背景 最近开始实习了，老大让我自学一下sc(spring cloud)，学就学嘛，也不是难事。看完spring cloud的全家桶,老大说让我重点了解一下它的链路追踪服务，后期会有这方面的任务安排给我做，所以呢我就重点关注这一方面，打算自己做个demo练练手，看了网上的教程，膨胀的我选择了个最新的版本，结果发现就这么掉坑里了。。。版本按照惯例，先说下springboot跟spring cloud的版本springboot：2.1.0springcloud：Greenwich.M1个人建议新手不要过分追求新版本，旧版本的还是够用的,比springboot 2.6.0搭配sringcloud Finchley SR2还是挺稳的，如果真的要探索新版本你会发现这里面的坑实在是踩不完，基本要花个一两天才能让自己从坑里跳出去，这样频繁踩坑会让新手很容易放弃~~~ps：不要问我为什么知道。。。主要问题闲话扯完了，可以进入正题了一共四个服务eureka-serverzipkin-server：新版本的zipkin服务端，负责接受sleuth发送过来的数据，完成处理、存储、建立索引，并且提供了一个可视化的ui数据分析界面。需要的同学话可以直接在github上下载https://github.com/openzipkin…嗯就是这两个家伙下面两个是两个服务eureka-server服务注册中心，这个实现我就不讲了，网上搜一大把，各个版本实现基本都是一致的，并不存在版本更新跨度极大的情况。而且这里我把它是打包成一个jar包,在需要的时候直接用java -jar XXX.jar 直接启动至于product跟order(也即实际场景下各种种样的服务A、B、C…)order服务只有一个接口/test，去调用product的接口这里的productclient就是使用feignf去调用order的/product/list接口product只有一个接口/product/list，查找所有商品的列表简单的来说，这里的场景就是order服务–（去调用）–>product服务说完场景后，贴一下这两个服务的相关配置信息(order跟producet的配置基本上是相同的）application.ymlspring: application: #服务名 name: product #由于业务逻辑需要操作数据库，所以这里配置了mysql的一些信息 datasource: driver-class-name: com.mysql.jdbc.Driver username: root password: 123456 url: jdbc:mysql://127.0.0.1:3306/sc_sell?characterEncoding=utf-8&useSSL=false&serverTimezone=Asia/Shanghai jpa: show-sql: true #重点 zipkin: #base-url:当你设置sleuth-cli收集信息后通过http传输到zinkin-server时，需要在这里配置 base-url: http://localhost:9411 enabled: true sleuth: sampler: #收集追踪信息的比率，如果是0.1则表示只记录10%的追踪数据，如果要全部追踪，设置为1（实际场景不推荐，因为会造成不小的性能消耗） probability: 1eureka: client: service-url: #注册中心地址 defaultZone: http://localhost:8999/eureka/logging: level: #这个是设置feign的一个日志级别,key-val的形式设置 org.springframework.cloud.openfeign: debug说完配置信息，就该讲一下依赖了，很简单，client实现链路追踪只需要添加一个依赖spring-cloud-starter-zipkin。就是这个 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zipkin</artifactId> </dependency>其实这些都是基础操作，是吧，那么来点进阶的。在sleuth-cli跟zipkin-server之间插入一个消息中间件rabbitmq/kafka，这里我举例中只使用rabbitmq来实现将链路追踪的数据存储到DB上，目前zipkin暂时只支持mysql/elasticsearch,这里我使用mysql如果你是刚开始学习sc，给你去实现的话，你肯定会开始打开浏览器开始搜索教程。结果你会发现，大部分博客上都是以前版本的实现方式，一些较旧会让你自己实现一个zipkin-server（我怀疑他们的版本是1.x）,你会发现很郁闷，因为这跟你想象的不太一样啊。继续找，终于在茫茫帖子中，找到了一篇是关于springboot2.0.X版本的实现链路追踪的教程，这时候你会兴奋，终于找到靠谱一点的啊，喜出望外有木有啊，但是，事情还没完，它会让你在客户端依赖下面这个依赖包 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-sleuth-zipkin-stream</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-sleuth-stream</artifactId> </dependency>结果你会发现，你在依赖它的时候，其实是依赖不了，为什么？因为版本的问题，什么？你跟我说你的pom文件没报错啊，但是，你打开idea右边的maven插件看一下这真的是一个巨坑，我一直不明白是怎么回事，直到有一次，我打开了这个页面，花了我一天的时间去摸索是什么原因造成的集成rabbitmq失败，真的是被安排得明明白白最后，豪无头绪的我，继续在网上查找一些springboot2.x版本的一些链路追踪的教程，在搜索了一个下午，我突然想起，诶不对，我应该直接去官网看它的官方教程的啊。。。虽然都英文，大不了我用chrome自带的翻译工具翻译一下咯。结果就立马打开spring的官网，选择了最新的版本，进去找了一下，还真的让我找到了！！！不得不说官方文档的重要性！https://cloud.spring.io/sprin…

带入gRPC：分布式链路追踪 gRPC + Opentracing + Zipkin原文地址：带入gRPC：分布式链路追踪 gRPC + Opentracing + Zipkin项目地址：https://github.com/EDDYCJY/go…前言在实际应用中，你做了那么多 Server 端，写了 N 个 RPC 方法。想看看方法的指标，却无处下手？本文将通过 gRPC + Opentracing + Zipkin 搭建一个分布式链路追踪系统来实现查看整个系统的链路、性能等指标 ????Opentracing是什么OpenTracing 通过提供平台无关、厂商无关的API，使得开发人员能够方便的添加（或更换）追踪系统的实现不过 OpenTracing 并不是标准。因为 CNCF 不是官方标准机构，但是它的目标是致力为分布式追踪创建更标准的 API 和工具名词解释Trace一个 trace 代表了一个事务或者流程在（分布式）系统中的执行过程Span一个 span 代表在分布式系统中完成的单个工作单元。也包含其他 span 的 “引用”，这允许将多个 spans 组合成一个完整的 Trace每个 span 根据 OpenTracing 规范封装以下内容：操作名称开始时间和结束时间key:value span Tagskey:value span LogsSpanContextTagsSpan tags（跨度标签）可以理解为用户自定义的 Span 注释。便于查询、过滤和理解跟踪数据LogsSpan logs（跨度日志）可以记录 Span 内特定时间或事件的日志信息。主要用于捕获特定 Span 的日志信息以及应用程序本身的其他调试或信息输出SpanContextSpanContext 代表跨越进程边界，传递到子级 Span 的状态。常在追踪示意图中创建上下文时使用Baggage ItemsBaggage Items 可以理解为 trace 全局运行中额外传输的数据集合一个案例图中可以看到以下内容：执行时间的上下文服务间的层次关系服务间串行或并行调用链结合以上信息，在实际场景中我们可以通过整个系统的调用链的上下文、性能等指标信息，一下子就能够发现系统的痛点在哪儿Zipkin是什么Zipkin 是分布式追踪系统。它的作用是收集解决微服务架构中的延迟问题所需的时序数据。它管理这些数据的收集和查找Zipkin 的设计基于 Google Dapper 论文。运行docker run -d -p 9411:9411 openzipkin/zipkin其他方法安装参见：https://github.com/openzipkin…验证访问 http://127.0.0.1:9411/zipkin/ 检查 Zipkin 是否运行正常gRPC + Opentracing + Zipkin在前面的小节中，我们做了以下准备工作：了解 Opentracing 是什么搭建 Zipkin 提供分布式追踪系统的功能接下来实现 gRPC 通过 Opentracing 标准 API 对接 Zipkin，再通过 Zipkin 去查看数据目录结构新建 simple_zipkin_client、simple_zipkin_server 目录，目录结构如下：go-grpc-example├── LICENSE├── README.md├── client│ ├── …│ ├── simple_zipkin_client├── conf├── pkg├── proto├── server│ ├── …│ ├── simple_zipkin_server└── vendor安装$ go get -u github.com/openzipkin/zipkin-go-opentracing$ go get -u github.com/grpc-ecosystem/grpc-opentracing/go/otgrpcgRPCServerpackage mainimport ( “context” “log” “net” “github.com/grpc-ecosystem/go-grpc-middleware” “github.com/grpc-ecosystem/grpc-opentracing/go/otgrpc” zipkin “github.com/openzipkin/zipkin-go-opentracing” “google.golang.org/grpc” “github.com/EDDYCJY/go-grpc-example/pkg/gtls” pb “github.com/EDDYCJY/go-grpc-example/proto”)type SearchService struct{}func (s *SearchService) Search(ctx context.Context, r *pb.SearchRequest) (*pb.SearchResponse, error) { return &pb.SearchResponse{Response: r.GetRequest() + " Server"}, nil}const ( PORT = “9005” SERVICE_NAME = “simple_zipkin_server” ZIPKIN_HTTP_ENDPOINT = “http://127.0.0.1:9411/api/v1/spans” ZIPKIN_RECORDER_HOST_PORT = “127.0.0.1:9000”)func main() { collector, err := zipkin.NewHTTPCollector(ZIPKIN_HTTP_ENDPOINT) if err != nil { log.Fatalf(“zipkin.NewHTTPCollector err: %v”, err) } recorder := zipkin.NewRecorder(collector, true, ZIPKIN_RECORDER_HOST_PORT, SERVICE_NAME) tracer, err := zipkin.NewTracer( recorder, zipkin.ClientServerSameSpan(false), ) if err != nil { log.Fatalf(“zipkin.NewTracer err: %v”, err) } tlsServer := gtls.Server{ CaFile: “../../conf/ca.pem”, CertFile: “../../conf/server/server.pem”, KeyFile: “../../conf/server/server.key”, } c, err := tlsServer.GetCredentialsByCA() if err != nil { log.Fatalf(“GetTLSCredentialsByCA err: %v”, err) } opts := []grpc.ServerOption{ grpc.Creds(c), grpc_middleware.WithUnaryServerChain( otgrpc.OpenTracingServerInterceptor(tracer, otgrpc.LogPayloads()), ), } …}zipkin.NewHTTPCollector：创建一个 Zipkin HTTP 后端收集器zipkin.NewRecorder：创建一个基于 Zipkin 收集器的记录器zipkin.NewTracer：创建一个 OpenTracing 跟踪器（兼容 Zipkin Tracer）otgrpc.OpenTracingClientInterceptor：返回 grpc.UnaryServerInterceptor，不同点在于该拦截器会在 gRPC Metadata 中查找 OpenTracing SpanContext。如果找到则为该服务的 Span Context 的子节点otgrpc.LogPayloads：设置并返回 Option。作用是让 OpenTracing 在双向方向上记录应用程序的有效载荷（payload）总的来讲，就是初始化 Zipkin，其又包含收集器、记录器、跟踪器。再利用拦截器在 Server 端实现 SpanContext、Payload 的双向读取和管理Clientfunc main() { // the same as zipkin server // … conn, err := grpc.Dial(":"+PORT, grpc.WithTransportCredentials(c), grpc.WithUnaryInterceptor( otgrpc.OpenTracingClientInterceptor(tracer, otgrpc.LogPayloads()), )) …}otgrpc.OpenTracingClientInterceptor：返回 grpc.UnaryClientInterceptor。该拦截器的核心功能在于：（1）OpenTracing SpanContext 注入 gRPC Metadata （2）查看 context.Context 中的上下文关系，若存在父级 Span 则创建一个 ChildOf 引用，得到一个子 Span其他方面，与 Server 端是一致的，先初始化 Zipkin，再增加 Client 端特需的拦截器。就可以完成基础工作啦验证启动 Server.go，执行 Client.go。查看 http://127.0.0.1:9411/zipkin/ 的示意图：复杂点来，自己实践一下总结在多服务下的架构下，串行、并行、服务套服务是一个非常常见的情况，用常规的方案往往很难发现问题在哪里（成本太大）。而这种情况就是分布式追踪系统大展拳脚的机会了希望你通过本章节的介绍和学习，能够了解其概念和搭建且应用一个追踪系统 ????参考本系列示例代码go-grpc-example系列目录带入gRPC：gRPC及相关介绍带入gRPC：gRPC Client and Server带入gRPC：gRPC Streaming, Client and Server带入gRPC：TLS 证书认证带入gRPC：基于 CA 的 TLS 证书认证带入gRPC：Unary and Stream interceptor带入gRPC：让你的服务同时提供 HTTP 接口带入gRPC：对 RPC 方法做自定义认证带入gRPC：gRPC Deadlines带入gRPC：分布式链路追踪 gRPC+Opentracing+Zipkin资料opentracingzipkin ...