分布式追踪系统应用调研

本文主要是介绍分布式追踪系统应用调研，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

分布式追踪系统应用调研(Doing...) 部门：运维技术部 时间：2021年6月8号 作者：敦岳
文章有引用部分内容未找到具体的作者所以未标注作者，请见谅   一、序言 业务不断的增加，模块的不断拆分，系统间业务调用就变得越复杂，对定位线上故障带来很大困难。整个调用链不透明，犹如系统被蒙上一块黑纱，当线上遇到故障时，整个技术部就陷入痛苦的漩涡。一次请求往往需要涉及到多个服务，因此服务性能监控和排查就变得更复杂，这时候分布式追踪系统应运而生，如揭开了黑纱，让阳光照进黑暗。   二、调研主题 APM的原理、流行部署架构、部署方案、系统已有的问题点和风险点把控 三、原理简介 1、APM（应用性能管理）与Dapper原理介绍 什么是APM APM (Application Performance Management) 即应用性能管理（应用性能监控） APM主要是针对企业 关键业务的IT应用性能和用户体验的监测、优化，提高企业IT应用的可靠性和质量。 旨在确保最终用户获得高质量的体验，降低IT总拥有成本（TCO) TCO （Total Cost of Ownership ），即总拥有成本，包括产品采购到后期使用、维护的成本。 这是一种公司经常采用的技术评价标准。 APM介绍 目前市面的系统基本都是参考 Google 的 Dapper（大规模分布式系统的跟踪系统）来做的。 跟踪业务请求的处理过程，完成对应用系统在前后端处理、服务端调用的性能消耗跟踪，提供可视化的界面来展示对跟踪数据的分析。 通过汇聚业务系统各处理环节的实时数据，分析业务系统各事务处理的交易路径和处理时间，实现对应用的全链路性能监测。 APM工具与传统的性能监控工具的区别在于，不仅仅提供一些零散的资源监控点和指标，其主要关注在系统内部执行、系统间调用的性能瓶颈分析，这样更有利于定位到问题的具体原因。 APM致力于检测和诊断应用性能问题，从而能提供应用预期的服务水平。 APM三大特征

1. 多级应用性能监控：覆盖通讯协议1-7层，通过事务处理过程监控、模拟等手段实现端到端应用监测。
2. 应用性能故障快速定位：对应用系统各个组件进行监测，迅速定位系统故障，并进行修复或提出修复建议。
3. 应用性能全面优化：精确分析各组件占用系统资源的情况，并根据应用系统性能要求给出专家建议。

APM的发展历程 目前APM的发展主要经历了前面的三个阶段： 第一阶段：以网络监控基础设施为主，主要监控主机 的CPU 使用率、I/O、内存资源、网速等，主要以各类网络管理系统（NMS）和各种系统监控工具为代表。 第二阶段：以监控各种基础组件为主，随着互联网的快速发展，为了降低应用开发难度，各种基础组件（如数据库、中间件等）开始大量涌现，所以这个时期应用性能管理主要是监控和管理各种基础组件的性能。 第三阶段：以监控应用本身的性能为主, IT 运维管理的复杂度开始出现爆炸性的增长，应用性能管理的重点也开始聚焦于应用本身的性能与管理上。 第四节阶段属于正在发展的阶段： 云计算方兴未艾，而DevOps以及微服务的兴起对传统APM产生了很大的冲击，传统厂商也在做一些革新，也做一些微服务方面的尝试和云计算方面的尝试。 随着Machine Learning、AI的技术的兴起，对定位故障、定位问题，也会起到一些帮助，基于大数据的分析的手段也会有一些帮助，目前市场上正在初步尝试阶段。 2016年Gartner对APM的定义分为三个维度

1. DEM-Digital experience monitoring：数字体验监控，浏览器及移动设备用户体验监控及利用主动拨测的实现的业务可用性及性能监控。
2. ADTD-Application discovery, tracing and diagnostics：应用自动发现、追踪和故障诊断，自动发现应用之间的逻辑关系，自动建模、应用组件的深入监控及性能关联分析。
3. AA-Application analytics：应用分析，通过机器学习，进行针对JAVA及.NET等应用的根源分析。

DevOps DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。 DevOps可以简洁的理解为“开发团队与运营团队之间更具协作性、更高效的关系”。 是两个相关趋势碰撞中出现的新术语 更多信息见：https://zh.wikipedia.org/wiki/DevOps APM 的核心思想 在应用服务各节点相互调用的时候，从中记录并传递一个应用级别的标记，这个标记可以用来关联各个服务节点之间的关系。 比如两个应用服务节点之间使用 HTTP 作为传输协议的话，那么这些标记就会被加入到 HTTP 头中。 可见如何传递这些标记是与应用服务节点之间使用的通讯协议有关的，常用的协议就相对容易加入这些内容，一些按需定制的可能就相对困难些，这一点也直接决定了实现分布式追踪系统的难度。 为什么要使用APM 随着公司业务的与日俱增，各个系统也越来越复杂，服务间的调用，服务的依赖，以及分析服务的性能问题也越棘手，因此引入服务追踪系统尤为重要。 现有的APM，基本都是参考Google的Dapper的体系来做的。通过跟踪请求的处理过程，来对应用系统在前后端处理、服务端调用的性能消耗进行跟踪（每个请求的完整调用链路，收集调用链路上每个服务的性能数据），方便工程师能够快速定位问题。 好的APM应满足的条件 总的来说，一个优秀的APM系统应该满足以下五个条件

