凌晨四点被公司的监控告警叫醒了,告警的原因是生产环境跑批任务发生故障。即刻起床处理故障,但还是花了不少时间才解决。
这次故障是一次数据校验的跑批任务,校验前面跑批任务的数据是否正确。幸运的是,之前的核心任务已经完成,并没有影响到生产上的交易系统工作。
为什么我这里提到了交易工作呢?因为交易系统是整个系统业务流量的入口,如果交易系统发生故障,那会给公司带来直接的收入损失。
今天我们聊的话题是服务治理,服务治理最终达到的结果就是系统 「7 * 24」 小时不间断服务。
1. 监控告警
公司的这次生产告警很准确,找到系统的直接维护人,并且通知到是哪个跑批任务出了故障。这次告警是通过监控跑批任务中间件的任务执行结果来触发的。
一般情况下,告警有哪些类型呢?我们看下图:
1.1 批处理效率
多数情况下批处理任务是不阻碍业务入口的,所以不需要监控。
在阻碍业务入口的情况下,批处理任务必须要监控。我举两个业务场景:
-
域名系统要通过dns信息和数据库记录来找出脏数据进行交易补偿,这期间客户查询域名信息可能是脏数据
-
银行日终跑批期间是不允许实时交易的,这个「7 * 24」小时不间断服务相违背
这些场景下批处理效率是非常重要的一个监控指标,必须配置超时阈值并进行监控。
1.2 流量监控
常用的限流的指标如下图:
流量监控我们需要注意几点:
-
不同的系统,使用的监控指标是不同的,比如
redis
,可以用QPS
指标,对于交易系统,可以用TPS
-
通过测试和业务量的预估来配置合适的监控阈值
-
监控阈值需要考虑突发情况,比如秒杀、抢券等场景
1.3 异常监控
异常监控对于系统来说非常重要。在生产环境中很难保证程序不发生异常,配置合理的异常报警对快速定位和解决问题至关重要。比如开篇提到的跑批告警,告警信息中带着异常,让我很快就定位到了问题。
异常监控需要注意下面几个方面:
-
客户端
read timeout
,这时要尽快从服务端找出原因 -
对客户端收到响应的时间设置一个阈值,比如
1
秒,超出后触发告警 -
对业务异常一定要监控,比如失败响应码
1.4 资源使用率
生产环境配置系统资源时,一般要对系统资源的使用率有一个预测。比如redis
在当前的内存增长速率下,多久会耗尽内存,数据库在当前的增长速率下多久会用光磁盘。
系统资源需要设置一个阈值,比如70%
,超过这个限制就要触发告