ARMS:端到端全链路,应用可观测再进化
内容介绍:
一、端到端全链路应用可观测再进化
二、企业级监控能力与智能化运维
三、架构升级与智能助手应用
四、智能化数据关联提升问题排查效率
五、应用可观测体系的构建与优化
六、客户案例
本次分享的主题是ARMS作为一款应用实时监控的产品,在做应用运维的时候,或多或少都接触过,甚至也在生产环境中使用过,端到端全链路应用可观测再进化。
两位同事已经分享了两非常重磅的两产品,第一是云监控2.0作为云原生的全站智能化可观测统一,一站式的数据处理和分析平台,最近的进展是 SLS 。本次分享的是 ARMS 最新的产品动态和未来眼镜的思考。
一、端到端全链路应用可观测再进化
所谓的端到端全链路,其实是从用户侧实际使用的终端应用,比如手机端的 app,PC 段的应用,以及后端不同方技术站实现的后端服务,提供覆盖全链路的应用可观测方案。此图是来自于Open Telemetry官方Demo的应用架构图,从此图可以看到应用架构相对来说是比较复杂的,相信在实际的业务当中业务应用的架构可能比此还复杂。这张图既有前端,也有网关,然后再到后端服务,并且后端服务是以不同语言实现的各种各样的服务。如此一相对比较复杂的应用,交由运维,我要保证它的稳定性的时候。这样的操作还是有点棘手的,会有不少的一些挑战。
在日常运维当中,可观测性是必不可少的一环,如何构建一非常有效,高效的可观测体系,但还是有不少的诉求。
比如在选型上方面,应用架构涉及到网关前端还有后端,如何使用一套可观测平台接入,而不是前端一套,后端一套,相信在数据割分散时,在日常问题排查时肯定会遇到此问题,所以需要多平台反复排查。
第二问题是应用调用关系复杂,如何在出现线上问题的时候,能够快速的去定界也是很大的问题。特别是线上问题出现了故障可能直接带来的品牌影响和资损。
第三是在大模型流行的情况下,然后再包括在可观测领域,话题也提了很多年。在大模型AI加持的情况下,有没有一字的辉夜,有没有一非常好的落地场景,能够真正意义上的解决。
所以从事例上分享,从运维视角上分享面对越来越复杂的应用架构,并且越来越高用户体验的要求。必然是希望有一更好的可观测方案去解决实际的业务问题,带来实际的价值提升。也可以从刚才的事例当中提取几非常典型的点。
第一点是希望完整的可观测平台,把方方面面的可观测数据全部采集。是需要全量接入一道客观车系统带来的直接业务效果必然是建设成本急剧下降。刚才提到多工具割裂,必然就会导致数据的分散。此时要运维多套可观测平台,此建设成本也很大。如果接触到一套可观测平台,它的建设成本是急剧下降。
第二点是统一数据标准,其实现在在回顾五年、十年可观测工具是非常多的,但是其实大家都有自己的数据标准,接入方式甚至是协议。此时必然就会导致数据割裂性问题,如果遵循统一的标准,不管是接入的标准,数据存储的标准还是数据传输协议的标准,这一整套全部统一接入之后,此时带来的直接效果是这些数据不仅仅监控告警作用,甚至还可以通过统一的数据当中挖掘更多的业务价值。
二、企业级监控能力与智能化运维
因为现在客户的业务场景不同,复杂度也不同,虽然监控工具是通用类的运维工具。但是,在通用的基础上,还是能够去抽象沉淀出很多的标准化的企业级能力供给不同的客户,不同的场景。有开箱即用的通用大盘有一些模板化的配置。还有非常典型的最佳实践,都可以沉淀成一些产品化的能力,这样给到客户可以直接使用,降低复杂难度,尤其是在数据和能力的开放性上,这里就反复到第二点是数据的标准性。因为是在封闭的体系其实很多有价值的数据都能拿到。你的能力也不能复用到客户本身的运维体。
最后一点智能化一定是要提供真正能解决问题,并且实用性很强。AI的能力帮助在可观的体系当中带来直接的运维效果。也是从不管是从视角还是从运维视角,也是希望可观测平台能够带来非常朴素的几点要求。
这几点看起来很泛,但是却非常实用。ARMS作为一款他们应用监控的一平台也是一直致力于能。开发运维作为观测利器,能够去提供很多作用。所以ARMS围绕着端端段的全链路,也带来了四大核心能力的全新升级。
三、架构升级与智能助手应用
第一是ARMS支持更丰富的应用类型。从前端上来分析,用户体验方面支持的移动端的app原生应用还支持很多小程序等等相关的web站点等等相关的一些终端应用。基本现在主流上的终端应用已经做到了全量的覆盖。
第二是服务端方面。熟悉ARMS的同学也知道ARMS之前一直是在深耕Java领域,今年也是重磅推出自研的Golang和Python的方针。他的能力是媲美于当前Java的应用。第二是更完整的调用链路,其实之前在聊调用链更多聊的是叫分布式调用链,分布式链路追踪。其实在分布式链路追踪的情况。今天要聊的是端到的前链路追踪,全链路一最典型的一流量架构是从终端应用再到网关,再到后端应用。ARMS就围绕着非常典型的流量架构全量全部支持,包括终端包括网关。还包括了现在用k8s非常典型的三大网关ALB、Nginx和MSE原生网关。同时,ARMS也是一直全面拥抱Open Telemetry的生态。Open Telemetry是现在一款开源的可观测框架,也是逐步在成为云原生领域应用可观测性的事实标准。
第三是更高效的数据连接,季风在演示观测图谱的时候大家看到Demo其实非常的实用,并且非常的高效,ARMS作为应用监控产品已经全量融入现在的云监控2.0可观测体系。所以它依然是可以复用刚才的全站数据图谱的能力。提供更高效的连接,除了单应用的指标链路和日志的无缝关联查询之外,更支持跨观测对象的数据关联提供ARMS作为一应用可观测平台,它可以上。从而构建全站的观测图谱。
第四是更智能的,更洞察。探索过在做根因洞察方面的能力叫据关联提供ARMS作为应用,可望平台它可以向上连接用户体验,向下连接基础设施,从而构建全站的观测图谱。第四是更智能的更音洞察。ARMS其实现之前也探索过在做更姻洞察方面的能力叫ARMS的智能洞察,原来的ARMS的智能洞察。其实主要还是围绕单应用单问题点去做自动化的异常巡检,同时给出可能的根因分析,但是现在面向越来越复杂的一微服务应用的时候,它的调用关系非常复杂。
单一的问题其实并不能直接表明跟问题的根因其实是需要拉通更多的观测对象更多的应用数据去判断根因,所以ARMS的根因洞察进行了一全面的架构升级,提供了基于根因的一告警的一收敛和影响面评估和根因分析的能力,同时也提供了Copilot的一形式的智能助手,帮助去获取更细节的更新报告,还有更优的一解决方案。
下面来分别看一下ARMS是大能力的一些细节。第一是原生支持更丰富的终端类型,左边是现在终端用户基本上全部的覆盖,第二是最常见已经有的是web站点和小程序,还有今年新增支持移动端的IOS和安卓的app应用,是windows和mac的PC的应用。同时,多终端应用提供了一致性的产品能力,包括多端的数据采集。多维的精准的数据分析,还有很多开箱即用的大盘基本上能够常见用到的大盘,基本上已经在控制台上全部提供出来了,还提供更加灵活的自定义大盘的一些能力。
同时,前端应用也是全系列全部支持链路追踪的能力默认就开启,因为前端和后端连接在一起,才能够达到真正意义上的全链路追踪能力。同时,前端它不像后端,后端可能没有么强的业务属性业务领域,但是前端其实更符合或者说更加能够贴切用户实际在使用过程当中的行为。所以用户体验监控在交互体验上是以会话为中心,更多的反映直接真实的用户行为分析,第三是的应用监控部分,除了ARMS在近几年一直深耕的 Java Agent 之外,也全新推出了自研的Golang和Python的探针,相信其实有很多的客户已经在生产的很多业务当中直接就选型了go,或者说Python。
特别是一些大模型的应用,可能是用Python的语言去实现大模型应用会更多,新增的 Golang 和 Python 的应用的话,也是直接是对标了当前Java全量的能力。包括无侵入低成本的接入,尤其是在容器环境下,提供几行Yaml的一注释就可以完成接入,不需要去注入到的镜像当中去,要各种Build等等相关的同时。
四、智能化数据关联提升问题排查效率
ARMS具有典型的几大能力,第一是指标大盘能力,全链路追踪能力和代码级的 Profiling 能力都是完全提供。第二是从客户端到服务端的一端到端全链路的追踪能力,其实从前端应用到后端应用接入到观测体系之后,如果请求链路它没有关联的话,如果出现问题钉钉界定音还是会有不少的挑战,如果从常见的流应用流量走向来分析,终端应用它是作为应用的流量的发起方会经过安全类的服务,再到负载均衡,或者说网关类的服务。最后请求会走到后端服务,同时后端服务之间会相互直接通过 HTP 或者说 RPC 相关的一些协议去调用,同时还会调用一些下游的一些中间件或者数据库的服务,这形成了非常典型的请求链路的路径。构建一套真正意义上的全链路追踪体系,效果是非常明显的,大家可以看一下中间的这张图。请求链路一目了然,基本上没有盲点,所以如果排查非常典型的错的问题,慢的问题,耗时的问题直接就可以在全链路的链条当中,一眼就可以定位出是哪一节点出现了慢的问题,错的问题。
所以ARMS是一直在致力于去提供端到端全链路的解决方案。
所以新增,首先第一是从最上面的的用户体验的终端应用已经做到了全系的覆盖。第二是在非常见特别是在k8s场景下三大网关的ALB、Nginx和MSE也都是全系覆盖了的链路追踪能力。
同时,ARMS一直致力于在阿里云生态和开源生态去推动的这套标准的缺失协议。因为链路追踪可能还不像指标类的一些数据一样,链路追踪第一是需要统一协议;
第二是需要把的缺失数据存储在一块儿,才能够达到中间这张图的效果,中间有一环,咱们协议不一样,就类似于接口一样,接口不同,就串不起来;
第三是观测图谱,刚才提到全链路最终是从请求链路的一请求的维度去经去记录记路过的服务,但是在实际问题排查的时候。
单一的链路数据其实在问题排查的过程当中,其实往往是不够的,因为可以观看中间的左边的例子,假设这是非常简单的。订单系统客户扫码通过小程序点单,必然会串联到下游,可能有网关有各种各样的微服务,还有一些中间间数据库等等相关的一些产品。如果是说有客户报上来说,我用你的小程序订单系统。会出现一些页面卡顿,还有出现一些偶发性报错的一些问题。其实在对终端应用上来说,他感知到的是在往下传递的当中,其实可能在时刻发生了很多的异常事件,所以说在排查路径当中。只看一些确实数据,还需要去关联去查询的日志指标,仪表盘还要看的告警事件等等相关的。如果这些数据没有被智能化的关联起来,我相信大家都有这样的体感。我今天到日志平台去看什么服务的日志,然后再到告警平台去看看段时间有没有对应的告警时候是需要告人的经验是季风说的老司机的经验,一步一步去排查,但是如果做到了一智能化的数据关联,构建了全量的观测图谱,其实可以把经验的能力沉淀到的平台当中去,所以ARMS作为云监控2.0当中非常重要的一环,已经把ARMS能够去提供的应用观测的数据全部融入到云监控2.0整全站可观测图谱当中去实现了。
所有数据的关联查询和自动化的架构感知,在基础上排查问题可能就不用凭借着经验的方式先到这里排查去佐证,然后再到平台去佐证是不是问题,而通过一条完整的排查路径就可以完成指标。告警链路等等相关的一些查询,从而能够大大的去提升整问题排查的效率。
最后,再聊聊更新洞察或者叫智能洞察,ARMS的智能洞察今年迎来了非常大的一升级,把它升级的品牌叫Problem Insights,Problem把它叫问题 Insights叫洞察,所以叫问题洞察Problem 从哪里来,原来ARMS的智能洞察,是针对单一应用进行更新巡检和更分析时候press从哪来,把ARMS把单一应用扩大到全部的观测对象。可以脑补场景,假设是调用Top当中,因为某一数据库的问题,导致向上传递所有的问题时候直接的表现是我可能收到一堆的告警。
上游被影响的服务都会受到告警。
但是这是第一现象,第二现象是告警来了之后我必然要去排查问题,排查问题的时候,到底哪告警才是真实反应,根因的告警其实我不知道。我要一步一步才排查,第三是非常严重的线上问题,此时此刻要向领导汇报故障到底影响了多少用户,哪些用户什么类型特征的用户。
所以ARMS针对Problem Insights做到的重大升级,基于相同的根因去收敛所有的异常事件。就相当于会后台计算每一次异常事件背后的根因,然后相同的根因把所有的告警事件收敛成的对象叫Problem问题。围绕问题就可以提供四个非常典型的产品能力,第一告警的降噪,因为刚才提到的一堆告警是受牵连的服务报上来的,收敛在问题当中,就可以搜到这些告警都是问题导致的。防止告警风暴我不知道我在抓虾。
第二问题是更因定位,因为它核心的原因是分析每一个异常事件的根因,所以更因定位必然就直接提供到。最原始的始作俑者的根因地方去。第三是影响面分析,提到端高端全链路,把终端应用和后端应用全部接进来了之后,就可以很好的去评估上游些终端应用,它带来一些特征值,比如说它的地域。它的用户信息就可以评估出来,它影响了哪些终端用户。
第三是AI辅助,因为季风演示的的Problem Insights的Demo中,呈现出的产品化的更新分析报告的时候,它展示的信息可能比较的精简,通过生成式AI唤起的CPL的智能助手的时候,可以通过自助探索的方式去剖析出更细节的一些信息,甚至是到方法站级别,还有等等其他的一些。
五、应用可观测体系的构建与优化
更细致的一些分析,同时基于CP的给出最直接的问题修复的建议,在过程当中,其实Problem理想是在做运维的时候,相信都有一很痛苦的点,是被告警。假设我要运维300应用,可能告警我没法想象。因为我要从单纯的从应用可观测的角度,我可能要配耗时配GC配错误率配等等相关的配慢调用。还有一些基础设施的,我可能告警的数量是往前配告警的难度和工作量非常大,Problem Insights的愿景是希望消除掉人为的告警配置。我希望有AI引擎一直在帮助去做自动化的一异常巡检,有问题看Problem就行。这一直在发展的一方向,再次回顾四大能力。
第一,要把所有的终端应用后,后端应用以统一的方式接入到平台。
第二不要实现从前端网关再到后端的全链路的打通。
全链路打通完了之后只是骨骼,把头胸脚全部串联在一起,但是我在日常问题排查的时候,我可能还需要其他的指标,需要看日志,需要看告警事件,需要看指标的时候就依赖整全站的观测图谱。
最后在辅助于的AI帮助去在问题排查的过程当中去尽可能的提效,尽可能快速的去找到问题的根因是什么,怎么去解决,影响了多少人,这是围绕端到端可观测的四大的方面的能力升级,最后我会分享两个实际的客户案例,在用ARMS构建应用可观测体系的时候,它的一些业务效果可以给大家做一个参考。
六、客户案例
第一是茶百道,其实大家都非常熟悉,一非常好喝的一茶饮品牌,从去年的时候就开始试点揭露ARMS到今年年初已经全量揭露,所以ARMS是它基于茶百道基于ARMS已经构建了非常完整的端到端可观测的体系。是茶百道内部业务连续性管理平台当中非常重要的一环。随着茶百道核心业务全部接入ARMS茶百道已经有非常完善的应急响应体系,并且根据自己的实际业务情况,配置了完善的告警,所以现在问题发现的时效性是出了问题便会发出告警,已经做到了秒级。第二是随着告警体系的不断完善,比如说设置排班体系升级体系以及值班体系的时候问题爆出来了之后再到问题解决。它的问题的时效性基基本上是缩短了50%以上。ARMS作为背后强有力的技术支撑,查白到整运维效能得到非常大的提升。
第二案例是也是大家很熟悉的极氪汽车作为高端的智能品牌一直在推出很多非常喜欢的汽车,同时极氪汽车今年5月份也都是在纽交所正式挂牌上市了。极氪汽车它有一个非常核心的业务是极氪APP,极氪APP作为连接用户的关键纽带APP它的稳定性,它的流畅度非常重要,所以目前极氪APP核心服务也基本上都揭露了ARMS的应用监控,为能够快速去应对突发情况,极氪的运维开发团队,也是深度使用了ARMS智能洞察功能,所以一些线上的一些突发问题,比如说一些发布会等等其他的一些突发问题,可以基于ARMS的智能洞察,快速的去定位根因。有效去提升了问题的排查效率,同时,极氪APP的后端服务非常多。
如果是单一用的智能巡检可能并不能直接找到问题的根因,时候即刻在试点使用现在新版本的 problem inside 基于新版本的基于更新的智能洞察能力,告警收敛的效果非常明显。减少了很多无效的告警,还有告警风暴的一些干扰。同时影响面分析也非常重要,到底是影响了哪类的用户,这些用户的些分析出来的数据是可以帮助的运维过程当中去提供很好的数据参考。便于决策下一步恢复或者应急的手段,所以整个落地的 AIOS 的效果也是非常明显的,最后来说,ARMS本次围绕端到端的全链路应用可观测新增非常多的重磅新能力。同时ARMS也一直在探索更多的可能性,为用户带来更实用的一些产品能力。希望大家也可以尝试多了解一下 ARMS ,多使用 ARMS 多给 ARMS 提意见。
本次分享到此结束。