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.
>=20
> Scenario 2: "Passing" firewalls, using remote workers to run check the
> master can't access due to access restrictions.
>=20
> 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 usi=
ng
> services inside the main office.
>=20
>> To sum it up, what I would imagine as Nagios' long-term development fo=
r
>> *your* scenario wouldn't be a Nagios/worker "tasks go downstream"
>> interface but one that allows a local Nagios to push "local" status da=
ta
>> (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 contro=
l,
>> formation of host/service *groups*, notifications for local/global
>> users, yadda yadda, with such a configuration brain split *will* be a =
bear.)
>=20
> 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 =3D host_name, o=
r
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
--=20
*NEU* - NEC IT-Infrastruktur-Produkte im :
Server--Storage--Virtualisierung--Management SW--Passion for Performance
Jochen Bern, Systemingenieur --- LINworks GmbH
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
PGP (1024D/4096g) FP =3D D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C2=
7
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
Unternehmenssitz Weiterstadt, Gesch=E4ftsf=FChrer Metin Dogan, Oliver Mic=
hel
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: Jochen.Bern@LINworks.de