[.com原稿]2017年4月14-15日，由The主办的WOTA全球架构与运维技术峰会北京万丽酒店隆重举行。此次WOTA设置了15个前沿热点技术论坛，来自Google、LinkedIn、Airbnb、百度、阿里巴巴、腾讯等国内外一线互联网公司的60+位技术大咖将带来50多场实践经验和积累的建筑经验。分享成功经验案例，携手打造为期2天的行业领先科技盛会。4月14日上午，在WOTA2017主会场，听云研发副总裁廖雄杰以《全栈APM--打造端到云的全方位监控体系》为主题进行了精彩的演讲。以下为演讲实录，让我们先睹为快！听云研发副总裁廖雄杰很高兴在这里与大家见面。今天给大家介绍一下APM的五个方面的工具集和操作方法。在运维场景中，以及在产品应用和交互场景中，可能会遇到一些性能问题，也可能是在产品运营阶段，因为这些问题直接影响到最终的用户体验。对于大规模的应用，我们可能还会涉及到很多环节。首先，我们会从终端用户APP或者PC浏览器访问，在终端用户端会出现一些问题。最终用户和我们的服务器之间可能会有网络CDN和云端的链接，服务器内部和服务器之间也会有链接进行交互，也会有各种组件进行交互。特别是现在许多公司都在实施微服务和其他面向服务的架构。在这个架构下，我们遇到了一个问题，就是你的架构层级越来越复杂，监控对于运维来说会越来越困难和复杂。但是，出现问题后如何监控这个链路呢？要监控网络的另一端，我们需要CDN或本地运营商。可能是用户自身网络环境的问题。所有的问题都需要定位。问题是什么？，哪些需要优化解决。服务器内的各种组件可能会出现问题。刚才AWS的张霞老师介绍了AWS云的概念。云是运维行业近几年的一大福音。现在听云的所有应用都部署在云端。应该说云解放了很大一部分运维的经验，把我们从冰冷的机房里解放了出来。现在很多运维基本上不需要我们背着两端的服务器满街跑三天。今天给大家介绍一下APM的概念，如何理解应用运维的各个环节，遇到问题和问题如何排查。众人恍然大悟，这是研发组相关人员所为。其实这个问题对于运维人员来说是一个很大的苦恼。当出现问题时，运维方首先要介入。是基础环境有问题，还是应用本身有问题。只有明确了权责，才能把问题交给研发，或者交给运维。今天先来介绍纬度APM的几大功能。事实上，它们也是APM的组件。我们实现了APM的几种常用方法。首先是DEM，无论是外部还是内部对应用本身的可用性和性能的监控，这是我们最直观的监控。应该说，当我们的用户出现问题的时候，首先应该也和这个有关。我们首先持续监控这个状态，以便我们可以在以后检查更深层次的问题。DEM是一个比较大的方面和函数纬度。其中有两个主要工具集。一种是RUM，是对真实用户的性能监控。它通常基于网络和移动终端。用户访问时，客户的注意力集中在网页浏览器或移动端。每个官方用户在向应用程序发出请求时，过程中都会采用一定的方式，比如浏览器通过嵌入，移动端的嵌入方式更加复杂。这需要自动嵌入，因为这不能在研发订单中嵌入监控代码，这两个嵌入过程应该是完全自动化的。首先是对真实用户的监控。与之对应的另一种方法是STM模拟交易监控。这个和上一个有什么区别？对于真实用户的监控，Web浏览器的例子存在什么样的缺陷？从性能上来说，监控是从真实用户的角度发起的。这绝对是最合理的。当出现问题时，我们最关心的是用户。但是，这种监控方式有一个比较致命的缺陷。我们说首先必须监控可用性和性能。如果是浏览器的方法，GS的方法大部分都是embedding，也就是说你的浏览器和你当前的页面至少需要一个正常的request和completion，然后你的GS才有可能正常运行。如果这个过程中出现网络异常或者只是页面GS错误，你的监控脚本根本加载不上，运行不了，那么问题就大了。当它不正常时，你通过这种方式监控起来相对容易。难的。所以STM在这方面有比较大的优势。STM是模拟用户。您可以将其定位在机房或最终用户，并在最终机器上部署一些机器人节点。它可能不是真正的用户，但是和真实用户一样，其实是终端用户的访问，可以控制浏览器去抓取网络事件和性能的各种指标，这是比较重要的两种监控方式，一个是DEM，一个是RUM，一个是STM。那么，APM的第二大功能就是DATD，这是什么意思呢？刚才说了从终端用户的角度来看，不管是正式用户还是模拟监控，都是终端用户的角度来观察应用。所以在这种方法的应用内部，比如访问数据库或者访问MQ，这个是无法被DEM监控到的，因为在用户远端是看不到的，最多是网络一端，不能在服务器内部可以看到。所以这里需要用到第二个功能类，也就是ADTD。你需要描述一下服务器内部，尤其是微服务架构，A服务和B服务的调用关系是什么，调用过程有没有问题？问题是A服务有问题还是B服务有问题。因此，所有这些痕迹都应该在这里描述。如果没有描述数据，则不会进行监控。第二大字段的另一个重要特征是除了描述它们之间的关系外，还有性能。一旦发现问题，就可以深入钻研。当终端用户访问应用的时候，应用看到它内部进来，后端和其他服务的交互，和数据库、缓存、MQ的交互，所有的组件都要钻出来，否则你最终会看到有是服务有问题，但不知道问题出在哪里，所以深钻也是有必要的。当它出现问题的时候，我们其实是有手段去分析行级代码的，到底是哪一行代码出了问题。因为在应用程序内部，通常通过合理的方式，通过代码植入，我们可以获得代码的信息。当出现问题时，它甚至可以将差异定义到行级代码。这应该是一个非常有用的运维工具。因为不需要知道每个应用开发的细节，可以快速定位问题，这一切都是工具化的。以上主要介绍了数据的来源以及我们是如何抓取这些数据的。有了这些数据之后，我们就可以通过机器学习和统计推断，找到数据表现异常的根源或根本原因。我们认为经常有警报。服务A、服务B、服务C的告警都是什么问题？这时候就需要追根溯源了。您可以使用统计学习方法和机器学习方法来分析从这些数据中得出的结论。这是后期数据处理的问题。刚才介绍了APM的主要实现方式，我们已经描述了APM的主要实现方式，包括它的功能纬度。现在我们来看一下，我们可以实现全栈，我们来看这张图，每个点我们可以做什么？我们的APP可能有原生APP，也可能是H5开发的。它在您的APP中运行。这部分是RUMAPP的一部分，分为两部分。这两种技术手段完全可以实现从端监控，前端可以看到网络性能，这些都是可以做到的。包括前端性能，比如某个脚本执行有问题，你至少可以定位到哪里。如果浏览器渲染有问题，可以在前端检测到。中间部分是网络层，是STM工作的区域。它可以最大程度地发现一些网络问题。为什么放在网络的这一端？模拟意味着我们可以在任何地方部署它。比如我们部署在机房，你可以部署在终端用户的机器上，你的机房和终端用户，你也可以按照你关心的区域运营商的比例来分配监控资源。您不必像官方用户一样。同样回报多少就是多少。你可以利用这段时间做更多的事情，还有一个好处就是STM的方式，通常是它的监控方式，本质上就是我们制定了一个特殊的A策略，也就是说你可以从浏览器中获取更多的东西，我们知道GS在真实用户的浏览器中工作，实际上你能做的事情相对较少。由于安全或技术限制，您可能无法获得您想要获取的许多数据。在STM中，可以抓取尽可能详细的数据，可以更透彻地分析问题。通过STM可以定位是CDN的问题，还是本地网络的问题，还是本地运营商网络的问题。骨干网有问题，可以定位。它可以通过你的节点部署在不同的位置，这样可以区分很多纬度。服务器内部的应用，包括云内部服务器，是ADTD的工作领域，可以对应用进行监控。理论上，访问本身可以从应用程序发起访问的地方进行监控。通过JDBC监控数据，嵌入监控代码，访问的数据库就出来了。所有的embedding应该说是技术上统一的，不像我们说的可能有很多专业的监控，比如每个数据库针对不同的协议，不同的服务器部署。对于APM的实现，一般情况下，我们会统一实现，因为当应用出现问题时，最终关心的是应用发起访问某个组件时是否有问题。如果有问题，你可以帮我定位就可以了。这是基本拓扑，您首先看到的是概览。二是真实用户的情况。这是一个IOS应用程序。您可以看到它的每个网络访问请求。它的曲线有一个时间段，它的访问时间是有标记的。通过分析大量真实的用户数据，然后将这些数据以图表和可视化的形式展示出来，符合运维的基本原则。所有的监测数据都应该在指标衡量后可视化，这样才能成为一种工具。这是一个真实的用户体验，在这里你可以看到网络的切片，看到网络包括了什么，你可能更关心的是解析DS用了多长时间，建立连接用了多长时间，然后会有一个第一个上报的时间，就是服务响应的时间。基本上可以定位是网络端的问题还是服务器端的问题。如果问题出在服务器端，可以使用其他技术手段。前面说了，通过STM监控，网络切片，建立连接等都是比较正常的。可以判断是由于服务器内部阻塞，阻塞了一段时间，给客户端发送了一个header。Report，我们会发送一个完整的request到它的response，网络的不同阶段可以做出非常详细的切片，这些切片是网络的一部分。刚刚提到ADTD，我们在这方面可以做些什么。Block展示了后端访问的不同服务，服务、服务、数据库和MQ之间的交互等，可以通过拓扑自动发现。应该说这个图运维也是很吃香的。毕竟架构越来越复杂了。基本上，当应用程序变得越来越复杂时，通常很难控制其后端架构。比如应用之间是如何交互的，它们的依赖是如何交互的，包括每一个服务，每一个组件，它的调用次数，吞吐量，错误率等等。可以直观的方式展示。其次，运维和研发更受关注。当出现问题的时候，你肯定想知道是哪一行代码出了问题。最后一步，你定位到问题后，我们可以提前调用代码，其他信息，如果是SQL调用出来的，可以自动抓取，辅助你在后期开发中做进一步的分析。例如，这里简单展示了不同的调用组件以及它们之间所花费的时间。左边的图显示了不同组件的调用次数，以及每个组件调用时间的比例。下面简单总结一下，现在说说全栈APM的简单步骤，真实用户性能，这里用的是DEM，主要是RUM。在网络切片方面，我们主要是利用DEM中的STM来模拟监控，其中网络切片最为细致。还有一个是npm没有介绍，可能有一些运维团队有这样的经验。有了NPM，你就可以用你机房的交换机，通过专门的软件分析每一个流量包，然后从流量包中分析出它的性能和性能。彼此之间的关系。但这是比较有限的。当您从服务器获取流量数据包时，可能会丢失很多信息。你只有一包数据，它能分析的内容比较有限。后台应用逻辑拓扑，包括通过ADTD对拓扑中各个组件和性能的监控，包括代码级监控可以监控应用进程，每个请求有多少次，平均时间。介绍全栈APM，相信运维应该有强迫症吧。也就是刚才说了那么多的监控方式，我们能不能串起来做一站式的监控。比如我刚才说的，从真实的用户到服务器，到我们的后端组件。当真实用户发现问题时，能否直接一步步查到真实用户到***端，***定位是网络端问题还是服务器端问题。如果是服务器端问题，那么实际上是哪个组件有问题。包括如果是在服务端，在后端调用某个服务时出现问题，导致前端响应变慢，是否可以一站式暴露，包括分析刚才提到的行级代码，这些方法可以结合使用。刚才讲了Web的RUB，我们怎么去到服务器，也就是怎么从浏览器追到服务器。包括关联他们的性能之间的关系，首先从浏览器的监控上来说，后面会介绍监控的方法，我们监控到一个请求的响应时间是比较长的。我们看下图，我们把它分解为服务端响应时间、网络层和前端渲染。显示时，首先以服务器端的时间作为单独的指标。从这张图可以看出是服务器端的问题还是前端网络的问题。我们可以通过钻取直接钻取到与后端关联的问题应用。这就到达了服务器端相应的请求。请求点击后，我们会看到某个组件，它是对另一个后端的服务，它的响应时间比较长，我们可以在一次演练中将它们全部关联起来。如果我们回头看，因为我们已经到达了服务器端。其实后端应该不用讲的很详细，因为基本上ADTD里面的大部分东西刚才都已经简单介绍过了，因为都到了服务器后端了，然后再往下钻就可以知道了它是哪个组件。这是浏览器对设备的详细分析。可以显示我们页面浏览每个元素的响应时间，可以看到有一个元素耗时比较长。然后我们从元素级别开始，我们可以向下钻取每个元素。比如请求比较慢，它的后端可能对应的是另外一个应用。你能从这里深入到后端应用程序吗？深入到后端应用之后，我们可以对ADTD后端进行分析。比如我们可以看到它从后端向后端请求了另外一个URL，在请求的过程中出现了问题，响应时间比较长。回头看看是哪个方法，哪一行代码有问题。下面简单介绍一下具体的实现方法。其实比较简单。我们需要连接浏览器和服务器端。首先，它会自动嵌入代码，服务器端也会自动嵌入代码。嵌入代码后，我们要做的就是将这个请求从浏览器发送到服务器，再从服务器返回给浏览器。我们用一个东西把request和response的过程放到某个地方发给服务器，然后发回去。对于浏览器方式，我们可以直接改Ajax，但是不能改主页面请求的HTTP头，但是有什么办法吗？在服务器端，我们也采用embedding的方式进行嵌入。其实我们在服务端嵌入的时候可以直接拦截JSP和PHP编译的过程，直接输出一些可以关联的信息。比如生成一些东西放在页面上，然后再带回来就可以了。总会有一些技术手段来实现这个过程。所以我们有办法关联它。Java可以自动修改。其实我们要做的就是把一个函数前后的时间传递过去。包括有异常的时候，也可以检测出来，发给服务器。服务器最终通过这种代码拦截方式访问数据库。你最终是通过调用API的某个函数来实现的，所以我们要拦截的就只是这样的函数。浏览器更简单。想必大家应该都见过类似的GS码吧。我们有很多广告分析和用户分析，很多网站都有。对于APM，我们需要获取其性能。很久以前，我们直接使用GS方式，但是很多时候是不可用的。例如，在浏览器内部，它不会通过GSAPI公开。2011年和2012年后，W3C开放了这两个标准，大多数主流浏览器也实现了这样的标准。其实实现方法比较简单。看看吧。它有一个Navigation计时接口，就是开始和结束的时候，可以得到对应的解析时间、渲染时间和链接建立时间。我们注入代码之后，你就可以得到所有你想要的前端网络，以及前端分析和性能监控数据，然后对其做一些简单的分析，就会出来一个监控界面。刚才我们大致介绍了Browser到Server，如何做一站式APM溯源。其实APP也有类似的方法。获取监控数据，并在其中嵌入代码。必须有技术手段。包括后端服务与服务之间，服务与数据库之间。主要是服务之间，我们说跨应用，包括服务之间的跟踪，API微服务可能用的比较多。得到这么多数据后，我们就可以追踪调用链了。所有从服务A到服务B和服务C的请求都可以被描述。当多个服务同时报警时，如何利用这些数据对问题的根本原因以及是什么原因造成的进行根因分析。本次介绍APM的使用场景，包括APM套件中的主要工具，以及APM套件中的几个主要实现方法。我的演讲就到这里，谢谢大家。记者将在WOTA2017全球运维与架构技术峰会之前继续为大家带来精彩报道，敬请期待！【原创稿件，合作网站转载请注明原作者和出处为.com】
