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

租户间调度/输入共享降低成本最重要的技术手段就是做了输入共享，输入共享在很多情况下能减少起码三倍或者五倍的日志拉取。因为在多数情况下一个日志会产出多个指标，不同的指标也可能会打到同一份日志里面。
怎么做呢？Brain 提前注册了 Reduce ， Reduce 提前注册了 Map ， Map 上有一个关系，就是这个 Map 要采集哪些机器上的哪些日志。最终可以构建出来一个关系来，就是监控项跟机器上的日志的对应关系。比如说第一个监控项要采集100台机器上的某个日志，第二个监控项还是要采集这批机器上的同样日志。这两个任务就合并掉了，最终所有的采集同一份日志的任务都会被合并掉，这是提前注册里面可以做的事情。
关系构建好了以后，就触发一个定时器来触发拉取。
清理僵尸配置我们根据某个配置它最近一段时间被多少人访问，有没有报警，报警后有没有人处理，等等一系列指标计算出监控项的健康度。如果健康度太低，就会通知用户去清理它，减少我们配置量。
统计值优先统计值优先也是现在不得不做的一个优化。因为以前很多应用打的都是流水的日志，以交易举例, 交易有很多环节, 每个环节至少有一行日志，最终有可能1亿笔交易对应100亿条日志。所以会要求大的业务方，把这些值改成统计值，至少是每秒或者每分钟聚合后的值打出来。
2.9、输入共享

文章插图

多个配置一份日志只采集一次
三、技术选择

文章插图

这是我们做监控的过程中做的一些技术选择。拉和推模式各有优缺点，为了准确性选择了拉的模式，不排除推的模式也能搞定准确性，还是会走到推的路线上来，因为架构总是不断迭代的。
计算应该在 Server 端还是 Agent 端执行呢？因为用户接受不了 CPU 使用率过高，会影响正常业务，因此我们最终选择所有的计算都在 Server 端完成。
对于使用开源框架还是自研框架，我们也希望用开源框架，但如果有的地方满足不了或者开源社区的方向跟我们期望的方向不太一致，我们可能就会基于这个框架的思想定制一个简易的。只有核心的设计，代码体量小维护也简单，其实我们计算框架做出来以后，几乎没有产生过什么 BUG ，因外它只做了消息分发线程池管理和故障守护这几件事情。
在数据库选择上，当前我们是直接写 Hbase ，正在和 HiTSDB 团队对接, 这是一个类 OpenTSDB 的存储, 在阿里云上也有提供。
对于监控来说，我们最终选择的自运维，我们几乎没有强依赖任何系统。为什么呢？因为我们有个理念，监控应该是最基础的设施，如果我们强依赖别人，我们监控不了它，所以我们做了一个自运维体系。
以上就是做的一些技术选择，经过了很多次迭代，最终走到了现在的路线。
四、方向
现在我们的方向是这四个：
1.标准化
2.一体化
3.服务化
4.智能化
4.1、标准化: MQL
select avg(cpu.util),max(load.load1) from system where App='AppTest' since 30mselect * from sunfire.1005_SM_13 since 30mselect * from spring filter class='classA' and method='methodB' where ip='192.168.1.1' since 1h
我们叫 MQL ，我们的 MQL 希望让用户能够用一个通用的语法来查询所有的监控数据。甚至是其他监控系统的数据，这样用户不用管数据是哪个平台产生的。MQL 在使用上也比原来的 API 更直观一些，会是我们后面主推的提供给用户 API 的方式。
4.2、一体化