阿里万亿交易量级下的秒级监控( 三 ) _秒级监控

2.5、准确

文章插图

准确性从这个系统一开始设计时贯穿始终的，也是我们为什么在一开始没有用流式计算的原因。
我们除了 pull 的机制来把控制权保持在服务端之外，还设计了齐全度，这对我们来说是非常重要的。传统的监控一个指标产生一个值就行了，我们每一个值还会对应一个相对应的齐全度。
这个齐全度代表什么意思呢？比如1000台机器里面有几台机器的网络不通或者机器挂掉了，因为机器多了什么问题都会有, 这很正常。
我们会在最后采集完成的时候，多打出来一个指标说1000台机器采集成功900台，失败100台，成功率是90% 。这时候用户就有参考了，如果此时发现交易量下跌了，一看齐全度也下跌了，基本上可以认为是采集的问题导致的下跌，有可能并不是真正的业务下跌，可以来找我们看为什么采集缺失。
因此齐全度是我们特意设计出来，为了让用户直观感受到采集的完整度的一个概念。
有了上面的措施还是不能保证准确，还需要有各种各样的测试来验证这些设计是不是可靠的。所以在线上搭很多环境，测试同学造了各种各样的配置，如虚拟的应用大部分机器都是坏掉的，或者大部分机器没有产生日志。再配合上各种各样的日志计算规则，去实时校验。
准确性回归是我们每次发布之前都必须做的，也是自动触发的过程。只要我们每次打包都会触发一次准确性校验。自灰度就是找一些小白鼠，先发布他们，再发布重要的客户。
2.6、稳定

文章插图

上面是我列举的一些影响系统稳定性的部分问题。最常见的像下发失败，这种好处理，直接重试就可以了。如果已经下发成功了，但是在做的过程中失败的，这就很麻烦了。所以我们 lika 框架很重要的一点，就是为这个服务的。比如 Brain 生成任务以后，它安装成功了一个 Reduce ， Brain 就会去守护这个 Reduce 。
我们有一套机制来保证 Reduce 执行成功，直到返回成功给 Brain ，这个任务才结束。如果没返回， Brain 就会不断探测它，一旦探测到它失败了，比如这台机器连不上了，或者机器是好的但是任务中间出异常挂掉了，那么 Brain 会重试它，换一台机器继续做这个任务。像 Reduce 安装完 Map 后失败了，也是类似的逻辑。
拉日志也会带来一些不可控的事情，就是我不知道要拉的日志到底有多大。有可能我这边分配的计算机器数很少，但是用户日志量非常大，就有可能把我们打爆了。因此我们有一系列自我保护的逻辑，会计算每个监控项的开销，不能高于某一个值。如果高于这个值，说明监控项消耗资源太高了，可能配了一些极其复杂的策略，这时为了自保必须把它kill掉。
我们也实现内存的分配策略，就是每次拉日志的大小是计算出来的。经过一系列的因素计算出来这次能拉多少日志。如果内存不够，等一会儿再去拉。
同时，我们也做了一系列的自我监控。我们是拿自己搭的另外一套环境来监控自己。报警也是在这上面配的，来观察各个租户的状态是不是正常的。
以上这些措施构成了稳定性的保证。
2.7、稳定性验收