支付系统的监控与报警

支付系统设计-6

Posted by shamphone on October 28, 2016

关于监控,在各个技术网站,几乎都是一搜一大把。几个大的互联网公司,也都有开发自己的监控系统。 关于这方面也有不少分享。 这里介绍针对支付系统的监控和报警,但大部分内容,应该来说,对其他系统也是通用的 。

现在基本上 Zabbix 成为监控的标配了。 一个常规的 Zabbix 监控实现, 是在被监控的机器上部署Zabbix Agent,从日志中收集所需要的数据,分析出监控指标,发送到zabbix服务器上。 !zabbix 监控 这种方式要求每个机器上部署 Zabbix 客户端,并配置数据收集脚本。Zabbix的部署可以作为必装软件随操作系统一起安装。

系统监控

先说相对比较简单的系统监控,一般系统监控关注如下指标:

  • CPU负载

  • 内存使用率;

  • 磁盘使用率;

  • 网络带宽占用

这些指标在zabbix agent中会提供默认实现,通过简单配置即可激活。装机时可以考虑统一配置这些监控。

JVM监控

JMX提供了关于JVM的大部分核心信息,启动时设置参数,支持远程访问JMX,之后即可通过接入JMX来实时读取JVM的CPU,内存等信息。zabbix也支持通过JMX来获取信息。

服务监控

服务监控主要指接口的状态监控。 服务监控关注如下指标:

QPS,每秒请求数 对于使用容器的系统,包括Apache Tomcat,Resin,JBoss等,可以从Access Log中采集到每个接口的QPS。没输出Access Log的系统,考虑通过Annotation来规范输出访问计数。当然,这个指标还可以细分为 每秒成功请求数、失败请求数、总请求数等。

请求响应时间 在服务器端监控每个接口的响应时间。简单做法是在方法执行前后打时间戳计算,对于HTTP请求,也可以从access log中获取接口执行时间。当然也可以用annotation来实现统一的执行时间监控。

执行异常数 指程序运行过程中发生的未捕获处理的异常,一般是对场景考虑不周导致的异常发生,比如空指针、错误参数、数据访问等的异常。 这些异常一旦发现,需要修复代码逻辑。 异常在应用日志中一般都会把错误堆栈打印出来。

监控项目 监控数据 数据源
系统监控 CPU使用率 zabbix agent默认采集
系统监控 内存使用率 zabbix agent默认采集
系统监控 带宽使用率 zabbix agent默认采集
JVM内存监控 free, used, heepsize JMX
GC监控 GC内存 GC 日志
GC监控 GC内存回收时间 GC 日志
Tomcat监控 最大会话数、会话数、互动会话数 JMX
Tomcat监控 最大线程数、当前线程数、繁忙线程数 JMX
服务状态监控 404/505等status数量 Tomcat访问日志
服务状态监控 每个接口的访问量 Tomcat访问日志
服务状态监控 每个接口发送的字节量 Tomcat访问日志
服务状态监控 每个接口的最大响应时间 Tomcat访问日志
服务状态监控 每个接口的最平均响应时间 Tomcat访问日志
服务监控 错误数 应用日志

数据库监控

数据库是大部分应用的核心和瓶颈,对其监控尤其必要。监控可以 在应用侧执行,也可以在数据库服务器上做。前者通过应用代码中打印日志来实现,或者直接override 链接池中相关方法来统一输出日志。在数据库服务器上执行监控,需要根据数据库的特点分别设计方案。以MySQL为例,可以通过监控其bin log来获取执行的sql语句以及执行时间。使用Alibaba Canal 来对接MySQL 的BinLog, 接收到BinLog消息后,解析消息数据,可以获取请求的SQL、参数、执行时间、错误代码等信息。

数据库监控重点关注如下指标:

  • 每秒请求数

  • 慢查询处理数

  • SQL语句执行时间

调用链监控

调用链监控指在微服务系统中,跟踪一个请求从发起到返回,在各个相关系统中的调用情况。 调用链监控是跨系统的监控,需要在请求发起时分配一个可以唯一识别本次调用请求(或者成为事务)的ID,这个ID会被分发到每个调用上。之后在调用日志中输出该ID。当所有日志都汇总起来后,可以从日志中分析本次调用的流程。 对于HTTP/HTTPS请求,可以考虑将ID放到Header里面,这样不会影响接口逻辑。

业务监控

业务监控是一个复杂的话题。这里以支付为例,说明业务监控的架构和实现。

