AiOps基础--APM性能指标浅析（一）

本人在APM产品领域已经工作将近两年，先后工作过成熟的APM产品，也从0到1带过全新的产品，对于这个行业中的国内外产品都有深入的研究。其实一开始接触APM我是头疼的，因为这是个技术性很强的领域，对于我这种技术小白的产品挑战是很大的。但是最后通过潜心的归纳和臭不要脸的问，一个技术小白还是可以在这个领域增长技术知识，并且有所建树。这篇文章也算是对最近两年的工作成果的总结吧。

2012年APM（Application Performance Management 应用性能管理）这个词才传入中国，国外三家做得最好的企业分别是Dynatrace、Appdynamics和Newrelic，而我国目前市面上领先的产品多是基于Newrelic的产品而演进的。

 与大部分外来概念相同，中国对于APM产品多半还是以模仿为基础，然后在市场教做人的情况下，不断完善产品，从而在市场份额中能够占据一席之地。但是经过我的了解发现，大部分国内厂商对于“临摹”这件事还是不是很认真的，比如吞吐率这个概念。吞吐率指的是每分钟事务请求数，单位为rpm（request per minuets），这个指标主要考量的是服务器在某一时段内的承载能力，是关于并发量的指标。但是国内厂商对于这个指标的处理是直接用总的请求数/分钟数，这会造成当一个请求只在某个特定时间使用时，拉长选择时间范围，吞吐率的值会直线下降（大部分时间它的请求数是0），导致吞吐率这个指标和请求数是一致的，不能分析高并发情况下，系统性能的情况。虽然只是个很小的细节，而且用户可能也不会察觉，但是这让我感觉APM这个行业在中国还是有很大的上升空间。

 之所以有这样的一个判断还来自于另一个事实的支撑，那就是真正的一线开发运维人员并没有接纳APM这个概念。在我接触的几十个APM产品开发中，很少有人对这个产品的功能和指标一探究竟，大部分人都是按照我的需求完成功能而已。做APM的人尚且如此，更不要说没有接触的人，他们可能都没有听说过APM这个概念。这也折射了中国工程师的现况，他们夜以继日的加班工作，也只能完成既定的业务功能、解决bug，业余时间还要学习新的技术架构，根本没有时间也没有意义去关注代码性能质量，所以Dynatrace这种技术性超强、逻辑复杂的产品在中国并不适用。虽然它是Gartner在这个领域认定的领导者，但是我也不认为我们现在应该朝这个方向去发展。

 APM的指标归纳下来其实并不多，从聚合之后的指标就是：平均响应时间、请求数、吞吐率、错误率、错误数以及错误/分钟和Apdex值。Apdex值是APM中衡量用户体验的重要指标，它的算法直接百度即可。但是在实践过程中，我发现一些发生了错误的请求统计它的响应时间是没有意义的。因为这些错误会导致请求时间过长或者过短，会影响平均值。而且请求一旦发生了错误关注点就应该在错误而不是时间，所以我们在产品中加入了平均响应时间剔除错误时间的逻辑。而且对于请求的分类也增加到四种：正常、缓慢、非常慢和错误。这样的改进可以让Apdex指标更丰满，毕竟发了404的请求，用户也肯定是不满意的。

 通过大量的数据验证，我们会发现统计型的指标是有局限性的。我们在寻找有问题的请求，如果只通过这些指标可能会错误一些潜在的问题。所以在这些通用指标外，还有些辅助型的指标可以帮助用户更好的寻找问题。例如：响应时间贡献度。按照请求的总响应时间占所有请求的总响应时间比例排序，再通过平均响应时间和吞吐率就可以避免那些，平均响应时间很高，但是请求次数很少没必要关注的情况。再比如P90响应时间，这个指标就可以很好的说明慢请求的分布情况。如果P90时间远高于平均响应时间，那说明这个请求的响应时间跨度很大，极其不稳定需要被关注。

 统计型的各个指标很容易帮助定位问题，但是并不系统，APM的核心拓扑图才是展现整个系统架构运行情况的关键。并且如果需要解决问题还要下钻单次请求，了解更多详尽的指标才能知晓影响代码性能的根因。关于这些，我想可能还需要两三篇文章才可以讲述清楚。