大数据框架下业务监控的一些思考北京珠三角JW万豪酒店隆重召开！徐军是极光第一位严格意义上的大数据工程师。现任大数据平台负责人，见证了极光大数据平台从0到1到如今规模的快速发展。他带给开发者的是大数据架构下业务监控的一些思考。通过类比地球的地质演化过程，描述了大数据架构下业务监控架构的演化历史。寒武纪—搭建Hadoop集群/Zabbix，监控机器基本指标。低等生物。这时，极光有了自己的第一个Hadoop集群。集群规模很小，业务和数据都比较小。这样对应的监控压力也很小，所以我们只使用业界比较流行的Zabbix来做一些基础的机器级别的监控。Zabbix监控机器基本指标，但业务和数据不多，不代表没有问题。有时候会等到第二天甚至第三天，业务部会反馈说集群有问题。上图是传统的监控画面，比较被动。这才刚刚开始，并没有投入多少精力。侏罗纪——开始关注监测/定期检查CDH监测侏罗纪时期，造山运动和火山活动强烈。爬行动物十分发达，出现了巨大的恐龙、飞龙和始祖鸟，植物中以苏铁和银杏最为繁盛。这是因为极光的集群规模随着业务的增长逐渐扩大，开始关注监控问题。鼎晖监控徐军表示，极光当时选择了Cloudera的鼎晖。如上图所示，是CDH监控的部分截图。监控非常细致细致，可以满足当时的大部分需求。所以在此基础上做了一些定制，连接监控系统和告警系统，达到知道集群状态的目的。白垩纪——基于Zabbix监控引入Kafka/customize等组件白垩纪时期，造山运动非常剧烈，我国很多山脉都是在这个时候形成的。在动物中，恐龙最为繁盛，鱼类和鸟类十分发达，哺乳动物也开始出现。植物中，开花植物十分繁盛，热带植物和阔叶树也有出现。此时极光集群规模不断扩大，业务复杂度不断增加。所以对监控的要求越来越高，业务需要引入了很多新的组件，比如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生态开发，第三方依赖较少。石墨架构石墨架构。它由三部分组成：Graphitewab、数据图像的渲染和与用户的交互。Carbon用于实现接收端口和接收指标数据的功能。Whisper是一个时序数据库，是参照ID类型数据库制作的。Graphite下的魔法——函数Graphite下的魔法——函数。如上图所示，可以看到下拉列表中有很多功能。在使用过程中，你会发现基本上正常业务可以用到的指标都可以覆盖到这里。设计师的页面——GrafanaGrafana。如上图所示，为了避免影响用户友好口碑，引入了Grafana组件。它是一个纯前端组件，不做任何数据采集、数据存储、数据计算。它只是一个与用户交互的纯UI，它的后端仍然是Graphite。后台配置GraphiteMetric就是按照Graphite的格式逐级定义目录。后来Graphite提供了一些丰富的方法，后面简单点击就可以完成。一些数据指标也会不时显示在顶部。强大的收集器和聚合器—StatsDStatsD。如上图所示，可以看到StatsD提供了非常多的metric类型，可以对接业务，并且提供了多种语言的collector，在监控场景下性能可以满足要求。Aaggregator可以对数据监控指标进行非常多的聚合操作。监控监视器——CabotCabot。Cabot组件充当用于监视的警报系统。如右图所示，可以看到metric就是我们之前在Graphite中提到的metric的路径。会实时显示图片，下面有几种返回格式。除了Graphite，Cabot还支持Jenkins、HTTP、ICMP等作为监控源。同时提供电子邮件、短信、电话等其他格式。但遗憾的是，这些解决方案都是基于一些开元组件和第三方组件，并没有办法连接到自己的报警系统，因为一般它自己会轮换一套报警系统。不过还好，Cabot是基于python的，所以做一些定制非常简单。监控系统架构监控系统架构。上图展示了整个监控系统的架构，最右边是各个业务。我们通过StatsD的Collector将各种指标收集到StatsD中，并进行一些负载均衡和聚合操作。然后将Metric解析到Graphite服务器。Graphite服务端页面比较丑，所以给Grafana加了个漂亮的帽子。整个系统只能采集数据，不能发现问题，所以在其中加入一个告警组件Cabot，这样整个业务系统的监控架构就完成了。大数据时代监控系统的未来挑战未来大数据时代监控系统将面临哪些挑战？从整个演进过程来看，架构是随着业务的不断发展而发展的。徐军主要解释了以下三点：***：集成大数据各个组成部分的通用监控报警系统。整个大数据平台的架构一定是从简单到复杂。随着业务的发展，旧的组件不能满足需求，然后引入新的组件，架构中加入的组件会越来越多。监控系统也需要覆盖这些组件。如何搭建一个通用的监控系统，而不是一个一个定制，一个一个写复杂的代码，这是一个需要时间去关注的问题。第二：整个监控系统是和内部报警系统相连的，但是还有很多其他的系统。其中，调度系统很有特色。如何像监控系统一样接入调度系统，实现资源的更好利用，是后面需要研究的课题。第三：有监控告警，可以非常及时的发现问题。但是找问题是没有用的，要解决问题。现在都是手动完成，那么如何通过程序自动触发监控系统中的恢复操作，让问题的响应时间从人工干预的几分钟甚至几小时变成程序自动恢复秒，甚至毫秒？更进一步，一个更方便、更易用、更强大的监控系统实际上可以检测到许多传统报警或人工无法检测到的问题，并在问题发生之前发出预警。讲座视频：http://edu.51cto.com/lesson/id-100759.html【讲师简介】徐军，高级Hadoop工程师，大数据平台负责人。极光Push第一位大数据工程师，见证并负责整个极光Push大数据平台的演进。目前负责Hadoop平台、流计算系统、图数据库服务、Spark算法平台等基础数据平台。在Hadoop运维开发和大型分布式计算平台领域拥有丰富的经验。
