關(guān)于UNIX服務(wù)器集群監(jiān)控系統(tǒng)的構(gòu)想，gadfly請進(jìn)

liupch

首先我認(rèn)為以下是要實現(xiàn)的功能。
1，監(jiān)控服務(wù)器的各項動態(tài)性能。包括內(nèi)存，CPU，進(jìn)程狀態(tài)，網(wǎng)絡(luò)狀態(tài)等。
2，系統(tǒng)要做到完全兼容SNMP協(xié)議，做到標(biāo)準(zhǔn)化。
3，報警做到郵件和SMS兩種方式。并且提供基于B/S和C/S的管理功能和報表功能。
4，提供預(yù)警功能和錯誤自動處理功能。也就是在報警的同時能夠執(zhí)行管理員預(yù)先安排好的處理腳本。
5，提供管理員通過手機短信來運行服務(wù)器上指定腳本的功能。
6，提供標(biāo)準(zhǔn)API包，客戶可以做二次開發(fā)。
7，最好可以做成一個版本跨多種平臺運行

其中一小部分功能已經(jīng)實現(xiàn)。大部分功能還只是設(shè)想。但是我個人認(rèn)為還都是可以實現(xiàn)的，雖然會受到很多客觀因素限制。

至于系統(tǒng)結(jié)構(gòu)我還是覺得應(yīng)該遵從SNMP規(guī)定的結(jié)構(gòu)，這樣是標(biāo)準(zhǔn)化而且開放的。
以上是一些簡單的想法，很多細(xì)節(jié)不成熟，還沒仔細(xì)考慮。而且個人認(rèn)為這個系統(tǒng)很大，值的一作，應(yīng)用前景應(yīng)該比較廣泛。

因此我希望成立一個工作室，采取開放的團(tuán)隊式開發(fā)。
不知大家有何看法

gadfly

幾個疑問.

1.如果是完全遵從snmp的框架的話，我相信有不少軟件已經(jīng)做的不錯。如NNM,
CA，而且這些軟件也能夠?qū)崿F(xiàn)你說的報表，告警功能，主機狀態(tài)，具備二次
開發(fā)的API，跨平臺等特征。你怎么能夠保證你的更強大？還是說你的更有特點？

2.從你以前的文章，我看到的是你采集數(shù)據(jù)的方式是你自己定義的協(xié)議，而不是
SNMP的方式，這也是你安全性高的一個原因。是有什么變動么？

另外你初始的設(shè)計目標(biāo)是什么？例如監(jiān)控的規(guī)模，原始數(shù)據(jù)的類型，針對的行業(yè)。

我想這些需要調(diào)研分析清楚了，才好談系統(tǒng)的框架設(shè)計。

無雙

3，報警做到郵件和SMS兩種方式。并且提供基于B/S和C/S的管理功能和報表功能。
5，提供管理員通過手機短信來運行服務(wù)器上指定腳本的功能。

這個比較有新意

無雙

看你的系統(tǒng)
基本需求說明如下
1 系統(tǒng)性能監(jiān)視
2 網(wǎng)絡(luò)防火墻功能
2 使用snmp協(xié)議
3 可定制的告警類型
4 可定制的告警操作，告警操作包括郵件、腳本、SMS
5 管理員可以用SMS操作
6 提供API接口，用戶可以對它進(jìn)行二次開發(fā).API功能應(yīng)該包括（網(wǎng)絡(luò)管理，系統(tǒng)控制，SNMP控制）
7 多平臺

無雙

另外有疑問的是現(xiàn)在網(wǎng)管都開始用CORBA開發(fā)
那么為什么不使用CORBA呢
CORBA的功能更強大

liupch

gadfly老兄，我知道現(xiàn)在很多大廠商都提供這樣的系統(tǒng)，而且作的很強大。
但是有一點問題，我個人感覺就是因為他們的產(chǎn)品做的太強大，功能太多，太復(fù)雜。所以導(dǎo)致價格巨貴，使用復(fù)雜，這些產(chǎn)品只能提供給大客戶，而大部分的中小客戶本來也想用，但是由于其價格問題，還有就是決大本分時間，我們使用的只是該系統(tǒng)的一小部分功能。很多強大的功能對于中小用戶來說基本用不到。所以沒必要花那么多錢去買用不到的功能。

