首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

许久不聊AI,你有没有想过也许小河老师是个机器人?

应用环境正在不断变化,我们研发和部署应用的方式也在不断变化。部署在动态云基础设施容器中的微服务创造了一个短暂的、分布式的环境,其规模前所未见。在这种情况下,我们进行应用性能管理(APM)的老方法就不再奏效,因为它们无法涵盖全部事务,无法完成完整的数据追踪,解决问题的效率也相对较低。很多关键的细节被遗漏,并且随着环境变得日益复杂,而现有的APM工具却无法诊断出关键应用运行速度慢或出现卡顿的原因,该问题所带来负面影响正在变得日益明显。

在这样的环境下,导致性能问题的原因往往掩藏在细节当中,且相互交织。因此,华而不实的仪表盘和时不时的屏幕快照已经无法帮助我们确定问题的原因所在。今天,IT性能调查员需要更加强大、更加完整的诊断数据,并使用各种各样的分析工具来从不同的角度分解数据并实现可视化。

Riverbed持续抓取端对端事务追踪数据、用户和设备数据、应用登陆数据、细粒度基础设施指标和网络包数据,甚至在对开支十分敏感的大型企业生产环境中也能实现这一点,从而提供一个统一的监控解决方案,满足今天云端应用的运行需要。

下面我们就来看看如何使用几种不同的分析方法从大数据驱动的关键应用中提取有效信息,查找和诊断问题,并设定优先事项。

点击两下就能解决所有问题

通过对包括完整用户数据、方法、登陆和SQL细节的事务记录进行简单的查询,你就能轻松地用SteelCentral AppInternals回答几乎所有性能问题。你可以在数十亿个事务中对元数据进行索引,从而迅速找到关键的事务或信息、生成报告、对比历史性能或深挖信息,以供进一步分析。

与业务相关的信息

AppInternals最方便的功能之一就是可以根据颗粒状用户元数据来搜索或定义事务类型,然后有针对性的只对这些事务进行分析。

比如,根据应用收集的用户数据,你可以定义一个事务类型:搜索(一种特定的事务功能)可穿戴电子设备(一种产品)的千禧一代(一个特定的年龄层)。你甚至还可以选择设定得更具体。或许你的业务所关注的是转移纽约仓库中的可穿戴设备库存,在这种情况下,你最关心的就是在美国西北部地区进行的搜索。你希望能够迅速看到这些搜索,并保证没有错误或遗漏。因此,你就希望自己的IT团队能够集中精力优根据商业优先点来优化某些特定的事务。

通过以下两个步骤就可以轻松在AppInternals中做到这一点:

搜索满足某些特定标准的事务或

根据这些标准定义事务,然后在用户界面中选择该事务类型

所有的表格、图表、地图和其他可视化内容都将实时更新,以显示某类型事务与其他类型事务相比所占的比重,相关结果可用来对商业漏斗进行分析。关于相关分析的应用实例还有很多,我将在今后的博客中详细讲解。

微服务——一个大规模的多层环境

我们来看一个熟悉的可视化的例子,即应用程序依赖图。对今天基于大规模多层次微服务的应用来说,你原本基础的n层架构或许看起来有一千层,即便对一个单一事务来说,情况也是如此。下图是一个典型的应用程序依赖图,要想对其进行解码几乎是不可能的。

要应对这一情况,你需要以一种不同的方式来对依赖关系进行可视化。性能图(上图所示)就能将中间层依赖抽象出来,以得出可操作且与IT和业务有关的信息,比如:

按照量和经济价值衡量,哪些是最重要的事务?

我的开发团队应当重点关注哪些代码的优化?

大部分APM供应商都根据抽样事务和不完整的、基于截图的数据追踪所得出的各个层次的数据构建叠加应用图。但是,这些图至多只是勉强接近真实情况,有时甚至及不准确,并带来错误的结论。有了AppInternals,你就能够孤立出单一事务或事务类型的端对端路径,基于业务重点进行更有针对性、更可靠的分析。

如何通过优化一个耗时53毫秒的对象节约2000个小时的处理时间!

这里有一个例子。它向我们展示了正确的数据和可视化是如何迅速确定哪些应用优化项目在全球范围内的影响力最大,对整体业务的发展作用最大的。

我们的一位工程师遇到了一位客户。客户公司运营的网站出现了主页性能下滑的问题。其他APM解决方案找到了代码中耗时过长的对象,但优化这些对象对网页整体性能的影响微乎其微,关键性能问题依旧存在。

进入AppInternals

使用性能图,我们的工程师立刻就找到了一个特定的对象,它本身仅耗时53毫秒。由于其他APM解决方案采取的是对对象耗时进行排序的方法,只根据不完整的跟踪数据,关注那些运行时间最长的对象,因此,这一对象就被成了漏网之鱼。但是,正是这一看似微不足道的对象,却是导致主页运行速度下降的最主要因素。对该对象进行优化将后端整体服务器运行时间从1.1秒降至62毫秒,相当于在700万个受影响的事务中,每天为客户省去了2000个小时的处理时间。

结论

基于微服务的架构将应用分解为分散的对象,以至于有时客户会看到一个单一事务的执行设计到了几千层。现代化的APM需要对所有层次进行追踪,分析工具则需要对分散在各处的蛛丝马迹进行处理和整合。Riverbed就能通过我们的超大规模集群式架构针对上万个对象进行这一操作。正如我们在这篇博文中所看到的,有了有全部元数据信息,包含完整的端对端事务追踪的大数据仓库,进行一些特殊的分析就为了可能。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181108B1KT6R00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券
http://www.vxiaotou.com