AppDynamics集成视频教程成绩单
我叫康纳·内斯, AppDynamics解决方案架构师, 在这个演示中, 我将向你们展示AppDynamics和Thous而且Eyes之间的新集成，以及如何使用这个原生集成, 我们已经扩展了为分布式云应用程序提供的端到端可见性.
现在, 这是一个针对关键业务的仪表板, 产生收入的保险应用程序，处理正在提交的政策申请和客户付款.
在这个视图中, 我们有正在提交的付款的上下文, 我们的终端用户正在体验的性能, 还包括第三方api的性能以及我们的应用程序所依赖的关键服务依赖关系.
现在我们在这个仪表板上看到了一些令人担忧的事情.
黄色表示提交的付款金额低于正常基线.
事实上，今天早些时候，支付完全停止了.
与我们收入的下降有关, 我们看到“创建费用”业务事务的响应时间增加了.
让我们来看看这个应用程序是如何工作的，并诊断出发生了什么.
这是我们“创造费用”业务交易的流程图.
这和我们在仪表盘上看到的是一样的，我们的响应时间很长，收入却下降了.
这个业务事务有多个支持它的微服务, 比如网页层, 核心服务和支付服务.
才能让交易成功, 这个后端微服务还依赖于由这个灰色云表示的外部支付处理API.
现在，我们可以清楚地看到响应时间突然增加.
这是客户确认服务付款的方式.
如果客户不能这样做, 这将导致许多客户不满意，并导致我们呼叫中心的电话激增.
仔细观察这些缓慢的快照，就能清楚地知道发生了什么.
此外部web服务调用的时间比正常情况下要长, 支付服务出错，导致远程调用超时, 是什么导致上游核心服务完全失败.
现在, 点击“下钻”将我们直接带到失败的HTTP请求的详细信息, 包括实际执行它的代码的调用图.
现在这个对支付处理器的外部web服务调用超时了, 这导致支付无法通过.
在这种情况下，要理解的最重要的事情是隔离问题域.
这是我们应用程序的问题吗, 网络有问题, 公共互联网或外部服务提供商的问题, 在这种情况下，哪个是我们的支付网关?
使用快照, 我们已经确认，缓慢不是来自我们的应用程序或我们的代码.
它是应用程序之外的东西.
现在, 通常在这一点上, 应用程序团队被免除了责任，问题被推给了网络团队, 这样的反反复复会造成浪费的指责和宝贵的时间, 而最终用户体验正在受到影响.
但如果我们能确切地找到外部环境在哪里影响到支付网关的连接呢? 回到仪表板, 我们可以通过AppDynamics和Thous而且Eyes的联合可视性快速回答这些问题.
对于那些不熟悉千眼的人, 他们是一个互联网和云智能平台，提供了互联网和外部环境如何影响应用程序性能的可见性.
现在我们在应用程序环境中运行了一个上千眼企业代理, 这让我们能够将可见性扩展到应用程序环境之外，并了解外部web服务请求如何穿越公共互联网.
事实上, 这张图从应用程序的角度直观地将后端响应时间与这些事务离开数据中心时的网络延迟联系起来.
现在, 果然, 与此同时，我们的收入下降，支付处理开始出现问题, 我们看到了千眼网络延迟的增加.
现在，这证实了确实是网络的问题，而不是第三方服务的速度慢.
通过AppDynamics和Thous而且Eyes的集成, 我们通过统一可见性和提供通用操作语言，帮助改进故障排除时从appop到NetOps的切换.
所以我们知道支付网关的网络延迟增加了, 但究竟是什么原因导致的呢?
让我们从这个仪表板直接无缝导航到thous而且 deyes测试，继续诊断这个问题.
在Thous而且Eyes, 我们有一个HTTP服务器测试，向我们的后端支付服务或应用程序所依赖的相同URL发出请求.
现在我们正在从五个不同的角度测试支付API, 其中四个来自全球各地, 也被称为由千眼托管的云代理.
第五个是在我们的应用程序环境中运行的Enterprise Agent, 这样我们就可以理解离开我们的环境到外部服务端点的事务如何遍历公共互联网.
现在，这个网络概述选项卡讲述了一个非常重要的故事.
正在发生的网络延迟的增加实际上是在几个不同的位置经历的, 主要在美国. 然而，它对应用程序环境的影响最大.
这有助于我们将这个问题从我们的数据中心网络或上游ISP的问题限制为我们的支付提供商的互联网路径的问题.
现在，我们如何通过互联网连接到这个支付提供商?
好吧，让我们看看路径可视化来理解.
第一个, 我将把我们所关注的时间框架改为问题开始之前，这样我们就能了解发生了什么变化.
现在, 我们的应用程序在太平洋西北部的一个数据中心运行, 这个路径可视化显示了连接是如何穿越公共互联网的. 左边是我们的企业代理.
右边是支付处理程序api的目的地或前门, 它们之间的每条线和圆都可视化了交通通过互联网到达目的地的路径.
在问题发生之前, 请求被传送到支付处理器美国的位置, 主办地点:阿什本, 或者亚马逊的美国东部地区.
和其他云代理, 比如日本和英国, 实际上是发送到支付处理器的新加坡位置.
这是一个经典的GeoDNS实现.
基于我们的实际位置, DNS返回服务的不同IP地址，以提供最低的延迟.
到目前为止一切正常，但当延迟激增时，让我们看看会发生什么.
等一下.
现在看起来我们的应用程序的API请求被一路路由到新加坡.
这与GeoDNS的目的相冲突.
为什么新加坡的服务端点会为来自美国的请求提供服务?
很明显, 这里有点不对劲, 但它解释了为什么我们突然看到更高的网络延迟和应用程序超时的根本原因.
现在, 这个独特的视图包含了我们的应用程序和网络团队了解问题所需的所有信息.
拥有这种统一的可见性可以避免所有人都参与的作战室.
相反，我们创建了一个ShareLink:一个始终可用的、交互式的千眼数据视图.
我们将这个ShareLink连同描述问题所需的所有上下文直接发送给支付团队，他们可以与支付供应商一起解决这个问题.
现在, 让我向你们展示如何在AppDynamics中设置仪表板，在一个视图中同时使用应用程序和网络上下文.
这种独特的视角得益于我们今天宣布的AppDynamics和Thous而且Eyes之间的新集成.
将上千眼指标放到这个仪表板上就像将上千眼凭证添加到AppDynamics中一样简单.
在那之后, 当我们选择要在小部件中显示的数据时, 我们不仅可以访问AppDynamics的数据, 比如应用程序和最终用户监控, 数据库或服务器, 但现在我们也有了千眼的数据源.
选择您关心的度量以及从中提取的测试, 我们立即绘制出这些数据而不需要建立任何复杂的数据集成.
这使得扩展应用程序的端到端可见性变得很简单，可以向应用程序添加Thous而且Eyes网络和互联网上下文.
现在, 总之, 与AppDynamics和thous而且 deyes合作, 我们为您的应用程序和网络提供完整的可视性，并提供相关的实时洞察，使您能够快速采取行动解决影响客户体验的事件.
谢谢你的宝贵时间.
