NeekeGaoChitao，云智慧高级架构师，高级PHP开发团队成员之一，云智慧愿景宝产品核心研发成员，以下是他的分享记录：首先从一个刚刚发生的真实案例说起，今天的分享因为刚刚在Perspective的QA环境处理一个宕机故障，耽搁了半个小时。该故障的表现是：应用出现500错误，无法正常访问，同时影响透视宝、监控宝和公共CWOP平台，导致测试进度瘫痪近两个小时。处理过程：查看nginx日志，发现存在无法安装upstream的问题。健康检查模块频繁报错。经排查，发现后端接口与上游断开。但是，此故障不是停机的根本原因。从上游踢完服务后，继续查看：查看apache日志，发现nginx正常转发请求给apache服务，apache服务返回500给nginx，nginx将500错误页面转换后抛出。正常的500错误不再是正常的响应。调整nginx正常抛出500后，继续排查。虽然QA模拟的是生产环境，但没有预期的压力规模，所以应该不会有大的流量高峰。检查nginx和apache状态页面后，确认并继续调查；基本上问题出在应用程序本身；查看应用本身的日志，各种grepless和more都做了，但是没有发现异常的日志。这个时候，估计大部分人都快疯了。我使用了VisionBao的PHPAgent进行排查，大概用了1分钟的时间定位到了问题。 故障的根本原因是QADB挂了。后来确认是监控宝的QA同事跑了一个用户来处理的。脚本。同时也导致Redis挂了。 这个跟Insight的PHPAgent没有关系吗？确实如此！这是PHPAgent的trace_error和trace_exception选项输出的日志。该功能已经在测试中，将于近期正式发布。最后解决问题很简单：关闭nginx，关闭apache，重启mysql，重启redis，重启apache，重启nginx。验证监控宝、透视宝和CWOP平台，恢复。本案例的应用场景是：用户在生产环境中会遇到由数据或流量、代码等引起的各种错误和异常，而这些错误和异常之前没有遇到过，所以没有关注错误和异常to，解决这个时候的问题，就需要用到APM产品视角的错误异常发现功能。该功能可以自动捕获由于资源、接口、数据或其他原因导致的意外异常，并进行报表和统计分析，实现准确提示和预警（预知未来）。CloudWisdomAPM产品的设计初衷：1.有效管理企业应用服务器软硬件和应用本身的性能问题；2、从性能管理的角度补充和充分理解企业应用架构的拓扑结构；3、准确发现并帮助解决企业应用的性能瓶颈问题；4、利用性能管理快速解决问题，规避潜在的应用风险，提升应用价值；为实现上述目标，我们需要做到以下几点：1.准确理解APM的真正含义。APM不仅仅是简单的速度监控和日志管理。很多APM厂商的界面看似很酷，但实际上只是做了很简单的日志统计管理。APM的内容很深很广。厂商喜欢把这张图扔出去糊弄用户，但是真正做到的APM却不多。 根据Gartner的定义，真正的APM需要五个方面：终端用户体验、应用架构映射、应用事务分析、深度应用诊断、分析和报告。去年有国外分析师做了分析比较，可以反映去年的情况，今年还要再做一个比较。2、从终端用户体验出发，实现“端到端”的数据“End2End”在很多年前就被业界提及，现在云智汇提出端到端后，业内几家厂商也在呼吁-到端的概念。端到端有很多种理解。我们的理解是，从最终用户开始，从请求到响应的整个链路所涉及的数据都可以有效串联起来。这样的数据是真正的端到端。实现方法也比较简单。请求会生成一个一致的hash，hash会随着整个请求过程一步步向后或侧向传输，响应会从最后一个或最侧边的响应开始逐步转发或侧向。3.用户行为数据与绩效管理数据的有机结合用户行为数据是大数据中最难以捉摸的一类数据。在大多数情况下，人类的行为偏好是固定的，或者有几个偏好的方向。比如颜色偏好、视角偏好，甚至有些人有特定的角落点击偏好。不同位置或颜色的按钮和链接可能对不同深度的应用程序性能产生不同的影响。同一个功能项，由于不同的偏好设置，也可能导致完全不同的价值体现。PerspectiveMobileSDK和WebRum非常友好的记录了用户的行为偏好和行为链接。4、利用智能发现技术，在应用代码运行时完成拓扑映射。基于第2点中提到的“端”到“端”的实现原则，通过对具体请求的“着色”处理，不难准确获取数据最“端”的请求中的请求链接。所以我们可以基于此为数以亿计的用户行为戴上“应用”的帽子。在这顶帽子下，数据不再是孤岛，而是与生命交替转化。我们可以准确的分析出一个应用的架构拓扑，哪些负载均衡可用，每个请求哪个负载点最重要；我们也可以准确的分析出一个服务集群中有哪些组成节点，以及每一个请求，到底是哪一个或者多个节点被黑了。比如这张漂亮的蜘蛛网： 这在维护旧系统或者刚接手的新系统时非常有用。曾经联系过深圳一家上市公司的CTO，他说他们有10多个架构师，准确画出他们的应用拓扑花了半年时间。5、采用智能探针技术，获取深入的性能指标。这里重点介绍一下SmartAgent各个插件的实现原理。比如刚才PHPAgent的应用。在与龙珠的合作中，一个特别有意思的需求是：缓存key***的统计。不是从缓存层面对状态的概览，意义太过局限，而是从应用层面的准确分析。例如：统计某个特定按键的攻击率。从这个层面来说，绩效指标的获取被赋予了非常深刻的意义。6.深入分析各项大数据指标，获取多维请求响应的散点信息。大数据指标不多说了，我们关注“多维度”和“散点”，比如请求交易数据。一个应用程序中的事务，由于各种参数的存在，基本上是不可枚举的；那么，在各种参数存在的前提下，如何统计响应时间呢？各厂商的做法：请求时间是这段时间最慢的这是相当不负责任的。为什么不负责任：我知道这是我的top10，然后呢？每天、每周、每月都说这个top10，这并不能反映我的应用程序的健康状况。我们需要注意的是那些在一定时间内请求量大，响应时间比较慢的事务。所以我们提出三个维度的交集：单位时间、请求数、响应时间。所以我们可以画一个矩阵图，X轴是时间，左边Y轴是请求数，右边Y轴是平均响应时间。这些交易用向量分散在这个象限中，那么我们可以得出结论，离XY的左边原点最远的距离就是我们关心的。经过抽象和产品整理，我们得到了这样一个非常有意义的分析结果： 整个项目的健康分析状态一目了然，同时也可以快速找到关注的目标。在具体实施中，维信宝经过多次实践演化，最终帮助这些典型客户解决了三个非常现实的需求：1.帮助企业解决普遍存在的“投诉就是反馈”的情况，极大地提升了研发运维，管理人员被动接受反馈，避免业务下滑和直接用户流失。2.帮助企业管理者在项目优化或重构过程中避免盲目的性能和体验优化，并提供有效的性能和体验优化建议以及相应的充分数据依据。3、帮助企业监控性能和体验，几乎没有成本，零修改。
