Pollerd Configuration
File | Description |
---|---|
$OPENNMS_HOME/etc/poller-configuration.xml |
Configuration file for monitors and global daemon configuration |
$OPENNMS_HOME/logs/poller.log |
Log file for all monitors and the global Pollerd |
$OPENNMS_HOME/etc/response-graph.properties |
RRD graph definitions for service response time measurements |
$OPENNMS_HOME/etc/events/opennms.events.xml |
Event definitions for Pollerd. For example, nodeLostService, interfaceDown, or nodeDown |
To change the behavior for service monitoring, the poller-configuration.xml
can be modified.
The configuration file is structured in the following parts:
-
Global daemon config
-
Define the size of the used Thread Pool to run Service Monitors in parallel.
-
Define and configure the Critical Service for Node Event Correlation.
-
-
Polling packages
-
Package to allow grouping of configuration parameters for Service Monitors.
-
-
Downtime Model
-
Configure the behavior of Pollerd to run tests in case of an Outage is detected.
-
-
Monitor service association
-
Based on the name of the service, the implementation for application or network management protocols are assigned.
-
<poller-configuration threads="30" (1)
pathOutageEnabled="false" (2)
serviceUnresponsiveEnabled="false"> (3)
1 | Size of the Thread Pool to run Service Monitors in parallel. |
2 | Enable or Disable Path Outage functionality based on a Critical Node in a network path. |
3 | In case of an unresponsive service, a serviceUnresponsive event is generated instead of an outage. This prevents the application of the Downtime Model in retesting the service after 30 seconds to help prevent false alarms. |
Configuration changes are applied by restarting OpenNMS and Pollerd. It is also possible to send an Event to Pollerd reloading the configuration. An Event can be sent on the CLI or the Web User Interface.
cd $OPENNMS_HOME/bin
./send-event.pl uei.opennms.org/internal/reloadDaemonConfig --parm 'daemonName Pollerd'
Metadata DSL
The Metadata DSL(domain specific language) lets you use dynamic configuration in parameter values to interpolate metadata into the parameter.
The syntax lets you use patterns in an expression, whereby the metadata is replaced with a corresponding value during the collection process.
During evaluation of an expression, the following scopes are available:
-
Node metadata
-
Interface metadata
-
Service metadata