Skip to content

Remote Workers

chuckablack edited this page Nov 11, 2020 · 1 revision

Quokka functions normally run on the quokka server. For example, discover of hosts, monitoring of devices, hosts, and status, summarization of status data, all run within the context of the quokka server.

However, certain functions require that they be run in 'superuser' or in Linux terms, 'sudo' mode. It is inadvisable to run a web application such as quokka in superuser mode, for security purposes. Thus, these functions are executed as separate programs, independent from the quokka server.

This has a positive side-effect, in that these separate applications, e.g. for packet capture, port scanning, or traceroute, may benefit from running on a different system than the quokka server. Hence, these can become what we call 'remote workers'.

Quokka does attempt to monitor its remote workers, to make sure they are available and responding in a timely manner. The following image is the workers screen:

Details of the implementation of the remote worker are described in the Implementation section of this documentation. Information about the workers, from the list in the figure above is as follows:

  • Actions: You can request status information (see figure below), packet capture, and traceroute for these workers. Note that you cannot do packet capture or traceroute for localhost, for workers.
  • Status: Availability of the worker, based on whether it has sent a heartbeat to the quokka server indicating it is alive and well.
  • Name: User-defined name for the worker, perhaps indicates the location of the worker.
  • Hostname: The configured hostname of the worker - this is important as it is used for communication to the worker.
  • Worker Type: The type of worker, i.e. the function it is providing. Note that there are technically separate workers for each type of function it performs.
  • Connection Type: The method of communication between the quokka server, and the remote worker, used to deliver 'commands' to the worker (e.g. capture packets for this IP, do a traceroute, etc.). Currently there are two mechanisms for communication - messaging via rabbitmq (in which the command is sent to the remote worker directly), or http (in which the worker receives commands as it periodically polls the quokka server during its heartbeat cycle).
  • CPU, Memory, Rsp Time: Values indicative of the health of the worker.
  • Last Checked: The last time this worker was heard from.

We even keep status information about the workers, and graph their availability, response time, and cpu and memory utilization:

Clone this wiki locally