简介：本文将分享ARMS在全链路追溯领域的最佳实践。分享主要分为四个部分。首先，对分布式链路追踪进行整体介绍。其次介绍了ARMS在分布式链路跟踪领域的核心能力。然后，介绍如何从0到1搭建一个完整的全链路跟踪系统。最后，介绍一些最佳实践案例。作者|YaHai&BaiYu今天给大家分享一下ARMS在全链路追踪领域的最佳实践。分享主要分为四个部分。首先，对分布式链路追踪进行整体介绍。其次介绍了ARMS在分布式链路跟踪领域的核心能力。然后，介绍如何从0到1搭建一个完整的全链路跟踪系统。最后，介绍一些最佳实践案例。什么是分布式链接跟踪首先，什么是分布式链接跟踪。我对分布式链路跟踪的理解是跟踪分布式系统中请求的流向和状态，从而辅助开发者进行故障诊断、容量评估、性能瓶颈分析等。我们可以看到一个典型的链路轨迹追踪的例子：比如用户通过手机进行下单动作，请求会通过手机端到网关，再到应用层，比如交易，订单、支付等一系列应用会穿插调用云基础设施，从而清晰还原用户的行为轨迹。为了更方便的理??解这个概念，我们可以将链路跟踪与物流跟踪进行比较。在发快递物流时，每个快递包裹都会被分配一个唯一的快递单号，这是系统请求的全球唯一的TraceId。使用快递单号查询快递经过哪些站点，是否有延误或漏件。那么，TraceId也可以用来查询各个系统之间请求的流向和状态。除了查询快递订单外，还可以对整个物流状态进行站点聚合统计，查看每个站点的吞吐量，优化物流效率。链接跟踪也是如此。我们可以对链路数据进行统计，然后查看各个应用或接口的状态，或者梳理出它们之间的强弱依赖关系。那么，什么样的系统更需要链路追踪呢？当微服务架构拆分得越细，越复杂的系统依赖服务时，就越需要链接跟踪技术，这在电商中很典型。接下来，让我们将链接跟踪视为可观察的三元组之一，即Traces、Metrics和Logs。它最大的价值在于实现了除了机器和时间维度之外的用户行为的确定性关联。怎么理解这件事？也就是在Tracing之前，比如通过指标或者日志，只能根据数据在同一台机器上，在同一时间点来判断他们应该在一起。但这只是弱关联，并不是强关联。调用链会明确说明这个请求是数据，也就是来到了这个节点，这个信息一定是准确的。通过这种确定性的关联，除了关联业务应用接口层面的数据，还可以给一些业务打上标签，比如来自什么渠道，订单金额等等。直接和间接的数据都关联起来，发挥1+1>N的价值。接下来，我们来看看链接跟踪的应用场景。我对它做了一个初步的分类。从下到上，最基础的一层是通过调用链还原单个请求的轨迹状态，这是最基础的应用。更进一步，可以对链路数据做聚合前或者聚合后的统计分析，看整个链路的概率分布的一些信息，比如整个服务维度的监控数据，整体依赖上游和下游。第二层次——聚合分析。第三层是除了调用链数据本身所拥有的链路数据之外，还可以起到进一步的关联作用，包括一些间接的业务数据，包括一些容器或者JVM的指标信息或者一些变化的日志事件，并且可以也通过调用链紧密相连，形成多维度的数据关联分析，最终实现我们定位根因的能力。前进有点像自动驾驶。这么多数据，能不能自动发现其中的一些问题呢？通过结合领域专家的经验和适当的算法，整个诊断过程可以自动化或半自动化。最后一步是诊断问题的最终目的——确保系统稳定。你能把问题诊断和系统恢复这两个东西联系起来吗？这样可以实现整个系统的故障自愈，进一步提高稳定性。这需要与管理和控制系统集成。目前的开源溯源系统大概是L1到L3级别。ARMS我们积累了大量的领域专家经验和算法可以达到L4级别，ARMS加上一些应用托管服务实现流控自动降级，弹性伸缩，结合监控系统实现故障自动修复能力。接下来，让我们看看链接跟踪的发展趋势。2010年，随着谷歌论文的发表，拉开了整个链接跟踪的技术序幕，许多厂商都实现了自己的链接跟踪技术。当然在Google之前还有很多其他的探索，但是Google给了后来的实现者一个比较完整的理论基础。同时，通过自身的实践证明了链路跟踪的企业级价值，这也是鼻祖立足之本。2016年因为各厂商都实现了自己的链路追踪，这个标准一直没有统一，给上云上云带来了很多问题。因此，开源社区发起了OpenTracing项目，定义了较为完整、标准的链路通用规范，同时也开发了类似Jaeger的符合OpenTracing规范的开源实现。2019年大家认为可观察性在逐渐向融合发展。仅仅追踪是不够的。Tracing需要关联指标和日志。OpenTracing的定义比较狭窄，不能满足可观察性的需要。于是在2019年，就是OpenTeleMetry，然后提出了这样一个开源项目。OpenTracing和OpenCensus的整合可以致力于解决Logs、Traces、Metrics的有机统一。ARMS链接跟踪有哪些功能？接下来我们就来看看ARMS链路追踪都有哪些能力。首先，我将ARMS的能力抽象为四点：解决接入难的问题。例如，一个企业有很多不同类型的应用程序和不同语言的应用程序。除了前后端链接，服务端还有很多Java、Go等应用。ARMS可以更有效的完成对这些应用的跟踪接入。解决诊断难的问题。ARMS可以提供各种全息调查，例如日志和跟踪，或者深入分析线程的能力，以帮助您定位根本原因。解决运维难的问题。在大规模场景下，linkprobe的管理和升级都比较困难，包括服务器的稳定托管。ARMS可以提供??稳定可靠的全托管和免运维能力。解决成本高的问题。ARMS作为云端产品，可以按需、批量使用。随着业务的爆发式增长，您只需按量付费，无需一开始就购买大量机器或投入大量人力。下面就这四个方面一一介绍：一是准入难。ARMS目前提供Java非侵入式探测技术。如果你是Java应用，可以快速接入ARMS。比如通过一个-javaagent命令，或者在ACK容器服务环境下，可以通过一个Annotation快速访问。如果是非Java语言，也可以使用开源SDK通过修改Endpoint快速接入ARMS，实现全链路追踪，基本等同于开箱即用。我们对语言组件的覆盖比较全，主流组件基本都支持。同时，ARMS完全兼容开源的OpenTracing、OpenTelemetry等各种开源格式。如果已经连接，迁移到ARMS也很方便。二是诊断困难。在生产环境诊断问题时，有时不仅需要调用链，还需要大量其他数据。比如你发现某个应用接口或者业务有问题，你可以根据各种条件筛选出想要的调用链，通过调用链向上下游追溯，看问题很可能是哪里的瓶颈.如果此时出现一些慢的情况，也就是接口粒度不够定位问题的时候，我们可以利用ARMS的线程分析功能，自动帮你在本地获取到慢调用的完整方法栈，以及实现代码级定位。如果有业务错误，也可以关联业务日志，可以看到每次调用、每个请求背后业务的行为和日志有什么关联。如果前面四步还不足以定位到根本原因，还可以结合内存快照或者线程池分析。一般是数据库连接满了，或者线程池满了。除了以上一套帮助团队完成定位的诊断能力，ARMS还可以通过自动诊断能力解决常见问题。比如我们经常会遇到一些数据库MySQL的问题。数据库MySQL的原因有很多。批次等。面对这些常见原因，ARMS可以自动诊断。解决了诊断难点，接下来就是运维难点。公司越大，这个问题就越严重。ARMS作为阿里鹰眼的升级版，结合多年在双十一场景的验证和优化，积累了大量的经验。比如我们的Agent会经过多轮的各级灰度验证来保证我们客户端的稳定性。.服务器也会支持，比如多可用区容灾或者全链路端SLO系统的建设，还有我们的多级客服和oncall应急值班，可以直接享受这样的服务，不需要重建这样一个系统。在大多数场景下，除了稳定性之外，在海量数据场景下，经常会遇到查询性能问题。当数据达到每天数百TB时，数据存储和数据查询的索引可能会失效，无法满足业务需求。ARMS积累了多种性能加速方案。比如最基本能做到的就是租户地理隔离。其次，数据可以通过应用程序进行路由和存储。如果应用层面不够，可以继续使用数据的一些特定特征，比如TraceId或者其他特征进一步分散，提高并发查询的效率。第四点就是大家比较关心的成本问题。除了自身的按需存储，ARMS还采用数据冷热分离和精准采样的方案，进一步降低用户成本。比如我们可以存储热数据，比如30分钟内，我们会频繁查询数据，我们可以存储在热存储中，满足全量分析的需要。30分钟后的数据被持久化，比如15天，30天。这个时候你可以只存储错误、慢或者某些业务特征（比如VIP用户的一些链接），这样整个存储成本会比较低，查询体验也会保持。当然在做链接采样的时候难免会遇到不准确的指标数据。ARMS在客户端完成预聚合，保证无论链路数据如何采样，即使是千分之一，依然保证指标数据的准确性。这是一个简单的比较。如果采用开源方案，至少需要搭建存储和流计算处理服务器。这样的ES和ECS的成本大概是200元/天。但是如果直接用ARMS现收现付的话，一天也就十几块钱左右。每GB的成本可能不到10毛钱，不到20毛钱，远低于开源自建的成本。值得一提的是，ARMS已进入GartnerAPM象限，也是中国唯一一家云厂商。Gartner对ARMSAPM的评价是在中国影响力最强。对于开源集成也非常好，在成本上有很大的优势。如何从0到1搭建一个追踪系统介绍完产品的核心能力，我们再来说说如何从0到1搭建一个追踪系统。我们大概需要完成这四个步骤：第一步是完成上下文整个应用的全链条透明传输，从端侧设备开始到后端，再到网关或应用等。这里的话其实涉及到异构语言的数据连接和前后端的透传。这套方案已经被ARMS实现了。第二步，完成客户端的全链路埋入后，我们的数据会上报，我们将面临存储和计算成本。最好的方式是能够按需存储数据，只存储有价值的数据。数据以降低成本。第三步，数据入库后，必须进行查询，才能充分发挥其价值。这时候遇到的问题是数据的格式不统一。能不能把指标数据都转成Prometheus之类的格式，让指标数据的格式比较统一。Traces能否支持这种OpenTelemetry格式？，然后日志支持此方案的Loki。如果在进入第4步之前，数据格式保持与开源一致，将更容易释放价值。除了产品提供的预设仪表板外，还可以灵活定制用户画像。当然你也可以根据用户的使用习惯做一些自定义的控制台。同理，报警也是一样的。我们可以使用PromQL来制作灵活的自定义警报。同时我们也支持将数据路由到用户名下的一些存储，比如SLS下，这样你想做一些二次分析这些都可以支持批量分析。这是我们从0到1构建链接跟踪系统的大致步骤。接下来，逐个查看每个步骤。第一步是完成异构应用的全链路跟踪，比如前端或者整个透传格式，或者需要采用统一的格式，比如我们可以选择统一的Jaeger格式来透传我们的protocol首先是我们的前端接入，比如我们可以使用CDN或者NPM这两种低代码的接入方式，可以支持外部小程序等各种场景。如果我们的后端是JAVA的话，会优先使用ARMSAgent来完成这样一段代码的无入侵访问。并且在JAVA的应用上，我们会提供很多边缘诊断、无损统计等高级能力。对于非JAVA，比如我们可以通过开源的Agent和SDK进行访问，然后上报给我们的Endpoint，当然ARMS也兼容SkyWalking的协议格式。第二步，刚才说了，数据打通后，要进行精准的采样，冷热分离。但是对于用户来说，有必要定义我们的尾部采样策略。例如，除了默认的全量采样外，是否需要根据业务特点进行采样，或者根据需要调整数据存储周期。第三步，自定义监控仪表板。除了ARMS默认提供的dashboard，您还可以基于Grafana，结合业务数据、应用数据甚至容器数据，自定义统一的监控dashboard。比如双11大促，或者日常线上突发事件，可以快速浏览整个业务线的表现，快速定位问题的大致范围。第四步，除了建立监控外，还需要更有效的告警机制，因为人通常不会一直盯着监控或Trace控制台，必须要有一个应急入口。告警其实就是我们的运维。第一个入口。这里介绍三种典型的警告做法。比如，一个公司或团队刚刚起步，或者一个新产品上线的时候，很多东西都缺失了。这时候我们可以借助ARMS的告警模板能力，快速构建更多通用应用、容器、中间件的告警能力，解决从0到1的问题。当一个团队或者一个公司一步步成长起来的时候，就会有越来越多的数据和越来越多的系统。当通货膨胀达到一定水平时，警报可能分散在多个系统中。这时候又会带来效率问题。您可以利用ARMS的告警能力，将多个告警源的数据一起分析，甚至进行组合过滤规则。例如，当流量突然暴增，后台耗时变高，CPU被充分利用时，会发出扩容或降级的告警通知。当企业发展的更远，发展的好，团队会越来越多，人员也会越来越多。这时候，一个系统可能会有很多团队来协作运维。我们不仅需要解决数据爆炸的问题，还需要解决人员协同的问题。这时，可以基于ARMS的ChatOps能力解决应急协调问题。第五步，即使以上都做了，还是有很多公司愿意搭建自己的专属平台，因为可能大家在可观察性或者监控报警方面已经有很好的经验，还有场景积累，只需要扩展一些这些平台。该能力完全基于ARMS等开放数据的能力。无论是通过嵌入外部页面，还是构建OpenAPI，还是直接开放存储进行批量数据分析，都可以更好的完成二次开发。最佳实践最后，我们来看一些常见的实践案例。比如调用链通常聚合成一个应用维度的拓扑或者服务维度的拓扑，但是这个时间往往是不够的，可能更关注一个特定的场景。下订单的情况也是如此。有时仅仅关注整体秩序是不够的。您可能还需要关注新渠道或新在线类别。我们可能需要看一下某个线下零售渠道，它的下单链接是什么样的。或者对于一个新的品类，需要将这部分业务场景单独分离出来进行链接染色，从而实现这部分具体业务场景的应用和依赖排序。这是通过非侵入式商业染色实现的。第二部分，ARMSAgent不仅做可观察数据，还具备检测和保护安全数据和安全行为的能力。面对最近流行的Log4j2高危核弹级漏洞，基于RASP技术，可以有很好的自我防护能力。即使不更改代码，也可以通过动态配置完成安全保护。除了安全防护，RASP还可以提供攻击溯源或漏洞定位分析等能力，比传统的防火墙防护更有效。因为它和IDC防火墙的区别有点像戴口罩和打疫苗的区别。第三个场景是在容器场景下实现全景监控。你可以把来自Prometheus或Loki或eBPF、APM等的端到端数据放在一起，通过2D和3D拓扑展示整个过程和端到端链路的下端。分析。同时，我们也提供定期巡检，或根据专家经验和算法自动诊断和报告问题。这是我们容器场景下全景监控的最佳实践。第四种场景，部分架构复杂的用户多云、跨云部署；出于数据安全考虑，他们也可能会去自建机房进行混合云部署。为了解决前后端、多语言、跨云部署等问题，ARMS全链路追踪帮助用户完成复杂场景下的全链路追踪挑战，将各种场景中的链路连接在一起，最大化释放链接跟踪价值。第五部分是ARMS近期推出了TraceExplore功能，除了传统的调用链查询和应用服务统计监控之外，还提供了实时采集分析能力。举个简单的例子，我们经常需要在超过三秒的请求上查看分配了哪些接口或IP，以便处理慢速接口，或者单机故障诊断。这个时候我们在预聚合的时候，肯定没有办法在超过三秒或者某个特定的过滤条件等于某个东西的场景下做一个预统计。这时候，我们就需要一个灵活的聚合后分析能力。这是TraceExplorer可以提供的值。除了我们刚才说的单机慢界面之外，如果结合我们的业务指标，比如说我们把我们的一些用户的等级也输入到我们的Attributes里面，对吧？我们可以根据不同的用户级别分析它的一些流量情况，以及它的一些响应延迟，这样用低代码完成这样的自定义分析会更方便。当然这里也是灰度监控。例如，如果我们在重启前将当前版本注入环境变量，我们可以看到不同版本之间的流量和性能变化。最后给出一些ARMS比开源做得更好的最佳实践。比如接口偶尔超时，接口级的调用链不够诊断和更新。我们需要一个完整的方法栈，但是问题的场景已经过去了，怎么自动给你保存呢？也就是这样一种能力，可以通过ARMS线程分析自动诊断。当我们的微服务或者数据库的性能值满了的时候，这个时候可能所有的请求都会变慢，但是你很难直观的体现在调用链上，因为这种资源问题很难通过链接记录下来。这时候ARMS提供的池监控可以直接分析出每类线程的当前情况，并配置告警。另外，比如你要分析一些内存泄漏问题，或者一些在线运行代码与本地行为不一致的问题，可以使用白屏内存诊断，或者在线调试比如ArthasAbility来帮忙您可以快速找到根本原因。以上就是我们今天对链接跟踪的整体介绍，同时也涉及到我们对整个全链接跟踪的一些最佳实践。谢谢你！原文链接本文为阿里云原创内容，未经许可不得转载。
