Zenoss的监控组件研究

研究的目的：仅仅作为Java再次实现的参考，所以非常肤浅并加上了很多主观猜想。

如有不妥之处，欢迎大家指正。

 

图1

 

上图是一些常用的Zenoss采集组件。左侧为已针对该设备添加的采集组件，右侧为未添加监控的采集组件。

而对应这些采集组件我们发现可以在系统后台的功能代码中找到一一对应关系。

功能代码路径：$ZENOSS_HOME/Product/DataCollector/plugins/

参考截图：

图2

图3

 

例如：图1中"zenoss.cmd.darwin.cpu"的插件我们可以在后台找到相对应的代码(参见图3)，这是一个基于shell采集机制的获取Mac OS X系统CPU信息的采集组件，对应的后台代码路径在"$ZENOSS_HOME/Product/DataCollector/plugins/zenoss/cmd/darwin/cpu.py"，来看前台组件的"."与后台代码路径的"/"完整对应，这样设计确实很方便，有利于自定义监控组件的扩展，我们来大致看看对应代码。

图4

 

走"/usr/sbin/sysctl -a"，然后再截取感兴趣的关键字。最后统一存入Products.ZenModel.CPU这个对象的结构体中。

其他的采集组件代码均实现了"condition"和"process"这两个方法。看来是通过一个统一的模式实现调用的。这模式是什么呢？因为对python一知半解所以说不上来。

但是至此，我们能够得到如下一些结论：

1.zenoss的建模、性能采集组件均与后台的一个功能代码文件直接对应

2.前台可以动态托拽采集组件从而直接实现后台功能代码调用，这个过程不需要重启zope服务

3.后台功能代码默认大致有snmp、cmd/linux、cmd/darwin几类，而其中基于snmp采集的仅cpu采集就有好几个（图2：CpuMap.py、DellCPUMap.py、HPCPUMap.py）

4.前台配置与后台采集组件有一一对应关系，对Java重构实现有参考价值

 

至于采用何种设计模式能够效仿实现这样的对应调用功能呢？我想应该方法很多吧，所谓各村都有各村的高招。

目前我能想到的是否可以采用装饰者模式+反射，待下篇日志再总结汇总。