1、zipkin
zipkin是Twitter的一个开源项目,它基于Google Dapper实现。我们可以使用它来收集各个服务器上请求链路的跟踪数据,并通过它提供的REST API接口来辅助我们查询跟踪数据以实现对分布式系统的监控程序,从而及时地发现系统中出现的延迟升高问题并找出系统性能瓶颈的根源。除了面向开发的API接口之外,它也提供了方便的UI组件来帮助我们直观的搜索跟踪信息和分析请求链路明细,比如:可以查询某段时间内各用户请求的处理时间等。
zipkin的架构图如下:
由上面的架构图可以看出,zipkin有四个核心组件:
2、构建zipkin-server
目前最新版的zipkin-server,是直接到官网获取最新可执行的jar,然后直接运行该jar文件,例如:
curl -sSL https://zipkin.io/quickstart.sh | bash -s java -jar zipkin.jar
也可以用docker启动,在此通过docker来启动zipkin-server服务。
由于在此存储组件使用Elasticsearch,所以先通过docker将Elasticsearch启动,执行如下命令:
docker run -d -p 9200:9200 --name es elasticsearch:6.6.0
如果在启动elasticsearch的时候出现如下错误:
[1]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]
可以先执行如下命令解决:
sysctl -w vm.max_map_count=262144
接下来,启动zipkin-server服务,执行如下命令:
docker run -d -e STORAGE_TYPE=elasticsearch -e ES_HOSTS=192.168.208.134:9200 -p 9411:9411 --name zipkin openzipkin/zipkin:2.12.1
通过浏览器打开http://192.168.208.134:9411页面,如果出现如下界面,则表示zipkin-server服务启动成功了:
3、微服务集成zipkin
在原来微服务的pom文件中,添加如下的依赖:
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-sleuth</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zipkin</artifactId> </dependency>
然后在application.yml文件需要新增如下配置:
spring: zipkin: base-url: http://192.168.208.134:9411 sleuth: sampler: percentage: 1
其中spring.sleuth.sampler.percentage表示收集跟踪信息的比例,1表示全部收集,它的值的范围是0-1之间的。
4、部署zipkin-dependencies
由于新版本当中,如果需要查看各个微服务之间的依赖关系,则必需要部署zipkin-dependencies,此处还是通过docker来部署,由于zipkin-dependencies运行一次就会结束,所以可以让其每小时运行一次,即:
docker run -e STORAGE_TYPE=elasticsearch -e ES_HOSTS=192.168.208.134:9200 openzipkin/zipkin-dependencies:2.0.4 sh -c 'crond -f'
5、参考资料
zipkin.io/
https://github.com/openzipkin/docker-zipkin
https://github.com/openzipkin/docker-zipkin-dependencies
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持小牛知识库。
当我将单体应用拆成多个微服务之后,如何监控服务之间的依赖关系和调用链,以判断应用在哪个服务环节出了问题,哪些地方可以优化?这就需要用到分布式追踪(Distributed Tracing)。 CNCF 提出了分布式追踪的标准 OpenTracing,它提供用厂商中立的 API,并提供 Go、Java、JavaScript、Python、Ruby、PHP、Objective-C、C++ 和 C# 这九
Zipkin跟踪演示使用Zipkin作为跟踪服务端,提供跟踪Envoy请求记录展示的功能。这个沙箱与上面描述的前端代理架构非常类似,但有一点不同:在响应返回之前,service1对service2进行API调用。这三个容器将被部署在名为envoymesh的虚拟网络中。 所有的请求都经过前端Envoy进行路由,该Envoy充当位于envoymesh网络边缘的反向代理。端口80通过docker com
本章介绍如何使用Zipkin或Jaeger收集启用了Istio的应用程序的调用链信息。 完成本章后,你可以理解有关应用程序的所有假设以及如何使其参与跟踪,无论您使用何种语言/框架/平台构建应用程序。 BookInfo示例用来作为此任务的示例应用程序。 环境准备 参照安装指南的说明安装Istio。 如果您在安装过程中未启动Zipkin或Jaeger插件,则可以运行以下命令启动: 启动Zipkin:
随着服务的数量和复杂性的增加,跨数据中心的统一的可观察性变得越来越重要。Linkerd 的跟踪和度量工具旨在汇总,为所有服务的健康提供广泛而细致的洞察。Linkerd 作为服务网格的角色使其成为可观察性信息的理想数据源,特别是在多语言环境中。 当请求通过多个服务时,使用传统的调试技术来识别性能瓶颈变得越来越困难。分布式跟踪提供通过多个服务的请求的整体视图,允许立即识别延迟问题。 使用 linker
本文向大家介绍Spring Cloud Zipkin服务端追踪服务,包括了Spring Cloud Zipkin服务端追踪服务的使用技巧和注意事项,需要的朋友参考一下 Zipkin 简介 ZipKin 是一个开放源代码的分布式跟踪系统,用于收集服务的定时数据,以解决微服务架构中的延迟问题。包括数据的收集、存储、查找和展现。 每个服务向 Zipkin 报告计时数据,Zipkin 会根据调用关系通过
我最近将我的项目从spring boot 1.4.1、spring cloud Sleuth 1.1.0、spring cloud Zipkin 1.1.0升级到spring boot 1.5.3、spring cloud Sleuth 1.2.0、spring cloud Zipkin 1.2.0。 在最新版本的spring cloud Sleuth中,他们添加了“错误”标签,一旦出现任何异常,