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