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

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