Measurement Probe Management

At the heart of the OpenTestPoint framework is an API that allows the authoring of individual data collectors known as probes, written in either C++ or Python.

All probes running on a single node are managed by a Controller. The term node is used throughout to mean a physical machine, a virtual machine or an LXC container. Different node types may participate together within the same OpenTestPoint deployment.

The otestpointd application contains a single Controller that instantiates and manages one or more probes based on input XML configuration. Each probe is created within its own isolated process, otestpoint-probe, which acts as a container for the plugin and provides process isolation between probes.

Sample otestpointd configuration for node-1 from EMANE Tutorial Demo 1:

<otestpoint id="node-1" discovery="node-1:8881" publish="node-1:8882">
  <probe configuration="probe-emane-physicallayer.xml">
    <python module="otestpoint.emane.physicallayer" class="PhysicalLayer"/>
  </probe>
   <probe configuration="probe-emane-rfpipe.xml">
     <python module="otestpoint.emane.rfpipe" class="RFPipe"/>
   </probe>
   <probe configuration="probe-emane-virtualtransport.xml">
     <python module="otestpoint.emane.virtualtransport" class="VirtualTransport"/>
   </probe>
</otestpoint>

The below process listing results from executing otestpointd with the above mentioned XML. More information on otestpointd can be found using the --help option.

[me@node-1 ~]$ ps ax | grep [o]testpoint
   65 ?        Ssl    0:00 otestpointd -d otestpointd1.xml
   81 ?        Sl     0:00 otestpoint-probe
   92 ?        Sl     0:01 otestpoint-probe
  100 ?        Sl     0:00 otestpoint-probe

Probe instances can optionally be passed a configuration file for processing as part of the initialization process. Parsing and validating a configuration file is a probe responsibility. The OpenTestPoint framework does not impose any restriction on the type or format of probe configuration input. While the presence of a probe configuration file is optional from the framework's perspective, it may be required by the probe instance. A probe instance may throw an exception if the configuration file name is missing or if there is a problem with the configuration content.

Probe containers are responsible for querying their respective probe instance for measurement data on the same experiment wide time boundaries in order to provide a tidy aligned view of all metrics.

Time synchronizing all nodes running instances of otestpointd is a network infrastructure (testbed) responsibility that is outside the scope of the OpenTestPoint framework. See the ptpd wiki for multi-node time synchronization information.