Antwort: Re: Why distinguish hosts from services?

[Andreas Ericsson]

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

In which way is it depending on it? Is it depending on coreswitch to
be up and running, or should this "object" only return OK if coreswitch
is down?

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


True that, and in my book that's actually a good thing. Having one check
depend on a lot of different *hosts* is just godsdamn awful. You can
already make it depend on any number of services with the current syntax.

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

You can already do that, using hostdependencies.

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

Hashes aren't all that efficient. They're just better than doing brute-force
full-text searches every time.

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

Right, and what is 90-95% of the questions about on nagios-users?

> But with some standard templates that could easily be taken care of.
> 

Show me, and I'll be convinced.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

-------------------------------------------------------------------------
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=/