What is the difference between Minion and Remote Poller?

With OpenNMS it is possible to monitor distributed environments in two scenarios. This short article gives you an idea of what solution fits best with your use case.

Central Service monitored from different locations

The first scenario is when you want to test if a centrally provided service can also be reached from a different remote location. The Remote Poller gives you an additional view from a different network perspective. As an example, you provide a service (blue circle) in a central location in the drawing below. You monitor this service from your central OpenNMS instance in your central location.

You have to install the Remote Poller in each location. You provision a Node with the Service in your central OpenNMS server in your central location. For each remote location, you have to create a remote Polling Package which defines how the Remote Poller has to monitor this service.


  • The service in the central location needs to be accessible from the remote locations
  • The node gets additional response time data from the Remote Location
  • You get dedicated service events when the service is unavailable in the Remote Location

Distributed services in different locations

The second scenario is when you want to monitor services in network locations your OpenNMS server can’t reach easily. The Minion can be installed in this Locations. It acts as a proxy for your OpenNMS instance. The Minion can act as a Syslog receiver, SNMP Trap Receiver, Flow receiwer and can execute poller tasks. The communication between OpenNMS and the Minion is by default ActiveMQ but can also be replaced with Apache Kafka.

:biohazard: A Minion doesn’t have an own scheduler, polling tasks are still scheduled on the central OpenNMS instance. This is nothing to offload polling or data collection work. The Minion helps you to get firewall friendly access to all the network management protocols in your remote location.

:tipping_hand_woman: A Minion can help you to deal with overlapping IP address space. You can use a location in each address space that ensures services get monitored in the right way.


  • Ensure your OpenNMS Server and the Minion can communicate, by default ActiveMQ on port 61616/TCP or Apache Kafka
  • Deploy a Minion in each remote network and define a Location
  • Each Node and the Services are provisioned in the central OpenNMS server and are assigned to a Location.
  • Polling tasks for a Node assigned to a Location will be forwarded to a Minion in the Location and are not tested from the OpenNMS Server itself.

Terminology and History

Remote Poller and Minions are two different components in OpenNMS. The Remote Poller was developed first and the Minion is a new development. The idea is to deprecate the Remote Poller.

The Location you see in the Web UI and you assign to Nodes during provisioning is related to the Minion. The XML file which defines Monitoring Locations is related to the Remote Poller.

Can I do the same with Minion instead of using the Remote Poller

You can do a similar thing with Minion as with the Remote Poller. You would need to install a Minion in each remote location. You have to provision for every location a Node with the services and assign it to the location you want to monitor.

There are caveats:

A Node can only be in one location. This means you have to provision copies of the same node in each location you want to monitor it from.


How secure is the communication between minion and opennms ? I am planning to deploy opennms in cloud and minion in customer’s private network. What all factors I should consider in terms of security?

If you use ActiveMQ you can use SSL, you find here an article about How do I use SSL with ActiveMQ. If you use Apache Kafka instead of ActiveMQ you find a guide here.