Policy Templates

Templates can contain agent policies that are automatically deployed to all nodes the template is applied to. Policies provide centralized management of agent configuration, log monitoring rules, file delivery, and more.

For detailed information on each policy type and how policies work at the agent level, see Agent Policies.

Policy Types

NetXMS templates support the following policy types:

Type Description

Agent Configuration

Pushes configuration parameters to agents

Log Parser

Deploys log parsing and monitoring rules

File Delivery

Delivers files to managed hosts

User Support Application

Configures the user support application

Managing Policies on Templates

Adding a Policy

  1. Select a template and click the Agent Policies tab

  2. Click the plus icon to create a new policy

  3. Give it a name, choose the correct policy type, and click OK

  4. The newly created policy will open for editing in a new tab

Editing a Policy

An existing policy can be modified by right-clicking it and selecting Edit from the menu, or by double-clicking on it. Use the Save button after configuration changes.

Policies are deployed to nodes automatically:

  • After editing, the Agent Policies view shows a "Changes in policies have been made" message with a Deploy policies button. This button redeploys all policies unconditionally, the same as Force deploy in the policy list (or Force deployment of agent policies in the template’s context menu).

  • Closing the view instead deploys only policies that have actually changed (based on version/hash comparison).

  • Both paths deploy only to nodes with a live agent connection at that moment.

  • Every configuration poll verifies policy deployment on the node, so nodes that were offline receive the policy on their next poll.

Removing a Policy

When a configuration policy is deleted or a template is removed from a node, the policy is automatically undeployed from the node.

Agent Configuration Policies

Agent configuration policies push configuration snippets to agents. This is the recommended way to manage agent settings at scale, rather than editing nxagentd.conf on each host.

Use cases:

  • Define external metrics for custom monitoring

  • Configure external lists

  • Define actions for remote execution

  • Load subagents

  • Set agent parameters (log file location, file store path, etc.)

Example policy content:

# Custom Linux monitoring metrics
ExternalMetric = Hardware.CPUTemp: sensors | grep 'Core 0' | tr -s ' ' | cut -d' ' -f3 | tr -d '+°C'
ExternalMetric = Custom.ProcessMemory(*): pgrep -f "$1" | head -1 | xargs -r ps -o rss= -p
ExternalList = System.Services: systemctl list-units --type=service --state=running --no-legend | cut -d' ' -f1
SubAgent = filemgr.nsm
In ExternalMetric and ExternalList command lines, $1 …​ $9 are replaced with the metric’s arguments, and any other $ is removed by the agent. Shell constructs like awk '{print $3}' or $(command) will not survive this substitution — avoid $ in inline commands (use cut, xargs, etc.), or move the logic into a script file delivered by a file delivery policy. In Action command lines, only $N sequences with a supplied argument are replaced; unmatched $ sequences are left intact.

Merging Behavior

The main agent configuration is merged with additional rules from policies:

  • If the policy and master config have the same parameter that can be set only once (e.g. LogFile), the policy will overwrite the master config value

  • If the policy and master config have the same parameter that can be set multiple times (e.g. Target for PING subagent or Query for DBQUERY), the policy will merge both lists

The agent should be manually restarted to apply the configuration after an agent configuration policy is deployed or undeployed.

Log Parser Policies

Log parser policies deploy monitoring rules that watch log files for patterns and generate events.

Example policy:

<parser>
  <file>/var/log/syslog</file>
  <rules>
    <rule>
      <match>(error|fail|critical)</match>
      <event>100000</event>
      <description>Generic error watch</description>
    </rule>
    <rule>
      <match>out of memory</match>
      <event>100001</event>
      <description>OOM condition watch</description>
    </rule>
  </rules>
</parser>

The <description> element is only a label for the rule. The text of the generated event comes from the event template; regular expression capture groups from <match> are passed as event parameters %1, %2, and so on.

Log parser configuration is applied right after log parser policy is deployed or undeployed — no agent restart is required.

Multiple log parser policies can coexist on the same agent. Each policy monitors its specified file independently.

For complete log parser syntax, see Log Monitoring.

File Delivery Policies

File delivery policies automatically upload files from the server to agents.

To configure a file delivery policy, first create root folders (directories with the full path to the location where uploadable files and folder structure should be placed). After the folder structure is created, files can be added to this structure. On policy apply, folders will be created (if possible) and files will be uploaded.

In file and folder names, the following macros can be used:

  • Environment variables as ${ENV_VAR_NAME}

  • strftime(3C) macros for date/time formatting

  • Text inside backticks will be executed as a command and the first line of output will be taken — this works only when the requesting server is listed in the agent’s MasterServers; the environment variable and strftime macros are expanded unconditionally

File delivery policy uses the File Manager subagent to upload files, so the filemgr subagent should be loaded and root folders should be defined to provide write access to folders.

For details, see File Delivery.

Combining Policies with DCIs

Templates commonly combine policies and DCIs for complete monitoring solutions. For example, a "PostgreSQL Monitoring" template might contain:

  • An agent configuration policy that defines external metrics for PostgreSQL monitoring

  • DCIs that collect those metrics using the external metrics

  • Thresholds on the DCIs that generate alerts for abnormal values

  • A log parser policy that monitors the PostgreSQL log for errors

This approach packages a complete monitoring solution in a single template that can be applied to any PostgreSQL server.

Policy Deployment and Storage

Installed policy configurations are stored as files under the agent’s data directory, in a per-type subdirectory (agent configuration policies in config.d, log parser and user support application policies in their own directories). The list of applied policies is stored in the agent’s local database.

If the agent discovers a record in its local database for which the policy file is missing, it will delete the record from the database.

When performing deployment, the server checks information in the agent’s database against its own database and issues necessary commands.

Best Practices

  • Name policies descriptively — include the purpose and target platform (e.g., "Linux - Custom Disk Metrics", "Windows - IIS Log Parser")

  • Group related configuration into a single policy rather than many small ones

  • Test policies on a staging template with a few test nodes before applying to production

  • Use multiple templates to layer generic and specific policies on the same node

  • Document policy contents with comments (# for agent config, <!-- -→ for log parser XML)