企业如何从 0 到 1 构建整套全链路追踪体系
简介:本文将分享 ARMS 在全链路追踪领域的最佳实践,分享主要分为四部分。首先,是对分布式链路追踪的整体简介。其次,是对 ARMS 在分布式链路追踪领域的核心能力进行介绍。然后,介绍如何从 0 到 1 构建整套全链路追踪体系。最后,介绍一些最佳实践案例。
作者 | 涯海&白玙
今天,我来跟大家分享 ARMS 在全链路追踪领域的最佳实践,分享主要分为四部分。首先,是对分布式链路追踪的整体简介。其次,是对 ARMS 在分布式链路追踪领域的核心能力进行介绍。然后,介绍如何从 0 到 1 构建整套全链路追踪体系。最后,介绍一些最佳实践案例。
什么是分布式链路追踪
首先,什么是分布式链路追踪。我对分布式链路追踪的理解就是跟踪请求在分布式系统中的流转路径与状态,从而协助开发人员能够进行故障诊断、容量评估、性能瓶颈分析等工作。
我们可以看到典型的链路轨迹追踪例子:比如用户通过手机做了一个下单动作,这个请求会通过移动端来到网关,再到应用层,比如说有交易、下单、支付等等一系列的应用,然后中间也会穿插到去调用云基础设施,这样用户的行为轨迹是能够被清晰还原出来的。
对于链路追踪来说也是一样的,我们可以把链路数据进行一个统计,然后去看每一个应用或接口的状态,或者去梳理它们之间的强弱依赖。那么,什么样的系统更加需要链路追踪呢?当微服务架构拆分的越精细,服务间依赖越复杂的系统,就更加的需要链路追踪技术,比较典型的就是电商这种。
接下来再看一下链路追踪的应用场景,我对它做了一个初步分级。
再往上,可以对链路数据去做预聚合或后聚合统计的分析,去看整个链路在概率分布上的一些信息,比如说整个服务维度的监控数据,上下游整体的依赖,这是第二级——聚合分析。
第三等级,就是除了调用链数据本身具备的这些链路数据之外,还可以更进一步发挥关联性作用,把一些间接的业务数据,包括容器或者 JVM 的一些指标信息或者是一些变更的日志事件,也能够通过调用链紧密的关联在一起,形成多维数据关联和分析,最终来实现我们根因定位的能力。
再往后有点像自动驾驶,有了这么多数据,能不能够自动发现其中一些问题?可以结合领域专家经验和恰当的算法,来实现整个诊断流程自动化或者半自动化。
最后一步就是诊断问题的最终目标--保障系统稳定。能不能够把问题诊断和系统恢复两个事关联在一起?从而实现整个系统的故障自愈,进一步提升稳定性。这个就需要与管控系统去融合。目前开源 Tracing 系统大概是在 L1 到 L3 的等级。ARMS 我们那边沉淀了很多领域专家经验以及算法可以做到 L4 等级,ARMS 再加上一些应用托管服务进行自动流控降级、弹性扩缩容,把监控和管控系统结合在一起,从而实现故障自愈能力。
接下来我们再看看链路追踪的发展趋势。在 2010 年,随着谷歌论文发表,拉开了整个链路追踪的技术序幕,很多厂商都纷纷实现了自己的链路追踪技术。当然,在谷歌之前也有很多其他探索,但谷歌给了后续实现者比较完整的理论基础。同时,通过自身实践,证明了链路追踪的企业级价值,这是开山鼻祖式的奠基。
ARMS 的链路追踪到底具备哪些能力
接下来,我们看一下 ARMS 的链路追踪到底具备哪些能力。首先,我把 ARMS 的能力抽象为四个点:
- 解决接入难的问题。比如说企业有很多不同类型应用,不同语言的应用。除了前端后关联,服务端也有很多如 Java 、Go 等应用。ARMS可以更有效地去完成这些应用的追踪接入。
- 解决诊断难的问题。ARMS 可以提供各种各样的,比如说日志和 Trace 的全息排查,或者是线程剖析这种深度的诊断的能力来帮助你去定位根因。
- 解决运维难的问题。在大规模场景下,链路的探针管理、升级都是比较困难的事情,包括服务端的稳定性托管, ARMS 可以提供稳定可靠的全托管、免运维能力。
- 解决成本高的问题。ARMS 作为云上产品可以按需按量地来使用。随着业务爆发式增长,只需要按量地去付费就可以,也不需要一开始就购买一大批机器或投入比较大人力。
首先就是接入难, ARMS 目前提供了 Java 无侵入的探针技术方式,如果你是 Java 应用就可以很快地接入 ARMS。比如说通过一个 -javaagent 的命令,或者是在 ACK 容器服务环境下,通过一个 Annotation 就可以很快地接入。如果是非Java语言,也可以利用开源 SDK 通过修改 Endpoint 快速地接入到 ARMS,从而实现全链路追踪,基本上相当于是开箱即用的。
其次,诊断难。在生产环境去诊断问题时,有时不仅仅需要调用链,还需要很多其他的数据一起结合。比如说发现某个应用接口或者是业务出现问题,根据各种各样条件来去筛选出想要的调用链,通过调用链来去追溯上下游,看看问题大概瓶颈点在哪里。如果这个时候出现了比较慢的一些情况,就是接口粒度还不足以定位问题的时候,我们可以通过 ARMS 的线程剖析功能,自动地帮你把慢调用本地完整的方法栈能够获取下来,能够实现代码级定位。如果是业务上出错了,还可以跟业务日志进行关联绑定,能够看到每次调用,每笔请求关联背后业务的行为和日志是什么样的。如果前面这四步仍然不足以去定位根因,还可以结合内存快照或是线程池分析,常见的就是数据库连接打满,或者是线程池打满等。
解决完诊断难,接下来就是运维难的问题。越是体量越大的公司,这个问题会越严重。ARMS 作为阿里鹰眼的升级,在双十一场景下结合多年验证与优化,沉淀了大量经验,比如说我们的 Agent 是会经过多轮、各种级别的灰度验证,保证我们客户端侧稳定。服务端也会支持比如说多可用区容灾或者是全链路端的 SLO 体系建设,还有包括我们多级的客户支持和 Oncall 应急值班,这些都是可以直接享受到这样的服务,而不需要重新的去建设这样的体系。
第四点就是大家比较关心的成本问题,ARMS 除了自身按需存储之外,还通过冷热数据分离和精准采样方案,进一步降低用户成本。
当然,在做链路采样时就无可避免的会遇到指标数据不准的情况。ARMS 通过在客户端完成预聚合,来保证链路数据无论怎么去采样,即使千分之一,但依旧保证指标数据精准性。
这里做个简单对比,如果采用开源方案,最起码需要存储以及流计算处理服务器建设,这种 ES 和 ECS 的成本大概 200 元/天。但如果直接使用 ARMS 的按量付费,每天大概只需要十几块钱。每 GB 成本可能只要 1 毛 9 不到 2 毛钱,远远低于开源自建成本。
如何从 0 到 1 建设追踪体系
介绍完产品核心能力之后,来讲讲如何从 0 到 1 建设追踪体系。
第一步,完成整个应用的全链条全链路的上下文透传,从端侧设备开始到后端,然后网关或者是应用等等。这里面的话其实就涉及到异构语言的数据打通和前后端的透传,这一套方案 ARMS 是都已实现了。
第二步,正如刚才所讲,数据打通之后,需要去进行精准采样和冷热存储分离。但是对于使用者来说,需要去定义我们尾部采样策略,比如说默认的除了错慢全采之外,有没有需要根据业务特征进行采样,或者是按需的去调整数据存储周期。
第三步,就是需要去自定义监控大盘,就除了 ARMS 提供的默认大盘之外,你还可以基于 Grafana,把业务数据、应用数据,甚至容器数据放在一起,来去定制统一监控大盘。比如说双 11 大促,或日常线上应急场景,都可以去快速地浏览整个业务线的表现,能够快速地定位到问题的大致范围。
第四步,当建立监控之外,还需要有一个比较有效的告警机制,因为大家平时也不太会去一直盯着监控或者是 Trace 控制台,肯定需要有应急入口,告警其实就是我们运维的第一入口。在这里介绍三个比较典型的告警实践。
比如说公司或者是团队在刚起步或新产品刚上线的时候,很多东西都是比较缺失的。这个时候,我们可以通过 ARMS 的告警模板能力,把比较通用的应用、容器、中间件的告警能力能够快速地构建出来,解决从 0 到 1 的问题。
当团队或者是公司一步步成长起来,数据会越来越多,系统会越来越多。等到膨胀到一定程度时,告警可能分散在多个系统之中。这个时候又会带来效率问题,就可以使用 ARMS 的告警能力,把多个告警源的数据放在一起去分析,甚至可以去做组合过滤规则。比如,当流量突然激增,性能后端的耗时变高,CPU 打满的时候,发出建议扩容或是建议降级的告警通知。
当企业进一步地发展,发展得很好,团队越来越多,人员越来越多。这个时候,可能一个系统会有很多个团队来共同的去协作运维,我们不仅仅需要解决数据爆炸问题,还需要解决人员协同的问题。这个时候就可以基于 ARMS 的 ChatOps 能力来解决应急协同问题。
第五步,即使前面都做了之后,还有很多公司有建设自己专属平台的意愿,因为可能大家已经有了比较好的可观测或监控报警方面的经验以及场景沉淀,只需扩充部分这样的能力,是完全可以基于 ARMS 这种开放数据的能力。无论是通过外部页面的嵌入,还是 Open API 建设,或是直接把存储开放出来,进行批量数据分析,都可以更好地完成二次开发。
最佳实践
最后,我们来介绍常见实践案例。比如,调用链通常聚合成一个应用维度的拓扑,或者是服务维度的拓扑,但这个时候往往还不够,还可能会更关注某特定场景。
第二部分,ARMS Agent 除了做可观测数据之外,同时也具备安全数据、安全行为检测与保护的能力,面对最近比较火的 Log4j2 高危核弹级漏洞,基于 RASP 技术就可以有很好的自我防护能力。即使不改代码,也可以通过动态配置的方式,完成安全防护。除了安全防护之外,RASP 也可以提供攻击溯源或者漏洞定位分析等等能力,相比于传统的防火墙式保护会更有效一些。因为它跟 IDC 防火墙的区别,有点像我们戴口罩和打疫苗这样的一个区别。
最后,给出了一些 ARMS 相对于开源做的更好的最佳实践。比如说接口偶发性超时的时候,接口级的调用链,还不足以诊断更新,我们需要完整的方法栈,但是那个问题现场已经过去了,怎么能够自动帮你保存下来呢?那就是可以通过 ARMS 线程剖析自动诊断的这样的一个能力。
以上就是今天我们对链路追踪整体的介绍,也涉及到我们对整个全链路追踪的一些最佳的实践,感谢大家!
本文为阿里云原创内容,未经允许不得转载。