Antwort: Re: Why distinguish hosts from services?

[Thomas Guyot-Sionnest]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sascha.Runschke at gfkl.com wrote:
|
| 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.

I did not misunderstood, but rather exaggerated on Stéphane's comment
that they are useless. We need dependencies and making them non-obvious
(as in your example) will only help people make configuration mistakes.

What Holger suggested is rather to keep the same configuration objects
but make the core nagios logic work just like it was a bunch of object
dependencies (no distinction between services and hosts). His goal is to
make the _code_ simpler, without altering the way we configure everything.

| 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.

That's almost the opposite. Everywhere in Nagios the code takes
different paths to accommodate very slight distinctions between hosts
and services. By getting rid of these distinctions and making Nagios
treating all of them as standard monitoring objects, we could make them
follow a single path thus getting dis of code duplication and needless
complexity.

| 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.

I don't agree. For most people it's much more obvious to define hosts
and their service, which implicitly define a dependency between the host
and services, than to make everything explicit.  Most people just don't
want to bother with dependencies, they enter hosts, services and Nagios
does its magic.

Regards,

- --
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFInIIG6dZ+Kt5BchYRAtQ+AKCYBoHqYx5IiAeDci8o0b0/ABchlwCfWgPm
tT9OJzFjxPdS98sbCWuYKDM=
=99kv
-----END PGP SIGNATURE-----

-------------------------------------------------------------------------
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-devel mailing list
Nagios-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-devel