听云研发副总裁廖雄杰 - 全栈APM--打造端到云的全方位监控体系

很高兴在这里跟大家见面，我今天介绍的是APM五方面的工具集和操作的方法。在运维的场景，以及产品应用和交互的场景里可能会遇到一些性能问题，也可能是产品运营的阶段，因为这些问题是直接影响用户最终的体验。
对于大型的应用来说，我们也可能涉及到很多的环节，首先我们会从最终用户APP或者PC浏览器的方式访问，最终用户这一端就会有些问题产生。最终用户到我们服务器之间可能有网络CDN和云中间的环节，服务器内部会有服务器和服务器之间的环节要发生交互，以及各种组件都要发生交互。
尤其是现在很多公司在推行微服务化，以及其他的服务化的架构。在这种架构下，我们遇到一个问题，就是你的架构层级越来越复杂，监控对于运维来说，它的体量难度和复杂度也会随之加大。
然而出现问题之后怎么去监控这个环节的问题，我们要监控网络另一端，需要CDN或者是本地运营商，有可能是用户自己网络环境的问题，所有的问题需要定位出来，到底是哪方面的问题，哪些需要去优化和解决。对于服务器内部的各个组件都有可能发生的问题。
刚才AWS的张侠总介绍了AWS云的概念，这几年云对运维界来说是很大的福音，现在听云全部的应用都在云上面部署。应该说云解放了运维很大一部分的经历，把我们从冷冰冰的机房里面解放出来，现在很多运维基本上不用我们再三天两头扛着服务器满大街跑。
今天介绍APM概念，对于运维来说怎么样了解应用的各个环节，当遇到问题和出现问题的时候，怎样进行排查。大家猛一看到这个是研发团队相关人员干的事情，实际上这个问题对于运维人员来说是很大的苦恼，当出现问题的时候首先肯定是运维这边首先要介入，你要定位到底是基础环境出现问题，还是应用本身内部出现问题。只有把权责定位清楚以后，你才有可能把问题交给研发或者留给运维处理。
今天首先介绍一下APM几大功能纬度，其实也是APM的组件，我们实施APM几种常用的方法。
首先是DEM，不管是从外部或者是内部对应用本身进行可用性和性能的监控，这是我们最直观的监控。应该说我们的用户出现问题的时候，首先它应该也是跟这个有关系。我们首先把这个状态持续监控出来，我们才有可能再往后面排查有没有更深层次的问题。DEM是比较大的方面和功能纬度，这里面主要的工具集，分成两种，一种是RUM，这个是真实用户的性能监控。通常会基于有Web端和移动端，用户访问的时候客户集中在Web浏览器或者是移动端。从每一个正式用户向应用发生请求的时候，在这个过程当中通过一定的方式，比如像浏览器通过嵌码的方式，移动端有更复杂的嵌码的方式，这个需要自动的嵌码，因为这个不能在研发的接单把监控代码嵌进去，这两个嵌码的过程应该完全是自动化的。
首先是真实用户的监测，另外一个方式跟它相对应的是STM模拟事务监控，这个跟刚才那个有什么不太一样的地方呢？真实用户的监测，拿Web浏览器举例子有什么样的缺陷，表现上来看是从真实用户的角度发起监测，这肯定是最合理的，出问题的时候我们最关注的也是用户。但是这种监测方式有比较致命的缺陷，我们说监控首先可用性和性能肯定都需要监控起来。
如果是Web浏览器的方式，目前绝大部分都是GS的方式就是嵌码，这意味着你的浏览器，你当前的页面至少需要正常的请求和完成，之后你的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内部工作，这一块是RUM的APP的一部分，分为两部分，这两个技术手段都完全可以做到从最终端监测，前端看到网络性能的情况，这些都可以做到。包括前端性能的情况，比如说有一段脚本执行的有问题，你至少可以定位出来大概在哪一块，浏览器渲染的时候有问题，在前端可以监测出来。
中间这一部分是网络这一层，是STM工作的区域，可以最大程度的发现一些网络的问题，它为什么是网络放在这一端，模拟的意味着我们可以把它部署在任何地方。比如说我们部署在机房里面，你可以部署在最终用户的机器上面，你的机房和最终用户，你也可以按你关心的区域运营商，按你的比例分配监测的资源，你不用像正式用户一样返回多少是多少。可以利用这些时间做更多的事情，而且有一个好处，就是STM的方式，通常它的监控方式，本质上是我们开发一个专门的A政策，这个意味着你可以获取到浏览器更多的事情，我们知道GS工作在真实用户的浏览器里面，你能做的事情其实是比较少的。你想获取到的很多数据，可能因为安全或者是技术方面的限制，你是无法实现的。在STM这一块可以抓到尽可能细的数据，可以把问题分析的更透彻，通过STM你可以定位，它是CDN的问题，还是本地网络的问题，还是本地的运营商网络有问题，还是说骨干网络出现了问题，这些都可以定位出来。可以通过你的节点在不同的位置部署，这样就可以区分很多的纬度。
后面服务器内部，包括云内部服务器的应用是ADTD工作的领域，可以监测应用，理论上来说从应用发起访问的地方，访问本身是可以监控的。数据通过JDBC监控，把监控代码嵌上，访问的数据库就出来了。所有的嵌码应该说在技术上都是统一化的，不像我们说的可能有很多专业的监控，比如说数据库每一种都是针对不同的协议和不同的服务器部署。对于APM的实现方式，一般情况下我们会通过统一的方式实现，因为应用出现问题的时候，最终关心的是应用向某个组件发起访问的时候到底有没有问题，有问题你能给我定位出来就可以了。
这是基本的拓扑图，第一个看到的是概览的情况。第二个是真实用户的情况，这个是IOS的应用，可以看到它的每一个网络访问请求，它的曲线有一个时间段，它的访问时间标上去了，通过分析大量的真实用户的数据，然后把这个数据通过图表的方式、可视化的方式展现出来，这个符合运维的基本原则。所有的监控数据都应该是指标度量出来之后，然后可视化出来，这样的话才能成为一个工具。
这是真实的用户体验，然后在这里可以看到网络的切片情况，看到网络包括什么，可能比较关心的DS解析化了多长时间，建立连接的时候用了多长时间，然后会有首报时间，就是服务服务响应的时间。基本上可以定位出来到底是网络端的问题，还是服务器端的问题。如果是服务器端的问题，可以通过其他技术手段，刚才说了通过STM监控方式，网络切片，其他的像建连比较正常，可以判断由于服务器内部发生阻塞，导致阻塞了一段时间向客户端发送一个首报，我们会把一次完整的请求到它响应回来，网络不同的阶段都可以做出非常详细的切片，这是网络的一部分。
刚才说了ADTD，这一块我们可以做什么。在块展示了后端访问到不同的服务，服务跟服务之间的交互，服务跟数据库和MQ等等，通过拓扑的方式可以自动发现出来。应该说这个图运维也是比较喜闻乐见的，毕竟架构越来越复杂，基本上当应用越来越复杂的时候，更多时候会发现很难去掌控它后端的架构。比如说应用跟应用之间关系是怎么交互的，应用跟组件之间它们的依赖关系是怎么交互的，包括每一个服务，每一个组件，它的调用次数、吞吐量和错误率，这些都是可以以直观的方式展现出来。
再其次是运维和研发比较关注的，当出现问题的时候，肯定是想知道到底是哪行代码出现了问题。最后一步，当你定位问题之后，我们可以通过提前把代码调用，以及其他的信息，如果是SQL调出可以自动抓取出来，协助你后面的开发进行进一步的分析。
比如说这里简单的展示不同的调用组件，它们之间占用的时间。左边那个图展现了不同的组件它的调用数，以及每一个组件调用时间的比例。
现在我们简单总结一下，现在我们说全栈APM简单的几步，真实用户性能，这边用的是DEM，主要还是RUM。在网络切片这块，我们主要用到DEM里面的STM就是模拟监测的方式，网络切片做的是最细的。另外一个是NPM没有介绍，可能也有运维团队有过这样的经验，NPM你可以把你机房里面的交换机，通过专门的软件分析流量的每一个包，然后从流量的包里面分析它的性能和各个之间的关系。但是这个比较局限，从服务器拿到流量包可能有很多信息已经丢失了，你只有一个包数据，它能分析出来的内容相对来说比较有限一点。
后台应用逻辑拓扑，包括拓扑里面每一个组件和性能的监控是通过ADTD的方式，包括代码级的监控可以监控到应用过程，每一个请求有多少次，它的平均时间是多少。
介绍完全栈APM，我相信对于运维应该都会有一个强迫症。就是刚才说了这么多监控手段，我们能不能把它串起来做成一站式的监控。比如说刚才说从真实用户到服务器，到我们后端的组件。到真实用户发现问题的时候，能不能从真实用户一步一步直接排查到最后端，最后的定位到底是网络端的问题，还是服务器端的问题。如果是服务器端的问题，它到底是哪个组件的问题。包括如果是服务器端，后端某一个服务调用时候出现了问题，导致前端的响应变慢，能不能一站式的暴露出来，并且包括刚才说的行级代码的分析，这些方式都可以结合起来用。
刚才说了Web的RUB，我们怎么样到服务器，就是浏览器到服务器怎么样追溯一个问题。包括关联它们性能之间的关系，首先我们从浏览器的监控里面，监控方式后面会稍微介绍一下，我们监控到一个请求它的响应时间比较长。
我们看下面这个图，我们把它分解成服务器端的响应时间，以及网络层以及前端的渲染。展示的时候首先把服务器端的时间单独作为一个指标，在这个图上你可以看出来，它到底是服务器端发生的问题，还是前端的网络发生了问题。
我们可以通过钻取的方式直接钻取到后端关联出问题的应用，这个已经到达服务器端对应的请求，这个请求点开之后，我们会看到某一个组件，它是往另外一个后端的服务，它的响应时间比较高，我们可以一次钻取把它全都关联出来。
我们再往后看的话，既然已经到达服务器那端。其实后端应该没有必要详细说了，因为基本上大部分的ADTD里面的东西，刚才已经简单介绍了，因为已经到达服务器后端，再往下钻取可以发现到底是哪一个组件，这个是浏览器详细的分析。每一个元素我们页面浏览响应的时间都可以展示出来，我们看到其中有一个元素时间比较长。然后我们给它从元素的级别开始，每一个元素我们可以往后钻取。比如说请求比较慢，它的后端可能对应另外一个应用，能不能从这里钻取到后端的应用里面去。
钻取到后端的应用之后，我们可以通过ADTD后端的分析。比如说我们可以看到它请求后端再后端另外的URL，请求的时候发生了问题，响应时间比较长。再往后看，我们可以看到它到底是哪个方法，哪一行代码出现了问题。
具体的实现方式简单介绍一下，其实也比较简单，我们要把浏览器和服务器端，首先它会自动嵌码，服务器端也会自动嵌码。嵌完码之后，我们要干的事情，从这个请求，从浏览器端一直发到服务器端，再从服务器端回到浏览器端。我们把请求和响应的过程用一个东西放到某一个地方传到服务器，然后再传回来就可以了。对于浏览器的方式，我们可以直接把Ajax改掉，但是主页面的请求你没有办法改HTTP头的，但是有什么办法吗？服务器端我们也是通过嵌码的方式嵌进去的，事实上我们可以在服务器端嵌码的时候直接拦截JSP、PHP编译的过程，我们直接输出一些可以关联起来的信息。比如说生成一个东西放到页面里面，然后带回来就可以了，总会有一些技术的手段实现这个过程。所以我们有办法把它关联起来。
Java可以自动修改，把我们要干的事情，其实在一个函数的前后打上时间传上来就可以了。包括出现异常的时候，也可以监测出来传到服务器这端来，服务器端最终是通过这套代码拦截的方式，访问数据库，你最终都是通过调用API某一个函数实现的，所以我们要拦截的就是这样一些函数。
浏览器就更简单了，想必大家应该都会看过类似的GS的代码，我们很多广告分析，以及用户分析，很多网站都有，对于APM来说我们要获取它的性能，在很早以前是直接用GS的方式，但也有很多时候是获取不到的。比如说在浏览器的内部，它没有通过GS的API开放出来。在2011年、2012年之后W3C把这两个标准开放出来，大部分主流的浏览器也都实现了这样的标准，其实实现的方式比较简单，简单看一下它有一个Navigation timing的接口，它是在哪个时间开始，在哪个时间结束，对应的解析的时间、渲染的时间和建链的时间都可以拿到。我们把代码注入进去之后，你可以拿到所有你要的前端网络，以及前端的解析和性能监控的数据，完了之后对它做一些简单的分析，这样一个监控的界面就出来了。
刚才我们大概介绍了Browser到Server，怎么做一站式APM的溯源。其实对于APP来讲也有类似的方式，监控数据都拿到了，代码都嵌入进去了，肯定有技术手段。
包括后端的服务跟服务之间，服务跟数据库之间。主要是服务跟服务之间，我们说跨应用，包括要实现服务跟服务之间的追踪，API微服务可能用的比较多一点。当我们拿到了这么多的数据之后，可以对它调用链的追踪方式，所有的请求从A服务到B服务、C服务，所有的调用链都可以描述出来，当多个服务同时报警的时候，如何拿这些数据对它问题的根因，到底是什么原因导致的，做一个根因分析。
本次给大家介绍了APM使用场景，包括APM套件里面主要的工具，APM套件里面几个主要的实现方式。我的演讲就到这里，谢谢大家。