百度多维度数据监控采集和聚合计算的运维实践分享(1)
2016-02-20 19:33:47   来源： 颜志杰 StuQ    评论：0 点击：

公式计算也如此，尽早的过滤不需要的数据，我们支持四则，逻辑运算，当agent端具备这样的表达能力后，扩大了agent采集的能力，可以采集很多有意思的监控项：

比如根据nginx的响应时间${cost}和http错误码${errno}，去定义损失pv，通过公式：${cost} > 2000 || ${errno} != 200 时间大于2s或errno不等于200，保证聚合计算功能纯碎性，降低数据传输量。

第二个问题，日志如何规整化，通过命名正则来格式化文本日志，我们用c++写的客户端性能较logstash快不少，这里强调一下，我们没有像logstash一样可以支持多个线程去做正则，只有一个线程来计算，这样做的考虑是：

正则匹配成功性能还可以，一般性能耗在不匹配的日志，出现不匹配的时候，正则会进行一些回溯算法之类的耗时操作，agent设计尽量少进入处理“不匹配日志”。

通过增加“前置匹配”功能，类似大家去grep日志的时候，“grep时间戳|grep–P ‘正则’ ”，字符串查找和正则匹配性能相差极大，agent端借鉴这个思想，通过指定字符串查找过滤，保证后面的日志基本都匹配成功，尽量避免进入“正则回溯”等耗时操作，在正确的地方解决问题。

这种设计保证agent最多占一个cpu。实践证明，通过“前置匹配”，保证进入正则日志基本匹配成功，几千qps毫无压力，而且一般只占一个cpu核30%下。

第三个问题，Tag扩展性，tag是整个多维度监控的精髓，首先我们支持用户自定义任何tag属性，有统一的接口提供，你可以对监控数据上定义任何的tag，比如搜索服务里面可以加上库层属性。

前面提到的运营商、省份，这个通过在agent端用一个ip库来实现反解，当然ip库更新是一个问题，目前随着agent的升级来进行更新，时效性不高。大家可以考下为何不放在server端处理:)

日志采集agent通过上面的一些手段，基本满足了在关键指标的采集上的要求，完成了“标准化”，数据“精简化”的需求。

总结一下，日志采集就是标准化的过程，通过采集配置将日志里面的信息变成多维度的数据模型，发送给后端模块处理。

跟logstash比，想强调前置匹配功能点，没有借鉴其多线程处理的设计，坚持单线程处理，如果监控需要消耗太多的资源去达到，那么我就对这个合理性存疑了。

采集就介绍到这，下面开始介绍实时汇聚计算。

前面提到，多维度数据监控不关注“单机”数据，只关注聚合数据，那首先第一个问题，怎么圈定“聚合"范围?这块功能在名字服务中实现，名字服务不展开。

如上图，通过名字服务完成聚合范围的圈定，支持三级范围圈定(实例id=>服务=>服务组)，一个机器上的模块称为实例，实例发送的数据就是刚刚上面讲的采集agent发出来的，每个数据都带一个id标示，称为实例id。

范围圈定后，通过指定聚合规则，我们拼成一个聚合所需要的数据结构，这个数据是自包含的，即监控数据+聚合规则都包括在里面，如下图所示：

将多维度数据+聚合配置变成聚合自包含数据，自包含数据包含了怎么对这个数据进行计算，上面标示要按照isp运营商汇聚，以及按照运营商和城市来汇聚。

有了聚合自包含数据后，就开始进行汇聚计算，如下图所示：

首先我们只支持一些特定的运维算子，计算count、sum、avg、分位值、min/max基本上能涵盖运维的需求，比如count就是pv，sum/avg/分位值算平响等。

遇到的挑战包括：

1.单个汇聚的数据量过大，比如要计算10w机器的cpu_idle，最终需要要按照filed去累加，过大数据缓存累加，容易OOM，这个需要考虑storm的算子设计。

2.数据范围的圈定是支持三层，也就是数据上卷操作如何来支持。

先来看第一个问题，介绍storm算子的设计，大家看下图：

整个topology做到了无状态，处理的数据是自包含，其次计算加了一层预处理bolt，先用shuffer来处理一层，降低field到聚合bolt的计算量。比如计算10w机器的10s 钟cpu_idle(1wqps)先用10个预处理bolt，每个bolt就是只要累加1/10的数据，然后到下一层的计算量就会较小了。