[1475] in Coldmud discussion meeting

root meeting help first first in chain previous in chain previous next next in chain last in chain last

Re: system monitoring

daemon@ATHENA.MIT.EDU (Wed Nov 17 13:51:45 1999 )

From: "Bruce Mitchener, Jr." <bruce@puremagic.com>
To: <coldstuff@cold.org>
Date: Wed, 17 Nov 1999 10:33:57 -0800
Reply-To: coldstuff@cold.org

On Tuesday, November 16, 1999, Charles Lance Woodson wrote:
> Lately I've been adding and removing a lot of monitoring
> messaging to coldcore systems (CML compiler, setting system)
> at Aeternity so that I could easily see how they work.  The
> thought occured to me that a monitoring system might be
> helpful to others coming behind me that would likely wind up
> doing the same thing.  Before I go any further, let me ask if
> there is currently any monitoring system in place that I simply
> haven't discovered?


Well, I'd encourage you to document your findings myself and provide that
for the people following in your footsteps.  No real documentation of many
of the main systems in ColdCore seems to exist.   Even if you just summarize
findings in a quick post to the mailing list, someone else could either read
it in the archives of the list or take it upon themselves to write more
docs.

> If the answer to that is no, does anyone have suggestions as to
> what the best concept for a monitoring system would be?  I was
> thinking of using @set to allow users to hook themselves into
> an event for the specific system.  The system itself would then
> need to be modified to send the appropriate messaging to users
> hooked to the event.  Would such a monitoring system be a major
> performance impactor?  If this isn't acceptable, what about
> simply sending .announce() calls from different systems to a
> monitoring $place?


This doesn't really differ much from a good logging system.  ColdCore also
lacks a good logging system. :)

There are a couple of approaches to take here.

1) Modify the channel system and use it.  Some things that might be useful
in a modification would be the idea of priorities:  Informational, Warning,
Critical Error, Fatal Error.  Ken on the Cold Dark tells me that syslogd is
like this.  The logging systems from some large software projects have
structures resembling that to some degree.  However, this doesn't buy you
logging, analysis, or many other useful things, only the ability for a
person to get spammed with a lot of data.

2) Given time, desire and motivation, I'd probably do something slightly
different.  Java and some of the commercial application servers out there in
the real world have really nice event-driven logging systems.  Firing off
events, having listeners (some of whom might log to files, some might send
email to a paging system, others might broadcast to a channel), and so on
can be a very powerful and extensible system.  It is probably overkill for
what you want it for now, but if you're building a large application in
Cold, I think you'd benefit from this type of model greatly.

 - Bruce