[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Proposal] control storage systems

From: Martin Pala
Subject: Re: [Proposal] control storage systems
Date: Mon, 14 Oct 2002 21:24:54 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020913 Debian/1.1-1

Jan-Henrik Haukeland wrote:

Martin Pala <address@hidden> writes:

For the next major release (4.0?) we have 1) Central configuration
mea culpa - it was planned to 3.0, i hope i will now be more
accurate with the timeframe :)

Well, you have some good excuses :)

2) Monitoring filesystems ++ (Rory + hauk)


Rory do not want monit to remove temporary files. I have no opinion
this way or that, what do other committers think?

-1 for removing files. I think it is sufficient to sent alarm. In the case that the space will come critical, it often signals some problem, that can't be solved just by removing temporary files. If the "watermark" is set carefully and the admin will be noted by monit about it, he can get action before something bad will happen. If the systems behavior is production of unneeded temporary files, it can be solved by simple cronjob.

3) Web-services (instead of SNMP)

+1   We maybe should implement similar mechanism as SNMP traps - it
means active notifycation in the case of failure. I'm not sure if we
should realy support SNMP traps as planned early - what do you think?

I think that web-services could (probably) be used instead of
SNMP. When it comes to push or pull, that is, if a monit server should
push data to a central statistic/report gathering application or the
central application should pull data from X monit servers I'm not
sure. We have to think about this when we write up the design. The
push model is maybe preferable since the central application can wait
for incomming connection instead of knowing the address:socket for
every monit servers to request data.

Base is i think to pull data from monit daemon via present http layer (extended by mentioned methods) - the connection is initiated by data gathering/process mangling station. The note about SNMP traps is motivated to have some mechanism for sending actively trap/signal that some important event occured instead of waiting for connection from monitoring station. This is often used for example to signalize critical HW/SW problem - so if there could be daemon/receiver that can watch such traps and signalize alerts like SNMP does. Maybe there could be two phases - first that just collect data and manipulate monit nodes (client) and the optionaly second, where listener will be implemented to support behavior similar to SNMP traps (the first phase is more important, but the second will probably be easy to implement too).

4) Start work on a GTK or http/browser application for reporting status
  (Should we do GTK or web for the client? Personally I would like
to     play around a bit with GTK but web is probably easier)
I personaly preffer web technologies for similar purposes such as PHP
for their portability and simple remote access

Yepp, me too if I have to be honest about it it.

- on the other side, X application can be preffered on lot of the
sites too. I planne to look on X applications in the near future too
(i preffer QT but it doesn't matter) so it can maybe be good

I have done lots of GUI with Java before (hated it) and as you say it
could be a nice excuse to try to write a GTK+ application. I prefer
GTK above QT since I do not know squat about C++ and do not plan to
learn it either :)

+1 for GTK

(or we can maybe use Zervlet as web alternative :)

Yeah, that would be a good alternative. It's exactely for this type of
applications I have written the Zervlet system. But the thing is, I
partly plan to earn a living from the zervlet system and have thought
long and hard about open source it and finally decided against it.
It's going to be free for non-commercial use, but unfortunately not
open source. I have no problem about using the zervlet system with
monit, in fact I would love to do so, but I'm not sure about others?
I don't have problem to write free aplication for commercial/closed zervlet library - i like monit 'cervlet' concept and it makes me fun to use it. If the zervlet library will be free of charge for non-commercial use (campus, etc.), i don't see any problem. Big firms can have profit from it (such as my employer :) so why they can't pay for the superior engine, that can be used for other applications too (i don't know license condition yet so maybe in fact it can be other way). I personaly planne to use zervlet library for future development, but there other opinions too - we can maybe start with GTK based application to 'join forces' and have completly opensource solution without care about lawyers as noted Christian.

Anyway, I'll summarize this discussion for the 4.0 release after we
have discussed it more and voted on it, and put it up on the monit

reply via email to

[Prev in Thread] Current Thread [Next in Thread]