大数据系统之监控系统（一）

一个稳定可靠的系统离不开监控，咱们不只监控服务是否存活，还要监控系统的运行情况。运行情况主要是对这些组件的核心metrics采集、抓取、分析和报警。

1、监控的数据

监控的日志数据通常包括：

v APP、PC、Web 等系统运行Log：采用Flume-NG搜集

v 用户日志 : 采用Flume-NG搜集

v 后端Server（SOA）日志：采用Flume-NG搜集

v 大数据组件的Metrics:JMX和HTTP

v MYSQL等数据库日志：CANAL

不一样公司有不一样的设计要求，这方面都很少说了。

2、组件运行时监控

• 采集agent : Flume-NG
• 消息系统 : Kafka
• 数据库消息系统：MQ
• 实时流处理 : Storm
• 分布式日志存储：hbase
• 分布式搜索 : Elasticsearch

这也是不少互联网日志解决方案的通用选型。可是，这些组件自身提供的监控方案以及他们支持的第三方监控工具，却各不相同：

• Flume-NG : 支持http/jmx metrics，支持的监控工具：Ganglia
• Kafka : 支持jmx metrics，支持的监控工具：Yahoo!
• Storm : 支持jmx metrics，自带Storm UI
• Elasticsearch : 支持http形式的status请求

从上面的结果来看，这显然不符合咱们的指望，咱们的几个关注点：

• 监控统一化，或者说去异构化
• 配置方便，随着系统稳定后，可以自由配置咱们认为很是重要的监控指标
• 统一的可视化，能在一个管控台上一目了然地看到咱们但愿看到的监控指标

总结一下，如上的这些组件在被监控能力上虽然各有差别，不过仍是有一些共同点，那就是：

• Jmx
• http

这两种协议的metrics请求，各个组件都至少支持其中的一个，这也是不少互联网日志解决方案的通用选型。

3、元数据存储与设计

为了达到数据采集通用性和扩展性，让定时数据采集任务具备更好的适应性和自动化。这就须要对采集的数据规范化，须要进行元数据的设计和管理。

咱们设计了一个层次化的组织结构，他们从上到下依次是：

v Meta Category

v Meta Type

v Meta Source

v Job Metadata

v Job Scheduler

　　上面的这些数据都提供了在管控台进行配置管理的功能。为了提高定时任务的可扩展性和自管理性。咱们选择用Zookeeper来存储任务的拓扑以及元数据信息。Zookeeper除了是很好的元数据管理工具，仍是很主流的分布式协同工具。它的Event机制，使得咱们对Job生命周期的自动化管理成为可能。咱们经过对各个ZNode的children ZNode进行监听，来动态感知Job的变化，感知到节点的变化以后，咱们就能够动态建立或者删除某个job。