I think this screams for an NSCA relay agent so that you don't have to actually have to make the changes on more than 1 nagios server, which is what you'd currently have to do. Such an agent should work just like a dhcp relay, get a request, buffer and try passing it on to the remote nagios server, retry if the wan link is down etc...
Alternatively, for right now, a config framework like puppet + revision control + scripted auto update/config change to passive check forwarding on remote nagios server + reload would probably be a workaround to do what you want so you only have to modify nagios in one place and the other follows suit automatically. I love doing stuff like that. -h -- Hari Sekhon Always open to interesting opportunities http://www.linkedin.com/in/harisekhon David Jacobson wrote: > Hi There, > > We monitor a large amount of services for all our customers. We do not > have the luxury of all the networks being on the same WAN/LAN > infrastructure. > > A lot of our servers have public IP’s and a lot do not. > > Typically, we have been monitoring the *NIX servers using a > combination of active and passive (active where we can, passive where > the server does not have a public IP) > > What the above creates, is quite a mess and a difficult process to try > and explain to all our support agents on how to monitor our customer > servers, due to all differences. > > We are now redoing our monitoring from scratch (using Groundwork) - in > an ideal world each server would be accessible via an active check and > we could ensure that 99% of all monitoring changes are doing via the > Groundwork interface (assuming we run NRPE on each server and have > external arguments accepted) - what’s great about this, the junior > support engineers could easily make changes via an interface. > > However, as discussed not all servers are accessible directly, so I’m > considering just doing an all passive approach to simplify the process > – to install nagios on every server which submits its active checks > back via NSCA. The thing I hate about this, is the fact that we have > to log on to every server to make a monitoring change, which is what I > was trying to avoid. > > I guess we could make the passive approach a bit better, by making use > of something like puppet and version control so we don’t really have > to log on to the servers... > > Before I start this whole project, I would like to know if anyone has > any ideas on the “Best way” to do this, any advise would be > appreciated. At the moment, I’m steering towards passive for > everything and version control. > > My main goal here is monitoring that works, that is simple to modify > moving forward. (KISS methodology) > > -- > Regards, > > David Jacobson > Technical Director > SYNAQ (Pty) Ltd > > Tel: 011 262 3628 > Direct: 011 262 3626 > Fax: 086 637 8868 > Cell: 083 235 0760 > Mail: [EMAIL PROTECTED] > Web: http://www.synaq.com > > Key Fingerprint > 8246 FCE1 3C22 7EFB E61B 18DF 6E8B 65E8 BD50 78A1 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Nagios-users mailing list Nagios-users@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
