WOT2016互联网运维与开发者峰会上，来自极光推送首位大数据工程师许俊做了以 “大数据架构下对于业务监控的几点思考”为主题的演讲。本文章是把本次分享干货亮点的整理成文字形式，呈献广大的用户。
许俊是极光的第一位严格意义上的大数据工程师，目前是大数据平台的负责人，见证了极光大数据平台从0到1，迅速发展到现在规模的历程。他给开发者带来的是大数据架构下对于业务监控的几点思考。通过类比地球地质演进的过程，来描述大数据架构下的业务监控架构的演进历史。
图1 大数据迅速发展到现在规模的历程
寒武纪——搭建Hadoop集群/Zabbix对机器基本指标监控
几亿年前的地球处于寒武纪，北半球大部分被海水淹没，地球上的生物比较匮乏，主要是一些类似蓝藻、红藻这样的低等生物。这时极光有了第一个Hadoop集群，集群规模非常小，业务、数据也比较少。这样对应到监控上的压力也很小，所以只用业界比较流行的Zabbix做一些基本的机器层面的监控。
图2 Zabbix 对机器基本指标监控
但业务、数据不多，不代表没有问题，有时候会等到第二天，甚至是第三天，业务部门反馈出来，才知集群出现问题。如上图是传统的监控图，比较被动。这刚刚开始，并没有投入太多的精力做这个事情。
侏罗纪——开始重视监控/定时检查CDH监控
侏罗纪时期，有造山运动和剧烈的火山活动。爬行动物非常发达，出现了巨大的恐龙、空中飞龙和始祖鸟，植物中苏铁、银杏最繁盛。这是极光的集群规模随着业务的增长逐渐扩大，开始重视监控问题。
图3 CDH监控
许俊表示，当时极光选用的是Cloudera的CDH， 如上图，是CDH监控上的部分截图，监控是非常详细和细致，能满足当时大部分需求。因此在这个基础上做了一些定制，对接到监控系统和报警系统，达到知晓集群状况的目的。
白垩纪——引入Kafka等组件/基于Zabbix监控做定制
白垩纪时期，造山运动非常剧烈，我国许多山脉都在这时形成。动物中恐龙最盛，鱼类和鸟类很发达，哺乳动物开始出现。植物中显花植物很繁盛，也出现了热带植物和阔叶树。此时，极光集群规模继续扩大，业务的复杂度继续提升，故对监控的要求越来越高，并且因业务需要引进很多新组建，类似Kafka等。
图4 基于 Zabbix 定制的业务监控
针对需求，监控也应随之进步。CDH满不能满足需求的情况下，因有Zabbix传统监控，就在已有的系统前提下做一些定制和开发。如上图，在Zabbix框架前提下做的一些定制化开发，可以看到监控的是其中一个zabbix节点内存使用的情况，也同样对接到告警系统，这样能够覆盖到之前覆盖不到的业务层级。这个过程持续了比较长的时间，但在用的过程中发现两个问题：其一，Zabbix更关注CPU、Memory、Network 等机器指标，对业务指标支持不好。其二，只能做简单的记录和展示，无法灵活地发现问题。
许俊表示，在这个时期极光又遇到新的困难，想看看继续沿着之前的思路想，已有的方案能不能解决。目前监控方案有CDH方案、根据Zabbix做定制方案。CDH方案，虽然Hadoop整个是开元的，但CDH版本的监控这一套是相对比较封闭，并且定制化比较高，所以如果在这个基础上做比较困难。Zabbix也遇到两个问题，好像这条路走不下去了。这时开始反思是不是应该换个方向，换个思路解决这个问题。
新生代——需要一套通用功能丰富的监控系统
新生代时期，地壳有强烈的造山运动，早期的爬行动物绝迹，哺乳动物繁盛，生物达到高度发展阶段。此时对于监控指标的压力越来越大，简单的指标监控已经不能满足要求，出现了越来越多的类似 “平均值”、“最大值”、“求和” 等更灵活多样的需求，这就需要一套更通用和功能丰富的监控系统。
图5 大数据平台的架构
大数据平台架构。如上图是大数据平台的实际架构中的一部分，下面深色域是整个集群核心，在CDH的监控下已经得到比较好的监控。上面Flume是作为数据收集的核心的组建，Kalka是作为现在数据的重点中心。这两个组建目前是没办法覆盖到监控里面去，所以在做一个通用的监控系统时，必须照顾到Kalke、Flume，及类似的开元组建。
图6 基于时间序列的监控
选择Graphite作为核心监控组建。许俊表示，经过调研发现基于时间序列的监控能够满足需求，它可以把监控指标值存储以外，每个指标都会带上一个时间戳，这样就可以基于时间戳做非常多变换。选择Graphite的原因有三：其一，可提供一站式解决方案，完成数据收集、存储和展示比较核心的功能。其二，提供了非常丰富的数据的操作，基本能涵盖我们绝大部分的需求。其三，Graphite整个框架是基于Python生态圈开发，第三方依赖少。
图7 Graphite的架构
Graphite架构。有三个部分组成：Graphite wab，数据图片的渲染及对用户的交互。Carbon，是来实现接听端口，接收指标数据的功能。Whisper，是一个时间序列的数据库，是参考了ID类型数据库做的。
图8 Graphite下的魔法 — Functions
Graphite下的魔法 — Functions。如上图可以看到下拉列表里面有非常多丰富的Functions，在使用过程中会发现，基本上平时业务里面能用到的指标这里面都能覆盖到。
图9 设计师的页面 — Grafana
Grafana。 如上图，为了避免对用户友好信誉的影响，引入Grafana组件。它是一个纯前端的组建，不做任何数据收集、数据存储及数据计算，只是一个纯UI来和用户完成交互，其后端依然是Graphite。在后台配置Graphite Metric，就是按照Graphite的格式，一级一级的把目录定下来，后面Graphite提供一些丰富方法，可以在后面通过简单的点击就能完成。也会在上面时时的把一些数据指标给展示出来。
图10 强大的collector&aggregator — StatsD
StatsD。如上图，可以看到StatsD提供了非常多的Metric的类型，可以对接到业务，并且它提供各种语言的Collector，在监控场景下性能可以达到要求。Aaggregator能对数据监控指标做非常非常多聚合的操作。
图11 监控的监控 — Cabot
Cabot。Cabot组件作为监控的告警系统。如上右图，可以看得到Metric就是我们前面提到Graphite那个Metric的路径，它会实时把图片秀出来，下面有几种格式的返回。Cabot除了Graphite以外，它还支持Jenkins、HTTP、ICMP等作为监控来源。同时它提供其他格式如，邮件、短信和电话等。但是很遗憾它这些方案都是基于一些开元组件和第三方的组件来做，没办法对接到自己的告警系统，因为一般都会自己轮一套告警系统。但是好在Cabot又基于python做的，所以做一些定制非常简单即可。
图12 监控系统架构
监控系统架构。上图是监控系统的整个架构，最右边是各个业务，我们通过StatsD的Collector，把各种Metric收集到StatsD，做一些负载均衡及聚合操作。然后把Metric剖析给Graphite服务器，Graphite服务器页面比较丑，所以给它加了一个漂亮帽子Grafana。整个系统只能收集数据，不能发现问题，所以给它做加一个告警组件Cabot，这样一来整个业务系统的监控架构就完整了。
图13 大数据时代监控系统未来存在的挑战
大数据时代监控系统未来面临哪些挑战呢？从整个演进的过程来看，架构是随着业务不断的发展而发展的，许俊主要讲解了以下三个重点：
第一：要整合大数据各个组件的通用监控告警系统。整个大数据平台的架构，肯定是从简单到复杂，随着业务的发展，旧的组件不能满足需求，然后引入新的组件，会有越来越多的组件加入到架构中。监控系统也需要覆盖到这些组件。怎么样做一套通用监控系统，而不用每个都去定制，每个都去写复杂的代码，这是面需要花时间关注的问题。
第二：整个监控系统和内部告警系统给对接，但是还有很多各种各样的系统。其中非常有特点调度系统，要怎么像对接监控系统一样，把调度系统对接起来，完成资源更好的利用，是后面需要研究的课题。
第三：有监控，有告警，能非常及时的发现问题。但发现问题没用，还要解决问题。现在都是采用人工去做的方式，那怎么样通过程序的方式，在监控系统里面自动触发恢复的操作，让问题响应时间从人工干涉的几分钟，甚至几个小时，变成程序自动恢复的几秒，甚至几毫秒？甚至更进一步，更方便好用及强大的监控系统，其实能发现很多之前传统的告警或人工没办法发现问题，可以在问题发生之前就发出预警。
核心关注：拓步ERP系统平台是覆盖了众多的业务领域、行业应用，蕴涵了丰富的ERP管理思想，集成了ERP软件业务管理理念，功能涉及供应链、成本、制造、CRM、HR等众多业务领域的管理，全面涵盖了企业关注ERP管理系统的核心领域，是众多中小企业信息化建设首选的ERP管理软件信赖品牌。
转载请注明出处：拓步ERP资讯网http://www.toberp.com/
本文标题：大数据架构下对于业务监控的几点思考
本文网址：http://www.toberp.com/html/consultation/10839719385.html
相关文章
