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

标签：

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

一、监控的数据

监控的日志数据一般包括：

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

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

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

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

v MYSQL等数据库日志：CANAL

不同公司有不同的设计要求，这方面都不多说了。

二、组件运行时监控

• 采集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请求，各个组件都至少支持其中的一个，这也是很多互联网日志解决方案的通用选型。

三、元数据存储与设计

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

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

v Meta Category

v Meta Type

v Meta Source

v Job Metadata

v Job Scheduler

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

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

标签：

原文地址：http://www.cnblogs.com/bigdatafly/p/5618474.html