大数据架构下对于业务监控的几点思考。通过类比地球地质演进的过程,来描述大数据架构下的业务监控架构的演进历史。

寒武纪——搭建Hadoop集群/Zabbix对机器基本指标监控

 几亿年前的地球处于寒武纪,北半球大部分被海水淹没,地球上的生物比较匮乏,主要是一些类似蓝藻、红藻这样的低等生物。这时极光有了第一个Hadoop集群,集群规模非常小,业务、数据也比较少。这样对应到监控上的压力也很小,所以只用业界比较流行的Zabbix做一些基本的机器层面的监控。

Zabbix 对机器基本指标监控

 但业务、数据不多,不代表没有问题,有时候会等到第二天,甚至是第三天,业务部门反馈出来,才知集群出现问题。如上图是传统的监控图,比较被动。这刚刚开始,并没有投入太多的精力做这个事情。

 侏罗纪——开始重视监控/定时检查CDH监控

 侏罗纪时期,有造山运动和剧烈的火山活动。爬行动物非常发达,出现了巨大的恐龙、空中飞龙和始祖鸟,植物中苏铁、银杏最繁盛。这是极光的集群规模随着业务的增长逐渐扩大,开始重视监控问题。

CDH监控

 许俊表示,当时极光选用的是Cloudera的CDH, 如上图,是CDH监控上的部分截图,监控是非常详细和细致,能满足当时大部分需求。因此在这个基础上做了一些定制,对接到监控系统和报警系统,达到知晓集群状况的目的。

 白垩纪——引入Kafka等组件/基于Zabbix监控做定制

 白垩纪时期,造山运动非常剧烈,我国许多山脉都在这时形成。动物中恐龙最盛,鱼类和鸟类很发达,哺乳动物开始出现。植物中显花植物很繁盛,也出现了热带植物和阔叶树。此时,极光集群规模继续扩大,业务的复杂度继续提升,故对监控的要求越来越高,并且因业务需要引进很多新组建,类似Kafka等。

基于 Zabbix 定制的业务监控

 针对需求,监控也应随之进步。CDH满不能满足需求的情况下,因有Zabbix传统监控,就在已有的系统前提下做一些定制和开发。如上图,在Zabbix框架前提下做的一些定制化开发,可以看到监控的是其中一个zabbix节点内存使用的情况,也同样对接到告警系统,这样能够覆盖到之前覆盖不到的业务层级。这个过程持续了比较长的时间,但在用的过程中发现两个问题:其一,Zabbix更关注CPU、Memory、Network 等机器指标,对业务指标支持不好。其二,只能做简单的记录和展示,无法灵活地发现问题。

 许俊表示,在这个时期极光又遇到新的困难,想看看继续沿着之前的思路想,已有的方案能不能解决。目前监控方案有CDH方案、根据Zabbix做定制方案。CDH方案,虽然Hadoop整个是开元的,但CDH版本的监控这一套是相对比较封闭,并且定制化比较高,所以如果在这个基础上做比较困难。Zabbix也遇到两个问题,好像这条路走不下去了。这时开始反思是不是应该换个方向,换个思路解决这个问题。

 新生代——需要一套通用功能丰富的监控系统

 新生代时期,地壳有强烈的造山运动,早期的爬行动物绝迹,哺乳动物繁盛,生物达到高度发展阶段。此时对于监控指标的压力越来越大,简单的指标监控已经不能满足要求,出现了越来越多的类似 “平均值”、“最大值”、“求和” 等更灵活多样的需求,这就需要一套更通用和功能丰富的监控系统。

大数据平台的架构

 大数据平台架构。如上图是大数据平台的实际架构中的一部分,下面深色域是整个集群核心,在CDH的监控下已经得到比较好的监控。上面Flume是作为数据收集的核心的组建,Kalka是作为现在数据的重点中心。这两个组建目前是没办法覆盖到监控里面去,所以在做一个通用的监控系统时,必须照顾到Kalke、Flume,及类似的开元组建。

