jasper的技术小窝

关注DevOps、运维监控、Python、Golang、开源、大数据、web开发、互联网

监控系统client端的设计

作者:jasper | 分类:监控 | 标签:     | 阅读 1368 次 | 发布:2015-02-08 12:14 a.m.

监控系统是一个网站的守护神,现在主流的几款监控系统,包括zabbix、nagios、ganglia、cacti等等,都各有各的适用场景,也各有各的缺点。监控系统都是基于B/S架构的,包括client端和server|端,如果要开发一套这样的系统应该注意哪些方面呢,下面就先从client端谈谈我的看法。

现在也的确有一些现成的client可供选择包括collectd,statsd什么的,statsd 是一个 NodeJs 的 daemon 程序,简单轻巧,使用 UDP 协议,专门用来收集数据,收集完数据就发送到其他服务器进行处理。 collectd是C语言开发的一个较为古老的工具,像 statsd 一样它也做周期性收集统计数据。

那么既然有轮子了,我们为什么还需要重复地去造呢?因为他们都有各自的缺陷,那我就仅以本文谈谈一个监控系统的client端需要的因素。

一、语言选择

  1. 尽可能选择系统调用少的语言,这能减少client端的负载;
  2. 不需要依赖第三方环境,比如java依赖jvm,python、ruby等等也有自己的运行环境;
  3. 可以跨多个os,像windows、centos、ubantu这些主流的os;
  4. 开发简单,易于扩展,因为很多时候需要自定义很多插件;

现在主流的监控系统的的client端都是C语言写的,而这其中也是有原因的。因为相比于其他的语言C语言调用系统最少(当然如果你能用汇编、或是二进制会调用更少),而且它的运行不依赖环境,在任何的环境下都能运行。但是C太难写了,第三方的库太少,而且现在好像会写C的人也是越来越少了。基于多方考虑,感觉现在正火的Golang或许是一个不错的选择。Golang被称之为the next C,但是相对于C,他有丰富的第三方库;而且Go可以交叉编译,你能很方便地编译成不同os的版本。

二、架构考量

  1. 要轻巧,使之不会影响到其他正常应用的运行;
  2. 数据的发送要和采集做到解耦,因为数据发送那一块不是总是一层不变的;可能由于server端的变动,数据有可能发到队列,也有可能直接发到时间序列的数据库等等,解耦后能方便修改;
  3. 数据发送需要有timeout的设置,而且有retry的机制,如果是server端挂了,不能导致client端一直处于等待;
  4. 要做到监控的metric方便配置,当然我们可以和配置管理结合起来;
  5. 因为是被动模式,所以需要有heartbeat这样的机制,来判断机器是否存活。
  6. client端的调度,不能简单地使用crontab的机制,这样会遇到好多锁的问题;所以我们需要一个调度器,可以用server端发命令的方式。
  7. client的自动发现,这个其实不能算在client的设计里,而是应该放在client的部署里面,这就要求我们的client是方便部署的。

我前面提到的一些现成的client可以拿来参考,因为关于一些os层面的监控都是已经实现了的,我们可以亦或把他们改变语言,亦或是改变一下架构;就能做到他为我用了。

今天就暂时想到这么多,后面如果有新的想法,我会不断地更新上去。这是client端,那么server端我后面也会提到我的一些想法。


转载请注明出处:http://www.opscoder.info/minitor_client.html

别人正在读
其他分类: