> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Sent: den 8 februari 2005 22:17
> To: 'mon@linux.kernel.org'
> Subject: Re: RF(E|C): pseudo.monitor
>
>
>
>
> --On Tuesday, February 08, 2005 8:51 PM +0100 "Peter Wirdemo
> (MO/EMW)"
> <[EMAIL PROTECTED]> wrote:
>
> > I have a question, would it be hard to implement some kind of pseudo
> > monitor, or does it exist?
> >
> > Instead of executing new monitors the pseudo monitor only
> monitors the
> > result of other monitors or watches.
> >
> > The pseudo monitor is not an external monitor. It should be
> implemented
> > internally in mon "core", since all the data from all other
> monitors is
> > in there...
> >
> > Like the example below, instead of running all monitors
> again, the pseudo
> > monitor looks on the result returned by other monitors. The pseudo
> > monitor should trigger an error if the checked
> service/watch has failed
> >
> > Maybe this "feature" is allready possible using the
> 'depend' feature. If
> > so, it's obioulsy not clear to me howto! (i'm using depend, only to
> > supress alerts/monitors)
> >
> > Maybe not the clearest example, but it's late and I have to
> go home...
>
> I've thought about doing something along these lines.
>
> I'd do it by adding new service config option "correlate",
> which would be
> used instead of a monitor option. The tricky questions are:
> How often do we calculate the ok/failed state of this
> service? Do we still
> use an interval for that?
> What do you do about nesting & dependencies.
>
My simple plan was hacking in 'sub run_monitor' ...but I'm not the one to
tell...
Mon should't really know the differens between this monitor and an external
monitor.
Thats why I kept the monitor config option. But in some way tell mon to do the
"monitoring" internally instead. i.e checking values in %watch{...}
If this is possible, all the things about interval, dependencies should be
handled like any other monitor...i.e no change...
Like Harry Moyes told me, this could be implemented using a standard "external"
monitor, using the Mon::Client interface. But one of the goals was minimizing
system resources to do this job.
An external monitor is maybe the cleanest way to solve the problem. I dont
know!.
>
> I don't think this would be incredibly hard to add, but
> getting the details
> right might be tricky.
>
>
> -David Nolan
> Network Software Designer
> Computing Services
> Carnegie Mellon University
>
> _______________________________________________
> mon mailing list
> mon@linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/mon
>
_______________________________________________
mon mailing list
mon@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/mon
