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. 帮助企业几乎无成本地、零修改地进行性能、体验监控。
