Dualstack monitoring best practice

Michael Friedrich michael.friedrich at univie.ac.at
Tue Jan 10 22:23:16 CET 2012


On 10.01.2012 10:51, Andreas Ericsson wrote:
>>
>> sure, the patch needs some rework, but when done, it fits, even it won't
>> make it upstream due to the change of the objects abi. but for safety
>> reasons in upgrading, your solution is better.
>>
>
> We might turn "address" into an array variable later. I'm not sure it's
> worth it though.
It's being demanded as "multiple addresses for one host" which comes to 
mind when seeing a host as

- management ip, and a bunch of service ip addresses (for naming 
purposes custom vars will be better)
- vmware / xen cluster with more than one unique address
- dualstacked ip addresses

as well as other examples.
> Until someone finds a best practice that is flexible
> enough to allow all setups while making the most common one really, really
> simple we probably won't try to do anything that will lock people in to a
> particular kind of reasoning.
it's pretty hard to determine what might be best. especially when more 
addresses would mean more macros to be processed, and performance gain 
would suffer more than such enhancements will bring to those actually 
having demanded that. making things opt-in is not always an option either.
> That ofcourse requires someone to actually
> figure out first what the most common case is, and then to figure out a
> best practice for how to monitor it that enough people agree on to make
> it at least a majority vote that we dictators implement.

ideas.nagios.org might be a good place to vote.

http://ideas.nagios.org/a/dtd/Better-support-for-multihomed-hosts---more-than-one-address-entry/8006-3955

and it doesn't need to be you "dictators", maybe others got time, ideas, 
patches. like the guy asking for the additional icon defintion for 
action|notes_url patch - that's rather huge and might address such 
attribute questions by good example. even better is the address6 patch 
adding new macros too. but maybe there are too many changes in recent 
svn commits and 3.2.3 => 3.3.1 which makes people fear that their patch 
work could not be used. (maybe git solves it ;)

>
> Until such a time, custom variables, plugin hackery and check command
> voodoo seems to do the trick for most people.

Yep that's true. Adding the address6 patch was solely for the reason of 
integrating our management databases better into the network and server 
monitoring. But i truly understand your demand to keep the object abi 
clean and compatible. Btw - seen a patch on svn for changing the 
scheduling logic and adding a hash attribute to objects.h - hopefully 
targetted head against 3.4 then?

kind regards,
michael


-- 
DI (FH) Michael Friedrich

Vienna University Computer Center
Universitaetsstrasse 7 A-1010 Vienna, Austria

email:     michael.friedrich at univie.ac.at
phone:     +43 1 4277 14359
mobile:    +43 664 60277 14359
fax:	   +43 1 4277 14338
web:       http://www.univie.ac.at/zid
            http://www.aco.net

Lead Icinga Core Developer
http://www.icinga.org


------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null





More information about the Users mailing list