Hi Mark
Frost, Mark {PBG} wrote:
> This topic of unreachable hosts that's come up recently has got me
> thinking about an issue we have. We have a few hosts that are behind
> proxies and as such are impossible to ping. They have a single service
> which we can check through the proxy successfully.
>
>
Why not simply use this check then as the host check as well as the
service check?
Cheers
Johannes
> I'm a little stuck on what to do with the host checks. I can supress
> the alerts, but they still always show as critical (kind of permanently
> critical). Maybe I'm too anal, but I don't like that. It's
> meaningless. So I was thinking of making the host check command
> identical to the service check command. The end result being that if
> the service is up, the host will also show up, if the service is down,
> the host will also show down. Still weird, but at least kind of
> conceptually correct.
>
> What concerns me about is the my understanding of how host and service
> checks would work in this case. If the service check fails, it's going
> to want to fallback and try the host check which will fail also because
> it's running the exact same check as the service. However, what if
> I've disabled notfications on the host itself? That is, I really only
> ever want service alerts -- no host alerts. In the case of a normal set
> of host/service checks, Nagios will notice that the host is down,
> suppress alerts about all the services being down and send out only a
> "host is down" alert.
>
> In the scenario where the host and service checks are the same and the
> host notifications are disabled, wouldn't a service alert be suppressed
> and I'd never hear about an issue on this host? Again, conceptually,
> the service result is all that's meaningful. Maybe Nagios is smarter
> than that and would decide that since the host notifications were
> disabled that it would go ahead and send the service alerts anyway? I
> guess this could be an issue with any host that has notifications
> disabled now that I think about it.
>
> I tried earlier to disable all checking of the host in this case and
> that gives me a host unreachable alert when the service goes down. That
> makes sense since the host can't be checked, but I don't want it going
> into that bogus state.
>
> What would probably be ideal is if Nagios had some way of marking a host
> as being irrelevanet. That is, the service would sort of stand alone
> without any host dependency in terms of monitoring. Kind of strange,
> though.
>
> Thanks
>
> Mark
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> 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
>
--
Johannes Dagemark
CTO / VP Engineering
________________________________________
op5 AB
Första Långgatan 19
SE-413 27 Gothenburg
cell: +46 733-70 90 24
fax: +46 31-774 04 32
Email: j...@op5.com
http://www.op5.com/
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
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