我希望這個系統(tǒng)最好提供一些常用的功能，這些功能是最簡化的，也是最基本的。但是我們并不排斥高級的功能。我希望這個系統(tǒng)能像搭積木一樣擴充。用戶可以根具額外需求來增加另外的模塊�；蛘唛_發(fā)自己的模塊。這也是我為什么要完全兼容snmp和提供API的原因。我說的是兼容snmp，這樣才有利于用戶或這第三方來開發(fā)其他模塊。

關(guān)于監(jiān)控的規(guī)模，現(xiàn)在這套系統(tǒng)里面我已經(jīng)監(jiān)控了將近100臺服務(wù)器，其中有solaris和FreeBSD，您說的原始數(shù)據(jù)類型是什么意思？俺不大明白。至于針對的行業(yè)我現(xiàn)在說不上，因為我覺得有可能非常廣泛。

還有就是無雙老兄問我為什么不用CORBA開發(fā)。
CORBA只是一個規(guī)范，它提供了相互通訊和相接一套規(guī)則。CORBA絕大部分時候是要用java實現(xiàn)的。但是JAVA現(xiàn)在有不足之處就是它太應(yīng)用化，對于底層的開發(fā)顯得非常軟弱無力。而這個東西最基本的就是對于底層的開發(fā)。所以C才是最理想的語言。

gadfly

sorry，這些天，太忙了，我不能說明具體的細(xì)節(jié)，或者很深入的。

原始數(shù)據(jù)的類型：可能是我表達(dá)的不夠準(zhǔn)確，應(yīng)該說是你監(jiān)控的對象是什么？
收集的是這些對象哪方面的信息？例如主機狀態(tài)，還是網(wǎng)絡(luò)服務(wù)狀況？

我覺得監(jiān)控的規(guī)模應(yīng)該是你需要定義的。不同的規(guī)�？梢杂胁煌�的框架設(shè)計。
甚至說你的規(guī)�？梢詿o限擴充，也是一種定義，這也能影響你的設(shè)計。

其次行業(yè)，不同的行業(yè)有不同的需求，例如金融，ICP，idc這些客戶，有太多不同的業(yè)務(wù)需求。也許不影響你的框架，但是影響你對項目的規(guī)劃

至于是否用Corba作通信中間件，還是C作開發(fā)，我想都是分析和設(shè)計以后決定
的事

個人意見，請各位發(fā)表指正

liupch

對于原始數(shù)據(jù)我似乎明白一些您的意思了。其實我最初的本意就要監(jiān)控，采集服務(wù)器本身的動態(tài)數(shù)據(jù)信息，當(dāng)然也包含了服務(wù)器當(dāng)前的網(wǎng)絡(luò)狀態(tài)，但是更看重的是運行在該服務(wù)器上的各種服務(wù)，在精確一些就是進(jìn)程的狀態(tài)。當(dāng)初設(shè)計的時候，監(jiān)控目標(biāo)只限于服務(wù)器本身，不包含路游器等其他一些硬件網(wǎng)絡(luò)產(chǎn)品。

所以這個系統(tǒng)我更感興趣的是服務(wù)器本身的動態(tài)指標(biāo)，而不是像現(xiàn)有的大多數(shù)的網(wǎng)管軟件那樣注重網(wǎng)絡(luò)管理的功能。很多朋友問我能不能自動監(jiān)測出網(wǎng)絡(luò)的拓?fù)浣Y(jié)構(gòu)，讀取服務(wù)器，路游，網(wǎng)關(guān)，甚至打印機的MIB庫等。是因為他們誤解了我的初衷。起碼我現(xiàn)在還沒打算把這些功能加進(jìn)去。

因為我的本意并不是做一個大而全的系統(tǒng)，一是能力所限，二是個人感覺大而全未必就實用。我要作一個含有最基本功能的系統(tǒng)。

關(guān)于系統(tǒng)結(jié)構(gòu)，我還是覺得采用CS結(jié)構(gòu)的比較好。因為現(xiàn)在的設(shè)計是支持分組管理，所以我認(rèn)為監(jiān)控規(guī)模可以無限增大，這主要取決于監(jiān)控服務(wù)器本身性能和配置。

就像gadfly老兄說的，各行業(yè)都有自己獨特的應(yīng)用，所以要想作出針對各個行業(yè)的功能基本上來說是很苛刻的。所以我才要提供API讓客戶能夠自己針對本行業(yè)的特點進(jìn)行二次開發(fā)。我的系統(tǒng)應(yīng)該作為一個提供預(yù)警，報警和執(zhí)行處理腳本的平臺。他是一個基本的平臺，只要按照一定規(guī)范開發(fā)的模塊都可以在這平臺值上運行，并有我的平臺的支持。有點像操作系統(tǒng)和應(yīng)用程序的關(guān)系。這樣我就可以把由于針對不同行業(yè)而需要進(jìn)行不同開發(fā)的風(fēng)險和復(fù)雜度化解掉。還是那句話，做一個最基礎(chǔ)的平臺。

gadfly

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

你就是想實現(xiàn)一個監(jiān)控的通信平臺，在這個平臺的基礎(chǔ)上，可以很容易的開發(fā)出所需要的對不同主機和服務(wù)狀況的監(jiān)控。所謂通信平臺，就是能夠屏蔽各種底層差異，有著一套內(nèi)部自有的通信協(xié)議和體系，并且能為基于這個平臺提供各種所需的服務(wù)。

不知我的定義是否準(zhǔn)確，請各位補充。

有一個疑問？是集中式的監(jiān)控還是分布式的？

至于如何屏蔽底層，這個可以在系統(tǒng)設(shè)計的時候在確定。

就先由需求到系統(tǒng)功能定義吧。
1.能告警和預(yù)警，以及執(zhí)行相應(yīng)的腳本，需要一套消息機制，也就是說平臺具有消息(或者事件)的發(fā)布和訂閱功能。

2.能夠無限擴大監(jiān)控的規(guī)模，這就要求平臺的服務(wù)節(jié)點能夠線性擴充(相信單個
的服務(wù)器滿足不了大規(guī)模的監(jiān)控需求)。這就要求服務(wù)模塊能夠分布部署，并且
能夠協(xié)調(diào)工作。

3.如果支持分布式的監(jiān)控，多點分組管理，能夠動態(tài)的增長監(jiān)控對象，相信需要
整個系統(tǒng)需要命名服務(wù)，用于定位不同的資源和服務(wù)。

4.能夠收集大量的各個主機的服務(wù)狀況，需要系統(tǒng)具備大量數(shù)據(jù)的傳送和存儲功能

這只是我想到的這個系統(tǒng)最基本的功能。請補充

liupch

基本上同意您的觀點。

關(guān)于系統(tǒng)我還是初步計劃采取集中式監(jiān)控。一臺服務(wù)器只作監(jiān)控和各種邏輯判斷，報警，數(shù)據(jù)存儲等工作。這樣可以做到設(shè)置的集中管理，方便管理者。數(shù)據(jù)也全部存儲在這臺服務(wù)器上，盡量減少被監(jiān)控服務(wù)器的系統(tǒng)資源開銷。其實根本原則就是盡量能節(jié)省被監(jiān)控服務(wù)器的資源占用。至于大量的數(shù)據(jù)傳輸可以有以下兩種方案解決：
1，控制采樣頻度，數(shù)據(jù)采樣不要過于頻繁，這樣就減少了采樣得到的數(shù)據(jù)量，但是缺點是犧牲了報警的及時性。
2，數(shù)據(jù)壓縮后在傳輸，缺點是會過多占用被監(jiān)控的服務(wù)器的資源。壓縮算法一般都是比較占用CPU的。

其實關(guān)于系統(tǒng)的結(jié)構(gòu)和如何實現(xiàn)都是技術(shù)問題。我現(xiàn)在很關(guān)心的是大家對這個想法的看法和意見。還有就是可行性。很又可能將來的設(shè)計和我現(xiàn)在實現(xiàn)的方法完全不同。

gadfly老兄，請問您是做技術(shù)那一方面的？