--=_alternative 004D28B9C125749E_=
Content-Type: text/plain; charset="utf-8"
content-transfer-encoding: quoted-printable
[email protected] 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.
>=20
> 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
>=20
> Seriously, hosts implement two type of dependencies:
>=20
> 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=20
out)
>=20
> 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=20
"inside",
yet nagios just tries to "simplify" things for us, so that we do not need=20
to make
services depending on their hosts - nagios does that for us.
Sadly that also burdens us with some limitations, for example can't=20
services
be dependent on other hoststates.
If we would have simple object definitions, where we could freely choose=20
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
--=20
Sascha Runschke
Netzwerk- und Systemmanagement
Telefon : +49 (201) 102-1879 Mobil : +49 (173) 5419665 Fax : +49 (201)=20
102-1102105
GFKL Financial Services AG
Vorstand: Dr. Peter J=C3=A4nsch (Vors.), J=C3=BCrgen Baltes, Dr. Till Ergen=
zinger, Dr. Tom Haverkamp
Vorsitzender des Aufsichtsrats: Dr. Georg F. Thoma
Sitz: Limbecker Platz 1, 45127 Essen, Amtsgericht Essen, HRB 13522
--=_alternative 004D28B9C125749E_=
Content-Type: text/html; charset="utf-8"
content-transfer-encoding: quoted-printable
[email protected] 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 wil
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]