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.
Lance
----- 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
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
>
>
>
|