百度定义的APM
APM = Application Performance Management，应用性能管理，对企业系统即时监控以实现对应用程序性能管理和故障管理的系统化的解决方案。
应用性能管理是一个比较新的网络管理方向，主要指对企业的关键业务应用进 行监测、优化，提高企业应用的可靠性和质量，保证用户得到良好的服务，降低IT总拥有成本(TCO)。一个企业的关键业务应用的性能强大，可以提高竞争 力，并取得商业成功，因此，加强应用性能管理（APM）可以产生巨大商业利益。
主要功能
应用性能管理主要功能如下：
监测企业关键应用性能：过去，企业的IT部门在测量系统性 能时，一般重点测量为最终用户提供服务的硬件组件的利用率，如CPU利用率以及通过网络传输的字节数。虽然这种方法也提供了一些宝贵的信息，但却忽视了最 重要的因素--最终用户的响应时间。现在通过事务处理过程监测、模拟等手段可真实测量用户响应时间，此外还可以报告谁正在使用某一应用、该应用的使用频率 以及用户所进行的事务处理过程是否成功完成。
快速定位应用系统性能故障：通过对应用系统各种组件（数据库、中间件）的监测，迅速定位系统故障，如发生Oracle数据库死锁等问题。
优化系统性能：精确分析系统各个组件占用系统资源情况，中间件、数据库执行效率，根据应用系统性能要求提出专家建议，保证应用在整个寿命周期内使用的系统资源要求最少，节约TCO。
新应用性能管理环境的一个关键特性是部署在需要的地方：靠近服务。有多种方式来实现这一点：
· 在虚拟机管理程序环境中，监控空间内虚拟机的响应时间和资源消耗情况；
· 在没有管理程序（例如专用物理服务器）或管理程序遥不可及（即在IaaS环境）时，在操作系统上运行；
· 在容器内；
· 在Java或.Net应用服务器环境内；
·在终端用户设备，连续或按需即时下载。[2]
如果这还没有让APM足够模糊，现在又出现了另一种新方法，即基于网络的 APM，这是一个无代理系统，它充分深入到现有网络设备，观察整个企业内的网络内容和流量，分析应用响应时间，并使用有线协议识别错误。这有别于传统的 APM方法，传统方法通常使用安装在应用服务器的代理，从IT环境选定的几个点（包括局域网、广域网和任何相关数据库）获取性能指标样本，以确定哪里的传 统应用出现了问题。
虽然从其优势来看，基于网络的APM仍然有限，因为它通常用于查看应用在网络的节点之间需要走多远，但重要的是，很多供应商正将其包含在APM工具套件中。[3] 2015年开始，APM供应商推出的工具产品更加深入应用[4] ，包括基于用户相应时间的用户体验分析、业务交易分析、业务系统视图分析、故障定位分析等。
下一代APM
新一代APM：让整个IT团队参与应用性能监控。
好的APM可以让IT组织中原本孤立的各个方面集中在一起，比如自动生成 准确的业务应用系统组件关系视图、关系视图实时更新、准确掌握应用访问逻辑关系等。APM工具可以帮助那些原本一直局限于监控自身领域的管理员，使他们成 长为理解应用及其支持基础架构的更有战略价值的性能管理专业人员。
此外，软件即服务提供商也希望有一些不需要指派专职应用管理专业人员的工具
以上内容摘自于百度。
先来看一张APM的性能监测图表
在2015年12月30日10：31-32分一分钟的时间内，响应了100次客户请求，每个服务程序对应的响应时间都给出来了，后面有个APDEX 的性能指数，在这100次响应请求当中，采样50次访问请求，满意的访问请求为43次小于0.5秒，可容忍的访问请求为2等于0.5秒次，不满意的为2次大于0.5秒。
该系统详细反应了一分钟内整套系统的运行效率，试想如果这一分钟如果某个服务出错，可以很清晰的判断出来。如果不够详细，接着看下面的图
很明显的看出来，center.aspx的响应时间超过了预期，
点击查看center.aspx看看为什么这个响应这么慢？
慢的原因是因为执行了两条 Database dt_manager_log-select 语句。还有更详细的的，看看是怎么调用的
清晰的看到具体的语句，是怎么调用， 很明显这就是一个查询语句而查询的速度这么慢肯定是不正常的
接下来这条语句是怎么执行的
这条语句执行了12次，最快845MS 最慢3582MS 系统瓶颈就在这里了，很遗憾我不是DBA，不知道这么解决这个问题，转给专业的DBA有这些信息，应该很容易解决这个问题。
回过头来看我们的平时使用交易系统的遇到的几个运维状态
1、系统登录不了，
一般是怎么操作的？
第一步，用户反映到我们的维护人员
第二步，维护人员鸡飞狗跳的去找原因，服务器，网络，防火墙，ISP，操作系统，应用服务，软件配置，
第三步，短时间找不出问题，就把负责这套系统的，硬件实施工程师，软件实施工程师，开发工程，DBA全部都抓到客户现场，一个一个的排除问题。
第四步，花了很长时间解决问题，也可能是临时解决问题。写总结报告，除了相应的工作人员增加一点工作经验之外，下次出现该问题，还是一样的解决。效率非常底下。
2、系统登录不了，客户有部署常规的如cacti等监控系统
第一步，通过传统的监控系统，可以排除服务器，网络，防火墙，ISP，操作系统的问题，
第二步，询问是否某个员工误操作了，
第三步，如果没有误操作，是否程序存在bug.
第四步，同样需要维护人员费劲脑汁查找，有的时候时间不允许，干脆把故障服务器上操作系统整个作为镜像打包，然后重新安装操作系统，重新部署服务。如果是操作失误还好，这样就相当于解决问题了，如果是BUG过一段时间又出问题了。
3、客户反映系统响应速度很慢
第一步，登录查看各个系统的运行状态
第二步，查看网络的出口的吞吐量，看是否超出ISP提供的带宽
第三步，查看各个服务器的CPU,内存 I/O
第四步，有时候会非常郁闷的发现，所有指标都是正常的，但相应速度就是很慢。
第五步，找不出问题，就把负责这套系统的，硬件实施工程师，软件实施工程师，开发工程，DBA全部都抓到客户现场，一个一个的排除问题。
囧囧囧囧囧囧囧囧囧囧囧！！！！！！！！！！！！！！！！ 貌似这么萝卜白菜一把抓都成解决问题的常态了
4、这套系统最大支持多少个用户同时访问？保持最佳访问效果的时候能支持多少用户
第一步，压测前端的WEB，同时查看各个服务器资源的利用率
第二步，压测中间件，同时查看各个服务器资源的利用率
第三步，压测数据库，同时查看各个服务器资源的利用率
第四步，按照一定比例弄个平均数据。
但这玩意真的准吗？？？？？？？？ 各个测试都是彼此间独立的，前端压测WEB或者客户端的时候推送了那些服务到中间件，这个时候中间件的硬件资源，软件资源利用率是多少？数据库的硬件资源，软件资源利用率
是多少？各个子系统之间测试都是相对独立的，
5、用户量增多，做个二期方案
第一步，加服务器，
第二步，继续加服务器加存储加网络设备加带宽
我们总能想出一些理由，单实际情况是怎么样的呢？ 也许只是需要增加前端的WEB应用就可以了，也许只是数据库性能没有跟上来。根本不必要全部增加服务器。但是我们拿不来具体详细的数据。
6、交易系统卡单了，要查询一下卡在哪里了
先看下有没有常规的监控系统，如果有可以查看各服务器，网络设备的状态，
如果没有就苦逼了，一个一个登陆服务器，网络设备查看LOG日志吧，而且90%的几率是找不出具体的问题。最多只能找到一个大概范围，比如是中间件出了问题，更详细一点，中间件哪里出了问题，最多定位到服务，
然后是服务的承受能力到极限了，还是和其他服务器有冲突，或者是服务对应的网络出问题了，基本上是找不出来的。可能下次又会出现同样的问题。
说了这么多会遇到的问题，结合上的面提到的APM 应用性能管理系统，有没有什么想法？
以前的管理系统都是面向基层层，可以知道服务器状态好不好，性能可不可以，资源利用率怎么样，一般监控到硬件层，操作系统层，对于应用层一般无能为力，有的管理系统可以通过插件的形式监控到如apache tomcat aoracle等应用但彼此是孤立的，并不能把整个系统作为一个整体，为运维人员员提供详细的运维依据，只能靠运维人员的经验去分析判断故障点，性能瓶颈等。
APM的好处显而易见，特别是对于我们电子交易的现状，一般客户没有自己专业的运维人员，基本上90%以上的问题都需要我们的技术人员提供支持，或者现场服务。而每次服务都需要去收集各个子系统的日志，询问客户相关的操作有了这个APM之后，我们可以直接远程部署业务性能监控，随时随地掌控运行状态以及详细运行数据。甚至一个人可以代运维N个客户的交易系统。
有C++难题，加我！