关于监控，在各个技术网站，几乎都是一搜一大把。几个大的互联网公司，也都有开发自己的监控系统。 关于这方面也有不少分享。 这里介绍针对支付系统的监控和报警，但大部分内容，应该来说，对其他系统也是通用的 。
现在基本上 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里面，这样不会影响接口逻辑。
业务监控
业务监控是一个复杂的话题。这里以支付为例，说明业务监控的架构和实现。
支付业务监控
每个支付通道监控包括如下内容：
-
支付通道接口请求数： 如果一段时间内接口请求环比大幅度下降，可能是该接口出现问题了。
-
支付通道接口请求失败数，即调用接口失败的数量。
-
支付通道接口请求延迟。
-
支付通道支付失败率。每个通道支付有一定的失败率，如果给定时间内突然有超过这个失败率的情况出现，则可能是通道出现问题了。
-
支付通道同步、异步调用次数。
支付接口，如支付、提现、退款、签约、订阅等，监控如下内容：
-
总金额，如果总金额有大的波动，则有洗钱的可能。
-
每笔平均金额。
-
支付成功率
监控架构
实际上对一个业务来说，大部分系统监控的指标是类似的，而按照这种方式，每个指标在各个被监控系统中还需要单独写脚本实现，工作量大。针对这种情况，可以采用日志集中监控的方式来处理。 考虑到日志最终都需要归并到一个日志仓库中，这个仓库可以有很多用途，特别是日常维护中的日志查询工作。多数指标可以在日志上完成计算的。 借助这个系统，也可以完成监控： ！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跑满。
日志分级本身无太大意义。
参考架构
他山之石，可以攻玉
- 大众点评的实时监控系统, 目前已经开源到github成CAT系统了。
- 京东 MySQL 监控之 Zabbix 优化、自动化
- Mercury:唯品会全链路应用监控系统解决方案详解
感谢您对本文的关注，如需要及时收到凤凰牌老熊的最新作品，或者有相关问题探讨，请扫码关注“凤凰牌老熊”的微信公众号，在公众号里留言或者回复，可以尽快处理，谢谢。
本文欢迎转载，转载时请注明本文来自 微信公众号“凤凰牌老熊”。
