Feature Request HostGroup in environment.
What.
Export the HostGroup of the about to be run monitor into its environment.
Possibly something like
MON_HOST_GROUP
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
signature.asc
Description: OpenPGP digital signature
___
mon mailing list
mon@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/mon
Re: Feature Request HostGroup in environment.
I think thats a great idea.
Which is probably why it already exists... :)
try MON_GROUP and MON_SERVICE
(I see that the documentation doesn't list those for monitors, only
for alerts, but they do exist and work.)
-David
On Wed, Jan 6, 2010 at 1:30 PM, Nathan Gibbs wrote:
> What.
>
> Export the HostGroup of the about to be run monitor into its environment.
> Possibly something like
> MON_HOST_GROUP
>
> 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
mon@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/mon
Re: Feature Request HostGroup in environment.
On Wed, 6 Jan 2010, David Nolan wrote: I think thats a great idea. Which is probably why it already exists... :) try MON_GROUP and MON_SERVICE (I see that the documentation doesn't list those for monitors, only for alerts, but they do exist and work.) i just updated mon.8 to reflect all of the environment variables set in run_monitor and in call_alert. there were a couple things missing. ___ mon mailing list mon@linux.kernel.org http://linux.kernel.org/mailman/listinfo/mon
Re: Feature Request HostGroup in environment.
* Jim Trocki wrote: > On Wed, 6 Jan 2010, David Nolan wrote: > >> I think thats a great idea. >> >> Which is probably why it already exists... :) >> >> try MON_GROUP and MON_SERVICE >> Cool, software that reads the feature request from my mind months before I realize I need the feature. What can't Open Source software do? ;-) >> (I see that the documentation doesn't list those for monitors, only >> for alerts, but they do exist and work.) > Mon has "undocumented" features!!! NO way! > i just updated mon.8 to reflect all of the environment variables set in > run_monitor and in call_alert. there were a couple things missing. > > While your at it, list_views isn't documented in the Mon::Client man page. Thanks -- Sincerely, Nathan Gibbs Systems Administrator Christ Media http://www.cmpublishers.com signature.asc Description: OpenPGP digital signature ___ mon mailing list mon@linux.kernel.org http://linux.kernel.org/mailman/listinfo/mon
Re: Feature Request HostGroup in environment.
* Jim Trocki wrote:
> On Wed, 6 Jan 2010, David Nolan wrote:
>
>> I think thats a great idea.
>>
>> Which is probably why it already exists... :)
>>
>> try MON_GROUP and MON_SERVICE
>>
Oh' that works so nicely.
A thing of beauty.
# NPG
# Changed the default assignment from $ME to $HG-$ME.state.
# It was a real pain to test this thing stnadalone when it kept
# overwriting itself. The work of a true BCFH. ;-)
# Also now seperate instances will not clobber each other's state.
if ( $ENV{"MON_GROUP"} ) {
$HG = $ENV{"MON_GROUP"};
}else{
$HG = "testing";
}
$STATEFILE = $opt{"statefile"} || "$HG-$ME.state";
# NPG End
Hopefully, later this week or next, I'll release revisions of the
reboot.monitors.
Question?
To kill or not to kill $opt{"statefile"}.
Personally, I favor killing it, as it now has nothing but hack value and
the code would be cleaner without it.
--
Sincerely,
Nathan Gibbs
Systems Administrator
Christ Media
http://www.cmpublishers.com
signature.asc
Description: OpenPGP digital signature
___
mon mailing list
mon@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/mon
