I think thats a great idea.

Which is probably why it already exists... :)


(I see that the documentation doesn't list those for monitors, only
for alerts, but they do exist and work.)


On Wed, Jan 6, 2010 at 1:30 PM, Nathan Gibbs <nat...@cmpublishers.com> wrote:
> What.
> Export the HostGroup of the about to be run monitor into its environment.
> Possibly something like
> Why?
> Summary
> To give a monitor a way to identify itself form another instance of
> itself running in a different HostGroup.
> Detail
> For years I've had a situation where a server reboot or an snmpd service
> restart would occasionally put the reboot.monitor into an error state
> for a random amount of time longer than necessary.  Anywhere from 5
> minutes to hours.
> Sometimes the problem would fix itself, other time I would have to rm
> the state file.
> What was happening was that the reboot.monitor in HG1 where the reboot
> happened would write the state file just after the reboot.monitor in HG2
> would read it. Obviously the monitor in HG2 would write out incorrect
> data for the hosts in HG1.
> Yes, in this particular instance I could use the --statefile= option &
> be done with it.  However I'm thinking beyond this particular monitor.
> If this feature was added
> 1. any monitor that needed a unique statefile name could trivially get one.
> $STATEFILE = $ENV{"MON_HOST_GROUP"} . "$ME.state";
> This or something like it could be added to the monitor template.
> 2. All statefiles would follow a convention of HostGroup.Monitor.state.
> 3. It would be easy to know what file was built by which monitor instance.
> 4. No need to implement an option to set a statefile name.
> 5. Simpler config as the above options are no longer needed.
> What do you think?
> :-)
> --
> Sincerely,
> Nathan Gibbs
> Systems Administrator
> Christ Media
> http://www.cmpublishers.com
> _______________________________________________
> mon mailing list
> mon@linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/mon

mon mailing list

Reply via email to