基于时间序列的监控

 选择Graphite作为核心监控组建。许俊表示,经过调研发现基于时间序列的监控能够满足需求,它可以把监控指标值存储以外,每个指标都会带上一个时间戳,这样就可以基于时间戳做非常多变换。选择Graphite的原因有三:其一,可提供一站式解决方案,完成数据收集、存储和展示比较核心的功能。其二,提供了非常丰富的数据的操作,基本能涵盖我们绝大部分的需求。其三,Graphite整个框架是基于Python生态圈开发,第三方依赖少。

Graphite的架构

 Graphite架构。有三个部分组成:Graphite wab,数据图片的渲染及对用户的交互。Carbon,是来实现接听端口,接收指标数据的功能。Whisper,是一个时间序列的数据库,是参考了ID类型数据库做的。

Graphite下的魔法 — Functions

 Graphite下的魔法 — Functions。如上图可以看到下拉列表里面有非常多丰富的Functions,在使用过程中会发现,基本上平时业务里面能用到的指标这里面都能覆盖到。

设计师的页面 — Grafana

 Grafana。 如上图,为了避免对用户友好信誉的影响,引入Grafana组件。它是一个纯前端的组建,不做任何数据收集、数据存储及数据计算,只是一个纯UI来和用户完成交互,其后端依然是Graphite。在后台配置Graphite Metric,就是按照Graphite的格式,一级一级的把目录定下来,后面Graphite提供一些丰富方法,可以在后面通过简单的点击就能完成。也会在上面时时的把一些数据指标给展示出来。

强大的collector&aggregator — StatsD

 StatsD。如上图,可以看到StatsD提供了非常多的Metric的类型,可以对接到业务,并且它提供各种语言的Collector,在监控场景下性能可以达到要求。Aaggregator能对数据监控指标做非常非常多聚合的操作。

监控的监控 — Cabot

 Cabot。Cabot组件作为监控的告警系统。如上右图,可以看得到Metric就是我们前面提到Graphite那个Metric的路径,它会实时把图片秀出来,下面有几种格式的返回。Cabot除了Graphite以外,它还支持Jenkins、HTTP、ICMP等作为监控来源。同时它提供其他格式如,邮件、短信和电话等。但是很遗憾它这些方案都是基于一些开元组件和第三方的组件来做,没办法对接到自己的告警系统,因为一般都会自己轮一套告警系统。但是好在Cabot又基于python做的,所以做一些定制非常简单即可。

 监控系统架构

 监控系统架构。上图是监控系统的整个架构,最右边是各个业务,我们通过StatsD的Collector,把各种Metric收集到StatsD,做一些负载均衡及聚合操作。然后把Metric剖析给Graphite服务器,Graphite服务器页面比较丑,所以给它加了一个漂亮帽子Grafana。整个系统只能收集数据,不能发现问题,所以给它做加一个告警组件Cabot,这样一来整个业务系统的监控架构就完整了。

 大数据时代监控系统未来存在的挑战

大数据时代

 大数据时代监控系统未来面临哪些挑战呢?从整个演进的过程来看,架构是随着业务不断的发展而发展的,许俊主要讲解了以下三个重点:

 第一:要整合大数据各个组件的通用监控告警系统。整个大数据平台的架构,肯定是从简单到复杂,随着业务的发展,旧的组件不能满足需求,然后引入新的组件,会有越来越多的组件加入到架构中。监控系统也需要覆盖到这些组件。怎么样做一套通用监控系统,而不用每个都去定制,每个都去写复杂的代码,这是面需要花时间关注的问题。

 第二:整个监控系统和内部告警系统给对接,但是还有很多各种各样的系统。其中非常有特点调度系统,要怎么像对接监控系统一样,把调度系统对接起来,完成资源更好的利用,是后面需要研究的课题。

 第三:有监控,有告警,能非常及时的发现问题。但发现问题没用,还要解决问题。现在都是采用人工去做的方式,那怎么样通过程序的方式,在监控系统里面自动触发恢复的操作,让问题响应时间从人工干涉的几分钟,甚至几个小时,变成程序自动恢复的几秒,甚至几毫秒?甚至更进一步,更方便好用及强大的监控系统,其实能发现很多之前传统的告警或人工没办法发现问题,可以在问题发生之前就发出预警。