关于UNIX服务器集群监控系统的构想，gadfly请进

liupch

首先我认为以下是要实现的功能。
1，监控服务器的各项动态性能。包括内存，CPU，进程状态，网络状态等。
2，系统要做到完全兼容SNMP协议，做到标准化。
3，报警做到邮件和SMS两种方式。并且提供基于B/S和C/S的管理功能和报表功能。
4，提供预警功能和错误自动处理功能。也就是在报警的同时能够执行管理员预先安排好的处理脚本。
5，提供管理员通过手机短信来运行服务器上指定脚本的功能。
6，提供标准API包，客户可以做二次开发。
7，最好可以做成一个版本跨多种平台运行

其中一小部分功能已经实现。大部分功能还只是设想。但是我个人认为还都是可以实现的，虽然会受到很多客观因素限制。

至于系统结构我还是觉得应该遵从SNMP规定的结构，这样是标准化而且开放的。
以上是一些简单的想法，很多细节不成熟，还没仔细考虑。而且个人认为这个系统很大，值的一作，应用前景应该比较广泛。

因此我希望成立一个工作室，采取开放的团队式开发。
不知大家有何看法

gadfly

几个疑问.

1.如果是完全遵从snmp的框架的话，我相信有不少软件已经做的不错。如NNM,
CA，而且这些软件也能够实现你说的报表，告警功能，主机状态，具备二次
开发的API，跨平台等特征。你怎么能够保证你的更强大？还是说你的更有特点？

2.从你以前的文章，我看到的是你采集数据的方式是你自己定义的协议，而不是
SNMP的方式，这也是你安全性高的一个原因。是有什么变动么？

另外你初始的设计目标是什么？例如监控的规模，原始数据的类型，针对的行业。

我想这些需要调研分析清楚了，才好谈系统的框架设计。

无双

3，报警做到邮件和SMS两种方式。并且提供基于B/S和C/S的管理功能和报表功能。
5，提供管理员通过手机短信来运行服务器上指定脚本的功能。

这个比较有新意

无双

看你的系统
基本需求说明如下
1 系统性能监视
2 网络防火墙功能
2 使用snmp协议
3 可定制的告警类型
4 可定制的告警操作，告警操作包括邮件、脚本、SMS
5 管理员可以用SMS操作
6 提供API接口，用户可以对它进行二次开发.API功能应该包括（网络管理，系统控制，SNMP控制）
7 多平台

无双

另外有疑问的是现在网管都开始用CORBA开发
那么为什么不使用CORBA呢
CORBA的功能更强大

liupch

gadfly老兄，我知道现在很多大厂商都提供这样的系统，而且作的很强大。
但是有一点问题，我个人感觉就是因为他们的产品做的太强大，功能太多，太复杂。所以导致价格巨贵，使用复杂，这些产品只能提供给大客户，而大部分的中小客户本来也想用，但是由于其价格问题，还有就是决大本分时间，我们使用的只是该系统的一小部分功能。很多强大的功能对于中小用户来说基本用不到。所以没必要花那么多钱去买用不到的功能。

我希望这个系统最好提供一些常用的功能，这些功能是最简化的，也是最基本的。但是我们并不排斥高级的功能。我希望这个系统能像搭积木一样扩充。用户可以根具额外需求来增加另外的模块。或者开发自己的模块。这也是我为什么要完全兼容snmp和提供API的原因。我说的是兼容snmp，这样才有利于用户或这第三方来开发其他模块。

关于监控的规模，现在这套系统里面我已经监控了将近100台服务器，其中有solaris和FreeBSD，您说的原始数据类型是什么意思？俺不大明白。至于针对的行业我现在说不上，因为我觉得有可能非常广泛。

还有就是无双老兄问我为什么不用CORBA开发。
CORBA只是一个规范，它提供了相互通讯和相接一套规则。CORBA绝大部分时候是要用java实现的。但是JAVA现在有不足之处就是它太应用化，对于底层的开发显得非常软弱无力。而这个东西最基本的就是对于底层的开发。所以C才是最理想的语言。

gadfly

sorry，这些天，太忙了，我不能说明具体的细节，或者很深入的。

原始数据的类型：可能是我表达的不够准确，应该说是你监控的对象是什么？
收集的是这些对象哪方面的信息？例如主机状态，还是网络服务状况？

