Telemetry Daemon

The telemetry daemon (telemetryd) provides an extensible framework you can use to handle sensor data pushed to Meridian. Use the framework to support applications that use different protocols to transfer metrics. With telemetryd, operators can define listeners supporting different protocols to receive the telemetry data and adapters transferring the received data into generic formats like flows or performance data.

telemetryd overview
Figure 1. Generic component overview of components in telemetryd

The configuration is split in two parts. Listeners and attached parsers or connectors on one side receive telemetry data transported over a specific protocol and parse the data according to the protocol’s specification. On the other side, adapters pick up the parsed data and enrich it before persisting it.

Queues transport the parsed telemetry data from parsers to adapters by binding a specific parser to a specific adapter.

Listeners and Parsers

Listeners receive sensor data from an external source and hand them off to parsers, which handle the transport protocol format and extract the transported data.

A listener does the transport protocol handling like opening a socket and accepting incoming connections. The received messages are then passed to the parser configured for the listener that parses the concrete protocol implementation and extracts all available information out of the received message. For further processing, the extracted data is handed over to the configured queue.

For example, a listener may open a UDP socket for receiving packets and an assigned parser parses the incoming IPFIX packets.

Parsers and listeners must work together closely. Therefore, they cannot be combined in any random way. Which parser is supported by which listener is described in the documentation of each respective parser.


Connectors initiate a connection and maintain a session with an agent. A new connector is created for every agent it is responsible for connecting to. Agent here refers to an IP service that is a named service attached to an IP interface on a specific node. Connectors do not use parsers, and dispatch messages directly to a queue.

telemetryd connectors
Figure 2. Connectors in telemetryd


Adapters enrich and process the data dispatched over a queue. They receive the data from the queue and transform it into a format usable by Meridian. Adapters can also enrich the incoming data to attach node or interface information, depending on information already available.

For example, an adapter may be used to transform telemetry data received via sFlow into performance data and persist it to the applicable node.

Since an adapter must handle data dependent to a transport protocol, not all adapters can be used in combination with any possible parser. Which parsers are supported by which adapters is described in the documentation of each respective adapter.

If you have multiple adapters, the execution order is the same as defined in the telemetryd-configuration.xml.

Working with Minions

Listeners and parsers run on Minion, but adapters do not. Adapters run on Sentinel, while the main Meridian instance can run listeners, parsers, and adapters. When using Minion as a listener, you must use adapters on Meridian or Sentinel to transform the data.


Queues transfer data between parsers and adapters and are represented by a channel in the messaging system.

Configuring Queues

The following options can help fine tune queue behavior:

Queue attribute (OpenNMS) Key (Minion/Sentinel) Description Default value



Number of threads used for consuming and dispatching messages.

(2 * number of cores)



Maximum number of messages to keep in memory while waiting to be dispatched.




Whether to use the routing key when forwarding messages to the broker. This enforces message ordering.




Messages are aggregated in batches before being dispatched. When the batch reaches this size, it will be dispatched.




Messages are aggregated in batches before being dispatched. When the batch has been created for longer than this interval (ms) it will be dispatched, regardless of the current size.


When using Kafka as a message broker, setting use-routing-key to false allows the messages to be balanced across all partitions. This can be done safely for flows, but is not supported for metrics when using thresholding (order is required).

When setting these options in OpenNMS, they can be added as an attribute to the <queue> element. For example:

<queue name="IPFIX" use-routing-key="false">

When setting these options on Minion, you can add them as parser properties, and on Sentinel as adapter properties:


Push Sensor Data through Minion

Listeners and their parsers may run on either Meridian or Minion, whereas adapters run on Meridian or Sentinel. If a listener and its parsers are running on Minion, the received messages will be dispatched automatically to the associated adapters running in Meridian or Sentinel via a queue. Minions can listen (receive) data, but require Meridian or Sentinel to process.

telemetryd minion
Figure 3. Running Listener on a Minion forwarding packets using the messaging system

Reverse Hostname Resolution

Some parsers support reverse hostname resolution to annotate IP addresses with the actual hostname. The Minion performs the reverse name lookup while parsing the protocol data. The resolved hostname, if found, is attached to the address information and both are sent to the adapter for further processing.

For more information see DNS Resolver

The following parsers currently support reverse hostname resolution: Netflow v5, Netflow v9, IPFIX, and sFlow.