云智慧在应用性能管理中的深化和实践

Neeke 高驰涛,云智慧高级架构师,PHP高级开发组成员之一,是云智慧透视宝产品的核心研发成员,以下是他的分享实录:
先从一个刚刚发生的真实案例开始这次分享,今天的分享延迟了半个小时,原因是我刚刚在处理透视宝QA环境中的一个宕机故障。
这个故障的表现是:应用500错误,无法正常访问,同时影响透视宝、监控宝和公共的CWOP平台,造成近两个小时的测试进度瘫痪。
处理过程:查看nginx日志,发现有upstream不能命中问题,health check模块频繁报错,排查之后发现是一个后端接口从upstream中掉线,然而这个故障并不是导致宕机的根本原因。
从upstream中踢掉该服务后,继续排查:查看apache日志,发现nginx将请求正常地转发到了apache服务,apache服务返回500给nginx,nginx转换500错误页后抛出,正常的500错误已经不能正常地响应。
调整nginx抛出正常500后,继续排查,虽然QA模拟生产环境,但并没有应有的压力规模,于是不应出现大流量洪峰,查看nginx和apache状态页后,确认,继续排查;基本上问题定位在应用本身;查看应用本身的log,各种Less more grep一通,没有发现异常日志,这时一般人儿估计要抓狂了。
我用了透视宝的PHPAgent,进行故障排查,定位问题大约花了1分钟,



故障的根源是QA的DB被打挂了,后来经确认,是监控宝的QA同事在跑一个用户处理脚本。同时导致被打挂的还有Redis。



这和透视宝的PHPAgent没有关系啊?
有关系!这是PHPAgent的trace_error和trace_exception选项,打出的日志。这项功能已经在测试中,即将正式发布上线。
最终解决问题方案非常简单: 关闭nginx,关闭apache,重启mysql, 重启redis,重启apache,重启nginx。验证监控宝、透视宝和CWOP平台,恢复。
这个案例的应用场景是:
用户在生产环境中会遇到各种因数据或流量、代码等造成的错误和异常,而这些错误和异常之前并没有遇到过,因此错误和异常并未被关注,此时解决问题需要使用APM产品透视的错误和异常发现功能。
该功能可以自动捕捉因资源、接口、数据或其他原因造成的未预知异常,并进行汇报和统计分析,做到精准提示和预警(预测未来)。
云智慧APM产品透视宝的设计初衷:
1. 有效管理企业应用服务器软硬件和应用本身的性能问题;
2. 从性能管理的角度补充并充分地了解企业应用架构拓扑;
3. 准确找到并帮助解决企业应用的性能瓶颈点;
4. 使用性能管理快速解决问题,规避潜在的应用风险,从而提升应用价值;
要达到以上目标,我们需要做到这样几个要点:
1.        要准确理解APM的真正含义。
APM绝不仅仅是简单的速度监测和日志管理。不少APM厂商,看似酷炫的界面,其实只是做了一个非常简单的日志统计管理。APM包含的内容非常深广,厂商们喜欢把这张图抛出来忽悠用户,但是真正做到的APM的,其实并不多。

云智慧在应用性能管理中的深化和实践




