应用性能监控

先看下百度里面对应用性能监控的基本定义：

APM = Application Performance Management，应用性能管理，对企业系统即时监控以实现对应用程序性能管理和故障管理的系统化的解决方案。

应用性能管理是一个比较新的网络管理方向，主要指对企业的关键业务应用进行监测、优化，提高企业应用的可靠性和质量，保证用户得到良好的服务，降低IT总拥有成本(TCO)。一个企业的关键业务应用的性能强大，可以提高竞争力，并取得商业成功，因此，加强应用性能管理（APM）可以产生巨大商业利益。

资源池-》应用层-》业务层

这个可以理解为APM的一个关键点，原有的网管类监控软件更多的是资源和操作系统层面，包括计算和存储资源的使用和利用率情况，网络本身的性能情况等。但是当要分析所有的资源层问题如何对应到具体的应用，对应到具体的业务功能的时候很难。

传统模式下，当出现CPU或内存满负荷的时候，如果要查找到具体是那个应用，那个进程或者具体哪个业务功能，哪个sql语句导致的往往并不是容易的事情。在实际的性能问题优化中往往也需要做大量的日志分析和问题定位，最终才可能找到问题点。

资源上承载的是应用，应用本身又包括了数据库和应用中间件容器，同时也包括了前端；在应用之上则是对应到具体的业务功能。因此APM一个核心就是要将资源-》应用-》功能之间进行整合分析和衔接。

和BAM的整合

APM不应该是孤立的，可以将APM理解为衔接底层网管和资源监控，上层BAM业务活动监控之间的桥梁。在这里要强调两点，应用本身的性能问题最终会对应到具体的业务功能，同时对于最终的业务人员不关心应用和底层资源而更加关注业务本身的效率和性能。

对于BAM业务监控的重点包括了单个业务功能本身的执行效率和性能分析，也包括了业务系统间集成和协同的效率和分析。对于在SOA或ESB集成平台里面我们会关系系统间的业务和数据集成，这也将纳入到BAM业务监控的范畴里面。

在前面有一篇文章我专门谈到过对于企业IT信息和资产的可视化问题，可以看到IT系统和应用功能，包括其集成架构和基础设置资源的可视化将更好的反应出IT对业务的支撑情况。例如一个端到端业务流程可以看到哪些业务系统在支持，有哪些业务和数据集成；对于一个业务功能我们可以快速的看到支撑的 IT系统，同时还可以朝下分析快速的看到对应使用的资源情况等。要实现这些需要的就是APM和BAM的高度整合和配合。

在讨论APM的具体功能前，还是需要思考下APM出现关键解决的问题有哪些。

首先对于资源和操作系统层的监控有时候很难真实反应出应用是否正常？传统做法有时候也会专门做应用监控，类似在应用里面内置sdk包或心跳检测机制。确保应用本身的中间件和数据库正常。这应该是APM至少应该包括的一个使用场景。

其次，如何及时的发现应用性能问题？同时在应用性能问题发现后能够协助开发人员准确的定义到具体的业务功能点，再进一步定位到具体的数据库 sql或代码组件。要明白有不少场景是虽然资源利用率不高，但是应用响应缓慢或有严重的性能问题，这些都需要到应用监控层面才能够反应出来。

最后，即我们所说的业务层面，即应用究竟承载了多少业务，产生了多少业务单据，有多少业务流程或活动在执行，这些业务本身的响应和性能如何？如何能够准实时的分析和监控这些数据，那么就可以更好的反应出IT系统对整个业务的支撑情况。

核心的功能有哪些？

应用监控状态的监控：首先要反应出当前应用是否运行正常，具体的监控指标涉及到本身类似心跳方式的应用健康检测，同时包括对中间件，线程数，JVM内存，消息，数据库连接池等关键内容的监控。

性能分析和诊断：这个应该是APM相当重要的一个功能，即对于一个业务功能出现性能问题的时候，我们可以快速的进行性能分析和诊断，包括涉及到的业务组件和数据库sql，一个业务请求从发起到每一层调用所花费的具体时间，sql语句本身的时间耗费等，如果能做到这点将帮助我们快速的定位到业务性能问题。

日志采集和告警：前面有文章也谈到过特别是将来的分布式架构下，对于中间件和数据库的准实时日志采集和分析将成为监控和定位问题的一个关键点。因此APM需要具备这个能力，即可以准实时的采集各种中间件，应用的日志信息并进行结构化处理，对于出现告警的日志能够实时的发出告警和邮件通知等。

难点在哪里？

其一是APM产品能够完全平滑的部署，对原有的业务系统没有任何影响，只需要增加相关的配置，这个是APM产品能否通用化的一个关键点。其二是监控的实时性问题，能否做到基本准实时的业务监控和性能告警。其三是性能分析的时候对问题的定位能够深入到哪个程度，如是否能够到具体的组件和sql语句。