支付业务监控

每个支付通道监控包括如下内容:

  1. 支付通道接口请求数: 如果一段时间内接口请求环比大幅度下降,可能是该接口出现问题了。

  2. 支付通道接口请求失败数,即调用接口失败的数量。

  3. 支付通道接口请求延迟。

  4. 支付通道支付失败率。每个通道支付有一定的失败率,如果给定时间内突然有超过这个失败率的情况出现,则可能是通道出现问题了。

  5. 支付通道同步、异步调用次数。

支付接口,如支付、提现、退款、签约、订阅等,监控如下内容:

  1. 总金额,如果总金额有大的波动,则有洗钱的可能。

  2. 每笔平均金额。

  3. 支付成功率

监控架构

实际上对一个业务来说,大部分系统监控的指标是类似的,而按照这种方式,每个指标在各个被监控系统中还需要单独写脚本实现,工作量大。针对这种情况,可以采用日志集中监控的方式来处理。 考虑到日志最终都需要归并到一个日志仓库中,这个仓库可以有很多用途,特别是日常维护中的日志查询工作。多数指标可以在日志上完成计算的。 借助这个系统,也可以完成监控: !zabbix 监控

日志通过Apache Flume来收集,通过Apache Kafka来汇总,一般最后日志都归档到Elastic中。 统计分析工作也可以基于Elastic来做,但这个不推荐。 使用Apache Spark 的 Streaming组件来接入Apache Kafka 完成监控指标的提取和计算,将结果推送到Zabbix服务器上,就可以实现可扩展的监控。 这个架构的优势在于:

  • 监控脚本的跨系统使用。 指定日志规范后, 只要按照这个规范编制的日志,都可以纳入监控,无需额外配置。

  • 服务重新部署时无须考虑监控脚本的部署,所有监控直接生效。

难点在于,提炼一套通用的日志规范,考虑如何通过Spark来分析日志。

日志收集

Flume和logstash都可以用于日志收集,从实际使用来看,两者在性能上并无太大差异。flume是java系统,logstash是ruby系统。使用中都会涉及到对系统的扩展,这就看那个语言你能hold住了。

日志数据流

flume和logstash都支持日志直接入库,即写入hdfs,elastic等,有必要中间加一层kafka吗?太有必要了,日志直接入库,以后分析就限制于这个库里面了。接入kafka后,对于需要日志数据的应用,可以在kafka上做准实时数据流分析,并将结果保存到需要的数据库中。

日志分析

Streaming分析,可以走spark,也可以用storm,甚至直接接入kafka做单机处理。这取决于日志数据规模了。spark streaming是推荐的,社区活跃度高,又集成了多种算法。

日志系统与日志框架

Java主流的日志系统有log4j,JULlogback等,日志框架有apache commons logging,slf等,关于这些系统的历史掌故恩怨情仇八卦趣事,网上有不少资料,这里不详细介绍。

日志系统选型

最好的编程语言是PHP还是Java? 同样的,也有争论:最好的日志框架是slf还是commons-logging?最好的日志系统是Log4j还是Logback?在使用上,它们的API和使用方式大体类似,slf有模版支持,但这也不是关键需求。而性能方面,从我们测试用例中也没有发现哪个系统或框架有明显优势。对性能有决定性影响的是使用方式。

日志高能预警

根据我们的测试,在高并发系统中,关于日志,有如下结论:

  • Log4j与logback在高并发下性能上并无太多差异,不用太纠结使用哪个API,.影响性能的是日志内容的写法和数据量

  • 输出类名和行号会严重影响性能,这需要使用到性能不佳的反射机制。执行频率高,性能要求高的代码,禁用反射,禁用new操作。

  • 高峰期系统出错,如果打印错误堆栈,那绝对是雪上加霜,理由同上。

  • 多线程时输出日志,写锁是影响性能的关键因素。缓解写锁的措施,首选加大日志写入缓冲区,其次是异步打印。异步对性能有提升,但不显著。写锁出问题的一个现象是CPU跑满。

日志分级本身无太大意义。

参考架构

他山之石,可以攻玉


感谢您对本文的关注,如需要及时收到凤凰牌老熊的最新作品,或者有相关问题探讨,请扫码关注“凤凰牌老熊”的微信公众号,在公众号里留言或者回复,可以尽快处理,谢谢。

本文欢迎转载,转载时请注明本文来自 微信公众号“凤凰牌老熊”。