根据Gartner的定义,真正的APM要求做到5个范围:终端用户体验,应用架构映射,应用事务分析,深度应用诊断,分析与报告。
去年国外一位分析师做过一次分析对比,可以反映去年的情况,今年需要再做一下对比。
2. 从终端用户体验出发,做到数据的“端”到“端”
多年前业内就在提End2End,现在业内几个厂商在继云智慧提出端到端概念之后,也在这么吆喝。端到端有很多种理解,我们的理解是,从终端用户出发,将从request到response整个链路中涉及到的数据,有效地串接起来,这样的数据才是真正的端到端。
实现方式也比较直接,从请求开始产生一致hash,该hash将伴随整个请求过程,一步一步向后或旁进行传递,并从最末或最旁的响应开始,一步一步向前或旁进行回应。
3.用户行为数据与性能管理数据的有机结合
用户行为数据是大数据中最难令人捉摸的一类数据。大多数情况下人的行为喜好是固定的,或有几个偏好方向。如色彩喜好,第一视点喜好,甚至有的人会有特定的边角点击喜好。不同的位置或色彩的按钮、链接,可能在不同的深度会对应用的性能造成皆然不同的影响。
同样的一个功能项,由于不同的喜好设定,也可能会造成完全不同的价值体现。透视宝Mobile SDK和Web Rum,都非常友好地记录地用户的行为喜好,行为链路。
4.使用智能发现技术,完成应用代码运行时的拓扑映射。
基于要点2所讲的“端”到“端”实现原理,为某一个特定的请求进行“染色”加工,不难在数据的最未“端”准确得到一次请求中的请求链路。于是我们可以基于此对数以亿万计的用户行为,戴上一个“应用”的帽子。
在这个帽子下面,数据不再是一个个的孤岛,而是有生命的交替转换。我们可以准确地分析出一个应用的架构拓扑,有哪些负载均衡,每次请求命中的是哪一个负载点;也可以准确地分析出一个服务集群中,有哪些组成节点,每一次请求,究竟命中的是哪一个或多个节点。如这张漂亮的蜘蛛网:

云智慧在应用性能管理中的深化和实践



云智慧在应用性能管理中的深化和实践



这在维护一个旧有系统或刚刚接手的新系统时,是非常有用的。曾经接触过深圳的一家上市企业的CTO,他说他们有10余名架构师,需要用半年之久,才能准确地画出他们的应用拓扑。
5.使用智能探针技术,取得深层次性能指标。
这里着重要说就是SmartAgent各个插件的实现原理。如PHPAgent刚刚的一次应用。在与龙珠的合作中,一个特别有意思的需求,即是:统计cache key的命中。不是从cache层面统览的status,这样的意义过于局限,而是从应用层面,进行准确分析。如:统计某一个具体key的命中率。从这个层面,性能指标的取得,已经被赋予了非常深的意义。
6.深度分析各项大数据指标,得出多维度请求应答的散点信息。
大数据指标不再多说,我们着重说“多维度”和“散点”,比如请求事务数据。一个应用中的事务基本是不可枚举的,因为有各种参数的存在;那么在各种参数存在的前提上,怎么对响应时间进行统计?
各厂商的做法:这段时间内请求时间最慢的事务top10,这是相当不负责任的做法。为什么不负责任:我知道这就是我的top10,然后呢?天天说这个top10,周周说,月月说,这并不能反映我的应用健康状态。我们需要关注的是,某段时间内,请求次数又多,响应时间又相对较慢的这些事务。
所以我们提出了三个维度的交叉:单位时间内,请求次数,响应时间。
于是我们可以画出一幅矩阵图,X轴是时间,左Y轴是请求次数,右Y轴是平均响应时间。这些事务以向量散落在这个象限内,那么我们可以得出,距离XY的左原点,距离最远的,即是我们所关注的。
经过抽象和产品梳理,我们得出了这样非常有意义的分析结果:

云智慧在应用性能管理中的深化和实践



云智慧在应用性能管理中的深化和实践



整个项目对于事务的健康分析状况,一目了然,同时又可以快速找到关注目标。
透视宝在具体实现中,经过了多次实践和演化 最终帮这些典型客户解决了这样非常实际的三个需求:
1. 帮助企业解决普遍存在的“投诉即反馈”的情况,非常有力的改善了研发、运维、管理人员被动接受反馈的现状,避免了业务下降和直接的用户丢失。
2. 帮助企业管理者避免了项目优化或重构过程中,盲目的性能、体验优化,提供了有效的性能、体验优化建议,和相对应的充分的数据佐证。
3. 帮助企业几乎无成本地、零修改地进行性能、体验监控。
云智慧官网:www.cloudwise.com


你可能感兴趣的:(云智慧在应用性能管理中的深化和实践)