作者简介：
黄小龙 (易宝支付CTO)
摘要：
随着业务系统的不断迭代建设，基于现有的日志监控系统或报警平台，是否能够精准的定位问题根源及自动化实时捕捉微小的异常或错误在系统运行的过程中会有什么样的影响?面向业务提供全栈性能监控和分析的诉求凸显越来越重要，本文将结合应用监控架构设计的最佳实践原则(《架构即未来》第三十一章节“应用监控”)，结合实际的监控架构设计的思路，引申出应用性能监控建设架构并结合实际案例加以介绍。
“系统事故对企业的损失不言而喻，与其投入重点精力做时候的补救，倒不如提前在之前做好架构设计和业务应用监控。” ——摘自《架构即未来》之应用架构核心思想
监控架构的核心思想
当企业处在快速成长的时期，业务系统也在不断的迭代更新中，如若无法快速识别系统可扩展的瓶颈，必将遭受长期的系统服务中断的痛苦，因为任何微小的异常隐患或程序报错的发生，轻则影响用户体验，造成用户埋怨不断，重则可能会引发系统的故障，如业务系统宕机这般灾难性的故障。在参与过往的业务系统应急处理过程中，经事后RCA(Root Cause Analyze )的源头分析发现均有共同点，就是引发错误的根源被隐藏极深，在事故处理过程中很难短时间内发现源头的端倪，即便通过了严格的业务变更评审及DBA细致的SQL走查，终究会有一些“漏网之鱼”，而这些问题通常在标准的业务覆盖回归测试中很难被发现，也只有在生产运行后的一段时间，被某种“神奇的力量”触发。要想做到事前预防或在最佳时期处理清楚问题隐患，确保业务大规模上量后能够稳健的运行，则需要思考的问题是 “基于现有的日志监控系统或报警平台，是否能够精准的定位问题根源及自动化实时捕捉微小的异常或错误在系统运行的过程中会有什么样的影响?”
如果想要能精准定位并具备相应的能力来捕获这些“漏网之鱼”，便离不开应用监控架构的思路来指导。因为要完成这件事情，有过行业经验的朋友或专家会告诉你，这不仅仅需要有大量的信息来搜集和检索，如统一的大数据日志监控系统(ELK)，还得要有非常得力的应用性能管理(Application Performance Management)工具如云智慧透视宝进行7*24小时实时的监测分析，一旦出现问题可以做到秒级甚至毫秒级别的快速捕捉问题，通过配套的自动检查分析机制，来筛选并验证一些细小的错误，在通过共性部分来反查应用代码，刨根问底，发现存在的隐患是不是引发灾难源头。比如发生了故障，首先会考虑的是“出问题了吗?”之后就是“出什么问题了?”然后就是“问题出在哪里?”最后便是“是什么问题?”随着问题的递进和深入，所需要回答和准备的数据也越来越多，这也是数据规模与问题针对性之间的重要联系(见下图)，作为架构设计者和事故处理负责人必然会问到的这四个核心问题。
图一：数据规模与问题针对性之间的关系，摘自 “《架构即未来》第三十一章 应用监控架构P31.3”
应用监控架构的核心思想就是帮助运维改变这样的窘迫局面：“每次发生系统级别故障，花费很长的时间去定位引发故障的根源如变更的步骤遗落、代码编写不规范、业务SQL的超出标准等，这些根源所引发的问题都不一样，都需要经过各式各样的应急去处理，直到事后的问题整改，完成故障的闭环。看似标准符合逻辑，但这样周而复始下去，往轻的一方面解读是在业务上所反馈出来表象便是让商户或用户不断的试错，正常的业务交易中断，逐渐地丧失了对产品的信心;往重的方面去分析，业务系统的故障，会增加企业的运营成本，甚至影响核心的技术团队实力”我们不妨换个思路来，首先解决“问题发生之前有尽早发现故障前兆的报错或者异常信息?”，因此，引申出了我们在进行业务应用监控架构设计的核心思想，这也是为客户提供更好的服务水平承诺(SLA：Service Level Agreement)的标准化结构设计重点。为提升用户体验，系统的平均响应时间(ART：Average Response Time)和有效成功率(EST：Effective Success Rate)这两大指标也是面向应用监控可量化衡量的参考依据。