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

posted on 2016-06-26 20:06  成都笨笨  阅读(6332)  评论(0编辑  收藏  举报