
[[ga-pollerd-configuration]]
= Configure Pollerd
:description: How to configure pollerd in {page-component-title} to change service monitoring behavior: define thread pool, downtime model, asynchronous engine.

For information on configuration and log files related to pollerd, see xref:reference:daemons/daemon-config-files/pollerd.adoc[] in the reference section.

You can modify `$\{OPENNMS_HOME}/etc/poller-configuration.xml` to change the behavior for service monitoring.
The configuration file has the following parts:

* Global daemon configuration:
** Define the thread pool size used to run service monitors in parallel.
** Define and configure the critical service for node event correlation.
* Polling packages:
** Package to group service monitor configuration parameters.
* Downtime Model:
** Configure pollerd behavior to run tests if an outage is detected.
* Monitor service association:
** Implement application or network management protocol assignments.
This configures settings for individual services, based on their names.

.Global configuration parameters for pollerd
[source, xml]
----
<poller-configuration threads="30" <1>
                      pathOutageEnabled="false" <2>
                      serviceUnresponsiveEnabled="false"> <3>
----

<1> Size of the thread pool.
This lets service monitors run 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, generate a `serviceUnresponsive` event instead of an outage.
This stops the xref:operation:deep-dive/service-assurance/downtime-model.adoc[Downtime Model] from retesting the service after 30 seconds, and prevents false alarms.

Restart {page-component-title} and pollerd to apply configuration changes.
You can also reload the configuration to send an event to pollerd.
You can send an event using the CLI or the web UI.

.Send `configuration-reload` event via CLI
[source, shell]
----
cd $OPENNMS_HOME/bin
./send-event.pl uei.opennms.org/internal/reloadDaemonConfig --parm 'daemonName Pollerd'
----

The following shows settings to configure a reload event in the UI:
.Send `configuration-reload` event in the web UI
image::service-assurance/04_send-event-WebUI.png["Page displaying configuration settings for generating a configuration-reload event", 700]

[[ga-pollerd-configuration-meta-data]]
== Metadata DSL

The <<deep-dive/meta-data.adoc#ga-meta-data-dsl, 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

[[ga-pollerd-configuration-async]]
== Asynchronous engine

By default, the number of polls active at any given time is limited by the number of threads that are allocated to pollerd.
Each thread is responsible for one poll, and will block until the poll is completed; this is true even when the polling is done by a Minion at a remote location.
In this case, the thread is blocked for the duration of the remote procedure call.

If you have hundreds of locations and hundreds of nodes at each location, you may want to reduce the number of threads required on your {page-component-title} instance.
Each thread allocates a fixed amount of system memory.
Having too many threads active at a given time can cause extensive load on the system.

When enabled, the asynchronous polling mode mitigates this load.
It allows threads to be released while polls are active, enabling Minions to process more polls than the number of threads available.

To enable the feature, set the following attributes in the top-level element of `etc/poller-configuration.xml`:

[source, xml]
----
<poller-configuration threads="30"
                      asyncPollingEngineEnabled="true" <1>
                      maxConcurrentAsyncPolls="200" <2>
----
<1> Enables the asynchronous polling engine.
<2> Used to limit the number of polls active, since each of these still consumes some memory resources.

In this mode, threads are used only to trigger a poll to run; this means that the number of threads can typically be reduced.
You can see the actual number of active (in-flight) polls by reviewing the `NumPollsInFlight` metrics associated with pollerd's MBeans.

NOTE: To disable asynchronous polling, set `asyncPollingEngineEnabled` to false.