Antwort: Re: Why distinguish hosts from services?
Sascha.Runschke at gfkl.com
Sascha.Runschke at gfkl.com
Thu Aug 7 16:02:47 CEST 2008
nagios-devel-bounces at lists.sourceforge.net schrieb am 07.08.2008 13:37:24:
> Than make the host check a "check_dummy!0!Host assumed to be up" pull
> the plug on that host and enjoy the spam when your host goes down.
>
> An an exercise, you can do the same on a router and it's 1,000 hosts
> behind it, pull the plug on the router and watch your mail server melt
> down as nagios starts sending 10,000 notifications at once :)
>
> Seriously, hosts implement two type of dependencies:
>
> 1. Service depend on the host being up
> 2. Child hosts depend on parent host being up (will send UNREACHABLE
> notifications instead of DOWN on child hosts, and those can be filtered
out)
>
> In most setups you will need at least one of these dependencies, so if
> you remove host checks you will need another simple and obvious way to
> define them. Do you have a suggestion for that?
I think you seriously misunderstood him Thomas.
He just suggested that we should drop the notation of hosts, services and
such. As in real all they are is objects depending on each other. Yet the
fact, that they have different names, makes things more complicated then
needed and they put up several limitations.
If you'd go over to a "pure object definition", it could look like this:
(definition is simplified for easy of reading)
define object {
name coreswitch
check check_icmp
}
define object {
name webserver01
check check_icmp
depending_on coreswitch
}
define object {
name DISKS
check check_disks
depending_on webserver01
}
etc.pp.
I hope you get the point.
Right now the current host- and servicedefinition merely do the same
"inside",
yet nagios just tries to "simplify" things for us, so that we do not need
to make
services depending on their hosts - nagios does that for us.
Sadly that also burdens us with some limitations, for example can't
services
be dependent on other hoststates.
If we would have simple object definitions, where we could freely choose
all
dependancies we want - Nagios would even be more powerful in my opinion.
Even better: it would be totally easy to build up hashtables with pointers
for checking logics of depencies and such, as there is no need anymore
to handle hosts and services different. It's all the same.
There would be no more limitations of any kind, yet it of course makes
things a little bit more complicated to configure.
But with some standard templates that could easily be taken care of.
Regards
Sascha
--
Sascha Runschke
Netzwerk- und Systemmanagement
Telefon : +49 (201) 102-1879 Mobil : +49 (173) 5419665 Fax : +49 (201)
102-1102105
GFKL Financial Services AG
Vorstand: Dr. Peter Jänsch (Vors.), Jürgen Baltes, Dr. Till Ergenzinger, Dr. Tom Haverkamp
Vorsitzender des Aufsichtsrats: Dr. Georg F. Thoma
Sitz: Limbecker Platz 1, 45127 Essen, Amtsgericht Essen, HRB 13522
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20080807/1746a4d2/attachment.html>
-------------- next part --------------
-------------------------------------------------------------------------
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=/
-------------- next part --------------
_______________________________________________
Nagios-devel mailing list
Nagios-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-devel
More information about the Developers
mailing list