Minion

A Minion is an instance of the Karaf OSGi service that enables Horizon to monitor devices and services in locations that Horizon cannot reach. Minions communicate with these remote devices while OpenNMS performs coordination and task delegation.

Minions can operate behind a firewall and network address translation (NAT) as long as they can communicate with Horizon via an ActiveMQ or Apache Kafka message broker.

CAP_NET_RAW and CAP_NET_BIND_SERVICE capabilities are assigned out of the box, allowing you to bind Minions to privileged ports (less than 1024).

Use Minions to monitor devices and services in hard-to-reach, remote network locations. Minions provide the following benefits:

  • No need to set up and maintain a large set of firewall rules for multiple management protocols.

  • Avoid the difficulty of communicating with managed devices over unreliable networks, using UDP-based management protocols.

  • Simplify network communication to the message broker.

How it works

A Minion monitors all the managed nodes and IP services in the same location (for example, Pittsboro office, building-3). The Minion communicates with the message broker, which in turn communicates with the core instance.

location
Figure 1. Nodes with Minions in locations

By default, every node provisioned in Horizon is created in the default location. The Horizon core instance handles all nodes and services in the default location.

To enable the Minion to handle all nodes and services in a remote location, you must define a location (for example, "Pittsboro office, building-3") in your core server, and configure the location property on the Minion to match. The Minion registers itself to the Horizon instance on start-up.

Horizon’s' provisioning system lets you associate nodes with any location. Horizon delegates monitoring requests for nodes in a specified location to the Minion(s) configured for that location, using the Minion as a proxy.

The following provides a more detailed overview of the communication between a Horizon instance and a Minion:

communication
Figure 2. Minion communication

By default, the Horizon instance automatically provisions the Minion as a node and automatically monitors it with the Minion-Heartbeat service. The Minion sends heartbeat messages to show it is running and functioning properly in the defined location.

The specific management protocol messages (for example, SNMP, ICMP) are piped through a message broker communication channel and executed by a Minion. The broker forwards responses to the central Horizon instance, which processes them accordingly.

A Minion proxy scenario supports the following management protocols:

  • Receive Syslog messages and SNMP traps and forward them through the message broker to a central Horizon instance.

  • Act as a proxy for SNMP performance data collection.

  • Act as a proxy for service monitors to test availability and measure response times from applications.