我觉得监控的规模应该是你需要定义的。不同的规模可以有不同的框架设计。
甚至说你的规模可以无限扩充，也是一种定义，这也能影响你的设计。

其次行业，不同的行业有不同的需求，例如金融，ICP，idc这些客户，有太多不同的业务需求。也许不影响你的框架，但是影响你对项目的规划

至于是否用Corba作通信中间件，还是C作开发，我想都是分析和设计以后决定
的事

个人意见，请各位发表指正

liupch

对于原始数据我似乎明白一些您的意思了。其实我最初的本意就要监控，采集服务器本身的动态数据信息，当然也包含了服务器当前的网络状态，但是更看重的是运行在该服务器上的各种服务，在精确一些就是进程的状态。当初设计的时候，监控目标只限于服务器本身，不包含路游器等其他一些硬件网络产品。

所以这个系统我更感兴趣的是服务器本身的动态指标，而不是像现有的大多数的网管软件那样注重网络管理的功能。很多朋友问我能不能自动监测出网络的拓扑结构，读取服务器，路游，网关，甚至打印机的MIB库等。是因为他们误解了我的初衷。起码我现在还没打算把这些功能加进去。

因为我的本意并不是做一个大而全的系统，一是能力所限，二是个人感觉大而全未必就实用。我要作一个含有最基本功能的系统。

关于系统结构，我还是觉得采用CS结构的比较好。因为现在的设计是支持分组管理，所以我认为监控规模可以无限增大，这主要取决于监控服务器本身性能和配置。

就像gadfly老兄说的，各行业都有自己独特的应用，所以要想作出针对各个行业的功能基本上来说是很苛刻的。所以我才要提供API让客户能够自己针对本行业的特点进行二次开发。我的系统应该作为一个提供预警，报警和执行处理脚本的平台。他是一个基本的平台，只要按照一定规范开发的模块都可以在这平台值上运行，并有我的平台的支持。有点像操作系统和应用程序的关系。这样我就可以把由于针对不同行业而需要进行不同开发的风险和复杂度化解掉。还是那句话，做一个最基础的平台。

gadfly

好，我明白了你的大概意思。

你就是想实现一个监控的通信平台，在这个平台的基础上，可以很容易的开发出所需要的对不同主机和服务状况的监控。所谓通信平台，就是能够屏蔽各种底层差异，有着一套内部自有的通信协议和体系，并且能为基于这个平台提供各种所需的服务。

不知我的定义是否准确，请各位补充。

有一个疑问？是集中式的监控还是分布式的？

至于如何屏蔽底层，这个可以在系统设计的时候在确定。

就先由需求到系统功能定义吧。
1.能告警和预警，以及执行相应的脚本，需要一套消息机制，也就是说平台具有消息(或者事件)的发布和订阅功能。

2.能够无限扩大监控的规模，这就要求平台的服务节点能够线性扩充(相信单个
的服务器满足不了大规模的监控需求)。这就要求服务模块能够分布部署，并且
能够协调工作。

3.如果支持分布式的监控，多点分组管理，能够动态的增长监控对象，相信需要
整个系统需要命名服务，用于定位不同的资源和服务。

4.能够收集大量的各个主机的服务状况，需要系统具备大量数据的传送和存储功能

这只是我想到的这个系统最基本的功能。请补充

liupch

基本上同意您的观点。

关于系统我还是初步计划采取集中式监控。一台服务器只作监控和各种逻辑判断，报警，数据存储等工作。这样可以做到设置的集中管理，方便管理者。数据也全部存储在这台服务器上，尽量减少被监控服务器的系统资源开销。其实根本原则就是尽量能节省被监控服务器的资源占用。至于大量的数据传输可以有以下两种方案解决：
1，控制采样频度，数据采样不要过于频繁，这样就减少了采样得到的数据量，但是缺点是牺牲了报警的及时性。
2，数据压缩后在传输，缺点是会过多占用被监控的服务器的资源。压缩算法一般都是比较占用CPU的。

其实关于系统的结构和如何实现都是技术问题。我现在很关心的是大家对这个想法的看法和意见。还有就是可行性。很又可能将来的设计和我现在实现的方法完全不同。

gadfly老兄，请问您是做技术那一方面的？