Core 4 Remote Workers

[Jochen Bern]

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"

Regards,
								J. Bern
-- 
*NEU* - NEC IT-Infrastruktur-Produkte im <http://www.linworks-shop.de/>:
Server--Storage--Virtualisierung--Management SW--Passion for Performance
Jochen Bern, Systemingenieur --- LINworks GmbH <http://www.LINworks.de/>
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel

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