Netify Agent Plugins

Netify plugins extend the agent pipeline with processing and output capabilities. This page outlines plugin types, compatibility guidance, installation considerations, and loader/configuration fundamentals.

Installation

Plugin installation steps depend on environment, packaging source, and licensing. Every plugin has a dedicated installation section with specific instructions. This document provides a high-level view of plugin configurations as well as the advanced topic of running more than one instance of a plugin.

Agent Compatibility

Netify plugins must maintain version compatibility with the agent (similar to an Application Binary Interface, or ABI). To reduce the risk of mismatches:

Use plugin and agent builds from the same source (e.g., the same repository or distribution channel)
When building from source, align all components to the latest tagged stable release
Follow versioning and upgrade guidance from the Netify project and developer teams

Incompatible plugins usually become apparent after upgrades when expected functionality stops working. To confirm, use the -V flag. Any plugin version showing ?.?.? is incompatible with the running agent and should be upgraded or downgraded.

This strict version alignment ensures stability while enabling the platform to evolve quickly with new features and improvements. By clearly defining compatibility boundaries, the system can introduce new capabilities, performance optimizations, and protocol enhancements without risking unintended side effects in deployed environments.

Terminal - Netify

$ sudo netifyd -V
...
Sink plugins:

 sink-http: 1.0.35
    /etc/netifyd/netify-sink-http.json
    /usr/lib64/libnetify-sink-http.so.0.0.0
 sink-log: 1.0.33
    /etc/netifyd/netify-sink-log.json
    /usr/lib64/libnetify-sink-log.so.?.?.?

Plugin Types

There are two types of Netify plugins:

Processor Plugins: Processor plugins can access Netify Agent internal flow state and execute processing actions that generate specific telemetry structures. Processor plugins are often linked to a sink plugin so those structures can be delivered locally or remotely.
Sink Plugins: Sink plugins act as output mechanisms that transport or store telemetry produced by processor plugins.

Plugin Loader Configuration

Each plugin includes a loader configuration in /etc/netifyd/plugins.d . Removing this file prevents the plugin from loading entirely, but that's often more disruptive than necessary. In most cases, it’s better to disable the plugin within the configuration, or simply change the file extension from .conf so the agent ignores it during initialization.

Loader filenames use a two-digit numeric prefix (e.g., 10-netify-sink-log.conf ) to control load order. Lower numbers are processed first. This structure is consistent across all plugins. The example Sink Log loader configuration is shown below, along with a description of the configuration properties.

The [sink-log] line defines the section (tag) name. This tag must be unique across all plugin loader configurations.

enable

string

State of the plugin loader.

Options:

yes no

plugin_library

string

Shared object library path.

conf_filename

string

Configuration file for this instance of the plugin.

Example: /etc/netifyd/plugins.d/10-netify-sink-log.conf

[sink-log]
enable = yes
plugin_library = /usr/lib64/libnetify-sink-log.so.0.0.0
conf_filename = ${path_state_persistent}/netify-sink-log.json

You can use the following commands to enable/disable the plugin loader configuration using the command line.

Terminal - Netify

netifyd --enable-plugin netify-sink-log       # Enables plugin
netifyd --disable-plugin netify-sink-log      # Disables plugin

Advanced Loader Configuration

Separate Files

In some cases, you may need to instantiate multiple instances of the same plugin. For example, you might want to send compliance telemetry to a third-party message queue provider while continuing to send stats and events to your primary message queue system. This can be achieved in two ways.

The first is by creating separate loader configuration files, each with a unique identifier. See example.

Filename: /etc/netifyd/plugins.d/10-netify-sink-mqtt-primary.conf

[sink-mqtt-primary]
enable = yes
plugin_library = /usr/lib64/libnetify-sink-mqtt.so.0.0.0
conf_filename = ${path_state_persistent}/netify-sink-mqtt-primary.json

Filename: /etc/netifyd/plugins.d/20-netify-sink-mqtt-compliance.conf

[sink-mqtt-compliance]
enable = yes
plugin_library = /usr/lib64/libnetify-sink-mqtt.so.0.0.0
conf_filename = ${path_state_persistent}/netify-sink-mqtt-compliance.json

Single File

Alternatively, multiple tag sections can be place in one loader file.

Every loader instance uses its own configuration file via conf_filename . For plugin-specific options, refer to each plugin's configuration section, for example, the MQTT message queue configuration.

Filename: /etc/netifyd/plugins.d/00-netify-sink-mqtt.conf

[sink-mqtt-primary]
enable = yes
plugin_library = /usr/lib64/libnetify-sink-mqtt.so.0.0.0
conf_filename = ${path_state_persistent}/netify-sink-mqtt-primary.json

[sink-mqtt-compliance]
enable = yes
plugin_library = /usr/lib64/libnetify-sink-mqtt.so.0.0.0
conf_filename = ${path_state_persistent}/netify-sink-mqtt-compliance.json

Tag names must be unique and reference different configuration files. If tags are not unique, the agent will refuse to start!