在2000年及更早的时候，应用大都是简单的3层架构，即界面层、业务逻辑层和数据访问层。而随着云技术和移动互联网的发展，时代对IT技术提出了更高的要求，它需要适应更迅捷的变化。同时，产品的迭代速度和效率变得更快，应用的复杂性也发生了爆炸式的增长，新时代的应用也变得更加难于管理。
我们能看到，IT部门在面对新生的应用管理方面包括了这样几个方面：
SOA:面向服务的新架构
云资源的利用：类似 AWS EC2及私有云等，公司的IT资源已经演变成为一种云计算能力
大数据：海量的复杂数据，引发了大数据分析的浪潮，例如Hadoop, Storm和Spark等
移动化：在所有的用户流量中，几乎一半以上都来自于移动端
敏捷开发：业务的变化越来越快，随之就要求开发团队需要采用更灵活的架构来应对
在这其中，唯一不变的则是对关键业务流程稳健运行的要求。那么问题来了，
原有的传统的监控工具在面对所有新技术、新架构的应用时挑战巨大，它可能还没准备好应对这种变化，怎么办?
数字化转型规模在愈发扩大，各行业对性能监控提出了更高的要求，传统的监控方案只能定位解决不到30%的问题，怎么办?
传统的监控方案，面对新时代的应用体验秒级要求时往往无计可施，尤其是“最终用户到底在关键业务流程上经历了什么”，怎么办?
快速定位一个最终用户关键业务的性能问题是所有DevOps急于需要解决的，怎么办?
怎样才能保障关键业务流程方方面面的继续稳健运行?
Gartner 在2016 年，对APM 重新规划了标准:
1、 (DEM) 数字化体验监控
支持对操作体验和数字化探针、人和机器的行为优化;与企业的应用和服务交互;包括基于网络和移动端最终用户的真实用户监控(RUM)和综合事务监控(STM)。
2、 (ADTD) 应用发现、追踪和诊断
了解服务端应用之间的关系，将事务映射到节点上，对方法和其他资源进行深度的检查;这是一系列的过程，关注点均在问题的修复，且是相互关联的;包括应用程序拓扑发现和可视化，用户定义的事务处理，应用组件的深度钻取。
3、(AA) 应用分析
机器学习、统计推断和其他方法;自动检测Java和.NET服务端应用支持的HTTP/S事务的性能异常的来源(或根本原因)。
即只有满足以上3个条件才能称作真正的APM 。而在这组概念中，Gartner 认为APM 的核心功能则是能够基于应用去做问题的发现与诊断。
2016 年，为了能够帮助DevOps团队快速实现不同业务逻辑下的性能排障，国内领先的应用性能管理服务提供商听云推出了全栈溯源解决方案，它在国内首次实现了全端、跨应用监控。2017 年，面对现阶段复杂的全栈环境，定位问题变得更加复杂，为了能够对应用性能问题更加深入的追踪与诊断，听云全栈溯源进行了全面升级。
什么是全栈溯源？
从用户体验出发，基于事务请求进行全栈问题的定位追踪叫全栈溯源。
全栈溯源实现了什么功能？
APP端事务请求全栈溯源
浏览器页面事务请求全栈溯源
拨测事务请求全栈溯源
单用户全栈溯源
全栈溯源对DevOps的价值？
1、清晰责任界定：可以为各部门提供统一的信息平台，共同讨论目前应用发生的问题，以及解决方案。
监控：应用的用户体验细节指标，包括用户前端响应时间、网络响应指标细节，以及后端各API接口，每个服务的健康状况，识别每条性能曲线上是否存在突发点。
问题定位：隔离用户的问题，界定问题发生的位置，判定是前端还是后端或者是网络的问题，甚至是数据库问题，并且将以业务部门看懂的方式在平台上以可视化的图表展示出来。
解决：直接在平台报表里找到根本原因，无论是某个程序的某段代码，或者是相关的SQL语句，还是DNS解析异常，甚至是前端图片的异常加载，这些无需专业人员来操作，就能够以简单明白的报表的方式，展示给各个部门，从而容易直接处理。
2、告警: 严重问题自动响应
在过去，当遇到客户投诉后，分析判断问题是如何发生的、运维研发介入直到最终解决，这一过程往往要经历至少一周以上的时间，甚至可能是数星期。听云全栈溯源是基于客户关键业务的自动质量控制平台，将把以周为单位的解决问题时间缩短为几分钟。同时，当发生严重问题时，系统会进行自动响应，及时告警。
全栈溯源典型应用场景：
全栈溯源下的web端慢页面追踪
通过听云Browser发现某应用某关键业务的页面平均响应时间过高，通过观察页面性能分解图发现，该页面主要耗时发生在服务端请求处理过程中。
通过慢页面下的元素追踪功能发现，后端请求发生了响应慢的情况，接下来可以钻取查看具体在服务端的处理情况。
通过追踪，跳转到听云Server查看对应请求处理的trace详情。
通过详情的摘要信息，可以看到最耗时的是蓝色部分的jdbc操作，它执行的这一次操作相对于这次后端处理耗时来说最长的，通过这点发现了主要耗时的位置。
钻入后需要查看该SQL耗时是由哪个SQL语句造成的，点击追踪详情。从追踪详情请求入口开始，查看各项耗时，发现某条SQL语句占用了95%以上的耗时。这样就形成了一条完整查看问题出处的链路。
通过粗略的SQL语句可以看到，这条慢SQL做了一些count统计以及跨表查询、distinct处理，它有很多可以优化的地方。这就是一个问题从开始到最后分析的整个过程。
同时，全栈溯源还可以实现——
全栈溯源下的移动端慢请求追踪
全栈溯源下的移动端慢交互追踪
全栈溯源下的服务端慢应用过程追踪
