Best Practises for a *NIX environment over multiple WAN's

[Hari Sekhon]

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: davidj at synaq.com
> 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 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