1. 低消耗，高效率：被跟踪的系统为跟踪所付出的系统资源代价要尽量小，现在主流的APM对于系统资源的消耗在2.5%-5%左右，但是这个数值应该越小越好，因为在大规模的分布式系统下，一个单节点的资源是无法把控的，可能是超强配置，也可能是老爷机，只跑几个小服务，但是本身性能已经十分吃紧了，如果这时候跟踪应用再一跑，很可能这个节点就挂掉了，得不偿失。
2. 低侵入性，足够透明：作为跟踪系统，侵入性是不可能不存在的，关键这种侵入性要在哪个层面，如何在越底层的层面上侵入，对于开发者的感知和需要配合跟踪系统的工作就越少，如果在代码层面就需要进行侵入，那对于本身业务就比较复杂的应用来说，代码就更加冗余复杂了，也不利于开发者快节奏的开发。
3. 灵活的延展性：不能随着微服务和集群规模的扩大而使分布式跟踪系统瘫痪，要能够充分考虑到未来分布式服务的规模，跟踪系统至少要在未来几年内完全吃得消。
4. 跟踪
5. 数据可视化
6. 和迅速反馈：要有可视化的监控界面，从跟踪数据收集、处理到结果的展现尽量做到快速，就可以对系统的异常状况作出快速的反应
7. 持续的监控： 要求分布式跟踪系统必须是7x24小时工作的，否则将难以定位到系统偶尔抖动的行为

  2、Dapper原理介绍 原理论文：https://bigbully.github.io/Dapper-translation/   四、调研目标     五、调研结论 目前市面上流行的接入方案： 1、jaeger+ES方式完全免费方式 官方学习文档：Getting Started   弊端： 在原生的Jaeger系统中，主要存在以下问题 系统不支持、高频率Span的实时接入和存储(Jaeger client/agent是分布式的，但是Jaeger collector是存在接入能力瓶颈的)，系统的缺乏健壮性，Jaeger Collector的失败会导致trace数据的丢失，系统无法跟踪经由kafka结偶的微服务系统之间的调用关系。   jaeger基础 a、基本介绍 jaeger的开发语言是golang jaeger支持OpenTracing协议，同属于CNCF基金会 jaeger支持各种各样的客户端，包括Go、Java、Node、Python、C++等 jaeger支持udp协议传输，当然也支持http jaeger的官网是 http://www.jaegertracing.io/ OpenTracing的官网是https://opentracing.io/ 官方文档：https://www.jaegertracing.io/docs/ github地址： https://github.com/jaegertracing/jaeger     b、能够解决的问题 分布式事务监控 性能分析与性能优化 调用链，找到根源问题 服务依赖分析 特性介绍：

• 分布式上下文传递

• 分布式事务监控

• 根本原因分析

• 服务依赖分析

• 性能、延迟优化

  架构 jaeger具有两种架构： 第一种：直接将数据写入存储       第二种：使用Kafka作为缓冲   通过对以上两图的观察，我们可以得知jaeger架构主要包括以下组件： jaeger-client：嵌入在应用程序里面，负责span的创建以及上报 jaeger-agent：每个物理机部署一个，负责收集client上报的span，然后转发给collector jaeger-collector：接收agent发来的span，写入后端存储 jaeger-query：提供rest接口，负责从存储中拉取trace信息供UI查询 jaeger-ui：展示trace和服务依赖图   c、安装和部署 安装包的下载地址：http://https://github.com/jaegertracing/jaeger/releases 安装包含五个二进制文件：

1. jaeger-agent
2. jaeger-collector
3. jaeger-query
4. jaeger-standalone
5. jaeger-ingester

Trace数据总要存在一个地方，jaeger支持ES（Elasticsearch）和Canssandra两种后端DB。国内用ES的多一点，我们就以ES为例，来介绍其安装方式(ES集群部署请参照： ES-集群安装和配置 )     端口整理 jaeger提供的各种端口来访问jaeger的服务 jaeger-agent 5775 UDP协议，接收兼容zipkin的协议数据 6831 UDP协议，接收兼容jaeger的兼容协议 6832 UDP协议，接收jaeger的二进制协议 5778 HTTP协议，数据量大不建议使用 它们之间的传输协议都是基于thrift封装的。我们默认使用5775作为传输端口   jaeger-collector 14267 tcp agent发送jaeger.thrift格式数据 14250 tcp agent发送proto格式数据（背后gRPC) 14268 http 直接接受客户端数据 14269 http 健康检查   jaeger-query 16686 http jaeger的前端，放给用户的接口 16687 http 健康检查       d、简单安装测试方案如下： 测试机器：10.6.178.85 jaeger程序端启动方式：

• 1、启动collector

