Maybe I misunderstood, but it sounds like you are going to have the workers=
listen for work coming from core, rather than the workers going and fetchi=
ng work? If that is the case it would concern me a bit as far as being rob=
ust, in that if a server goes away, or can't talk to a worker anymore, you =
have to deal with timeouts, and potentially cause slow-downs in getting wor=
k processed. So I always liked the idea better that the workers check in a=
nd get work from the core, then you remove the need for any listening socke=
ts. I think you'll also need to consider security in that when a worker do=
es check in, how do you know it's not a malicious worker, shared key or som=
ething, and then of course there's transport security, so ssl or payload-le=
vel encryption.
Dan
On Feb 2, 2013, at 8:12 AM, Eric Stanley wrote:
> All,
>=20
> I've been giving some thought to remote workers for core 4 and wanted to=
=20
> run those thoughts by this list. I see remote workers as a very useful=20
> extension to the worker concept in core 4.
>=20
> To implement remote workers, I think there are about 4 basic things that=
=20
> would need to be done.
> 1. Implement the ability to listen to multiple query handler interfaces=20
> (precursor to #2)
> 2. Implement the ability to create and listen on TCP socket query=20
> handler interfaces.
> 3. Add a host key to the worker registration to allow workers to specify=
=20
> the host(s) for which it will handle checks.
> 4. Write a stand-alone remote worker that can connect to the core=20
> instance via TCP.
>=20
> The reason I have steps 1 and 2, instead of combining them is first,=20
> because a generalized solution is more extensible and second, I think=20
> having multiple TCP listeners is a reasonable use case where you have a=20
> multi-homed system, but you may not want to listen on all interfaces.
>=20
> The host key should be allowed to specify one or more IP addresses, IP=20
> subnets, contiguous IP address ranges, host names and host name=20
> patterns/wildcards (i.e. *.example.com). If multiple workers register=20
> for the same host, some sort of distribution mechanism should be used to=
=20
> load balance the workers.
>=20
> Using the second criteria of host to determine which worker gets the=20
> check raises the question of the order of precedence for the criteria.=20
> Initially, I think the host should have precedence over plugin, but I=20
> can see implementing and order of precedence option in the core=20
> configuration file. This would be more important if additional worker=20
> selection criteria were added.
>=20
> The communication between the remote worker and the core process should=20
> be able to be protected by SSL. The remote worker will need a mechanism=20
> to retry the connection in the event the network drops the connection.
>=20
> I realize this is a sizable change and we may not want it to happen=20
> before the release of 4.0. Thoughts on this are welcome.
>=20
> Further down the road, I can see developing a remote worker proxy, whose=
=20
> sole job is to broker the communication between core and even more=20
> remote workers. This would enable a tree-shaped worker hierarchy for=20
> monitoring environments that are both large and dispersed geographically=
=20
> and/or topologically. This would require a re-registration process so=20
> the proxy workers could keep core updated with their abilities as=20
> leaf-node workers connected and disconnected.
>=20
> Thoughts?
>=20
> --=20
> Eric Stanley
> ___
> Developer
> Nagios Enterprises, LLC
> Email:estanley@nagios.com
> Web:www.nagios.com =20
>=20
>=20
> -------------------------------------------------------------------------=
-----
> 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
> _______________________________________________
> Nagios-devel mailing list
> Nagios-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/lis ... gios-devel
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: daniel.wittenberg.r0ko@statefarm.com