Core 4 Remote Workers

[Andreas Ericsson]

On 02/04/2013 01:58 PM, Jochen Bern wrote:
> On 03.02.2013 13:12, Andreas Ericsson wrote:
>> Scenario 1: Loadbalancing, using remote workers to enhance the cpu and
>> memory resources available to us.
>>
>> Scenario 2: "Passing" firewalls, using remote workers to run check the
>> master can't access due to access restrictions.
>>
>> Scenario 3: Remote view of inside services, using remote workers to see
>> the network from a particular point of view, such as a field office using
>> services inside the main office.
>>
>>> To sum it up, what I would imagine as Nagios' long-term development for
>>> *your* scenario wouldn't be a Nagios/worker "tasks go downstream"
>>> interface but one that allows a local Nagios to push "local" status data
>>> (from config to current check results) to an upstream "integration and
>>> oversight" Nagios.
>>>
>>> (And yes, pinpointing how exactly you can and want to do access control,
>>> formation of host/service *groups*, notifications for local/global
>>> users, yadda yadda, with such a configuration brain split *will* be a bear.)
>>
>> Yup. It *is* useful though. mod_gearman has the same issue, really, and
>> people use that.
> 
> I pondered that a bit. Getting tester and testee right is, to put it
> mildly, a recurring topic. I wonder whether we might want to introduce
> sort of a point-of-view definition into host and service definitions, as in:
> 
> define service{
> 	host_name		BranchA-Printer
> 	service_description	Submission Port
> 	as_seen_from		BranchA-Firewall
> 	}
> define service{
> 	host_name		BranchB-Intranet
> 	service_description	Login Web Form
> 	as_seen_from		BranchB-Gateway:Squid Proxy
> 	}
> 
> (I'm not sure whether the default value should better be = host_name, or
> empty / (local) "Nagios Process".)
> 
> This would, of course, partially duplicate parents and dependencies.
> (Or, more precisely, one should autogenerate dependencies out of them.)
> However, if we see semi-auto-organizing Nagios hierarchies on the
> horizon, an explicit separation between test-method-induced and
> service-inherent dependencies might actually be a good idea in and of
> itself.
> 
> An immediate benefit of introducing this concept would be that command
> definitions could change from stuff like
> 
> command_line	check_by_ssh -H `echo $HOSTADDRESS$ | sed 's/foo/bar/'` -C
> "check_http -H `echo $HOSTADDRESS$ | sed '/more/s/black/majick/'`
> 
> (or custom variables whose names change from one Nagios admin to the
> next ...) to something like
> 
> command_line	check_by_ssh -H $ASFADDRESS$ -C "check_http -H $HOSTADDRESS$"
> 
> In the long term, when a sub-Nagios registers its config / objects with
> a super-Nagios, the point-of-view information could be not only adapted
> automatically (super-Nagios: "testing all that is *that* sub-Nagios'
> job"), but possibly even aid in uniquely identifying the tested object
> and its state at the super-Nagios. As in,
> a) "sub-Nagios A has object X as_seen_from Y, sub-Nagios B has the exact
>     same, assuming that the name 'X' is unique at point-of-view Y, I can
>     conclude that it's indeed the same object" (and, thus, that I can
>     load-balance checks of X between them)
> b) "sub-Nagios A has object X as_seen_from Y, sub-Nagios B has object X
>     (known to be the same) as_seen_from Z, I can disregard UNKNOWNs that
>     come from only one of them"
> 

Consider this in terms of usecases. Which problem are we solving
by introducing multiple check-locations for the same check that we
don't solve by letting users configure several checks of the same
service, but distributing some of them to a remote worker (or a
different system that reports in passive check results)?

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

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan