接上篇：ZERO TO ONE |「付钱拉」支付系统架构系列二：如何提高应用的可用性（上篇）
我们讲到「付钱拉」 为了实现系统的可用性做了三点改变，其一是尽可能避免故障，接下来谈谈后面两点内容。
（二）及时发现故障
故障就像鬼子进村，来的猝不及防。当预防的防线被冲破，如何及时拉起第二道防线，发现故障保证可用性，这时候报警监控系统的开始发挥作用了。一辆没有仪表盘的汽车，是无法知道车速和油量，转向灯是否亮，就算“老司机”水平再高也是相当危险的。同样，系统也是需要监控的，最好是出现危险的时候提前报警，这样可以在故障真正引发风险前解决。
实时报警系统
如果没有实时报警，系统运行状态的不确定性会造成无法量化的灾难。「付钱拉」的监控系统指标如下：
实时性-实现秒级监控；
全面性-覆盖所有系统业务，确保无死角覆盖；
实用性-预警分为多个级别，监控人员可以方便实用地根据预警严重程度做出精确的决策；
多样性-预警方式提供推拉模式，包括短信，邮件，可视化界面，方便监控人员及时发现问题。
报警主要分为单机报警和集群报警，而「付钱拉」属于集群部署。实时预警主要依靠各个业务系统实时埋点数据统计分析实现，因此难度主要在数据埋点和分析系统上。
埋点数据
要做到实时分析，又不影响交易系统的响应时间，「付钱拉」在系统各个模块中通过redis实时做数据埋点，然后将埋点数据汇总到分析系统，分析系统根据规则进行分析报警。
分析系统
分析系统最难做的是业务报警点，例如哪些报警只要一出来就必须出警，哪些报警一出来只需要关注。下面我们对分析系统做一个详细介绍：
1-系统运行架构
2-系统运行流程
3-系统业务监控点
「付钱拉」的业务监控点都是在日常运行过程中一点一滴总结出来的，分为出警类和关注类两大块。
出警类：
网络异常预警；
单笔订单超时未完成预警；
实时交易成功率预警；
异常状态预警；
未回盘预警；
失败通知预警；
异常失败预警；
响应码频发预警；
核对不一致预警；
特殊状态预警；
关注类：
交易量异常预警；
交易额超过500W预警；
短信回填超时预警；
非法IP预警；
4-非业务监控点
非业务监控点主要是指从运维角度的监控，包括网络，主机，存储，日志等。具体如下：
服务可用性监控：
使用JVM采集YoungGC/Full GC次数及时间、堆内存、耗时Top 10线程堆栈等信息，包括缓存buffer的长度。
流量监控：
通过Agent监控代理部署在各个服务器上，实时采集流量情况。
外部系统监控：
通过间隙性探测来观察三方或者网络是否稳定。
中间件监控：
针对MQ消费队列，通过RabbitMQ脚本探测，实时分析队列深度；
针对数据库部分，通过安装插件xdb，实时监控数据库性能；
实时日志监控：
通过rsyslog完成分布式日志的归集，然后通过系统分析处理，完成日志实时监控和分析。最后，通过开发可视化页面展示给使用者。
系统资源监控：
通过Zabbix监控主机的CPU负载、内存使用率、各网卡的上下行流量、各磁盘读写速率、各磁盘读写次数(IOPS)、各磁盘空间使用率等。
以上就是「付钱拉」实时监控系统所做的，主要分为业务点监控和运维监控两方面，虽然系统是分布式部署，但是每个预警点都是秒级响应。除此之外，业务系统的报警点也有一个难点，那就是有些报警是少量报出来不一定有问题，大量报警就会有问题，也就是所谓的量变引起质变。
举一个例子，拿网络异常来说，发生一笔可能是网络抖动，但是多笔发生就需要重视网络是否真的有问题，针对网络异常「付钱拉」的报警样例如下：
“
单通道网络异常预警：1分钟内A通道网络异常连续发生了12笔，触发了预警阀值；
多通道网络异常预警1: 10分钟内，连续每分钟内网络异常发生了3笔，涉及3个通道，触发了预警阀值；
多通道网络异常预警2： 10分钟内，总共发生网络异常25笔，涉及3个通道，触发了预警阀值；
日志记录和分析系统
对于一个大型系统而言，每天记录大量的日志和分析日志是有一定的难度的。「付钱拉」每天平均有200W笔订单量，一笔交易经过十几个模块流转，假设一笔订单记录30条日志，可想而知每天会有多么巨大的日志量。
「付钱拉」日志的分析有两个作用，一个是实时日志异常预警，另外一个是提供订单轨迹给运营人员使用。
实时日志预警
实时日志预警是针对所有实时交易日志，实时抓取带有Exception或者Error的关键字然后报警。这样的好处是，如果代码中有任何运行异常，都会第一时间发现。「付钱拉」针对实时日志预警的处理方式是，首先采用rsyslog完成日志归集，然后通过分析系统实时抓取，再做实时预警。
订单轨迹
对于交易系统，非常有必要实时了解一笔订单的状态流转。「付钱拉」最初的做法是通过数据库来记录订单轨迹，但是运行一段时间后，发现订单量剧增导致数据库表过大不利于维护。
「付钱拉」现在的做法是，每个模块通过打印日志轨迹，日志轨迹打印的格式按照数据库表结构的方式打印，打印好所有日志后，rsyslog来完成日志归集，分析系统会实时抓取打印的规范日志，进行解析然后按天存放到数据库中，并展示给运营人员可视化界面。
日志打印规范如下：
“
2016-07-2218:15:00.512||pool-73-thread-4||通道适配器||通道适配器-发三方后||CEX16XXXXXXX5751||16201XXXX337||||||04||9000||【结算平台消息】处理中||0000105||98XX543210||GHT||03||11||2016-07-22 18:15:00.512||张张||||01||tunnelQuery||true||||Pending||||10.100.140.101||8cff785d-0d01-4ed4-b771-cb0b1faa7f95||10.999.140.101||O001||||0.01||||||||http://10.100.444.59:8080/regression/notice||||240||2016-07-2019:06:13.000xxxxxxx||2016-07-22 18:15:00.170||2016-07-2218:15:00.496xxxxxxxxxxxxxxxxxxxx
||2016-07-2019:06:13.000||||||||01||0103||111xxxxxxxxxxxxxxxxxxxxxxxxx
||8fb64154bbea060afec5cd2bb0c36a752be734f3e9424ba7xxxxxxxxxxxxxxxxxxxx
||622xxxxxxxxxxxxxxxx||9bc195a59dd35a47||f2ba5254f9e22914824881c242d211
||||||||||||||||||||6xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx010||||||||||
简要日志可视化轨迹如下：
日志记录和分析系统除了以上两点，也提供了交易和响应报文的下载和查看。
7*24小时监控室
「付钱拉」以上的报警项目给操作人员提供推拉两种方式，一种是短信和邮件推送，一种是报表展示。除此之外，由于支付系统相比互联网其他系统本身的重要性，「付钱拉」采用7*24小时的监控室保证系统的安全稳定。
（三）及时处理故障
在故障发生之后，特别是生产环境，第一时间要做的不是寻找故障发生的原因，而是以最快速度处理故障，保障系统的可用性。「付钱拉」常见的故障和处理措施如下：
自动修复
针对自动修复部分，「付钱拉」常见的故障都是三方不稳定造成的，针对这种情况，就是上面说的系统会自动进行重路由。
服务降级
服务降级指在出现故障的情况下又无法快速修复的情况下，把某些功能关闭，以保证核心功能的使用。「付钱拉」针对商户促销的时候，如果某个商户交易量过大，会实时的调整这个商户的流量，使此商户服务降级，从而不会影响到其他商户，类似这样的场景还有很多，具体的服务降级功能会在后续系列介绍。
本文主要的关注点是如何提供应用的可用性，以「付钱拉」最佳实践为背景来讲述的，后续会继续讨论「付钱拉」支付架构其他系列。
▼
敬请关注！
系列文章相关查看：ZERO TO ONE |「付钱拉」支付系统架构系列一：总体剖析
「付钱拉」最新线下活动：本周六北京FinTech线下活动 | 开通金融、天天投、脉脉、猿圈、SegmentFault向你发出邀请函
快速通道，长按二维码即刻报名
