<html> <head> <meta http-equiv=Content-Type content="text/html; charset=us-ascii"> <meta name=Generator content="Microsoft Word 11 (filtered)"> <title>Nagios Strategies</title> <style>  </style> </head> <body bgcolor=white lang=EN-US link=blue vlink=blue> <div class=Section1> It might also be interesting to see if there is a way to visually represent these service dependencies on the Status Map. I have people that are interested in viewing the status of the entire multi-tier application stack by application, but this is difficult the way it is represented now. I can create Host Groups for each application, and that should translate to a drawing layer on the Status Map, but from what I understand, it won’t necessarily show me the status of the application if, for example, an instance of an httpd daemon that the application depends on goes down. Has anybody tried anything like this? Thanks, Todd <div> <div class=MsoNormal align=center style='text-align:center'> <hr size=2 width="100%" align=center tabindex=-1> </div> From: nagios-users-bounces@lists.sourceforge.net [mailto:nagios-users-bounces@lists.sourceforge.net] On Behalf Of Hari Sekhon Sent: Thursday, December 21, 2006 5:11 AM To: Nagios Users mailinglist Subject: Re: [Nagios-users] Nagios Strategies </div> I'm also interested in this but haven't thought about how to actually go about doing something like this. I have looked at the service dependencies but the docs don't mention what you suggest so I would expect that it doesn't work like this... yet. unless anybody else has some more wisdom? -h <pre>Hari Sekhon</pre> Matthew Joyce wrote:  Hi all, I've found myself in a quandary and I'm wondering how other Nagios uses have address similar problems. We've recently upgraded to 2.6 and I've been tidying up the configs, sorting out service groups, etc. I've been adding checks for specific windows services, Exchange, Backup Exec, various MS SQL databases and that sort of thing. The more services I add, the more I consider their dependencies on each other. SNMP service is now a critical service, as without it I will get a storm of notification. I can see that service dependencies would fix this but it does seem overly complex to have to list each host/service pair in the dependency definition. One way I thought might work is to create a servicegroup called myserversnmp and add the service to the group in the service definition. Then, in the dependency definition, make that servicegroup dependent on SNMP Service on the host. This would mean I end up with a load of servicegroups, but make configuring easier as I just need to add one line per service and that's often done with copy/past/tweak. An alternative might be to regular expressions, but for me this would be an obfuscation, not really what I'm after. It would be nice if there was a service dependency directive in the service definition. How do others manage dependencies ? Thanks Matt <pre wrap=""> </pre><pre style='text-align:center'> <hr size=4 width="90%" align=center> </pre><pre> </pre><pre>-------------------------------------------------------------------------</pre><pre>Take Surveys. Earn Cash. Influence the Future of IT</pre><pre>Join SourceForge.net's Techsay panel and you'll get the chance to share your</pre><pre>opinions on IT & business topics through brief surveys - and earn cash</pre><pre><a href="http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV">http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV</a></pre><pre wrap=""> </pre><pre style='text-align:center'> <hr size=4 width="90%" align=center> </pre><pre> </pre><pre>_______________________________________________</pre><pre>Nagios-users mailing list</pre><pre><a href="mailto:Nagios-users@lists.sourceforge.net">Nagios-users@lists.sourceforge.net</a></pre><pre><a href="https://lists.sourceforge.net/lists/listinfo/nagios-users">https://lists.sourceforge.net/lists/listinfo/nagios-users</a></pre><pre>::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. </pre><pre>::: Messages without supporting info will risk being sent to /dev/null</pre></div> </body> </html>