滨州 网站建设,网站建设 模板,成都园林设计公司推荐,齐鲁建设网站简介#xff1a;本文将分享 ARMS 在全链路追踪领域的最佳实践#xff0c;分享主要分为四部分。首先#xff0c;是对分布式链路追踪的整体简介。其次#xff0c;是对 ARMS 在分布式链路追踪领域的核心能力进行介绍。然后#xff0c;介绍如何从 0 到 1 构建整套全链路追踪体…简介本文将分享 ARMS 在全链路追踪领域的最佳实践分享主要分为四部分。首先是对分布式链路追踪的整体简介。其次是对 ARMS 在分布式链路追踪领域的核心能力进行介绍。然后介绍如何从 0 到 1 构建整套全链路追踪体系。最后介绍一些最佳实践案例。
作者 | 涯海白玙
今天我来跟大家分享 ARMS 在全链路追踪领域的最佳实践分享主要分为四部分。首先是对分布式链路追踪的整体简介。其次是对 ARMS 在分布式链路追踪领域的核心能力进行介绍。然后介绍如何从 0 到 1 构建整套全链路追踪体系。最后介绍一些最佳实践案例。
什么是分布式链路追踪
首先什么是分布式链路追踪。我对分布式链路追踪的理解就是跟踪请求在分布式系统中的流转路径与状态从而协助开发人员能够进行故障诊断、容量评估、性能瓶颈分析等工作。
我们可以看到典型的链路轨迹追踪例子比如用户通过手机做了一个下单动作这个请求会通过移动端来到网关再到应用层比如说有交易、下单、支付等等一系列的应用然后中间也会穿插到去调用云基础设施这样用户的行为轨迹是能够被清晰还原出来的。 为了更方便的理解这个概念我们可以把链路追踪和物流追踪做对比。在发送快递物流时每个快递包裹都会赋予一个唯一的快递单号对于系统请求来说就是全局唯一的 TraceId。通过快递单号来查询快递途径哪些站点是否有延迟或丢件情况。那么也同样可以通过 TraceId 来查询请求在每个系统之间的流转路径和状态。除了快递订单查询之外还可以把整个物流状态按照站点去进行汇总统计来看每个站点吞吐从而进行物流提效的优化工作。
对于链路追踪来说也是一样的我们可以把链路数据进行一个统计然后去看每一个应用或接口的状态或者去梳理它们之间的强弱依赖。那么什么样的系统更加需要链路追踪呢当微服务架构拆分的越精细服务间依赖越复杂的系统就更加的需要链路追踪技术比较典型的就是电商这种。 接下来我们看一下链路追踪作为可观测的三元组之一就是 Traces、Metrics 和 Logs。其最大价值就是实现了除机器和时间维度之外的用户行为的确定性关联。怎么理解这个事情呢就是在没有 Tracing 之前比如说通过指标或者日志只能根据数据在同一台机器上并且在同一个时间点判断它们应该是在一起的。但这只是弱关联并不是强关联。而调用链会很明确说明这个请求就是这个数据就是来到了这个节点这个信息是一定准确的。通过这种确定性的关联除了可以将服务应用接口层面的数据关联起来之外还可以通过打标上下文传递的方式把一些业务的标签比如说来自于什么渠道、订单金额等这种直接、间接的数据都关联起来发挥 11N 的价值。
接下来再看一下链路追踪的应用场景我对它做了一个初步分级。 从下往上看最基础级就是通过调用链来还原单次请求的轨迹状态这是最基本的应用。
再往上可以对链路数据去做预聚合或后聚合统计的分析去看整个链路在概率分布上的一些信息比如说整个服务维度的监控数据上下游整体的依赖这是第二级——聚合分析。
第三等级就是除了调用链数据本身具备的这些链路数据之外还可以更进一步发挥关联性作用把一些间接的业务数据包括容器或者 JVM 的一些指标信息或者是一些变更的日志事件也能够通过调用链紧密的关联在一起形成多维数据关联和分析最终来实现我们根因定位的能力。
再往后有点像自动驾驶有了这么多数据能不能够自动发现其中一些问题可以结合领域专家经验和恰当的算法来实现整个诊断流程自动化或者半自动化。
最后一步就是诊断问题的最终目标--保障系统稳定。能不能够把问题诊断和系统恢复两个事关联在一起从而实现整个系统的故障自愈进一步提升稳定性。这个就需要与管控系统去融合。目前开源 Tracing 系统大概是在 L1 到 L3 的等级。ARMS 我们那边沉淀了很多领域专家经验以及算法可以做到 L4 等级ARMS 再加上一些应用托管服务进行自动流控降级、弹性扩缩容把监控和管控系统结合在一起从而实现故障自愈能力。
接下来我们再看看链路追踪的发展趋势。在 2010 年随着谷歌论文发表拉开了整个链路追踪的技术序幕很多厂商都纷纷实现了自己的链路追踪技术。当然在谷歌之前也有很多其他探索但谷歌给了后续实现者比较完整的理论基础。同时通过自身实践证明了链路追踪的企业级价值这是开山鼻祖式的奠基。 到了 2016 年因为之前大家厂商纷纷实现自己的链路追踪这个标准没有统一就为迁云、上云带来很多问题。因此开源社区发起了 OpenTracing 项目定义了相对比较完善标准的链路的通用规范也发展出了类似 Jaeger 这种符合 OpenTracing 规范的开源实现。到了2019年大家考虑到可观测逐渐向一体化发展光有 Tracing 也不够需要把Tracing和指标和日志能够关联在一起OpenTracing 定义就相对比较狭隘不能满足可观测的需求。所以在 2019 年就是 OpenTeleMetry然后提出了这样的一个开源项目。将 OpenTracing 和 OpenCensus 进行了融合能够致力于去解决 Logs 和 Traces、Metrics 三者有机统一。
ARMS 的链路追踪到底具备哪些能力
接下来我们看一下 ARMS 的链路追踪到底具备哪些能力。首先我把 ARMS 的能力抽象为四个点
解决接入难的问题。比如说企业有很多不同类型应用不同语言的应用。除了前端后关联服务端也有很多如 Java 、Go 等应用。ARMS可以更有效地去完成这些应用的追踪接入。解决诊断难的问题。ARMS 可以提供各种各样的比如说日志和 Trace 的全息排查或者是线程剖析这种深度的诊断的能力来帮助你去定位根因。解决运维难的问题。在大规模场景下链路的探针管理、升级都是比较困难的事情包括服务端的稳定性托管 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 成本可能只要 1 毛 9 不到 2 毛钱远远低于开源自建成本。 值得一提的就是ARMS 进入 Gartner APM 象限也是国内唯一的云厂商Gartner 对 ARMS 的 APM 评价是中国影响力最强对开源集成性也非常好成本也是非常大优势。
如何从 0 到 1 建设追踪体系
介绍完产品核心能力之后来讲讲如何从 0 到 1 建设追踪体系。 我们大概可能需要完成这样 4 步
第一步完成整个应用的全链条全链路的上下文透传从端侧设备开始到后端然后网关或者是应用等等。这里面的话其实就涉及到异构语言的数据打通和前后端的透传这一套方案 ARMS 是都已实现了。 第二步完成了客户端的这种全链路埋点之后我们数据要上报上来就会面临存储和计算的成本最好的方式就是说能够按需去存储数据只存有价值的数据来降低成本。 第三步就是数据存储下来之后肯定还要通过查询再发挥它的价值。这时候遇到的问题就是数据之间的格式不统一能不能把所有的指标数据转化成一个比方说 Prometheus的这种格式这样指标数据格式相对统一了Traces 能不能支持这种 OpenTelemetry 的格式然后是日志支持 Loki 这种方案。 如果数据格式跟开源保持统一再去做第 4 步释放价值就会比较容易。除了产品提供的预置大盘之外还可以灵活自定义用户档案。当然还可以按照用户的使用习惯也可以做一些自定义的控制台。同样道理告警也是一样的我们可以去用 PromQL 做一个灵活的自定义的告警同时我们也支持把数据路由到用户名下的一些存储比如说 SLS 下面这样你想去做一些二次的批量的分析这些都可以支持。这就是我们从 0 到 1 去建设链路追踪体系的大概步骤。 接下来每个步骤都单独来看。第一步就是要完成异构应用的全链路的追踪比如说前端或者说整个透传的格式或需要采用统一格式比如说我们可以选择统一的 Jaeger 格式来透传来我们的协议头我们前端接入比如说我们可以采用 CDN 或者 NPM 两种的这种低代码的接入方式可以支持外部小程序等各种各样的场景我们后端如果是 JAVA 的话就会优先推进使用 ARMS Agent 来完成无侵入的这样的一个代码的接入。并且在 JAVA 的应用上面我们会提供很多比如说边缘诊断、无损统计的这样一些高阶的能力非 JAVA 的话就可以比方说我们可以通过开源的 Agent 和 SDK 来接入然后并且上报到我们的 Endpoint 上面当然 ARMS 也在去兼容 SkyWalking 的协议格式。
第二步正如刚才所讲数据打通之后需要去进行精准采样和冷热存储分离。但是对于使用者来说需要去定义我们尾部采样策略比如说默认的除了错慢全采之外有没有需要根据业务特征进行采样或者是按需的去调整数据存储周期。
第三步就是需要去自定义监控大盘就除了 ARMS 提供的默认大盘之外你还可以基于 Grafana把业务数据、应用数据甚至容器数据放在一起来去定制统一监控大盘。比如说双 11 大促或日常线上应急场景都可以去快速地浏览整个业务线的表现能够快速地定位到问题的大致范围。
第四步当建立监控之外还需要有一个比较有效的告警机制因为大家平时也不太会去一直盯着监控或者是 Trace 控制台肯定需要有应急入口告警其实就是我们运维的第一入口。在这里介绍三个比较典型的告警实践。
比如说公司或者是团队在刚起步或新产品刚上线的时候很多东西都是比较缺失的。这个时候我们可以通过 ARMS 的告警模板能力把比较通用的应用、容器、中间件的告警能力能够快速地构建出来解决从 0 到 1 的问题。
当团队或者是公司一步步成长起来数据会越来越多系统会越来越多。等到膨胀到一定程度时告警可能分散在多个系统之中。这个时候又会带来效率问题就可以使用 ARMS 的告警能力把多个告警源的数据放在一起去分析甚至可以去做组合过滤规则。比如当流量突然激增性能后端的耗时变高CPU 打满的时候发出建议扩容或是建议降级的告警通知。
当企业进一步地发展发展得很好团队越来越多人员越来越多。这个时候可能一个系统会有很多个团队来共同的去协作运维我们不仅仅需要解决数据爆炸问题还需要解决人员协同的问题。这个时候就可以基于 ARMS 的 ChatOps 能力来解决应急协同问题。
第五步即使前面都做了之后还有很多公司有建设自己专属平台的意愿因为可能大家已经有了比较好的可观测或监控报警方面的经验以及场景沉淀只需扩充部分这样的能力是完全可以基于 ARMS 这种开放数据的能力。无论是通过外部页面的嵌入还是 Open API 建设或是直接把存储开放出来进行批量数据分析都可以更好地完成二次开发。
最佳实践
最后我们来介绍常见实践案例。比如调用链通常聚合成一个应用维度的拓扑或者是服务维度的拓扑但这个时候往往还不够还可能会更关注某特定场景。 同样是下单场景有时候关注整体的下单还不够可能还需要关注某个新渠道或新上线品类。我们可能需要看某个线下零售的渠道它的下单链路情况是怎么样的。或者是某个新品类需要把这一部分业务场景单独剥离出来去做链路染色从而能够实现这一部分特定业务场景的应用和依赖的梳理。这个就是通过无侵入的业务染色实现的。
第二部分ARMS Agent 除了做可观测数据之外同时也具备安全数据、安全行为检测与保护的能力面对最近比较火的 Log4j2 高危核弹级漏洞基于 RASP 技术就可以有很好的自我防护能力。即使不改代码也可以通过动态配置的方式完成安全防护。除了安全防护之外RASP 也可以提供攻击溯源或者漏洞定位分析等等能力相比于传统的防火墙式保护会更有效一些。因为它跟 IDC 防火墙的区别有点像我们戴口罩和打疫苗这样的一个区别。 第三个场景在容器场景下实现全景监控可以把来自于 Prometheus 或者 Loki 或者 eBPF、APM 等端到端数据放在一起通过 2D、3D 拓扑进行全程展示和端到端链路的下端分析。同时我们还提供定期巡检或是基于专家经验和算法的问题自动诊断和上报这个就是我们在容器场景下的一个全景监控的最佳实践。 第四个场景一些架构比较复杂的用户具备多云以及跨云部署出于数据安全考虑也可能会去自建机房进行混合云部署。为了解决前后端、多语言、跨云部署的问题ARMS 的全链路追踪帮助用户完成复杂场景的全链路追踪挑战把各种场景的链路串联在一起最大化去释放链路跟踪价值。 第五部分就是说 ARMS 最近新上线了 Trace Explore 功能相对于传统调用链查询和应用服务统计、监控之外还提供实时获取和分析能力。举个简单例子我们经常要看耗时大于三秒的请求分布在哪些接口或者是哪些 IP 上面从而进行慢接口的处理或单机故障排查诊断。这个时候我们在预聚合的时候肯定没办法把耗时大于三秒或者是某一个特定的过滤条件等于什么的场景之下去做一个预先统计。这个时候我们就需要一个灵活的后聚合分析的能力。这个就是 Trace Explorer 能够提供这样的一个价值。除了我们刚刚说的这种单机慢接口之外如果我们再结合我们的业务指标比如说我们把我们的一些用户的等级也打到我们的 Attributes 里面对吧我们就可以去按不同的用户等级来去分析它的一些流量的情况它响应的一些时延就能够更方便的低代码的去完成这样的一个自定义的分析。当然这里还举了一个灰度监控如果我们在重启之前比方说我们在环境变量里面注入我们当前的版本我们就可以看到不同版本之间一个流量和性能的变化。 最后给出了一些 ARMS 相对于开源做的更好的最佳实践。比如说接口偶发性超时的时候接口级的调用链还不足以诊断更新我们需要完整的方法栈但是那个问题现场已经过去了怎么能够自动帮你保存下来呢那就是可以通过 ARMS 线程剖析自动诊断的这样的一个能力。 当我们微服务或者是数据库的性能值打满时这个时候可能所有的请求都会变慢但是你在调用链上也很难直观的去反映出来因为这种资源类的问题是很难通过链路去记录下来的。这个时候 ARMS 提供的这种池化监控能够直接分析每一类线程当前情况并配置告警。除此之外比如说你想分析一些内存泄漏的问题或者是一些线上运行代码和本地行为不一致的问题都可以通过白屏化的内存诊断或者是 Arthas 这种在线调试的这样的一个能力帮你快速的去定位你的根因。
以上就是今天我们对链路追踪整体的介绍也涉及到我们对整个全链路追踪的一些最佳的实践感谢大家
原文链接
本文为阿里云原创内容未经允许不得转载。
