揭秘分布式追踪：提升应用性能
分布式追踪简介
在当今的技术时代，随着服务操作变得更加分布式，DevOps团队对其应用堆栈的可见性变得更加困难。这使得了解与性能相关的问题的全部程度以及它们如何影响整个基础设施变得更加复杂。例如，“响应时间”和“外部调用”等性能指标告诉我们系统中可能存在问题，但并未明确指出具体问题所在。
由于现代应用采用广泛分布的微服务方法来管理其IT运营，DevOps团队经常面临在最终用户受到影响之前跟踪、隔离和调试性能问题的困难。最好的办法是找出问题所在的子系统，然后深入挖掘。然而，这种方法要求开发人员投入大量时间和精力，这些资源本可用于生产和部署工作。
这就是分布式追踪发挥作用的地方。通过插装，IT和DevOps团队可以追踪请求的从开始到结束的全过程，并关联分布式数据，以确定应用性能难以发挥的确切位置。
什么是分布式追踪？
分布式追踪是一种监控技术，用于了解请求在应用堆栈中的行程。通过使用唯一标识符标签，分布式追踪捕获请求通过的每个操作的性能信息，帮助开发人员区分分布式系统内的操作以及每个服务的执行时间。分布式追踪还映射应用堆栈中不同操作之间的关系，绘制出整个追踪过程的可视化图，有助于更轻松地调试。
为什么需要分布式追踪？
在单体架构中，全局视图通常足以获得应用可观测性，因为整个系统作为一个整体运作，所有操作均为本地执行，任何时刻都执行可追踪数量的函数。在这种情况下，传统追踪足以完成任务，因为请求在单一系统中流动，所有组件都耦合在一起。
然而，基于微服务架构构建的应用拥有庞大的服务网络，这些服务相互连接以完成不同操作。这种方式被IT管理团队广泛采用，因为它提供了灵活且易于扩展的应用环境。由于小型开发团队可以管理每项服务，微服务架构允许他们为各个操作实施新的技术栈，并使用定义良好的API确保无缝通信。此外，团队还能在不干扰其他服务运行的情况下测试和部署更新。
微服务环境确保了组件之间的独立性，防止系统完全崩溃。相反，问题仅限于单个操作，能够轻松隔离和调试，无需造成大规模影响。但这也引出了一个问题：如何隔离此类问题。
尽管微服务架构带来了诸多优势，但其定制和灵活性亦存在缺点。原因如下：
例如，一个请求可能通过连接于不同应用环境中的各种服务流转；每项服务可能处理多个操作任务。因此，每当发生事务时，一个请求可能会依次调用多个服务。如果其中一个服务响应缓慢，后续操作也会受到影响，速度变慢。这一连串事件集体增加了该事务或事件的整体响应时间，使IT管理员难以确定问题的起源。
通过分布式追踪，DevOps团队可以可视化服务间的交互和关系，从而获得关于应用堆栈性能问题的详细信息。一旦确定了处理时间过长的具体服务，相关IT团队便能迅速得到通知，轻松定位故障，调试问题，并优化IT基础设施，以实现更高效的微服务协作。
但这并不意味着单体应用不会从分布式追踪中获益。单体结构也可能需要分布式追踪来提升调试速度和质量。
分布式追踪中的术语：
- Span（跨度）： Span表示单个服务执行其预定操作所需的时间，该操作可以是服务器响应、HTTP请求、API调用或数据库查询等。当请求通过每个服务时，会生成一个span，最早的称为“父span”，其后的为“子span”。这意味着每个span除了第一个操作外，都有一个父span。
- Trace（追踪）： Trace表示请求从始至终所执行的整个操作。它是请求经过的所有服务所花费时间的总和。本质上，trace是一个或多个span的集合。trace从用户与应用交互开始直到请求被处理完毕为止。
- Trace ID： 每个请求都被分配一个唯一标识符，称为trace ID。trace ID伴随请求传递，以便映射请求的完整流程，了解服务间的交互。
- Span ID： Span ID 分配给每个span操作。
- 父span与子span： span通常用来理解请求通过时不同服务之间的依赖关系。父span表示前一个服务操作，而子span代表后续服务操作。每个父span的持续时间取决于其对应的子span。当某个子span执行时间过长时，所有前置span的时间也会同时增加。这种方法有助于准确定位瓶颈所在。
分布式追踪如何工作？
为了理解分布式追踪的工作原理，假设用户正在尝试登录其账户的web应用：
当用户尝试登录时，从web应用前端生成HTTP请求，该请求穿过一系列服务，从数据库服务器检索数据。假设HTTP请求需经历一系列动作以完成整个过程，其HTTP请求流程为： 前端 → service-1 → service-2 → service-3 → 数据库服务器，之后返回。
假设发现web应用用户在将产品添加至购物车时等待时间过长。这类情况肯定会使终端用户感到沮丧，可能会中断购买过程，对业务运营和收益造成巨大影响。检查时，开发人员只能获知整个交易的响应时间，却无法掌握所涉及服务的操作效率。
此时，可以利用分布式追踪收集请求流经的每个步骤数据。通过分析分布式追踪数据，DevOps团队能够直观识别出占用大量响应时间并导致整体响应时间增加的特定服务。
基于上述场景，分布式追踪通过为请求分配Trace ID，使其在服务和数据库服务器间流转。每个服务的span根据其接收请求并完成请求所用时间计算。
例如，span D代表HTTP请求由service-3接收服务器的瞬间。span C从请求发送到数据库服务器开始，到收到响应结束。相似地，span B在service-2收到HTTP响应时结束，span A在service-1收到HTTP响应时结束。在此场景中，A是子span B的父span，B又是C的父span，依此类推。
当检测到某交易响应时间突然升高时，IT管理员可以追踪各span。查看各span后会发现，span A到C的响应时间都偏高，而span D无异常。因C为最底层子span，排查该节点问题通常可解决问题，因为父span仅为依赖。这种问题可能由多种原因引起，如流量激增、使用高峰、错误、作业重叠等。
如何用Applications Manager执行分布式追踪？
如果整个操作执行时间过长，通常会使用执行分布式追踪的系统来收集各服务的重要性能指标。使用像Applications Manager这样的应用性能监控工具，您可以执行分布式追踪，获得每个span的可视化细分，找出性能瓶颈。
只需几个简单步骤，即可轻松 下载Applications Manager 并在系统中进行配置。在仪表盘面板中，您可以为运行Java、node js、.Net、Ruby on rails、Python、PHP或.Net core的web应用创建新监控。一旦配置好应用监控，执行分布式追踪变得轻而易举。
Applications Manager设有专用的“APM”面板，集中管理所有应用监控。通过导航各应用监控，以下是使用Applications Manager执行分布式追踪的方法：
- 访问应用监控的“概览”标签。仪表盘整体展示事务的性能表现。
- 您可以看到列出“前5个表现最慢追踪”的条形图。
- 要执行分布式追踪，可选择表现不佳的事务。这将带您进入一个全新的追踪分析世界，详细分解调用、请求或查询所经历的步骤。
- 每个span根据组件类型上色，方便管理员区分和排查。
- 分布式追踪选项提供瀑布流视图，所有追踪顺序列出。开发者和IT管理员可自上而下跟踪各span，直至定位性能滞后点。
- 每个追踪均显示对应的响应时间。
- Applications Manager的分布式追踪工具还支持展开和折叠下拉菜单，便于查看导致性能问题的追踪区域。
- 为加快故障排查，Applications Manager设有切换按钮。激活后，工具会立刻高亮显示疑似性能瓶颈的追踪，帮助您快速跳转至慢速追踪部分。
当应用监控遇上分布式追踪：
拥有内置分布式追踪功能的 应用性能监控工具具备如下优势： 更快的故障排查
- 团队能够全面查看事务追踪步骤，更容易识别故障组件。开发人员无需逐条日志排查、耗费数小时调试，而是即时获得需关注区域通知，直接着手处理。这显著缩短了MTTR，降低系统停机时间。例如，若添加购物车环节出现问题，分布式追踪可帮助定位后台性能瓶颈。 通过团队协作提升生产力
- 微服务通常由不同团队管理，分布式追踪帮助识别需关注的服务模块。当某团队在其请求流程中遇到问题时，可准确通知负责相关性能瓶颈的团队，共同协助解决。 灵活性
- 将分布式追踪纳入应用管理策略，有助于组织根据需要轻松扩展。这使他们可以放心地扩展微服务环境，引入新的服务操作，因为有分布式追踪作为后盾。了解更多关于 微服务监控 提升终端用户体验!
- 终端用户在使用web应用时遇到操作困难，多数情况下问题来自单一服务操作，导致整个流程变慢，影响应用用户满意度（APDEX评分）。分布式追踪可帮助快速定位问题，避免数字体验受损。 通过分布式追踪领先竞争对手
随着更多web应用采用微服务架构，分布式可视化变得必不可少。借助分布式追踪，IT和DevOps团队能够识别、优化和排查问题，确保应用堆栈内的服务稳定运行。这为他们提供了对性能优化做出明智决策的信心，并加快问题处理速度。
总之，分布式追踪是插装工具应具备的核心功能之一，以全面了解应用堆栈内的相互依赖关系。Applications Manager便是将分布式追踪与
应用性能监控 结合的工具，企业可有效利用该工具确保业务应用满足终端用户预期。 想监控您的应用和IT基础设施？
立即开始，
下载我们的30天免费试用版 体验我们监控解决方案的所有功能，或 安排个性化演示 进行指导式体验。 Angeline，