export SPAN_STORAGE_TYPE=elasticsearch nohup ./jaeger-collector --es.server-urls http://10.21.42.90:9200/ --log-level=debug > collector.log 2>&1 &  

• 2、启动agent

export SPAN_STORAGE_TYPE=elasticsearch nohup ./jaeger-agent --reporter.grpc.host-port=10.6.178.85:14250 --log-level=debug > agent.log 2>&1 &    

• 3、启动query

export SPAN_STORAGE_TYPE=elasticsearch nohup ./jaeger-query --span-storage.type=elasticsearch --es.server-urls=http://10.21.42.90:9200/ > query.log 2>&1 &    

• 4、官方自带测试例子部署运行：

./example-hotrod frontend -p 8084 ./example-hotrod customer ./example-hotrod driver ./example-hotrod route     Example data模拟测试具体流程 frontend 服务接收 /dispatch 进行请求分发 frontend 调用服务 custom（/customer），custom 服务通过 mysql 获取消费者信息 frontend 调用服务 driver，rpc 调用（ findNearest）从 redis 找到距离消费者最近的 10 个车辆 frontend 并行调用服务 route，route 服务 /route 计算各个车辆到消费者的路径。这里并行可以通过打开信息流图可以发现每次 3 个一组，据此可以估计线程池大小为 3  

• 5、jaeger前端UI

测试地址： http://test-gaeger.ops.shabi.com/search（http://10.6.178.85/16686）  

• 6、测试数据触发生产测试数据

测试数据生产工具：http://test-hotrod.ops.shabi.com (http://10.6.178.85/8084)  

• 7、ES测试数据查询

http://elk.ops.tools.shabi.com/app/discover#/?_g=(filters:!(),refreshInterval:(pause:!t,value:0),time:(from:now-15m,to:now))&_a=(columns:!(_source),filters:!(),index:'01352080-c9b3-11eb-8306-9f8aaff1fc34',interval:auto,query:(language:kuery,query:''),sort:!())   8、测试结果           小结：准备工作完毕，有了一个server接收数据，调用链的主要工作就在于客户端开发   2、Apm+ES接入（部分高级功能收费） 使用 Elasticsearch 进行应用程序性能监测 (APM) | Elastic   开源测试方案： apm-application启动方式： java -javaagent:./elastic-apm-agent-1.24.0.jar \ -Delastic.apm.service_name=sample_apm \ -Delastic.apm.server_url=http://192.168.49.192:8200 \ -Delastic.apm.secret_token= \ -Delastic.apm.application_packages=accessing-data-mysql \ -jar accessing-data-mysql-0.0.1-SNAPSHOT.jar     开源测试权限创建 grant all on . to 'springuser'@'127.0.0.1' identified by 'ThePassword';flush privileges; grant all on . to 'springuser'@'localhost' identified by 'ThePassword';flush privileges;       3、ARMS阿里云收费服务 应用实时监控服务ARMS（Application Real-Time Monitoring Service）是一款应用性能管理（APM）产品，包含应用监控、Prometheus监控和前端监控三大子产品，涵盖分布式应用、容器环境、浏览器、小程序、APP等领域的性能管理，能帮助您实现全栈式性能监控和端到端全链路追踪诊断，让应用运维从未如此轻松高效。 官方文档：https://help.aliyun.com/product/34364.html     4、腾讯客户端性能分析QAPM 腾讯客户端性能分析（QAPM ）是一款全方位定位检测 App 应用性能的 SDK，其简单易用并能提供多维度检测及分析，只需简单的调用几个接口，就能对 App 进行全方位的性能检测 官方文档：https://cloud.tencent.com/document/product/683/15202   特性： 卡慢优化 在 App 的功能基本成型后，各种卡顿、慢、假死的用户投诉，就浮上水面了。腾讯的某些组件，优化到比操作系统 API 更快。QAPM 不仅能定位主线程上的直接原因，还更重视 IO、SQLite、内存、GC/页错误、流量等根本原因，促进性能全面优化。   闪退优化 App 闪退，若发现以内存不足（Out of memory ）为主因时，开发团队通常不知从何处下手优化。QAPM 提供了内存触顶分析能力，以复用内存、零泄漏为目标，解决它们。 电量优化 当用户投诉手机发烫，耗电太多时，QAPM 能定位常见的耗电代码，例如，长时点亮屏幕等动作；同时，QAPM 还将分析 CPU、IO、GC 等维度的开销，既能解决体     5、听云apm收费服务 为服务端应用和服务提供代码级的实时性能和业务监控帮助您随时掌握业务的健康状况，快速定位故障和瓶颈优化代码和服务效率，保障系统和业务稳定性，提升用户体验和业务表现 官网地址：https://www.tingyun.com/tingyun_apm.html         参考文献： APM（应用性能管理）与Dapper原理介绍简介：https://cloud.tencent.com/developer/article/1777355 Dapper大规模分布式系统的跟踪系统：https://bigbully.github.io/Dapper-translation/ Docker部署jaeger参考文档：https://jckling.github.io/2021/05/10/Jaeger/Jaeger%20+%20Elasticsearch%20+%20Kibana/

这篇关于分布式追踪系统应用调研的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！