百度多维度数据监控采集和聚合计算的运维实践分享
大家好，我是百度运维部平台研发工程师颜志杰，毕业后一直在百度做运维平台开发，先后折腾过任务调度(CT)、名字服务(BNS)、监控(采集&计算);今天很高兴和大家一起分享下自己做“监控”过程中的一些感想和教训。
现在开始本次分享，本次分享的主题是《多维度数据监控采集&计算》，提纲如下，分为3个部分：
1.监控目标和挑战
2.多维度数据监控
2.1.采集的设计和挑战
2.2.聚合计算的设计和挑战
2.3.高可用性保障设计
3.总结&展望
首先进入第一部分 ：监控目标和挑战，先抛出问题，装装门面，拔高下分享的档次(个人理解，欢迎challenge)。
监控期望做到：快速发现问题，定位问题(运维层面)，解决问题，甚至要先于问题发生之前，预测/防患未然，形成处理闭环，减少人工决策干预。
先解释一下“定位问题(优先运维层面)”，意思是站在运维角度“定义故障”，不需要定位到代码级别的异常，只需定位到哪种运维操作可以恢复故障即可，比如确定是变更引起的，则上线回滚，机房故障则切换流量等…
不是说监控不要定位到代码级别的问题，事情有轻重缓急，止损是第一位，达到这个目标后，我们可以再往深去做。
再解释下“预测/防患未然”，很多人第一反应是大数据挖掘，其实有不少点可以做，比如将变更分级发布和监控联动起来，分级发布后，关键指标按照“分级”的维度来展示。(记住“分级”维度，先卖个关子:)
“监控目标”这个话题太大，挑战多多。收敛一下，谈一下我们在做监控时，遇到的一些问题，挑两个大头，相信其他在大公司做监控的同学也有同感：
1.监控指标多，报警多
2.报警多而且有关联，如何从很多异常中找出“根因”
今天先抛出来两个头疼的问题，下面开始进入正题“多维度数据监控”，大家可以带着这两个问题听，看方案是否可以“缓解”这两个问题。
进入正题：
先看第一个问题：监控数据多。监控数据符合28定律，“关键”和“次要”指标需要区别对待，不能以处理了多大数据量引以为傲，需要按重要性分级处理，将资源倾斜到重要数据上分析和处理。
监控一个服务，把精力放在那20%的关键指标数据上，80%的次要指标作为出问题后，分析根因所用，如何采集关键指标，留到采集一章，下面以百度某产品线接入服务为例来说明“关键”指标处理有怎样的需求。
下面以百度地图产品线接入日志为例 (典型的nginx日志)：
- 223.104.13.177 - - [27/Jul/2015:16:08:21+0800] "GET /static/apisdk HTTP/1.1" 200 36224 "-" "-" "Dalvik/1.6.0 (Android 4.4.2; HUAWEI MT7)" 0.0020501076098 223.104.13.177 10.202.19.40 10.202.68.25:8210 www.baidu.com
百度地图接入服务需要有这些监控：按照运营商、省份、省份&运营商pv/平响；不同urihttp_code在不同机房pv/平响， 请求手机操作系统版本的pv…
可以看到，一个指标会变为多个指标，比如pv监控项按照 5大运营商*36个省份 * 5个机房将产生900个指标数据，人工管理这种配置很困难，而且如果新增机房，需要新增配置5*36=180个配置，这个就不是人干的了。
同时，这些指标之间是相互关联的，自然想知道地图pv数据，在哪几个运营商，省份，机房有数据，所以需要对监控项进行meta管理。
总结一下，“关键”指标数据需要多角度/多维度观察，会一点变多点，这些多点数据有关联，需要meta管理，简单配置，那么如何来解决呢?
数据模型先行*3(重要的事情说三遍)，选择一个好的数据模型来组织监控数据，解决上面提到的问题，将会有不同的效果，下面是两种数据模型的优劣(也是我们自己的监控历程)。
贴一下图：
监控数据需要多角度观察，这是强需求，在一维数据模型中，将维度信息放在了监控项名字里面，比如 nginx_pv_city_beijing_isp_unicom表示的是北京联通的 pv，nginx_pv_city_beijing_isp_cmnet表示北京中国移动的pv。
这种数据模型，监控项间无关联，除非对名字做一系列规定，并增加对名字做split操作之类，否则很难让上面两个数据产生关联；而且配置的个数是维度的笛卡尔积。
参考aws的cloudwatch，有了多维度数据模型，通过tags来扩展维度，比如把运营商、省份放到tags字段里面，这样用一份配置产生900关联的监控数据；并加入了product字段，在数据分级，权限控制上有作用，后面再展开。
日志里面没有运营商和省份，机房信息，是如何获得的呢?这些我们统一叫做“运维元信息”，先卖个关子，待会在采集那一节展开，不过大家可以先有个印象，tags里面“维度”的取值可以做到很有“扩展性”。
所以结论是，监控数据符合28定律，重要数据需要多角度观察，会产生多个相关联数据，需要有meta管理，需要动态简单配置。多维度数据模型可以很好的解决这些问题，内部我们将处理这数据模型的监控叫“多维度数据监控”。
多维度数据监控在处理/资源消耗上没有减少，900个数据一个不少，所以我们将这套解决方案定位在处理“关键”数据，倾斜资源；而且只关注不同维度的聚合数据，单机数据在单机上存储即可，这都是基于资源的考虑。
铺垫了这么长，现在看看“多维度数据监控”的框架拆解：
典型的分层处理架构，采集=>计算=>存储=>报警+展示，没什么特别说的，想要强调2点：
1.数据模型先行，任何的一个层级只要符合“多维度数据模型”都可以独立使用，每个层级都是服务化的。再强调一下“数据模型先行”。
2.聚合流式计算分布式架构，不暴露开源实现，开源之上都有适配层，很多的处理可以在适配层展开，这个好处在可用性章节具体展开。
下面开始依次介绍多维度采集&聚合计算&高可用性保证三个小节：
先介绍采集，如果大家对logstash熟悉那最好，采集agent很多功能点都是借鉴logstash来写的，当然设计上有些改动，欢迎拍砖。
数据采集就是一个标准化的过程，服务以某种方式吐出数据，采集负责把数据转换为监控数据模型，发往下游处理；所以理想情况是推监控标准，服务链接监控lib，lib将服务核心指标吐过来。
理想我们在努力中，然而… 所以，目前，关键指标大部分通过日志来获取，遇到的挑战是：
1.日志量大=>不传原始日志，而且在agent做各种手段来减少数据传输。
2.日志如何规整化=>参考logstash，用命名正则来规整。
3.tags要做到很有‘扩展性’=> agent端需要支持对tag的自定义。
依次来说，第一如何降低数据传输，首先单机会做聚合，即一个周期内(如10s)，所有tags取值相同的监控会合成一条数据发送。比如百度地图接入服务中，10s内来自北京联通的请求变成一条监控数据，这个策略实践证明对于减少数据是很明显的。
数据减少手段还有ETL和公式计算，agent端就确定哪些数据是不用传递的，比如实现dict映射，只有在字典dict内的值才放行，其他的都归结到other里面。
比如，运营商其实有20+，但一般OP就关注4大运营商，所以可以通过dict将其他的运营商都归结到“other”里面，而且还支持重命名，既规整了tag的取值，又减少了数据的传递，比如有如下的dict：
- "dict" : [
- "CHINANET => 电信" ,
- "UNICOM => 联通" ,
- "CMNET => 移动" ,
- "CRTC => 铁通"
- ]