一个稳定可靠的系统离不开监控，我们不仅监控服务是否存活，还要监控系统的运行状况。运行状况主要是对这些组件的核心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。