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

这里面存在很多可能会出问题的点，因为集群非常庞大，跑着跑着机器可能就挂掉了，这对我们来说是很正常的，一天挂掉十几台机器也是常有的事。下面说一下怎么解决可靠性的问题。
1.6、关键点

文章插图

上面架构有两个关键点：
一个是 Preload ，就是任务是提前注册的。它不是在需要的时候才生成任务。
我们把任务提前下发下去了，有什么好处呢？假如集群有一些坏掉的机器可能网络很慢也可能连不上，在这个阶段就可以提前发现这些机器屏蔽掉，在后面真正去做任务的时候，延迟就会相应的降低很多，因为不需要再去等去重试了。
同时， Preload 是输入共享的前提，因为不同的人会配同样的日志，并且规则可能也是类似的，我们在这里会做输入共享，去共享日志的采集来减少带宽和 CPU 的消耗，也会共享中间一部分计算的结果。
另一个是 Pull ，主动权控制在服务端，就是服务端发现数据拉不上来，想要放弃还是重试，可以由自己做出决定了。最终服务端会决定多长的时间内，一定把这些全部都处理完，而不会过了很长一段时间还有数据突然推上来的问题了。
还有就是 push 时, 有可能遇到网络抖动, 导致失败, 重试也不成功, 但在 pull 模式下, 相当于把 agent 作为 hadoop 中的 hdfs 节点, 只要日志还在, 我们就有补数据的机会
另外，降低用户开销对我们来说也是比较重要的，像双十一场景，交易的应用开销非常大，我们一定要尽量降低它们的开销。比如占了10%的 CPU ，交易的用户就受不了这个开销。
因此，所有的计算都是在服务端完成，也使得我们的集群规模非常大。
二、规模与挑战
2.1、挑战

文章插图

挑战主要来自于这四个方面，都是因为规模而引起的挑战。
2.2、规模

文章插图

现在有80多个租户，租户基本上一个租户对应一个大的业务，比如交易是一个租户，阿里妈妈是一个租户，高德是一个租户。部署机器最多的时候有6000多台，上面的应用有8000多个，每分钟处理的日志量在3000GB 以上，这只是常态化的日志量并不是最高峰的日志量。这么大的日志量用一个消息中间件去承载也是很困难的, 这也是我们没用流式计算的原因之一.
2.3、场景挑战
1.某应用有上万台服务器，每分钟产生的日志量近1T ，如何在秒级完成采集并输出准确的结果?
2.假如有很多人配置了基于该日志的监控项，如何降低开销?
3.假如过程中有服务器宕机了怎么办?
2.4、快速

文章插图

我们怎么实现快速拉取呢？
在 server 端，其中核心的链路是异步的，所有的通信也是异步的，没有一个地方允许有锁。这两个是通过上面提到的 lika 框架来实现的， lika 框架没有什么特别神奇的地方，把 Akka 的一些核心理念拿出来做了一个简化的框架，更简单更容易维护。
在 Agent 端，最重要的是用了 Zero-copy ，使得读日志不经过任何 CPU 的处理，直接通过 socket 发送出去。这样最大的好处是对用户极小开销，坏处就是不能压缩了。
Randomaccessfile 是配合动态二分法来使用的，配日志的时候没有让用户指定时间字段应该在哪个位置，时间是什么格式的，这些都是我们自己判断的。以及怎么知道用户的某个周期应该推上去的日志是哪些呢？就通过动态二分法来实现的。
Brain 生成拓扑的时候，是有时间戳的。agent 拿到以后，简单来说先看头和尾有没有，因为日志是不断打出来的，采集也是不断进行的，尾部拿到的概率特别大。如果不在就根据这个时间去找，把它做二分查找，最后找到时间。上面提到的唯一开销就来自这里，要去猜时间在哪，在极端情况下对用户的 CPU 也能控制在8%以下。