On Tue, 17 Sep 2002, David Nolan wrote:
> I'm trying to do the 'right' thing as much as possible. Which means I'm
> only loading 'state' information, not 'config' information.
my point is that if the "config" stuff changes, then the "state" info
must be assumed to be invalid, and it should be reset. this is why the
config reload causes a state reset; i chose to solve that problem at a
later time :)
all you need to do after a reload is simply compare the config values of
the old config to the new config, and if they're different, then reset
the state.
> I'm looking at that now, and I'm not really sure how its meant to be used.
> The documentation is pretty light, and doesn't provide any real examples.
> Is it just supposed to be a way to make it easier to parse the data given
> to a client by 'list opstatus', etc, and easy to generate data in the same
> format?
the idea is that mon, monitors, and alerts use those methods to pass
data back and forth to each other. it's not much of a "protocol" per se
(there isn't interaction such as an acknowledgement/sequencing/etc.),
but it's minimally a way of formatting the data.
> Are you intending for monitor scripts to start sending extra data to mon
> over the Mon socket, instead of via STDOUT?
no, all stdin/stdout.
> While some object to the STDOUT method, I think its cleaner then the socket based
>approach
i didn't mean to imply anything about the transport. i see no reason
that the "protocol" couldn't be used via either stdin/stdout or via a tcp
socket. actually, the trap handling should probably be handled via this
new "protocol", and there should be a "receive status" or "receive trap"
command in the existing protocol that the clients already use.
> see several potential problems with the socket based approach. (For
> example: Every monitor script will have to be aware of the name of the
> hostgroup/service it is being run on
this is already the case with traps--the sending agent must know to
which group/service the trap should be sent. again, i didn't imply that
monitors would be forced to initiate a connection to the mon server to
deliver their status.
however, if you'd like monitors spawned by the server to know which
group/service they're running as, then add this to sub run_monitor
in the proper place:
$ENV{"MON_GROUP"} = $group;
$ENV{"MON_SERVICE"} = $service;
> Are you particularly attached to that format for passing extra data between
> monitors and mon?
no.
> Personally I find the XML based format I posted
> yesterday much more palatable, but I'm flexible either way.
i'm all for an ascii format which is both easily comprehended by a human
and efficient to parse by a computer. i'm not sure how xml does or the
perl xml libs do with the latter requirement.
> I've just been using the same terminology that mon uses. 'hostgroups' and
> 'hosts'. In fact the Mon manpage doesn't reflect what you say the intent
> was. The manpage says a hostgroup is 'A single host or list of hosts,
> specified as names or IP addresses'. My impression has always been that
> putting things other then hosts in hostgroups is really just taking
> advantage of the fact that mon doesn't enforce that the hostnames must
> actually look like hostnames. (i.e mon allows any non whitespace character
> in a 'hostname') It seems like its an unintentional "feature".
yeah, well the point is the server doesn't interpret the "hosts" as
"hosts", i.e. it doesn't expect them to be a resolvable hostname or an
ip address or other such things.
Jim Trocki <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
Layed Off Computer System and Network Engineer
Transmeta Corporation
Santa Clara, CA
_______________________________________________
mon mailing list
[EMAIL PROTECTED]
http://linux.kernel.org/mailman/listinfo/mon
