转载

百度多维度数据监控采集和聚合计算的运维实践分享

百度多维度数据监控采集和聚合计算的运维实践分享

大家好,我是百度运维部平台研发工程师颜志杰,毕业后一直在百度做运维平台开发,先后折腾过任务调度(CT)、名字服务(BNS)、监控(采集&计算);今天很高兴和大家一起分享下自己做“监控”过程中的一些感想和教训。

现在开始本次分享,本次分享的主题是《多维度数据监控采集&计算》,提纲如下,分为3个部分:

1.监控目标和挑战

2.多维度数据监控

2.1.采集的设计和挑战

2.2.聚合计算的设计和挑战

2.3.高可用性保障设计

3.总结&展望

首先进入第一部分 :监控目标和挑战,先抛出问题,装装门面,拔高下分享的档次(个人理解,欢迎challenge)。

百度多维度数据监控采集和聚合计算的运维实践分享

监控期望做到:快速发现问题,定位问题(运维层面),解决问题,甚至要先于问题发生之前,预测/防患未然,形成处理闭环,减少人工决策干预。

先解释一下“定位问题(优先运维层面)”,意思是站在运维角度“定义故障”,不需要定位到代码级别的异常,只需定位到哪种运维操作可以恢复故障即可,比如确定是变更引起的,则上线回滚,机房故障则切换流量等…

不是说监控不要定位到代码级别的问题,事情有轻重缓急,止损是第一位,达到这个目标后,我们可以再往深去做。

再解释下“预测/防患未然”,很多人第一反应是大数据挖掘,其实有不少点可以做,比如将变更分级发布和监控联动起来,分级发布后,关键指标按照“分级”的维度来展示。(记住“分级”维度,先卖个关子:)

“监控目标”这个话题太大,挑战多多。收敛一下,谈一下我们在做监控时,遇到的一些问题,挑两个大头,相信其他在大公司做监控的同学也有同感:

1.监控指标多,报警多

2.报警多而且有关联,如何从很多异常中找出“根因”

今天先抛出来两个头疼的问题,下面开始进入正题“多维度数据监控”,大家可以带着这两个问题听,看方案是否可以“缓解”这两个问题。

进入正题:

百度多维度数据监控采集和聚合计算的运维实践分享

先看第一个问题:监控数据多。监控数据符合28定律,“关键”和“次要”指标需要区别对待,不能以处理了多大数据量引以为傲,需要按重要性分级处理,将资源倾斜到重要数据上分析和处理。

监控一个服务,把精力放在那20%的关键指标数据上,80%的次要指标作为出问题后,分析根因所用,如何采集关键指标,留到采集一章,下面以百度某产品线接入服务为例来说明“关键”指标处理有怎样的需求。

下面以百度地图产品线接入日志为例 (典型的nginx日志):

  1. 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:

  1. "dict" : [   
  2. "CHINANET => 电信"  
  3. "UNICOM => 联通"  
  4. "CMNET => 移动"  
  5. "CRTC => 铁通"    
正文到此结束
Loading...