[1484] in Coldmud discussion meeting

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

Re: system monitoring

daemon@ATHENA.MIT.EDU (Wed Nov 17 20:21:52 1999 )

From: "Charles Lance Woodson" <AE-Wauric@aephirsden.com>
To: <coldstuff@cold.org>
Date: Wed, 17 Nov 1999 19:02:28 -0800
Reply-To: coldstuff@cold.org

Thanks for the reply, Bruce, that helps.  I'm not sure exactly what we'll do
yet, but that gives us some good options.

I am documenting things as I go through them, but at this point they are
still simply cluttered notes indecipherable by anyone other than myself.
When I organize them into something resembling documentation, I'll forward a
copy to this mailing list.

----- Original Message -----
From: Bruce Mitchener, Jr. <bruce@puremagic.com>
To: <coldstuff@cold.org>
Sent: Wednesday, November 17, 1999 10:33 AM
Subject: Re: system monitoring

> 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
> findings in a quick post to the mailing list, someone else could either
> 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,
> Critical Error, Fatal Error.  Ken on the Cold Dark tells me that syslogd
> 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
> 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