Netxms Admin

NetXMS Administrator Guide
Release 3.8.267
Raden Solutions, SIA
Jun 16, 2021

CONTENTS
1 Introduction 1
2 Concepts 3
3 Installation 11
4 Upgrade 31
5 Quick start 37
6 Agent management 49
7 Server management 67
8 SNMP 75
9 User management 85
10 Object management 97
11 Network discovery 127
12 Data collection 131
13 Event processing 151
14 Data and Network visualisation 177
15 Grafana integration 219
16 Operating System Monitoring 223
17 File meta information 231
18 Log monitoring 237
19 Windows Event Log Synchronization 249
20 SSH monitoring 253
21 Service monitoring 255
22 Data Collection from Web Services 261
i
23 Database monitoring 265
24 Application monitoring 285
25 ICMP ping 289
26 Hardware(sensor) monitoring 293
27 UPS monitoring 299
28 Cluster monitoring 301
29 JVM monitoring 303
30 Hypervisor monitoring 307
31 Asterisk monitoring 311
32 Monitoring mobile devices 317
33 Network topology 321
34 Business services and SLA 325
35 Remote file management 329
36 Reporting 335
37 Image library 343
38 Mobile Console 345
39 Advanced topics 357
40 Scheduled tasks 375
41 Scripting 377
42 Appendix 381
43 Glossary 457
Index 461
ii
CHAPTER
ONE
INTRODUCTION
This document covers installation, configuration, and use of NetXMS.

NetXMS is an enterprise grade multi-platform modular open source network management and monitoring system. It
provides comprehensive event management, performance monitoring, alerting, reporting and graphing for all layers
of IT infrastructure — from network devices to business application layer. Having been designed with flexibility and
scalability in mind, NetXMS features a wide range of supported platforms. It is licensed under the GNU General
Public License version 2 as published by the Free Software Foundation.
1.1 Product Support
Contact us if you run into a problem or found a bug.

• Forum
• Telegram
• Issue tracker
• Facebook
• Twitter
• IRC channel
Priority support for NetXMS is provided by Raden Solutions
1.2 Conventions
The following typographical conventions are used in this manual.
Sample Description
Button Any GUI element: Button, Menu item
Another Guide Reference to external manual or man page
Control-M Keyboard shortcut
DCI Term which could be found in glossary
File → Exit Menu selection path, you must click on File, then Exit
1
NetXMS Administrator Guide, Release 3.8.267
1.2.1 Changelog
Complete change log for each product release is available at http://www.netxms.org/download/ChangeLog.
2 Chapter 1. Introduction
CHAPTER
TWO
CONCEPTS
2.1 Architecture overview
The system has three-tier architecture: the information is collected by monitoring agents (either our own high-
performance agents or SNMP agents) and delivered to monitoring server for processing and storage. Network ad-
ministrator can access collected data using cross-platform Management Console (Rich Console), Web Interface (Web
console) or Management Console for Android. Rich and Web console have almost the same functionality and the
same user interface.
3
2.2 Objects
All monitored network infrastructure is represented as a set of objects in NetXMS monitoring system. Each object
represents one physical or logical entity (e.g. host or network interface), or group of them (e.g. subnet, container).
Objects are organized into hierarchical structure. Each object has it’s own access rights. Access rights are applied
hierarchically on all children of object. For example if Read access right is granted to a user on a Container, then
user has Read right on all objects that this Container contains. Every object has set of attributes; some of them exist
for all objects (like id and name or status), while other depend on object class – for example, only Node objects have
attribute SNMP community string. There are default attributes and custom attributes defined either by user or external
application via NetXMS API.
NetXMS has six top level objects – Entire Network, Service Root (named “Infrastructure Services” after
system installation), Template Root, Network Map Root, Dashboard Root and Business Service
Root. These objects serve as an abstract root for an appropriate object tree. All top level objects have only one
editable attribute – name.
Object Class Description Valid Child Objects

Entire Network Abstract object representing root of IP topology tree.
All zone and subnet objects located under it. System • Zone (if zoning enabled)
can have only one object of this class. • Subnet (if zoning dis-
abled)
Zone Object representing group of (usually interconnected)

IP networks without overlapping addresses. Contains • Subnet
appropriate subnet objects.
Subnet Object representing IP subnet. Typically objects of this
class are created automatically by the system to reflect • Node
system’s knowledge of IP topology. The system places
Node objects inside an appropriate Subnet object based
on an interface configuration. Subnet objects have only
one editable attribute - Name.
Node Object representing physical host or network device
(such as a router or network switch). These objects can • Interface
be created either manually by administrator or automat- • Access point
ically during network discovery process. They have a • Network Service
lot of attributes controlling all aspects of interaction be- • VPN Connector
tween NetXMS server and managed node. For example,
the attributes specify what data must be collected, how
node status must be checked, which protocol versions
to use, etc. Node objects contain one or more interface
objects. The system creates interface objects automati-
cally during configuration polls.
Interface Interface objects represent network interfaces of man-
aged computers and devices. These objects created au-
tomatically by the system during configuration polls or
can be created manually by user.
Access point Object representing wireless network access point. A
node can have several access points, e.g. 2.4Ghz and
5Ghz, or in case of thin wireless access points managed
by a central controller. These objects are created auto-
matically by the system.
continues on next page
4 Chapter 2. Concepts
Table 1 – continued from previous page

Network Service Object representing network service running on a node
(like http or ssh), which is accessible online (via TCP
IP). Network Service objects are always created man-
ually. Currently, the system works with the following
protocols - HTTP, POP3, SMTP, Telnet, SSH and Cus-
tom protocol type.
VPN Connector Object representing VPN tunnel endpoint. Such objects
can be created to add VPN tunnels to network topology
known to NetXMS server. VPN Connector objects are
created manually. In case if there is a VPN connection
linking two different networks open between two fire-
walls that are added to the system as objects, a user can
create a VPN Connector object on each of the firewall
objects and link one to another. The network topology
will now show that those two networks are connected
and the system will take this condition into account dur-
ing problem analysis and event correlation.
Service Root Abstract object representing root of your infrastructure
service tree. System can have only one object of this • Cluster
class. After system installation it is named “Infrastruc- • Chassis
ture Services”. • Condition
• Container
• Node
• Sensor
• Subnet
• Rack
Container Grouping object which can contain any type of objects

that Service Root can contain. With help of container • Cluster
objects you can build object’s tree which represents log- • Chassis
ical hierarchy of IT services in your organization. • Condition
• Container
• Node
• Sensor
• Subnet
• Rack
Cluster Object representing cluster consisting of two or more

nodes. See Cluster monitoring for more information. • Node
Rack Object representing a rack. It has the same purpose as

container, but allows to configure visual representation • Node
of equipment installed in a rack. • Chassis
Chassis Object representing a chassis, e.g. a blade server enclo-

sure. Chassis can be configured as a part of a rack. • Node
2.2. Objects 5

Condition Object representing complicated condition – like “cpu
on node1 is overloaded and node2 is down for more than
10 minutes”. Conditions may represent more compli-
cated status checks because each condition can have a
script attached. Interval for evaluation of condition sta-
tus is configured in Server Configuration Variables as
ConditionPollingInterval with default value 60 seconds.
Template Root Abstract object representing root of your template tree.
• Template
• Template Group
Template Group Grouping object which can contain templates or other

template groups. • Template
• Template Group
Template Data collection template. See Data collection section

for more information about templates. • Mobile Device
• Node
Network Map Root Abstract object representing root of your network map
tree. • Network Map
• Network Map Group
Network Map Grouping object which can contain network maps or

Group other network map groups. • Network Map
• Network Map Group
Network Map Network map.

Dashboard Root Abstract object representing root of your dashboard
tree. • Dashboard
Dashboard Dashboard. Can contain other dashboards.

• Dashboard
Business Service Abstract object representing root of your business ser-

Root vice tree. System can have only one object of this class. • Business Service
Business Service Object representing single business service. Can con-

tain other business services, node links, or service • Business Service
checks. • Node Link
• Service Check
Node Link Link between node object and business service. Used to
simplify creation of node-related service checks. • Service Check
Service Check Object used to check business service state. One busi-
ness service can contain multiple checks.
2.2.1 Object status
Each object has a status. Status of an object calculated based on:

• Polling results
• Status of child objects (e.g. interfaces of node, nodes under container)
• Active alarms, associated with the object (after an alarm is resolved or terminated, it no longer affects object
status)
• Value of status DCIs (DCI that has Use this DCI for node status calculation property en-
abled)
There are multiple options for status calculation, see Status calculation for more information.
For some object classes, like Report or Template, status is irrelevant. Status for such objects is always Normal. Object’s
status can be one of the following:
Nr. Status Description
0 Normal Object is in normal state.
1 Warning Warning(s) exist for the object.
2 Minor Minor problem(s) exist for the object.
3 Major Major problem(s) exist for the object.
4 Critical Critical problem(s) exist for the object.
5 Unknown Object’s status is unknown to the management server.
6 Unmanaged Object is set to “unmanaged” state.
7 Disabled Object is administratively disabled (only applicable to interface objects).
8 Testing Object is in testing state (only applicable to interface objects).
2.2.2 Unmanaged status
Objects can be unmanaged. In this status object is not polled, DCIs are not collected, no data is updated about object.
This status can be used to store data about an object that is temporary or permanently unavailable or not managed.
2.2.3 Maintenance mode
This is special status, that’s why it is not included in above status list. This status prevents event processing for specific
node. While this node in maintenance mode is still polled and DCI data is still collected, but no event is generated.
2.2. Objects 7
2.3 Event Processing
NetXMS is event based monitoring system. Events can come from different sources (polling processes (status, con-
figuration, discovery, and data collection), SNMP traps, and directly from external applications via client library). All
events all are forwarded to NetXMS Event Queue.
NetXMS Event Processor can process events from Event Queue in either sequential or parallel mode. In sequential
mode events are processed one-by-one. Parallel processing mode allows to process events in several parallel threads,
thus increasing processing performance. See Event processing for more information.
Events in the Event Queue are processed according to rules defined in Event Processing Policy. As a result of event
processing, preconfigured actions can be executed, and/or event can be shown up as alarm.
Usually alarm represents something that needs attention of network administrators or network control center operators,
for example low free disk space on a server. NetXMS provides one centralized location, the Alarm Browser, where
alarms are visible. It can be configured which events should be considered important enough to show up as alarm.
Fig. 1: Event flow inside the monitoring system
2.4 Polling
For some type of objects NetXMS server start gathering status and configuration information as soon as they are added
to the system. These object types are: nodes, access points, conditions, clusters, business services, zones (if a zone has
more then one proxy, proxy health check is being performed). This process called polling. There are multiple polling
types, usually performed with different intervals:
Type Purpose
Status Determine current status of an object
ICMP Ping nodes and gather response time statistics
Configuration Determine current configuration of an object (list of interfaces, supported protocols, etc.)
Topology Gather information related to network topology
Routing Gather information about IP routing
Instance Discovery Verify all DCIs created by instance discovery process
Network Discov- Searches for new nodes by polling information about neighbor IP addresses from known
ery nodes
2.5 Data Collection
From each node NetXMS can collect one or more metrics which can be either single-value (e.g. “CPU.Usage”),
list (e.g. “FileSystem.MountPoints”) or table (e.g. “FileSystem.Volumes”). When new data sample is collected, it’s
value is checked against configured thresholds. This documentation use term Data Collection Item (DCI) to describe
configuration of metric collection schedule, retention, and thresholds.
Metrics can be collected from multiple data sources:
Source Description
Internal Data generated inside NetXMS server process (server statistics, etc.)
NetXMS Agent Data is collected from NetXMS agent, which should be installed on target node.
Server collect data from agent based on schedule.
SNMP SNMP transport will be used. Server collect data based on schedule.
Web service Data is objained from JSON, XML, or plain text retrieved via HTTP
Push Values are pushed by external system (using nxpush or API) or from NXSL
script.
Windows Performance counters Data is collected via NetXMS agent running on Windows machine.
Script Value is generated by NXSL script. Script should be stored in Script Library.
SSH Data is obtained from output of ssh command executed through SSH connec-
tion.
MQTT Data is obtained by subcribing to MQTT broker topics.
Network Device Driver Some SNMP drivers (NET-SNMP, RITTAL as of NetXMS v. 3.8) provide pa-
rameters for data collection. E.g. NET-SNMP provides information about stor-
age this way.
2.6 Discovery
2.6.1 Network discovery
NetXMS can detect new devices and servers on the network and automatically create node objects for them. Two
modes are available – passive and active.
In passive mode server will use only non-intrusive methods by querying ARP and routing tables from known nodes.
Tables from the server running NetXMS are used as seed for passive discovery.
In active mode in addition to passive scan methods configured address ranges are periodically scanned using ICMP
echo requests.
NetXMS can also use SNMP trap and syslog messages as seed for discovery.
2.5. Data Collection 9

2.6.2 Instance discovery
NetXMS can create parameters for Data Collection Item automatically. Instance discovery collects information about
node instances like disk mountpoints, device list, etc. and automatically creates or removes DCIs with obtained data.
2.7 Security
All communications are encrypted using either AES-256, AES-128, or Blowfish and authenticated. As additional
security measure, administrator can restrict list of allowed ciphers.
Agent authenticate incoming connections using IP white list and optional preshared key.
User passwords (if internal database is used) as hashed with salt with SHA-256.
All shared secrets and passwords stored in the system can be obfuscated to prevent snooping.
CHAPTER
THREE
INSTALLATION
3.1 Major changes between releases
3.1.1 3.0
Notification channels introduced as new functionality. SMS configuration automatically moved from server configu-
ration to notification channel depending on old driver with one of next names: AnySMS, DBTable, Dummy, GSM,
Kannel, MyMobile, Nexmo, NXAgent, Portech, Slack, SMSEagle, Text2Reach, WebSMS. No manual actions re-
quired.
Flags and dynamic flags moved to NetObject class. Separated node flags set by user and capability flags set by system
to flags and capabilities. Numeric values for flags, capabilities and dynamic flags were changed. Will affect only
NXSL scripts that checked those flags directly.
32 bit version of management console is not available any more.
Agent always requires encryption unless RequireEncryption parameter explicitly set to off. Might be required to
manually add “RequireEncryption” configuration parameter where required to disable encryption.
Agent policies were merged with templates. Each policy was converted to template. No changes required.
3.1.2 3.1
Regexp matching operation in NXSL returns array with capture groups or NULL as result. NXSL objects and arrays
in logical expressions are evaluated to TRUE. Might be require some NXSL script adjustments.
3.1.3 3.5
External Metrics (ExternalParameter, etc. . . ) expect UTF-8 encoding on Windows. Might need to adjust scripts called
by external metrics if non-ASCII characters are returned.
11
3.1.4 3.6
In this version “Certificate manager” was removed from server. All CA certificates configuration should be manually
moved to “TrustedCertificate” configuration parameter in server configuration file.
3.1.5 3.7
Introduced boolean type in NXSL. Comparisons like “func() == 1”, where ‘func’ is a function that returns boolean
type, will always result as false as boolean value ‘true’ is not equal to 1. Might require fixes in some NXSL scripts.
Regexp matching operation in NXSL returns array with capture groups or false as a result.
Clusters now have configuration poll. If you have configuration poll hook script that is referring to $node object,
this will produce error message in server log each time a configuration poll runs on a cluster. Replace $node with
$object or use condition if (classof($object) == "Node") or if ($node != null) prior to ac-
cessing attributes or methods of $node.
3.1.6 3.8
Minimal JRE (Java Runtime Environment) version for console is Java-11.
3.2 Planing
3.2.1 Operating system
Both NetXMS server and agent works fine on most operating systems, including Windows, Linux, and commercial
UNIXes. However, we test and officially support only some of them.
Supported platforms for NetXMS server and agent:
• Debian 9 (Stretch), 10 (Buster)
• Ubuntu 16.04 LTS (Xenial), 18.04 LTS (Bionic), 20.04 LTS (Focal Fossa)
• Linux Mint 19.3 (Tricia), Linux Mint Debian Edition 4
• Devuan ASCII
• Red Hat Enterprise Linux 8
• CentOS 8
• Windows 10, Windows Server 2016, 2019
• FreeBSD 12
• ArchLinux (Latest)
• AlpineLinux 3.8+
• Raspbian Buster
Support for the following platforms provided only to customers with active support contract:
• Debian 8 (Jessie)
• Ubuntu 14.04 LTS
• Devuan Jessie
12 Chapter 3. Installation
• Red Hat Enterprise Linux 6, 7

• CentOS 6, CentOS 7
• FreeBSD 11, FreeBSD 11.3
• Windows 7, Windows 8.1, Windows Server 2008 R2, 2012, 2012 R2
• AIX 6.1, AIX 7.x
• SUSE Linux Enterprise Server 11, 12, 15
• Solaris 11 (agent only)
• HP-UX 11.31 (agent only)
3.2.2 Server hardware
Minimal requirements: Core 2 duo 1GHz, 1024MB RAM, 1GB disk space.
3.2.3 Database
Database engines supported by NetXMS server:

• PostgreSQL 9.5, 9.6, 10, 11, 12, 13
• PostgreSQL with TimescaleDB 11, 12, 13
• MySQL 5.6, 5.7, 8.0
• MariaDB 10.1, 10.2, 10.3, 10.4
• Oracle 12c, 18c, 19c
• Microsoft SQL Server 2012, 2014, 2016, 2017
• SQLite (only for test purposes)
Postgres database tuning might be required depending on database size. Increase of shared_buffers might be
needed, rough recommendation is 25% of available RAM. Increase of max_locks_per_transaction is needed
if using TimescaleDB, rough recommendation is 512.
Database size and load is very hard to predict, because it is dependent on a number of monitored nodes and collected
parameters. If you plan to install database engine on the same machine as NetXMS server, increase your hardware
requirements accordingly.
Link to Excel file that allows roughly estimate the size that will be required for database: http://git.netxms.org/public/
netxms.git/blob/HEAD:/doc/misc/database_sizing.xlsx
3.2.4 Java
Java Runtime Environment (JRE) is needed for Desktop Management Console (nxmc) and for Web Management
Console. Supported Java version are 11 and 15.
Since version 3.8 Desktop Management Console with bundled JRE is provided for Windows.
3.2. Planing 13
3.2.5 Agent
Agent resource usage is negligible and can be ignored.
3.3 Installing from deb repository
We host public APT repository http://packages.netxms.org/ for all deb-based distributions (Debian, Ubuntu, Mint,
Raspbian, etc.). Packages are signed, and you’ll need to install additional encryption key for signature verification.
Two components are supported - “main” and “unstable”.
Supported URLs (CODENAME should be replaced with output of lsb_release -sc):
• Debian, LMDE - “deb http://packages.netxms.org/debian CODENAME main”
• Ubuntu, Mint - “deb http://packages.netxms.org/ubuntu CODENAME main”
• Devuan - “deb http://packages.netxms.org/devuan CODENAME main”
• Raspbian - “deb http://packages.netxms.org/raspbian CODENAME main”
3.3.1 Add APT repository
There are two options to add APT repository: by hand or using netxms-release package. Use of the release package
is strongly encouraged because it allow easy change in repository configuration and encryption keys updated in the
feature.
Using netxms-release package
Download and install netxms-release-latest.deb package, which contain source list file of the repository as well as
signing key.
wget http://packages.netxms.org/netxms-release-latest.deb
sudo dpkg -i netxms-release-latest.deb
sudo apt-get update
Manually
Add the repository to your sources.list:
echo "deb http://packages.netxms.org/$(lsb_release -si | tr A-Z a-z) $(lsb_release -

˓→sc | tr A-Z a-z) main" > /etc/apt/sources.list.d/netxms.list
wget -q -O - http://packages.netxms.org/netxms.gpg | sudo apt-key add -
sudo apt-get update
3.3.2 Installing packages
Server
Server require two components to function - server itself (package “netxms-server”) and at least one database abstrac-
tion layer driver (multiple can be installed at the same time, e.g. for migration purposes). These database drivers are
also used by agent for database monitoring (performing queries to databases).
Provided driver packages:
• netxms-dbdrv-pgsql - PostgreSQL driver
• netxms-dbdrv-mariadb - Mariadb driver
• netxms-dbdrv-mysql - MySQL driver (not built for Ubuntu 20 / Mint 20)
• netxms-dbdrv-odbc - unixODBC driver (can be used with DB/2 and Microsoft SQL)
• netxms-dbdrv-oracle - Oracle driver
1. Instal required packages (adjust command to match your environment):
apt-get install netxms-server netxms-dbdrv-pgsql
1. Create user and database (examples).

2. Modify server configuration file (“/etc/netxmsd.conf” to match your environment.
3. Load database schema and default configuration:
nxdbmgr init
1. Start server:
systemctl start netxmsd
1. Enable automatic startup of server:
systemctl enable netxmsd
Note: Default credentials - user “admin” with password “netxms”.
Agent
Install core agent package (“netxms-agent”) and optional subagent packages, if required:
apt-get install netxms-agent
Start agent
systemctl start nxagentd
Enable automatic startup of agent
systemctl enable nxagentd
3.3. Installing from deb repository 15

Management console
Desktop Management Console
Due to limitation of Eclipse platform used to build the Management Console, only x64 build is provided.
1. Make sure you have 64-bit Java version 11 or 15 installed you your system.
2. Download the latest version from http://www.netxms.org/download. You will need Linux installer (named
nxmc-VERSION-linux-gtk-x64.tar.gz, for example nxmc-3.4.178-linux-gtk-x64.tar.gz).
3. Expand package to your preferred directory using command:
tar zxvf nxmc-VERSION-linux-gtk-x86.tar.gz -C /DESTINATION_DIRECTORY
4. Run nxmc file from “/DESTINATION_DIRECTORY”.
Desktop management console produces log file .nxmc/data/.metadata/.log in home folder of currently
logged user. Inspect this log file if you encounter errors when running the console.
Web Management Console
NetXMS web interface is java based and should be deployed into servlet container to run. Minimal supported versions:
Jetty 9.3.28, Tomcat 8.5. Supported Java version is 11 or 15.
1. Install one of servlet containers that support servlet-api version 3.
2. Download latest version of WAR file from Web Interface Binaries section http://www.netxms.org/download/
(named nxmc-VERSION.war, for example nxmc-3.4.178.war).
3. Copy nxmc.war to webapps directory, in a few seconds it will be autodeployed and available at http://SERVER_
IP:SERVER_PORT/nxmc/
Tomcat default folder: /var/lib/tomcat9/webapps
Jetty default folder: $JETTY_HOME/webapps/
Web management console produces log file. For Tomcat it’s located at /var/lib/tomcat9/work/Catalina/
localhost/nxmc/eclipse/workspace/.metadata/.log. Inspect this log file if you encounter errors
when running the web console.
3.4 Installing on Red Hat, Fedora, CentOS or ScientificLinux
RPM packages are not released at the moment. Please refer to section Installing from source.
3.5 Installing on Windows
3.5.1 Server
1. Download the latest version from http://www.netxms.org/download. You will need Windows in-
staller (named netxms-VERSION-x64.exe, e.g. netxms-server-3.4.178-x64.exe). Please note that in
following steps VERSION will be used as a substitution for an actual version number.
2. Run the installer package on your server machine. Installation wizard will be shown. Follow the
prompts until the Select Components window opens.
3. On the Select Components window, select NetXMS Server option and an appropriate database client
library. You do not have to install database client library from NetXMS package, if it is already
installed on the machine (however, it might be required to add folder where the client library is
installed to system path).
4. For a typical installation keep default settings on Select Additional Tasks window. Set hardened file
system permissions makes installation folder accessible only to members of Administrators group
and SYSTEM user.
4. Follow the prompts until Ready to Install window opens.

5. On Ready to Install window, check whether everything is correct, then press the Install button.
6. After copying files, Server Configuration Wizard will open:
3.5. Installing on Windows 17

Press the Next button to start NetXMS server configuration.

7. Database selection window will open:
• Select the desired database engine and driver. For most databases, you will have two drivers available
– native and ODBC. Please note that if you select ODBC, you will have to manually configure ODBC
source.
• Enter the name of database server or ODBC source.
• In DBA login name and DBA password fields, enter database administrator’s login name and pass-
word. You have to fill these fields only if you have chosen Create new database option.
• Enter the desired database name, database user name and password. If you are not using ODBC,
the wizard will create database and a user for you. If ODBC is used, database and user should be
created beforehand.
MySQL note Bundled MySQL database drive does not support caching_sha2_password authenti-
cation which is default for MySQL starting from version 8. Either select Legacy Authentication
Method when installing MySQL, or use database driver installed along with MySQL. Database
driver gets installed when installing MySQL with Server-only option, however these two folders
should be included into system path: C:\Program Files\MySQL\MySQL Server 8.0\
lib C:\Program Files\MySQL\MySQL Server 8.0\bin.
Microsoft SQL note:
If you wish to use Windows authentication for database connectivity, use * (asterisk) as a login name
and leave the password field blank. If you specify asterisk as DBA login, user with which you are
logged in to Windows should have administrative rights to the database server. If you use asterisk as
DB login, you should run NetXMS Server service as a user with appropriate rights to the database.
Oracle note:
We recommend to use native database driver (oracle.ddr).
9. On the next window, enter address of your SMTP server. NetXMS will use it to send notification
e-mails.
10. Then next window will prompt you for logging method. Either check Event Log or select file, and
press the Next button.
11. Windows service configuration window will appear:
In most situations, you can run NetXMS server under Local System account. You may need to
run it under specific account if you are using Microsoft SQL database and Windows authenti-
cation, or for security reasons.
12. Windows service dependency window will appear:

If you have database engine running on same server, you can find it in service list and mark,
so NetXMS server’s service will depend on database service and service startup order will be
correct.
13. Follow the prompts until server configuration will be complete. After successful server configuration,
installation will be finished, and you will have NetXMS server up and running.
Server default credentials:
Login: admin
Password: netxms
3.5.2 Agent
1. Download the latest version from http://www.netxms.org/download, if you don’t have it. You will need Win-
dows Agent installer (named nxagent-VERSION.exe or nxagent-VERSION-x64.exe, for example nxagent-
3.4.178.exe).
2. Run the installer package on target server. Installation wizard will be shown. Follow the prompts until the
NetXMS Server window opens:
Enter IP address or host name of your NetXMS server. You can specify multiple management servers, separating
them by commas. Press the Next button to continue.
3. Subagent selection window will open:
In this window, you can select which subagents you wish to load. Each subagent extends agent’s functionality,
e.g.:

Subagent Description
filemgr.nsm Provides access to specified folders on monitored host from NetXMS Management Console
File Manager. Is also being used for distributing Agent Policy configuration files (see Agent
Policies.)
logwatch Allows monitoring log files and Windows Event Log and sending matched events to
NetXMS server.
ping.nsm Adds possibility to send ICMP pings from monitored host. Ping round-trip times can be
collected by management server.
netsvc.nsm, Adds possibility to check network services (like FTP or HTTP) from monitored host.
portcheck.nsm
winperf.nsm Provides access to Windows performance counters. This subagent is required if you need
to collect CPU utilization from monitored host.
wmi.nsm Provides access to WMI data.
ups.nsm Adds support for UPS monitoring. UPS can be attached to host via serial cable or USB.
For more information about subagents, please refer to Subagents.

4. Follow the prompts to complete the installation.
3.5.3 Management console
Desktop Management Console:

1. Download the latest version from http://www.netxms.org/download. Since version 3.8 there are three options
- archive (e.g. nxmc-3.8.226-win32-x64.zip), archive with bundled JRE (nxmc-3.8.226-win32-x64-bundled-
jre.zip) and installer, which also has JRE bundled (e.g. netxms-client-3.8.166-x64.exe). If using archive without
JRE, make sure you have JRE version 11 or 15 installed. Due to limitation of Eclipse platform used to build the
Management Console, only x64 build is currently provided.
2. If using archive version, extract zip in preferred directory. If using installer, launch it and follow the instructions.
3. Run nxmc file from extracted catalog (or launch from Windows Start Menu, if you used the installer).
Web Management Console:
Windows have two options: one is to manually install .war file into servlet container and the second one is to use
netxms-webui-VERSION-x64.exe installer. Installer will install Jetty and copy .war file into required folder. Below
will be described installation via the installer:
1. Download the latest version from http://www.netxms.org/download. You will need Windows installer netxms-
webui-VERSION-x64.exe (e.g.: netxms-webui-4.3.178-x64.exe). Due to limitation of Eclipse platform used to
build the Management Console, only x64 build is currently provided.
2. Run the installer package on your server machine. Installation wizard will be shown. Follow the prompts.
Installer allows to change installation path and port.
3. After installation procedure is finished check that WEB GUI is available at http://SERVER_IP:SERVER_PORT/
nxmc/
3.5.4 Unattended installation of NetXMS Agent
Windows Agent installer (named nxagent-VERSION.exe, for example nxagent-3.4.178.exe), has various command
line options for unattended installation. Installation will ignore any configuration file options (/CONFIGENTRY,
/NOSUBAGENT, /SERVER, /SUBAGENT, etc) if config file already exists or if /CENTRALCONFIG option is used.
However, it’s possible to delete and recreate the configuration file with /FORCECREATECONFIG command line
option.
The options are following:
Option Description
/CENTRALCONFIG Enable read configuration from server on startup. See Agent configuration files
on server for more information.
/CONFIGENTRY=value It can be used to add any parameter to configuration file during initial install. You
can specify it multiple times to add multiple lines. Section names can be added
as well.
/CONFIGINCLUDEDIR=path Set folder containing additional configuration files (will be set in configuration
file as ConfigIncludeDir).
/DIR=path Set installation directory (default is C:\NetXMS).
/FILESTORE=path Sets directory to be used for storing files uploaded by management server(s) (will
be set in configuration file as FileStore).
/FORCECREATECONFIG Delete existing agent configuration file and recreate it. However, settings stored
by installer in Windows registry will be used, if not explicitly specified by com-
mand line parameters. See /IGNOREPREVIOUSDATA.
/IGNOREPREVIOUSDATA Ignore any settings from previous install that are not explicitly specified in current
run. This is related to settings that can be changed when installer is run in GUI
mode, e.g. list of selected sub-agents. These settings are stored in Windows
registry.
/LOCALCONFIG Use local configuration file (it is the default).
/LOG Causes Setup to create a log file in the user’s TEMP directory detailing file instal-
lation and [Run] actions taken during the installation process.
/LOG=filename Same as /LOG, except it allows to specify a fixed path/filename to use for the log
file. If a file with the specified name already exists it will be overwritten. If the
file cannot be created, Setup will abort with an error message.
/LOGFILE=filename Set agent log file (will be set in configuration file as LogFile).
/MERGETASKS=”tasknames” Comma-separated list of tasks for installation. If a task is specified with ! charac-
ter prior to it’s name, it will be deselected. Possible values are fspermissions
- set hardened file system permissions, sessionagent - Install session agent,
useragent - Install user support application. e.g. /MERGETASKS="!
fspermissions,useragent"
/NOSUBAGENT=name Disable subagent name
/NOTUNNEL Disable tunnel operation (it is the default)
/REINSTALLSERVICE Reinstalls Windows service
/SERVER=IP Set server IP address or host name (will be set in configuration file as
MasterServers).
/SILENT Don’t show installation wizard, only a progress bar
/SUBAGENT=name Add sub-agent loading directive to configuration file. You can specify this param-
eter multiple times to add more than one sub-agent. List of possible subagents:
Subagents.
/SUPPRESSMSGBOXES Don’t ask user anything. Only has an effect when combined with /SILENT and
/VERYSILENT.
/TUNNEL Enable tunnel operation to IP address specified with /SERVER=.
/VERYSILENT Don’t show anything

Example:
nxagent-3.4.178.exe /VERYSILENT /SUPPRESSMSGBOXES /SERVER=10.0.0.1 /
SUBAGENT=UPS /SUBAGENT=FILEMGR /CONFIGENTRY=ZoneUIN=15 /CONFIGENTRY=[FILEMGR]
/CONFIGENTRY=RootFolder=C:\
This command will add 3 lines at the end of generated config file:
ZoneUIN=15
[FILEMGR]
RootFolder=C:\
3.6 Install on Android
3.6.1 Console
To install Android console download netxms-console-VERSION.apk (example: netxms-console-3.4.178.apk) file

from http://www.netxms.org/download page. Check that installation of applications from unknown sources is allowed
in security settings of your phone. Run this installer on required device.
After agent is installed go to settings and in main menu, connection part set all required connection credentials: server
address, port, user name, password.
Note: User that is used for connection should have Login as mobile device user right.
3.6.2 Agent
To install Android agent download netxms-mobile-agent-VERSION.apk (example: netxms-mobile-agent-

3.4.178.apk) file from http://www.netxms.org/download page. Check that installation of applications from unknown
sources is allowed in security settings of your phone. Run this installer on required device.
After agent is installed go to settings and activate agent. After agent activation several parameters should be set: server
address, port, user name, password. They can be found in under main menu, parameters section.
Note: User that is used for connection should have Login as mobile device user right.
Mobile device should be manually added to server. Find more information see: Monitoring mobile devices.
3.7 Installing from sources
3.7.1 Server
1. Download source archive (netxms-VERSION.tar.gz) from http://www.netxms.org/download/. VERSION is used

in names instead of an actual version number.
2. Unpack the archive:
tar zxvf netxms-VERSION.tar.gz
3. Since version 3.8 reporting server is being built along with the sources. This requires maven to be installed on
the system. You need Oracle and MS SQL JDBC drivers in your local maven repository.
Oracle JDBC driver library can be obtained here: https://download.oracle.com/otn-pub/otn_
software/jdbc/199/ojdbc8.jar
Microsoft SQL JDBC driver library can be obtaine here: https://www.microsoft.com/en-us/
download/details.aspx?id=54671 You will need sqljdbc_4.2/enu/jre8/sqljdbc42.jar file from this
archive.
To install these libraries: mvn install:install-file -DgroupId=com.microsoft.
sqlserver -DartifactId=sqljdbc4 -Dversion=4.2 -Dpackaging=jar
-Dfile=sqljdbc42.jar mvn install:install-file -DgroupId=com.
oracle -DartifactId=ojdbc8 -Dversion=12.2.0.1 -Dpackaging=jar
-Dfile=ojdbc8.jar
4. Change directory to netxms-VERSION and run configure script:
cd netxms-VERSION
./configure --with-server --with-pgsql --with-agent
Most commonly used options (check full list with ./configure --help):
Name Description
--prefix=DIRECTORY Installation prefix, all files go to the specified directory (e.g.
--prefix=/opt/netxms)
--with-server Build server binaries. You will need to select at least one DB driver
as well
--with-agent Build monitoring agent. It is strongly recommended to install agent
on a server box
--with-pgsql Build PostgresSQL DB Driver (if you plan to use PostgreSQL as
backend database)
--with-mysql Build MySQL DB Driver (if you plan to use MySQL as backend
database)
--with-odbc Build ODBC DB driver (if you plan to connect to your backend
database via unixODBC)
--with-sqlite Build SQLite DB driver (if you plan to use embedded SQLite
database as backend database)
5. Run build binaries and install them into /usr/local (unless changed with configure flag –prefix)
make
make install
6. Copy sample config file:
cp contrib/netxmsd.conf-dist /usr/local/etc/netxmsd.conf
By default, server load configuration file PREFIX/etc/netxmsd.conf (where PREFIX is installation
prefix set by configure), unless different file is specified with command line switch “-c”.
7. Create database user and adjust configuration file (netxmsd.conf) accordingly. Database creation examples can
be found there.
8. Further adjust server configuration file if required.
Detailed information about each configuration parameter can be found in section Server configuration file
(netxmsd.conf).
3.7. Installing from sources 25

9. Create required tables and load initial configuration using nxdbmgr utility:
/usr/local/bin/nxdbmgr init
10. Run server:
/usr/local/bin/netxmsd -d
3.7.2 Agent
1. Download source archive (netxms-VERSION.tar.gz) from http://www.netxms.org/download/. VERSION is used

in names instead of an actual version number.
tar zxvf netxms-VERSION.tar.gz
3. Change directory to netxms-VERSION and run configure script:
cd netxms-VERSION
./configure --with-agent
Most commonly used options (check full list with ./configure --list):
Name Description
--prefix=DIRECTORY Installation prefix, all files go to the specified directory
--with-agent Build monitoring agent. It is strongly recommended to install agent
on a server box
4. Run build binaries and install them into /usr/local (unless changed with configure flag --prefix)
make
make install
5. Copy sample config file:
cp contrib/nxagentd.conf-dist /usr/local/etc/nxagentd.conf
By default, agent load configuration file PREFIX/etc/netxmsd.conf (where PREFIX is installation
prefix set by configure), unless different file is specified with command line switch “-c”.
6. Adjust agent configuration file if required.
Detailed information about each configuration parameter can be found in section Agent configuration file (nxa-
gentd.conf).
Minimal required configuration:
MasterServers = 172.16.1.1 # server's IP - agent will drop connections unless

˓→address is whitelisted here
LogFile = /var/log/nxagentd
7. Run agent:
/usr/local/bin/nxagentd -d
3.8 Customizing the compilation process
3.8.1 Adding additional compiler or linker flags
(e.g. fixing atomics)
3.9 WebUI additional configuration
3.9.1 Installing web interface on remote system
There are few settings available for configuration in WebUI.

• server - server DNS name or IP
• loginFormImage - path to custom login image
• useEncryption - if encryption should be used
• sessionTimeout - session timeout
There are multiple ways to set connection configuration from WebUI to NetXMS server. Configuration is check in
next order:
1. Using JNDI. Environment should be set like nxmc/NAME for example: nxmc/server
2. nxmc.properties properties file in class path of your application server. Should be created in ini
format: NAME=VALUE. For example:
server = 127.0.0.1
Default locations:
Jetty
Tomcat
Debian default is /usr/share/tomcat9/lib. Other versions and Linux distribution may have dif-
ferent location.
Oracle Weblogic
$WEBLOGIC_HOME/user_projects/domains/YOURDOMAIN
3. jvm parameter in format -Dnxmc.NAME=VALUE. For example: -Dnxmc.server=127.0.0.1
4. Environment variable NXMC_NAME=VALUE. For example NXMC_server=127.0.0.1
5. If non of above configuration exists, Web UI tries to resolve “NETXMS_SERVER” DNS name for
server connection.
6. If none of above configuration exists, Web UI uses “127.0.0.1” as a server address.
3.8. Customizing the compilation process 27

3.9.2 Custom logo on login screen
It is possible to change default logo on login screen to custom image by setting loginFormImage property in
nxmc.properties file. Image file must be located within application server’s class path and file name must be given
relative to class path root with leading slash. For example, if custom image is in file logo.jpg located in the same
directory as nxmc.properties, correct entry will be:
loginFormImage = /logo.jpg
3.10 Default login credentials
Default login is “admin” with password “netxms”. On first login, user will be requested to change it immediately.
If required, password can be reset back to default using nxdbmgr utility.
3.11 Database creation examples
This chapter provides some database creation SQL examples.
3.11.1 PostgreSQL
createuser -P netxms
createdb -O netxms netxms
If TimescaleDB extension is about to be used, it should be added to the newly created database:
psql netxms
CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;
\q
Configuration file example:
DBDriver = pgsql.ddr
DBServer = localhost
DBName = netxms
DBLogin = netxms
DBPassword = PaSsWd
3.11.2 MySQL
echo "CREATE DATABASE netxms;" | mysql -u root -p

echo "CREATE USER 'netxms'@'localhost' IDENTIFIED BY 'PaSsWd';" | mysql -u root -p
echo "GRANT ALL on netxms.* to 'netxms'@'localhost';" | mysql -u root -p
DBDriver = mysql.ddr
DBName = netxms
(continues on next page)
(continued from previous page)

DBLogin = netxms
DBPassword = PaSsWd
3.11.3 Oracle
-- USER SQL
CREATE USER netxms IDENTIFIED BY PaSwD
DEFAULT TABLESPACE USERS
TEMPORARY TABLESPACE TEMP;
-- QUOTAS
ALTER USER netxms QUOTA UNLIMITED ON USERS;
-- ROLES
GRANT CREATE SESSION, CREATE TABLE, CREATE PROCEDURE TO netxms;
DBDriver = oracle.ddr
DBServer = //127.0.0.1/XE # instant client compatible connection string
DBLogin = netxms
DBPassword = PaSsWd
3.11. Database creation examples 29

CHAPTER
FOUR
UPGRADE
4.1 Upgrading on Debian or Ubuntu
4.1.1 Upgrading packages
To update all NetXMS packages run command:

apt-get update && apt-get upgrade
Management console

1. Download the latest version from http://www.netxms.org/download. You will need Linux installer(named nxmc-
VERSION-linux-gtk-x86.tar.gz or nxmc-VERSION-linux-gtk-x64.tar.gz, for example nxmc-1.2.17-linux-gtk-
x64.tar.gz).
2. Extract and replace old management console with the new one.
tar zxvf nxmc-VERSION-linux-gtk-x86.tar.gz -C /DIRECTORY
3. Run nxmc file from extracted catalog.
2. Replace old WAR file with the new one.
4.2 Upgrading on Red Hat, Fedora, CentOS or ScientificLinux
4.2.1 Adding our YUM repository
4.2.2 Upgrading
Server
1. Download the latest version from http://www.netxms.org/download, if you don’t have it. You will
need source archive (named netxms-VERSION.tar.gz, for example netxms-1.2.15.tar.gz). Please
note that in the following steps VERSION will be used as a substitution for an actual version number.
31

$ tar zxvf netxms-1.2.15.tar.gz
3. Change directory to netxms-version and run configure script:
$ cd netxms-1.2.15
$ sh ./configure --with-server --with-mysql
Be sure to include all options that were used at installation time.
4. Run make:
$ make
5. Stop NetXMS server.
6. Stop NetXMS agent.
7. Check database for possible inconsistencies:
$ nxdbmgr check
Proceed to the next step only if database checker does not report any errors!
8. Run make install:
$ make install
9. Upgrade database:
$ nxdbmgr upgrade
10. Start NetXMS agent.
11. Start NetXMS server.
Agent
tar zxvf netxms-1.2.15.tar.gz
cd netxms-1.2.15
sh ./configure --with-agent
4. Run make and make install:
make
make install
7. Run agent:
$ /usr/local/bin/nxagentd -d
32 Chapter 4. Upgrade
Management console

1. Download the latest version from http://www.netxms.org/download. You will need Linux installer(named nxmc-
VERSION-linux-gtk-x86.tar.gz or nxmc-VERSION-linux-gtk-x64.tar.gz, for example nxmc-1.2.17-linux-gtk-
x64.tar.gz).
2. Extract and replace old management console with the new one.
tar zxvf nxmc-VERSION-linux-gtk-x86.tar.gz -C /DIRECTORY
3. Run nxmc file from extracted catalog.
2. Replace old WAR file with the new one.
4.3 Upgrading on Windows
4.3.1 Upgrade
Server
1. Download the latest version from http://www.netxms.org/download, if you don’t have it. You will need Windows
installer (named netxms-VERSION.exe, for example netxms-1.2.15.exe).
C:\NetXMS\bin> nxdbmgr check
4. Run NetXMS installer and follow the prompts. Normally, you will not need to change any settings on installation
wizard windows. Alternatively, you can run the installer with /SILENT option to disable any prompts:
C:\Download> netxms-1.2.15.exe /SILENT
5. Check whether NetXMS Server service is running again. If it’s not, most likely you have to upgrade your
database to newer version. To upgrade database, use nxdbmgr utility:
C:\NetXMS\bin> nxdbmgr upgrade
6. Start NetXMS server, if it is not already started.
4.3. Upgrading on Windows 33

Agent
We highly recommend using centralized agent upgrade feature for agent upgrades. However, if you decide to upgrade
agent manually, it can be done in just a few steps:
1. Download the latest version from http://www.netxms.org/download, if you don’t have it. You will need Windows
Agent installer (named nxagent-VERSION.exe or nxagent-VERSION-x64.exe, for example nxagent-1.2.0.exe).
2. Run NetXMS agent installer and follow the prompts. Normally, you will not need to change any settings on
installation wizard dialog windows. Alternatively, you can run installer with /SILENT option to disable any
prompts:
C:Download> nxagent-1.2.0.exe /SILENT
Management console

1. Download the latest version from http://www.netxms.org/download. You will need Windows installer(named
nxmc-VERSION-win32-x86.zip or nxmc-VERSION-win32-x64.zip, for example nxmc-1.2.17-win32-x64.zip).
2. Replace old old folder with content of the zip.
3. Run nxmc.exe file from extracted catalog.
2. Replace old WAR file with the new one. Default path: INSTALLATION_DIRwebapps.
4.4 Generic upgrade using source tarball
4.4.1 Server
$ tar zxvf netxms-1.2.15.tar.gz
$ cd netxms-1.2.15
$ sh ./configure --with-server --with-mysql
4. Run make:
$ make
$ nxdbmgr check
$ make install
9. Upgrade database:
$ nxdbmgr upgrade
10. Start NetXMS agent.
11. Start NetXMS server.
4.4.2 Agent
tar zxvf netxms-1.2.15.tar.gz
cd netxms-1.2.15
sh ./configure --with-agent
4. Run make and make install:
make
make install
7. Run agent:
$ /usr/local/bin/nxagentd -d
4.5 Centralized agent upgrade
Steps to update agent remotely:

1. Download NetXMS agent installer from http://www.netxms.org/download/
2. Download the appropriate NPI file for your agent installer(NPI file is just a reference to actual package
file. You should have it as well in the same directory as NPI file.)
3. Open “Package Manager”
4.5. Centralized agent upgrade 35

4. Chose “Install new package. . . ”

5. Browse for NPI file
6. When new package appeared - right click on it and chose “Deploy to managed nodes. . . ”
7. Select the nodes you want to upgrade by holding CTRL key
CHAPTER
FIVE
QUICK START
In this section will be described basic configuration that should be done after server and agent clean install. Also will
be shown monitoring configuration for some common metrics like CPU of FS.
5.1 Default Credentials
Server login default credentials

Login: admin
Password: netxms
5.2 Basic agent configuration
Minimal configuration that should be set for agent is server address and path to log file. Action differ depending on
a platform where agent is installed. On Windows systems configuration file is automatically generated and populated
by installer, on UNIX systems it should be created/edited manually.
Minimal required configuration is done for agent.
5.2.1 Windows
In case if while installation MasterServer was set correctly no action is required from user.
Automatically generated configuration file can be found there: installation directory\etc\nxagentd.
conf.
Configuration file for Windows should look like this:
#
# Sample agent’s configuration file
#
MasterServers = 127.0.0.1
LogFile = {syslog}
37
5.2.2 UNIX/Linux
After agent is installed on a UNIX/Linux system it is required to create/edit file /etc/nxagentd.conf. This file
should contain at least this information:
#
# Sample agent’s configuration file
#
LogFile = /var/log/nxagentd
5.3 Basic server tuning
Server has 2 types of configuration: configuration file parameters and server configuration variables.
For server configuration file minimal requirements are path to log file, database driver name and all required creden-
tials depending on database. Location and required actions depends on what OS is used. More about OS specific
configuration search in OS subsections of this chapter.
List of possible database drivers:
• mssql.ddr Driver for Microsoft SQL database.
• mysql.ddr Driver for MySQL database.
• odbc.ddr ODBC connectivity driver (you can connect to MySQL, PostgreSQL, MS SQL, and Oracle via ODBC).
• oracle.ddr Driver for Oracle database.
• pgsql.ddr Driver for PostgreSQL database.
• sqlite.ddr Driver for embedded SQLite database.
There are quite a few important server parameters to be set right after installation. These parameters are accessible
through the Server Configuration window in the console. To open it, click on Configuration → Server Configuration.
To edit a setting, double click on the row in the table or right-click and select Edit. The following parameters may
need to be changed:
Parameter Description
PollerThreadPoolMaxSize This parameter represents maximum thread pool size. From this pool
will be taken threads for all types of polls: Status poll, Configuration
poll, etc. In case of big load on a server number of threads will be
increased till this size. When load come back to normal, number of
threads will be automatically decreased to base size. If you plan to
monitor large number of hosts increase this parameter from the default
value to approximately 1/5 of host count.
PollerThreadPoolBaseSize This parameter represents base thread pool size. From this pool will be
taken threads for all types of polls: Status poll, Configuration poll, etc.
This is minimal number of threads that will always run. If you plan to
monitor large number of hosts increase this parameter from the default
value to approximately 1/10 of host count.
NumberOfDataCollectors If you plan to monitor large number of hosts, to approximately 1/10 –
1/5 of host number. Use larger value if you plan to gather many DCIs
from each host.
EnableSyslogDaemon Set this parameter to 1 if you want to enable NetXMS built-in syslog
server.
38 Chapter 5. Quick start

Minimal required configuration is done for server.
5.3.1 Windows
For Windows systems this information is added to configuration file while installation procedure. It can be check that
all data was set correctly in this file: 'installation directory'\etc\netxmsd.conf.
Example of sample Windows configuration for mysql:
#
# Sample server configuration file
#
DBName = netxms_db
DBLogin = netxms
DBPassword = password
LogFile = {syslog}
5.3.2 UNIX/Linux
For UNIX based systems /etc/netxmsd.conf file should be created/populated manually.

Configuration file example for oracle database:
DBDriver = oracle.ddr
DBServer = ServerIP/Hostname.DomainName #Here is service (full database name), not SID
DBName = netxms
DBLogin = netxms
DBPassword = PaSwD
LogFile = /var/log/netxmsd
5.4 SMTP
SMTP configuration is done to create actions that will send e-mails on defined events. This configuration is done
through the Server Configuration window in the console. To open it, click on Configuration → Server Configuration.
To edit a setting, double click on the row in the table or right-click and select Edit. The following parameters may
need to be changed:
SMTPFromAddr Address that will be shown as a sender address when notification from
NetXMS will come.
SMTPFromName Name that will be shown as a sender name when notification from
NetXMS will come.
SMTPRetryCount Number of retries that NetXMS will try to do in case if message send-
ing will fail.
SMTPServer Server IP address or DNS name where NetXMS will send request for
message dispatch.
5.4. SMTP 39
5.5 SNMP Defaults
For SNMP can be configured some default values for authorization. It is required if you will have many SNMP devices
with similar credentials.
This information is set on Network Discovery view.
5.5.1 SNMP Communities
In this section you can add SNMP community strings to be tested during connection to the SNMP device that requires
authorization.
5.5.2 SNMP USM Credentials
In this section you can add SNMP version 3 credentials to be tested during connection to the SNMP device that
requires authorization.
5.6 Actions and Alarms
In this section will be shown how to configure alarm and email notifications generation on predefined
SYS_THRESHOLD_REACHED event. And alarm resolve on SYS_THRESHOLD_REARMED event.
First it should be created Send E-Mail action in Action Configuration view. There we will set recipient of e-mail,
subject and body of e-mail. In body of e-mail will be used Macros for Event Processing. It means that when message
will be sent, macros “%n” will be substituted with name of the node and “%m” will be substituted with event message.
Value of event message is personal for each event and can be found in event description.
Next step is to add processing policies. It is done in Event Processing Policy view. We will add this rules before all
other rules as it it is planed that this rules will be most commonly used ones.

It should be added rule that will send email and create Alarm on SYS_THRESHOLD_REACHED rule from
any node. In alarm message is added key that will be used in alarm resolve. Key is combined from text id
“SYS_THRESHOLD_REACHED_”, id of DCI and ID of node. This should be enough to resolve correct alarm.
After that should be created one more rule for alarm resolve with the same key as for alarm creation. After all config-
uration is done Event Processing Policy view should be saved.
5.7 Passive discovery
It is recommended to enable passive discovery when it is required to add all nodes in local network. In case if NetXMS
server has access to switches and routers via SNMP, all devices in network will be added automatically by discovery
process.
To enable passive network discovery open Network Discovery view. There in General section select Passive only
option and check that all default SNMP credentials are set as described in SNMP Defaults section. Other options that
can be set depending on requirements:
• Option to use SNMP trap source for further network discovery
• Option to set filer that will define rules for not adding nodes to NetXMS server
In our configuration we will not use filter to add all node available on our network and turn on option to use SNMP
trap source address for discovery. After all configuration is done remember to save it.
5.7. Passive discovery 41

5.7.1 Notes
If you have enabled automatic network discovery, wait for initial network discovery completion. This process can take
time, depending on size and complexity of your network. For large networks, we recommend that you let NetXMS run
over night to gather the majority of network information available. You can watch discovery progress in a real time
using NetXMS Management Console. Go to Object Browser or open default network map and see for new devices
and networks.
Please note that for successful network discovery your network must meet the following requirements:
• NetXMS server must have access to switches and routers via SNMP.
• All your network devices credentials(community string and password for v3) should be added to default creden-
tial list in Network Discovery view.
5.8 Manually add node
If the automatic network discovery does not detect all of your hosts or devices, or you decide not to use network
discovery at all, you may need to manually add monitored nodes to the system. The easiest way to accomplish this is
to right-click on Infrastructure Services in the Objects pane and select Create node. You will be presented with the
following dialog window:
Fig. 1: Create Node window
Please note that adding a new node object may take some time, especially if a node is down or behind a firewall. After
successful creation, a new node object will be placed into appropriate subnets automatically. As soon as you add a
new node to the system, NetXMS server will start regular polling to determine the node status.

5.9 Add DCI thresholds
In this section is described how to configure CPU usage monitoring using agent metric and using SNMP metric and
interface incoming traffic. There will be also shown threshold configuration for each DCI. This threshold will generate
SYS_THRESHOLD_REACHED event when defined condition is meet and SYS_THRESHOLD_REARMED when
collected data exists range of condition.
Earlier we already described how to configure email notifications and alarm generation, resolve based on this events.
In this chapter is described data collection and event generation based on collected data.
To add DCI for a node open Data Collection Configuration view from object menu. And select from drop-down menu
New parameter.
5.9.1 CPU usage
Add CPU usage metric from agent parameters:

1. Check that as origin is selected NetXMS Agent.
2. Click on Select button
3. Type in the input box “CPU”
Fig. 2: Parameter Selection
5.9. Add DCI thresholds 43

Fig. 3: Properties
4. Select System.CPU.Usage
5. Go to Threshold tab
6. Click Add
7. Set that if last one polled value is gather than 85, then generate SYS_THRESHOLD_REACHED
event, when value is back to normal generate SYS_THRESHOLD_REARMED event.

Fig. 4: Threshold
8. Click OK
Add CPU usage metric from SNMP parameters:
1. Check that as origin is selected NetXMS Agent.
2. Click on Select button
3. Type in the input box “.1.3.6.1.4.1.9.9.109.1.1.1.1.4”(this OID can may be not available for some
devices)
4. Click Walk
Fig. 5: Mib Walk Result
5. Select CPU that should be monitored in our case it is “.1.3.6.1.4.1.9.9.109.1.1.1.1.4.1”

Fig. 6: Select Window For SNMP DCI
6. Click OK
Fig. 7: Properties

7. Go to Threshold tab
8. Click Add
9. Set that if last one polled value is gather than 85, then generate SYS_THRESHOLD_REACHED
event, when value is back to normal generate SYS_THRESHOLD_REARMED event.
Fig. 8: Threshold
10. Click OK
Now you configured data collection of metric System.CPU.Usage that will be collected every 60 seconds, data will be
stored for 30 days, with 1 threshold that will be activated when CPU usage is mote than 85%.
5.9.2 Interface traffic
There is shortcut to create all required DCIs for interface traffic. Select interfaces for which should be created traffic
collection DCIs and select from drop-down menu Create data collection items. There can be created automatically all
required DCIs by selecting required checkbooks.


CHAPTER
SIX
AGENT MANAGEMENT
6.1 Introduction
NetXMS agent is daemon or service that runs on a node to provide additional monitoring options. This is optional for
installation, but it’s installation gives following advantages:
• Centralized configuration - you can change configuration of agent from management console; if needed, you
can even store agent configs on NetXMS server
• More secure: communications between NetXMS server and agent can be encrypted, additional authentication
on agent can be configured
• TCP instead of UDP is used for communications with agent - this can help in case of slow and poor quality links
• Remote command execution - agents can be used to execute commands on managed systems as a reaction to
certain events
• Proxy functionality: agent can be used as a proxy to reach agents on hosts not directly accessible by NetXMS
server
• SNMP proxy: agent can be used as a proxy to reach remote SNMP devices
• SNMP Trap proxy: agent can be used as a proxy to get messages from remote SNMP device
• Extensible: you can add new parameters very easy using configuration option like ExternalParameter or
by writing your own subagents
• Easy upgrade - you can upgrade all agents at once from console
• Provides file management possibilities on agent.
• Provides log file monitoring functionality.
6.2 Agent configuration files
Agent have 3 types of configuration files: master configuration file, additional configuration files and Agent Policy
configuration files. Master configuration file is the only mandatory file. Minimal configuration for master configuration
file is server address. Address should be set as MasterServers to be able to apply other configuration settings from the
server.
After configuration file change agent should be restarted to apply new changes.
Two formats are supported for configuration files and configuration file policies: XML and ‘key = value’ format.
In ‘key = value’ format configuration file can contain one or more parameters in Parameter = Value form, each
parameter should be on its own line. Parameters are grouped into sections. Beginning of a section is denoted by
49
section name in square brackets (example: “[sectionName]”). Section named “[Core]” contains parameters for agent
itself. It’s the default section, if a configuration file starts from parameter and not from section name, parameters
are treated as belonging to “Core” section. Subagents’ parameters should be placed in separate sections named by
subagent name. Same section name can be present several times in the configuration file. Comments can be inserted
after “#” sign
In XML format general tag should be <config>, second level tags contain section names and third level tags are agent
or subagent configuration parameters.
‘key = value’ format example:
[Core]
SubAgent = winperf.nsm
# Below is a configuration for winperf subagent, in separate section
[WinPerf]
EnableDefaultCounters = yes
Same example in XML format:
<config>
<Core>
<MasterServers>10.0.0.4</MasterServers>
<SubAgent>winperf.nsm</Subagent>
</Core>

<WinPerf>
<EnableDefaultCounters>yes</EnableDefaultCounters>
</WinPerf>
</config>
Example of configuration sections:
Detailed list of parameters can be found here: Agent configuration file (nxagentd.conf). The following parame-
50 Chapter 6. Agent management

ters can be specified in master configuration file only (and will be ignored if found in other configuration files):
DataDirectory and ConfigIncludeDir.
6.2.1 Master configuration file
File nxagentd.conf is a master configuration file for NetXMS agent. Depending on OS there are different locations,
where agent tries to find master configuration file.
UNIX-like systems
On UNIX systems master configuration file is searched in the following order:

1. If $NETXMS_HOME environment variable is set: $NETXMS_HOME/etc/nxagentd.conf
2. 'prefix'/etc/nxagentd.conf. ‘prefix’ is set during build configuration with --prefix='prefix'
parameter. If that parameter was not specified during build, /usr/local is used.
3. /Database/etc/nxagentd.conf
4. /usr/etc/nxagentd.conf
5. /etc/nxagentd.conf
If configuration file is placed in a different location or named in a different way, then it’s location and file name can be
given to agent with -c parameter or by specifying $NXAGENTD_CONFIG environment variable. In this cause search
in the locations mentioned above is not performed.
Windows
On Windows location of NetXMS config is stored in the registry. Alternatively, location of configuration file can be
provided to agent with -c command line parameter. If there is no record in the registry and -c parameter is not
specified, then agent tries to find configuration files in the following locations:
1. 'installation directory'\etc\nxagentd.conf
2. C:\nxagentd.conf
6.2.2 Additional configuration files
To increase maintainability, configuration can be stored in multiple additional configuration files located in a specific
folder. Additional configuration files override (if a parameter supports only one value) or supplement (if parameter
supports multiple values, e.g. list of servers or root folders for filemgr subagent) configuration parameters from master
file. Depending on OS there are different locations, where agent tries to find master configuration file.
UNIX-like systems
On UNIX systems it is searched in the following order (search is performed until first existing folder is found):
1. If $NETXMS_HOME environment variable is set: $NETXMS_HOME/etc/nxagentd.conf.d
2. 'prefix'/etc/nxagentd.conf.d. ‘prefix’ is set during build configuration with
--prefix='prefix' parameter. If that parameter was not specified during build, /usr/local is
used.
3. /Database/etc/nxagentd.conf.d
6.2. Agent configuration files 51

4. /etc/nxagentd.conf.d
5. /usr/etc/nxagentd.conf.d
A different configuration file folder name can be given by specifying $NXAGENTD_CONFIG_D environment vari-
able. In this cause search in the locations mentioned above is not performed.
Windows
On Windows location of configuration file folder is stored in the registry. If there is no record in the registry, then
agent tries to find configuration file folder in the following locations (search is performed until first existing folder is
found):
1. 'installation directory'\etc\nxagentd.conf.d
2. C:\nxagentd.conf.d
6.2.3 Agent policy configuration files
Agent policies allow to store agent configuration on server and deliver it to the agents. More information about Policies
can be read there: Agent Policies.
On agent configuration policy files are stored in a separate folder named config_ap under DataDirectory folder. Every
policy is saved into a separate file named by policy GUID.
6.3 Agent configuration options from server
6.3.1 Edit configuration file remotely
Right click on node, select Edit agent’s configuration file from menu. When closing the editor, a dialog will be
presented. New configuration apply is performed on agent restart. So to immediately apply new configuration select
Save and Apply. This option will save configuration file and automatically restart the agent. If just Save is selected,
then agent should be manually restarted to apply new configuration.
6.3.2 Agent configuration files on server
Agent master configuration files can be stored on server side and requested by agent, if it is launched with -M
<serverAddress> command line parameter. Each configuration file on server is stored along with filter script.
When server receives configuration request from agent, it goes through available configs and executes filter scripts to
find an appropriate configuration.
If appropriate configuration file is found, it is sent to agent and old nxagentd.conf file is overwritten (or a new
nxagentd.conf file is created, if it did not exist). When agent can’t connect to server or server hasn’t found right
configuration, the agent is started with old configuration file. In case if agent configuration file does not exist and it is
not possible to get new one from the server - agent fails to start.
New in version 1.2.15.
Doesn’t work with tunnel agent connection

Configuration
Each configuration has a name, filter script and the configuration file text.
• Name just identifies the configuration.
• Filter script is executed on configuration request to define which configuration file to send to the agent. Filter is
defined with help of NXSL scripting language. The following parameters are available in the filter script:
– $1 - IP address
– $2 - platform
– $3 - major version number
– $4 - minor version number
– $5 - release number
• Configuration file is the text of returned configuration file.
6.3.3 Agent configuration policy
Another option to store and distribute agent configuration are agent policies. In this case agent configuration is stored
on the server side as a policy belonging to template and deployed to the agent when corresponding template is applied
to a node. More information about policies and their types can be found in Agent Policies chapter.
6.3.4 Agent Configuration Policies vs. Agent Configuration Files on Server
A short lists of main points to compare both options:

Agent Configuration Files on Server:
• Assignment is based on rules described in filter scripts
• When configuration is changed, agent restart is needed to activate new configuration
• Config download from server is each time the agent starts (if option ‘-M servername’)
• When config is found on server, local Master config is overwritten, if not - existing Master config is used
6.3. Agent configuration options from server 53

• Works with master configuration file

• Does not required initial config (agent can be started without config), but in this case agent would fail if
nothing was returned from server
• Server provides configuration file without authorization which can be a security issue, if sensitive infor-
mation is present in configuration file.
• Doesn’t work via proxy
• Doesn’t work via tunnel agent connection
Agent Policies:
• Not possible for bootstrap agent
• After policy is deployed to agent, the agent should be restarted to activate new configuration.
• At minimum the server connection parameters must be in master config to be able to start agent
• Each policy is saved in a separate configuration file
• If policy and master config have same parameter that can be set only once (e.g. LogFile), then policy will
overwrite master config configuration
• If policy and master config have same parameter that can be set multiple times (e.g. Target for PING
subagent or Query for DBQUERY), then policy will merge lists of configs
• Can work via proxy
• Can work with tunnel agent connection
6.4 Agent Policies
Agent policies are additional configuration created by user (agent configuration or files) that are uploaded and updated
on agent when template is manually or automatically applied on the node. Agent policies belong to templates, so they
are applied to nodes to which a corresponding template is applied.
To create policy, right click a template and select Agent policies. Click plus icon to create a new policy, give it a name,
choose correct policy type and click OK. Existing policy can be modified by right-clicking it and selecting Edit from
the menu or by double clicking on it.
The following policy types are available:
• Agent configuration policy
• File delivery policy
• Log parser policy
• User support application policy
Policies are automatically deployed to nodes after creation/modification or when a template is applied to a node. When
configuration policy is deleted or template is removed from a node, the policy is automatically undeployed from node.
Policies get deployed / undeployed:
• On node configuration poll.
• When list of Agent Policies is closed in the management console. If a node is down at that moment, next
attempt will happen on configuration poll.
• When template is applied or removed from a node. If a node is down at that moment, next attempt will
happen on configuration poll.

Installed policy configurations are stored as additional files under agent DataDirectory. List of applied policies is
stored in agent local database.
If agent discovers for a record in local database, that policy file is missing, it will delete the record from database.
When performing deployment, server checks information in agent’s database with it’s database and issues necessary
commands.
6.4.1 Agent configuration policy
Agent configuration policy provides option to populate agent configuration with additional parts. Main agent configu-
ration is merged with additional rules from policy. Using policy for configuration file maintenance has advantages that
configuration is edited in centralized way and gives granular control on the configuration that each node gets. More
information about different agent configuration options can be found in above chapters.
It is possible to use the same parameters and format as in any NetXMS agent configuration file (key=value format or
XML format).
Example:
MasterServer=127.0.0.1
SubAgent=netsvc.nsm
SubAgent=dbquery.nsm
SubAgent=filemgr.nsm
[DBQUERY]
Database=id=myDB;driver=mysql.ddr;server=127.0.0.1;login=netxms;password=xxxxx;
˓→dbname=netxms
Query=dbquery1:myDB:60:SELECT name FROM images

ConfigurableQuery=dbquery2:myDB:Comment in param :SELECT name FROM images WHERE name
˓→like ?
ConfigurableQuery=byID:myDB:Comment in param :SELECT name FROM users WHERE id=?
[filemgr]
RootFolder=/
<config>
<core>

<MasterServers>127.0.0.1</MasterServers>
<SubAgent>netsvc.nsm</SubAgent>
<SubAgent>dbquery.nsm</SubAgent>
<SubAgent>filemgr.nsm</SubAgent>
</core>
<DBQUERY>
<Database>id=myDB;driver=mysql.ddr;server=127.0.0.1;login=netxms;password=xxxxx;
˓→dbname=netxms</Database>
<Query>dbquery1:myDB:60:SELECT name FROM images</Query>

<ConfigurableQuery>dbquery2:myDB:Comment in param :SELECT name FROM images WHERE
˓→name like ?</ConfigurableQuery>
<ConfigurableQuery>byID:myDB:Comment in param :SELECT name FROM users WHERE id=?</

˓→ConfigurableQuery>
</DBQUERY>
<filemgr>
<RootFolder>/</RootFolder>
</filemgr>
</config>
6.4. Agent Policies 55

Example:
Agent should be manually restarted to apply the configuration after the configuration policy is deployed or undeployed
to node.
6.4.2 Log parser policy
Information about log parser format and usage available in Log monitoring chapter.
Log parser configuration is applied right after log parser policy is deployed or undeployed to node - no agent restart is
required.
6.4.3 File delivery policy
File delivery policy is created to automatically upload files form server to agents.
First root folder or folders should be created - folders with the full path to place where uploaded file and folder structure
should be placed. After 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
• Text inside ` braces will be executed as a command and first line of output will be taken
Example:

6.4.4 User support application policy
6.5 Agent registration
Two ways of agent-server communication are available. Standard one is when server initializes connection to agent,
the second one is when tunnel is used and agent initialize connection to server.
6.5.1 Server to agent connection
There are few ways to register agent:

1. To enter it manually by creating a node
2. Run the network discovery and enter the range of IP addresses.
3. Register agent on management server nxagentd -r <addr>, where <addr> is the IP address of server.
To register agents using this option EnableAgentRegistration server configuration parameter should be set
to 1.
6.5.2 Agent to server connection
This connection requires certificate configuration on server side. More about required actions can be found in Server
configuration for Agent to Server connection / Tunnel connection. Agent requires ServerConnection parameter set in
agentd.conf file to server DNS or server IP address. It is possible to have several ServerConnection parameters in the
config, in this case agent will establish tunnel connection to multiple servers.
Right after agent start it will try to connect to the server. On first connect node will be shown in Agent Tunnels.
There are few ways to register agent:
1. To enter it manually by creating a node and then binding tunnel to already created node.
2. Create node from Agent Tunnels view by selecting one or more tunnels and selecting Create node and
bind. . . menu item.
Debugging
In case of errors enable server debug for “agent.tunnel” and “crypto.cert” to level 4 and agent log debug for “tunnel”
and “crypto.cert” to level 4. Check for “SYS_TUNNEL_SETUP_ERROR” events on management node.
6.6 Security
6.6.1 Message encryption in server to agent communication
Server encryption policy is configured in Server Configuration view by selecting one of 4 options for DefaultEncryp-
tionPolicy parameter. Default Policy is 2.
Policy types:
6.5. Agent registration 57

• 0 - Forbid encryption. Will communicate with agents only using unencrypted messages. If agent force encryp-
tion (RequireEncryption agent configuration parameter is set to yes), server will not accept connection with this
agent.
• 1 - Allow encryption. Will communicate with agents using unencrypted messages if encryption is not enforced
by setting RequireEncryption agent configuration parameter to yes or by selecting Force encryption option in
Communication properties of node object.
• 2 - Encryption preferred. Will communicate with agents using encryption. In case if agent does not support
encryption will use unencrypted communication.
• 3 - Encryption required. Will communicate with agent using encryption. In case if agent does not support
encryption will not establish connection.
Fig. 1: Force encryption option for node.
6.6.2 Security in agent to server connection
Agent to server connection uses TLS protocol to ensure communication security. Server has root certificate, that is
used to issue public certificate for agent. Server issues certificate to node when user manually binds tunnel to a node in
Agent Tunnels, or node is bind automatically (when AgentTunnels.UnboundTunnelTimeoutAction server configuration
parameter is set to Bind tunnel to existing node or Bind tunnel to existing node or create a new node). If required, this
process can also be automated by NXShell. More information: NXShell examples, Latest Javadoc.

6.6.3 Server access levels
Depending on how server’s IP address (or domain) is added to in nxagentd.conf, it will have different access level. It
is preferred to use MasterServers. There are 3 levels of access for an agent:
1. MasterServers - full access.
2. ControlServers - can read data and execute predefined actions, but cannot change config nor install policies.
3. Servers - read only access. (Is default for tunneled agent connection if other server level is not defined)
In case if server IP is not listed in one of this parameters agent will not enable connection with server in server to agent
connection or will set access level to Servers if tunnel connection is used.
6.6.4 Shared secret
Shared secret is another level of server verification. By default authentication is disabled.

To enable Shared Secret verification on agent set RequireAuthentication agent configuration parameter to yes. In
SharedSecret agent configuration parameter set password what should be used for authentication.
If authentication for agent is enabled, then while connection agent requested shared secret from the server. Server
check if password was set for this specific node in Shared secret field in communication properties of node. In case
if there is no shared secret server sends content of AgentDefaultSharedSecret server configuration variable as shared
secret.
Fig. 2: Shared secret field in node communication properties.
In case shared secrets are not identical connection is not established.
6.6. Security 59
6.6.5 Password encryption
When it is required to write password or Shared Secret in agent configuration file, there is possibility to encrypt it. All
passwords can be encrypted with help of nxencpasswd command line tool and added in configuration file in encrypted
way.
6.7 Subagents
Subagents are used to extend agent functionality. NetXMS subagent are libraries that are loaded by agent. By default
all subagents are included in agent build. Subagent may be not included in build only if on time of the build there
were no required libraries for subagent build. To enable subagent is require just to add line in main agent configuration
file (example: “Subagent=dbquery.nsm”). More about configuration and usage of subagents will be described in
monitoring chapters.
Below is list of available NetXMS subagents:
• Asterisk
• DB2
• Database Query
• DS18x20
• File Manager
• ECS
• Informix
• Java
• lm-sensors
• MongoDB
• MQTT
• MySQL
• Network Service Check
• Oracle
• Ping
• Port Check
• Raspberry Pi
• UPS
• Windows Performance
• WMI
• XEN

6.7.1 Java subagent
This is a special type of subagent, that allows to load Java plugins(subagents written using Java language). Java
subagent does not provide any functionality by itself.
There are several configuration parameters that are supported by Java subagent. None of them is mandatory.
Jvm Path to JVM. System default is used if not set.
Classpath This parameter is added to java CLASSPATH.
Plugin This parameter defines plugin that should be loaded. Can be used multiple times.
Configuration example:
MasterServers = netxms.demo
SubAgent=java.nsm
[JAVA]
Jvm = /path/to/jvm
Classpath = /path/to/user/classes
Plugin = bind9.jar
Java plugins
List of available java plugins:

• JMX
• Bind9
6.7.2 Load of subagent as separate process
Load of subagent as separate process can be used in case it is necessary to load agent and subagent under dif-
ferent users. It can be done by adding ExternalSubagent parameter with unique ID that will represent
connection name between agent and subagent. Create second configuration file for this subagent and add there
ExternalMasterAgent parameter with same ID and run instance of nxagentd with this config. Now exter-
nal subagent will communicate with master agent using Named Pipe. Only master agent will communicate with
server.
6.8 Agent Proxy node configuration
In case it is required to monitor nodes behind firewall, it can be configured access to one of subnet nodes and used this
node as a proxy node for others.
Proxy node can be set during node creation or in Communications tab of node properties. To configure proxy node
select node in object selector NetXMS Agent Proxy.
6.8. Agent Proxy node configuration 61


6.8.1 Agent configuration
To enable NetXMS Agent proxy “EnableProxy” agent configuration parameter should be set to yes.
6.9 Agent External Metrics
Other option to define new Metric that can be collected from node is to use
ExternalParameter/ExternalParameterShellExec, or ExternalList, or
ExternalParametersProvider configuration parameters to define command that will be executed on a
node and it’s output will be provided as a Metric. This functionality provides flexibility to create your own metrics,
lists or table metrics.
New Metrics will be visible in the Available parameters list only after agent restarts (agent reads a configuration file
only once on start) and configuration poll, so to force it’s appearance run Configuration poll manually after agent
restart.
Note: Since v. 3.5. on Windows platforms UTF-8 encoding should be returned in External Metrics.
6.9.1 ExternalParameter/ExternalParameterShellExec
ExternalParameter defines name of the metric and command that is executed synchronously when this metric
is requested by server. There can be provided parameters from DCI configuration, that will be available like $1, $2,
$3. . . , $9 variables. To accept arguments metric name should contain “(*)” symbols after name. Only first line of
script output will be given as a result of execution(metric value).
ExternalParameterShellExec has same meaning as ExternalParameter and behaves identically on
non-Windows systems. On Windows systems ExternalParameter executes specified command using system
process execution API’s CreateProcess() function. It will search in PATH, but the command should be with file ex-
tension, e.g. command.exe. ExternalParameterShellExec will use shell to execute specified command on
Windows.
To add multiple parameters, you should use multiple ExternalParameter/ExternalParameterShellExec
entries.
As this commands are executed synchronously, long commands may cause timeout. In this case
ExecTimeout configuration parameter can be set to change external parameter execution timeout or
ExternalParametersProvider can be used.
# Example
# Without DCI parameters

ExternalParameter=Name:command
ExternalParameterShellExec=Name:command
# With DCI parameters

ExternalParameter=Name(*):command $1 $2
ExternalParameterShellExec=Name(*):command $1 $2
#Real examples
ExternalParameter = Test:echo test
ExternalParameter = LineCount(*):cat $1 | wc -l
6.9. Agent External Metrics 63

6.9.2 ExternalList
ExternalList defines name of the list metric and command that is executed synchronously when this metric is
requested by server. There can be provided parameters from DCI configuration, that will be available like $1, $2,
$3. . . , $9 variables. To accept arguments metric name should contain “(*)” symbols after name. Lines of list are
separated with new line.
# Example

ExternalList=Name:command

ExternalList=Name(*):command $1 $2
6.9.3 ExternalParametersProvider
ExternalParametersProvider defines command(script) and execution interval in seconds. Defined script will
be executed as per interval and agent will cache parameter list. When server will request one of provided parameters
it’s value will be read from the agent cache. Main purpose is to provide data from long-running processes, or return
multiple values at once.
Script should print one or more “Parameter=Value” pairs to standard output. Multiple pairs should be separated by
new line. If parameter takes argument, it should be included in “Parameter(. . . )”.
Example of the script:
#!/bin/sh
echo 'Parameter1=Value1'
echo 'Parameter2=Value2'
echo 'ParameterWithArgs(AAA)=Value3'
echo 'ParameterWithArgs(BBB)=Value4'
Example of agent configuration:
#Example
ExternalParametersProvider=PATH_TO_PROVIDER_SCRIPT:POLL_TIME_IN_SECONDS
#Example (run /tmp/test.sh every 5 seconds)

ExternalParametersProvider=/tmp/test.sh:5
6.9.4 ExternalTable
ExternalTable defines name of the table metric, table metric description, column separator, instance column(s)
and command. Instance column(s), descriptions and separator are optional. If separator is not specified, default value
of , is used.
Instance column should contain unique identifier for each table row. If several instance columns are used, then com-
bination of these columns should be unique. This is necessary for building graphs and for threshold violation event
generation.
Command is executed synchronously when this metric is requested by server. Each table line is separated with new
line symbol. First line in returned text used as a name of the columns and all next lines will be used like table data.
Parameters from DCI configuration can be provided, that will be available like $1, $2, $3. . . , $9 variables. To accept
arguments metric name should contain “(*)” symbols after name.

# Example

ExternalTable=dciName:instanceColumns=columnName;description=description;
˓→separator=|:command

ExternalTable=dciName(*):instanceColumns=columnName;description=description;
˓→separator=|:command $1 $2
Separator supports special macros for separator:

• \n - \n
• \r - \r
• \s - space
• \t - tab
• \u115 - unicode character number 115
6.10 Agent Actions
For security reasons actions that can be executed on agent first are defined in agent configuration file and only then
can be used by users. This excludes that an unauthorized user can access system data through an arbitrary entered
command. Only users with access to the agent configuration file editing can define executed commands.
There are 2 options to define action:
1. Action - usual action definition. On Windows platform system process execution API’s CreateProcess() is used
to run the command, it will search in PATH, but the command should be with file extension, e.g. command.
exe.
2. ActionShellExec - Same as Action, but on the Windows platform agent will use shell to execute command
instead of normal process creation. There is no difference between Action and ActionShellExec on UNIX
platforms.
Both versions accept parameters that will be available like $1, $2, $3. . . , $9 variables.
After action is defined it can be used in the object tools - agent action or in actions - action execution on remote node.
Action should be defined in main section of agent configuration file.
# Example
Action=Name:command
Action=Name:command $1 $2
Action=cleanLogs:rm /opt/netxms/log/*
Action=ping:ping $1
ActionShellExec=listFiles:dir $1
6.10. Agent Actions 65


CHAPTER
SEVEN
SERVER MANAGEMENT
7.1 Configuration file
File netxmsd.conf is a configuration file for NetXMS server. It contains information necessary for establishing
database connection, and some optional server parameters. Default location for this file is /etc/netxmsd.conf
on UNIX systems and InstalationPathetcnetxmsd.conf on Windows.
The file can contain one or more parameters in Parameter = Value form, each parameter should be on its own line.
Comments can be inserted after “#” sign.
Detailed list of parameters can be found there: Server configuration file (netxmsd.conf).
#
# Sample server configuration file
#
DBName = netxms_db
DBLogin = netxms
DBPassword = password
LogFile = {syslog}
7.2 Server configuration for Agent to Server connection / Tunnel con-

nection
NetXMS provides option to establish connection from agent to server. This requires additional configuration on server
and on agent sides. This chapter describes server side configuration. Agent side configuration can be found in Agent
to server connection. Agent to server connection is a TLS tunnel carrying virtual server to agent connections.
Server configuration can be separated into two parts: initial configuration (certificate generation and configuration)
and node binding.
New in version 2.2.3: Tunnel automatic action options
Server provide option to configure automatic options on new unbound tunnel connection. Once new unbound tun-
nel connection comes to server - idle timeout counter starts for this connection. If nothing done while AgentTun-
nels.UnboundTunnelTimeout time, automatic action selected in AgentTunnels.UnboundTunnelTimeoutAction will be
executed.
There are 4 types of actions, that can be done automatically:
67
1. Reset tunnel - close tunnel. It will be automatically reopened again by agent. This process will update
information on server in case of change on agent.
2. Generate event - generates event SYS_UNBOUND_TUNNEL, that later can be used for administrator noti-
fication or any other automatic action (see Event processing).
3. Bind tunnel to existing node - will try to find correct node and bind tunnel to it. Node matching rules will
be described further.
4. Bind tunnel to existing node or create new node - will try to find correct node and bind tunnel to it. If node
is not found new node will be created under container mentioned in AgentTunnels.NewNodesContainer
server configuration parameter. Node matching rules will be described further.
Node is matched for binding if:
1. Zone UIN given by agent (is configured in agent configuration under ZoneUIN) match to node zone id
2. IP given by agent match to node’s IP address
3. Hostname or FQDN match with node name
7.2.1 Initial configuration
Certificate should be issued and added to the server configuration. This certificate will be used to issue public certifi-
cates for agents. Certificate usage should allow certificate signing. Certificates should be in PEM format. Server key
should be added to the certificate file or should be provided as a separate configuration parameter.
Certificate can be obtained in two ways:
1. By sending CSR request to your CA
2. Create self signed certificate
Possible server file configuration:
Parameter Description Required

TrustedCertificate Your certificate authority certificate or self Yes
generated CA certificate. If certificate
chain for server certificate is longer all
upper level certificates should be added
to configuration file by adding multiple
TrustedCertificate entries.
ServerCertificate Certificate issued by certificate authority. Yes
ServerCertificatePassword Issued certificate password Can be omitted for non password
certificates
ServerCertificateKey Issued certificate key Can be omitted if key is included in
server certificate file.
Possible server variable configuration:
68 Chapter 7. Server management

Parameter Description Default

AgentTunnels.UnboundTunnelTimeoutAction
Action that will be executed after idle Reset tunnel
timeout. Actions are described here:
Server configuration for Agent to Server
connection / Tunnel connection
AgentTunnels.UnboundTunnelTimeout
Tunnel idle timeout in seconds, that will be 3600
waited till automatic action execution.
AgentTunnels.NewNodesContainer
Container name where newly created
nodes will accrue. You can use ->
character pair to create subtree ( like
Office->Tunnel). If no container is
set nodes will appear under Entire Network
Self signed certificate sample
This manual describes only simplest option: self signed certificate creation without password. It does not contain any
information about file access right assignment or certificate password configuration.
1. Create private root key: openssl genrsa -out rootCA.key 2048
2. Create self signed root certificate: openssl req -x509 -new -key rootCA.key -days
10000 -out rootCA.crt
3. Create server key openssl genrsa -out server.key 2048
4. Create openssl.conf file. Content of file (dn section should be changed accordingly):
[req]
distinguished_name = dn
req_extensions = v3_ca
prompt = no
[dn]
countryName = LV
stateOrProvinceName = Riga
localityName = Riga
organizationName = netxms.org
commonName = Monitoring Server
[v3_ca]
basicConstraints = CA:TRUE
5. Create server certificate request openssl req -new -key server.key -out server.csr
-config openssl.conf
6. Sign server certificate with root CA certificate openssl x509 -req -in server.csr -CA
rootCA.crt -CAkey rootCA.key -CAcreateserial -out server.crt -days
5000 -extfile openssl.conf -extensions v3_ca
Add newly created certificates to server configuration (netxmsd.conf file).
TrustedCertificate = /opt/netxms/key/rootCA.crt
ServerCertificate = /opt/netxms/key/server.crt
ServerCertificateKey = /opt/netxms/key/server.key
7.2. Server configuration for Agent to Server connection / Tunnel connection 69

7.2.2 Node binding
Once server certificates are configured and agent is correctly configured (ServerConnection parameter set in
agentd.conf) requests for agent to server connection will be shown in Agent Tunnel Manager view.
Fig. 1: Agent Tunnel Manager
User should manually accept them by binding to existing node Bind. . . or by creating new one Create node and
bind. . . . Once node will be bound - it’s state in Agent Tunnel Manager view will be changed to Bound.
Fig. 2: Agent Tunnel Manager
7.3 Configuration variables
These variables are stored in database and can be changed using Server Configuration Editor view access-
ing it Configuration→Server Configuration or with help of nxdbmgr`(example: :code:`nxdbmgr set
<name> <value>).

Fig. 3: Server Configuration
Detailed description of each configuration can be found there: Server configuration parameters. Please note that
changes to most of the settings will take effect only after server restart.
7.4 Synchronization between servers
NetXMS does not provide horizontal scalability for server. But there is option to exchange with events between
servers. Information about configuration can be found there: Forward event. Event forward does not work with zones.
7.5 netxmsd commandline options
Command Description
-e Run database check on startup
-c <file> Set non-default configuration file Default is {search}
-d Run as daemon/service
-D <level> Set debug level (valid levels are 0..9)
-h Display help and exit
-p <file> Specify pid file.
-q Disable interactive console
-v Display version and exit
7.4. Synchronization between servers 71

7.6 Server debug console
Server debug console can be opened in Java console. It can be found in Tools -> Server Console.
It can be used to check debug messages or to execute one of server commands like “ldap sync”.
Server commands can be executed also through XMPP. To execute server command through XMPP should be fulfill
next requirements:
1. Server connection with XMPP should be configured in server configuration variables: XMPPLogin, XMPPPass-
word, XMPPPort, XMPPServer, EnableXMPPConnector.
2. XMPP user that will send commands should be connected with NetXMS user by pointing it’s XMPP name in
XMPP ID filed of General tab of NetXMS user properties.
3. NetXMS user that will execute this commands should also have Execute commands via XMPP access right.
Execution is done sending server command like a message to the user defined in XMPPLogin server configuration
variable.

7.6.1 Server commands
Command Description
debug [<level>|off] Set debug level (valid range is 0..9)
down Shutdown NetXMS server
exec <script> [<params>] Executes NXSL script from script library
exit Exit from remote session
kill <session> Kill client session
get <variable> Get value of server configuration variable
help Display this help
ldapsync Synchronize ldap users with local user database
poll <type> <node> Initiate node poll
raise <exception> Raise exception
set <variable> <value> Set value of server configuration variable
show components <node> Show physical components of given node
show dbcp Show active sessions in database connection pool
show fdb <node> Show forwarding database for node
show flags Show internal server flags
show index <index> Show internal index
show modules Show loaded server modules
show objects Dump network objects to screen
show pollers Show poller threads state information
show queues Show internal queues statistics
show routing-table <node> Show cached routing table for node
show sessions Show active client sessions
show stats Show server statistics
show topology <node> Collect and show link layer topology for node
show users Show users
show vlans <node> Show cached VLAN information for node
show watchdog Display watchdog information
trace <node1> <node2> Show network path trace between two nodes
7.7 Configuring self-monitoring
7.8 Database connection pool
7.9 ICMP proxy
To used ICMP proxy Ping subagent should be loaded for ICMP proxy node.
This proxy is used to check node availability when Zones are used.
7.7. Configuring self-monitoring 73


CHAPTER
EIGHT
SNMP
8.1 SNMP Drivers
Various SNMP devices might require special measures to get information, e.g. some devices provide additional in-
formation for interfaces only under vendor OIDs, etc. To address this, NetXMS provides a concept of SNMP drivers.
SNMP driver is detected automatically.
If SNMP driver was not automatically detected, it’s possible to set it manually by specifying driver name in custom
attribute snmp.driver on a node.
Possible SNMP driver names are:
• AT
• BAYSTACK
• CAMBIUM-CNPILOT
• CAMBIUM-EPMP
• CATALYST-2900XL
• CATALYST-GENERIC
• CISCO-ESW
• CISCO-GENERIC
• CISCO-NEXUS
• CISCO-SB
• CISCO-WLC
• DELL-PWC
• DLINK
• ERS8000
• EXTREME
• H3C
• HPSW
• IGNITENET
• JUNIPER
• MIKROTIK
• MOXA-EDR
75
• NET-SNMP
• NETONIX
• NETSCREEN
• NTWS
• OPTIX
• PING3
• PROCURVE
• QTECH-OLT
• RITTAL
• SAF-INTEGRA-B
• SYMBOL-WS
• TB
• UBNT
• WESTERSTRAND
8.2 MIB Explorer
MIB browser shows all loaded MIB configurations, and allows to run SNMP walk on a selected node nodes. Node can
be selected in browser by selecting Set node object. . . option in view menu or by opening MIB Explorer from node
menu.
76 Chapter 8. SNMP
To run walk user should select line of tree from were will be requested all data. By walk will be requested all OID
subtree of selected item.
After walk is done it’s results will shown in the table below.
There are next options available for results:

• Copy result line to clipboard
• Copy name of selected line to clipboard
8.2. MIB Explorer 77

• Copy type of selected line to clipboard

• Copy value of selected line to clipboard
• Export selected lines to CSV
• Show selection in MIB tree
• Create DCI from selected item
8.3 SNMP Trap Configuration
In this view is configured which event will be generated on exact trap OID and which OID data will be used as event
parameter data.
In SNMP Trap mapping configuration window can be set next parameters:

• Description of mapping rule
• Trap OID or trap OID group with many subtree OIDs, matching OID will be given to event as $1 parameter
• Event that will be generated on selected Trap OID
• User Tag is special event attribute, that can be got by %u macros or as attribute of event class. This attribute can
be set there or by script.
• Parameters - OID values that will be passed to event as $2, $3, $4. . . parameters
In parameter configuration(Edit SNMP Trap Parameter Mapping) can be configured next things:
• Description of a parameter
• Select if parameter should be found by OID or by position in the message
• Option not to convert value to hex string. If string contains not readable symbols(symbol number less than
space symbol number) it will be automatically converted to hex string, this option is required to prevent auto
conversion.
78 Chapter 8. SNMP
8.4 Default SNMP credentials
Default SNMP credentials can be set in Configuration → SNMP Credentials. It does not matter if credentials are used
for adding nodes manually, through network discovery or with the help of agent registration - in each case SNMP
Credentials configuration value will be checked.
8.4. Default SNMP credentials 79

8.5 Using ifTable and ifXTable
There are 2 types of subtree that provides information about interfaces: old one ifTable and new one ifXTable. Some-
times usage of new one creates error situations. In this situation ifXTable can be disabled. This can be done in Prop-
erties of node in Polling. Or this configuration can be set globally by changing UseIfXTable server configuration
parameter.
80 Chapter 8. SNMP
8.6 Configure SNMP Proxy
If there is need to monitor nodes behind firewall using SNMP, there is option to install on one of the nodes NetXMS
agent, open all required ports for this node and send SNMP request to other nodes in this subnet through installed
agent.
Proxy configuration can be done wile creation of node of for already created node can be change in Communications
tab of node properties. To configure proxy node select node in object selector SNMP Proxy.
8.6. Configure SNMP Proxy 81

82 Chapter 8. SNMP
To enable SNMP proxy “EnableSNMPProxy” parameter should be set to “yes”.
8.7 Configure SNMP Trap Proxy
It is possible to proxy SNMP traps.

In this case as a destination of traps should be set the proxy node.
To enable trap proxy “EnableSNMPTrapProxy” parameter should be set to “yes”.

Optionally can be configured also “SNMPTrapListenAddress” and “SNMPTrapPort”. Default values can be checked
there: Master configuration file
8.7.2 Server configuration
By default traps are accepted only from known nodes. To accept all traps set “LogAllSNMPTraps” server configuration
variable to 1.
To correctly send response for SNMPv3, it should be also configured the proxy node for the sender node. It is done in
sender node properties in “Communications” tab, SNMP section.
8.8 Import MIB
MIB files (MIBs) describe structure of information transferred via SNMP. Every device can support multiple MIBs,
some of them are standard and public, other can be proprietary and vendor specific. NetXMS uses compiled MIBs to
allow you to select OID and see its description (for example when selecting SNMP data for DCI collection). You do
not need to compile new MIBs if you are OK with direct input of OID.
8.8.1 Compiling MIBs
• Change suffix of your new MIB file to .txt

• Copy your MIB file to /usr/share/netxms/mibs
• Use nxmibc binary to create a new compiled MIB file from all MIBs in directory. Add parameter -z for com-
pressed output file.
nxmibc -d /usr/share/netxms/mibs -o /usr/share/netxms/mibs/netxms.mib
Parameters recognized by nxmibc:

nxmibc [options] source1 ... sourceN
Valid options:
-d <dir> : Include all MIB files from given directory to compilation
-o <file> : Set output file name (default is netxms.mib)
-P : Pause before exit
8.7. Configure SNMP Trap Proxy 83


-s : Strip descriptions from MIB objects
-z : Compress output file
8.8.2 Troubleshooting
If nxmibc fails, it may be caused by syntax or import errors in your MIB. Try to check it with smilint (part of net-snmp
package) and correct any errors on level 3.
84 Chapter 8. SNMP
CHAPTER
NINE
USER MANAGEMENT
9.1 Introduction
NetXMS has it’s own user database. All NetXMS user accounts stored in backend SQL database. Each account has
it’s own unique login name and identifier. The account may also have a password.
9.2 Terms and Definitions
9.2.1 Users
NetXMS has the following attributes for users:

• Unique identifier
• Unique login name
• First name
• Last name
• Description
• Authentication method
• Password
• Certificate
Not all attributes are mandatory.
Superuser
Note: Before version 2.1-M0 there was only 1 default user admin with user ID 0 and access to everything by default.
After version 2.1-M0 admin was made a normal user which can be deleted or disabled. As a default user with access
to everything was created system user, that by default is disabled.
NetXMS has built-in superuser with ID 0, which always has full access to the system. Default login name for superuser
is system. By default user is disabled. Superuser account can be renamed or disabled/enabled, but cannot be deleted.
System user can be used to correct access rights to object, that exists, but none has access to it.
85
9.2.2 Groups
Each user can be member of several groups. Groups are the preferred way to organize access permissions. You should
always grant permission to groups instead of using individual users. That way you will get a much shorter access
control list which is easier to handle. Access rights from multiple groups are summarized to calculate effective user
access rights.
Other groups can also be added as group members, in this case, the user access rights will be calculated by summarizing
the access rights from all the groups in the path to the user.
Everyone Group
NetXMS has built-in virtual group called Everyone. This group always contains all users in the system. It cannot be
deleted, and it’s members list cannot be edited.
9.2.3 System Access Rights
NetXMS has 2 types of access rights access rights per system that are described in this section and per object.
System access rights used to grant access to system-wide configuration (like Event processing) and functions (like
agent registration).
The following system access rights can be granted:
86 Chapter 9. User management

Access Right Description

Access server console Allow user to access server’s debug console. Server debug console
Configure event templates Allow user to configure event templates. Event processing
Configure object tools Allow user to configure object tools. Object Tools
Configure server actions Allow user to configure server actions. Event processing
Configure SNMP traps Allow user to configure SNMP trap mapping.
Control user sessions Allow user to see active user sessions and force terminate them. (Not yet imple-
mented)
Edit event processing pol- Allow user to edit Event Processing Policy. Event processing
icy
Edit server configuration Allow user to edit server configuration variables.
variables
Execute commands via Allows user to execute commands via XMPP.
XMPP
Login as mobile device Allows user to login with help of mobile application.
Manage agent configura- Allow user to create, edit and delete agent configurations stored on server. Agent
tions configuration options from server
Manage all scheduled Allow user to create, edit and delete all Scheduled tasks.
tasks
Manage DCI summary ta- Allows user to manage DCI summary table. Summary table
ble
Manage image library Allows user to manage image library. Image library
Manage mapping tables Allows user to manage mapping tables.
Manage own scheduled Allow user to create new and modify Scheduled tasks created by the user.
tasks
Manage packages Allow user to install, remove, and deploy server agent packages. Centralized agent
upgrade
Manage server files Allow user to upload files to server and delete files stored on server. Server File
Management
Manage script library Allow user to manage scripts in Script Library.
Manage users Allow user to manage user accounts. Please note that user having this access right
granted can modify own account to get any other system right granted.
Manage user scheduled Allow user to create, edit and delete user`s Scheduled tasks.
tasks
Read server files Allow user to read files stored on server and upload to agents (user still needs appro-
priate object rights for upload). Server File Management
Register agents Allow user to register NetXMS agents.
Reporting server access Allow user to access the Reporting server configuration. Reporting
Schedule file upload Allow user to schedule server file upload to an agent. Scheduled tasks
Schedule object mainte- Allow user to schedule maintenance for an object. Scheduled tasks
nance
Schedule script execution Allow user to schedule script execution. Scheduled tasks
Send notifications Allow user to send notifications via NetXMS server. This access right has no effect
unless server configuration variable AllowDirectNotifications set to 1.
Unlink helpdesk tickets Allow user to unlink alarm from external helpdesk system Integration with external
HelpDesk.
View all alarms Allow user to view all alarms generated by Event Processing Policy rules.
View audit log Allow user to view audit log.
View event log Allow user to view event log, alarm log.
View event templates con- Allow user to view configured event templates.
figuration
9.2. Terms and Definitions 87


View SNMP trap log Allow user to view SNMP trap log.
By granting the View all alarms access right, the user (or members of the group) will have access to view all generated
alarms. Should it be required to configure alarm viewing access for specific users or groups, please refer to Alarm
Category Configurator.
9.3 User Authentication
9.3.1 Internal Password
This is the default method for user authentication. Password provided by user compared against password stored in
NetXMS database.
Password Policy
Various restrictions can be put on internal passwords to force users to choose stronger passwords. The following server
configuration variables controls password policy:
Variable Description Default

MinPasswordLength Default minimum password length for a NetXMS user. The default applied only 0
if per-user setting is not defined.
PasswordComplexity Required password complexity. See table bellow for details. 0
PasswordExpiration Password expiration time in days. If set to 0, password expiration is disabled. 0
Has no effect on users with Password never expired flag set.
PasswordHistoryLengthNumber of previous passwords to keep. Users are not allowed to set password 0
if it matches one from previous passwords list.
Possible flags for PasswordComplexity:
Value Description
1 Password must contain digits
2 Password must contain uppercase letters
4 Password must contain lowercase letters
8 Password must contain special characters
16 Forbid alphabetical sequences (password considered invalid if it contains alphabetical sequence of 3 or
more letters of same case).
32 Forbid keyboard sequences (password considered invalid if it contains sequence of 3 or more characters
that are located on keyboard next to each other, like ASDF).
Complexity flags can be added together to get desired restrictions. For example, to force passwords to contain upper-
case and lowercase letters, PasswordComplexity variable must be set to 6 (2 + 4).
Changes to these configuration variables becomes effective immediately and does not require NetXMS server restart.

9.3.2 RADIUS
If RADIUS authentication method selected password provided by user sent to RADIUS server for validation. User is
granted access if RADIUS server responds with Access-Accept. Communication between NetXMS server and
RADIUS server controlled by the following server configuration variables:

value
RADIUSNumRetries The number of retries for RADIUS authentication. 5
RADIUSPort Port number used for connection to primary RADIUS server. 1645
RADIUSSecondaryPort Port number used for connection to secondary RADIUS server. 1645
RADIUSSecondarySecret Shared secret used for communication with secondary RADIUS netxms
server.
RADIUSSecondaryServer Host name or IP address of secondary RADIUS server. none
RADIUSSecret Shared secret used for communication with primary RADIUS netxms
server.
RADIUSServer Host name or IP address of primary RADIUS server. none
RADIUSTimeout Timeout in seconds for requests to RADIUS server 3
9.3.3 Certificate Authentication
This type of authentication can be selected manually in user preferences.

Login process using certificate is following:
1. Server send random challenge to client
2. Client sign server’s challenge with his certificate’s private key and send signed challenge along with public part
of certificate to server
3. Server validates certificate using CA certificate
4. If certificate is valid, server validates challenge signature using certificate’s public key
5. If signature is valid, server compares certificate subject with mapping data from user record
6. If mapping data match with certificate subject, access is granted
So, to login successfully, user must posses valid certificate with private key. Authentication by certificate also allows
smart card login - you just need to store certificate used for login on smart card instead of local certificate store.
Certificate management
CA certificates are searched in the list configured by “TrustedCertificate” configuration parameter in server configura-
tion file.
9.3. User Authentication 89

Link certificate and user
In “User Manager” view select user properties for required user. Then go to “Authentication” part.
In “Authentication Method” section: “Certificate”, “Certificate or Password”, “Certificate or RADIUS”.
Next two fields in combinations:

Certificate mapping method: “Subject”
Certificate mapping data: the subject of the CA.
Certificate mapping method: “Public key”

Certificate mapping data: the public key of the certificate
Certificate mapping method: “Common name”

Certificate mapping data: if no mapping data set, then linking certificate CN = user name, otherwise CN
= mapping data

9.3.4 CAS authentication
Central Authentication Service (CAS) single sign-on is supported in web interface only. The following server
configuration parameters control CAS operation: CAS.AllowedProxies, CAS.Host, CAS.Port, CAS.Service,
CAS.TrustedCACert, CAS.ValidateURL. See Server configuration parameters for the expanation of mentioned pa-
rameter meaning.
9.4 Integration with LDAP

NetXMS can perform one-way synchronization of users and groups with external LDAP server. User list replica is
refreshed automatically.
Already existing NetXMS users or groups will not be modified during initial synchronization (e.g. user “admin” or
group “Everyone”).
9.4.1 LDAP synchronization configuration
Server parameters controlling LDAP synchronization:
9.4. Integration with LDAP 91


value
LdapConnectionString Comma- or whitespace-separated list of URIs in a format schema://host:port. ldap://
* Supported schemas: ldap://, ldaps:// (LDAP over TLS), ldapi:// (LDAP over localhost:
IPC), and cldap:// (connectionless LDAP). 389
Windows specific: for server based on Windows system this parameter should
be set according to this rules: empty string(attempts to find the “default” LDAP
server), a domain name, or a space-separated list of host names or dotted strings
that represent the IP address of hosts running an LDAP server to which to con-
nect. Each host name in the list can include an optional port number which is
separated from the host itself with a colon (:).
Note: most LDAP implementations except recent versions of OpenLDAP do
not support mixed schema types in the single connection string.
LdapSyncUser * User login for LDAP synchronization
LdapSyncUserPasswordUser password for LDAP synchronization
*
LdapSearchBase The LdapSearchBase configuration parameter is the DN of the entry at which
to start the search.
LdapSearchFilter * The LdapSearchFilter is a string representation of the filter to apply in the
search.
LdapUserDeleteAction This parameter specifies what should be done while synchronization with 1
* deleted from LDAP user/group. 0 - if user should be just deleted from NetXMS
DB. 1 - if it should be disabled. If it is chosen to disable user, then on LDAP
sync user will be disabled and it’s description will be change on “LDAP en-
try was deleted.” Afterwards this user/group can be detached from LDAP and
enabled if it is required or just deleted manually.
LdapUserMappingName There should be specified name of attribute that’s value will be used as a user’s
* login name
LdapGroupMappingName There should be specified name of attribute that’s value will be used as a group’s
* login name
LdapMappingFullNameThere should be specified name of attribute that’s value will be used as a user
full name
LdapMappingDescription
There should be specified name of attribute that’s value will be used as a user
description
LdapGroupClass There is specified which object class represents group objects. If found entry
will not be of a user ot group class, it will be just ignored.
LdapUserClass * There is specified which object class represents user objects. If found entry will
not be of a user ot group class, it will be just ignored.
LdapGroupUniqueId Unique identifier for LDAP group object. By default LDAP groups are identi-
fied by DN. If in your configuration DN can be changed any time it is useful to
choose other attribute as unique group identifier.
LdapUserUniqueId Unique identifier for LDAP user object. By default LDAP users are identified
by DN. If in your configuration DN can be changed any time it is useful to
choose other attribute as unique user identifier.
LdapSyncInterval * This parameter is for setting synchronization interval in minutes between 0
NetXMS server and LDAP server. If synchronization parameter is set to 0 -
synchronization will not be done.
LdapPageSize * Limit of records that can be returned in one search page. 1000
* Required fields
Synchronization also can be done manually with ldapsync or just ldap command in server console.

9.4.2 LDAP users/groups relationships with native NetXMS users/groups
LDAP users and groups are handled in exactly the same was as users from internal database. Only difference is that
LDAP group membership is refreshed on each synchronisation and any non-LDAP user will be removed from the
group.
9.4.3 Login with help of LDAP user
Login process is completely transparent for the user - user name should match attribute set by LdapMappingName and
password should be current LDAP password for that user.
9.4.4 LDAP configuration debugging
If users are not synchronized the reason can be found by running manually ldapsync or just ldap command in server
console on debug lever 4.
Log when LDAP sync passed correctly:
[11-Sep-2014 16:28:08.352] [DEBUG] LDAPConnection::initLDAP(): Connecting to LDAP

˓→server
[11-Sep-2014 16:28:08.353] [DEBUG] LDAPConnection::syncUsers(): Found entry count: 3

[11-Sep-2014 16:28:08.354] [DEBUG] LDAPConnection::syncUsers(): Found dn: CN=Users,
˓→CN=Customers,DC=Northwind,DC=Extranet
[11-Sep-2014 16:28:08.354] [DEBUG] LDAPConnection::syncUsers(): CN=Users,CN=Customers,

˓→DC=Northwind,DC=Extranet is not a user nor a group
[11-Sep-2014 16:28:08.354] [DEBUG] LDAPConnection::syncUsers(): Found dn: CN=zev333,

˓→CN=Users,CN=Customers,DC=Northwind,DC=Extranet
[11-Sep-2014 16:28:08.354] [DEBUG] LDAPConnection::syncUsers(): User added: dn:

˓→CN=zev333,CN=Users,CN=Customers,DC=Northwind,DC=Extranet, login name: zev333, full
˓→name: (null), description: (null)
[11-Sep-2014 16:28:08.354] [DEBUG] LDAPConnection::syncUsers(): Found dn: CN=user,

˓→CN=Users,CN=Customers,DC=Northwind,DC=Extranet
[11-Sep-2014 16:28:08.354] [DEBUG] LDAPConnection::syncUsers(): User added: dn:

˓→CN=user,CN=Users,CN=Customers,DC=Northwind,DC=Extranet, login name: user, full
˓→name: (null), description: (null)
[11-Sep-2014 16:28:08.354] [DEBUG] LDAPConnection::closeLDAPConnection(): Disconnect

˓→from ldap.
[11-Sep-2014 16:28:08.354] [DEBUG] UpdateLDAPUsers(): User added: dn: CN=zev333,

˓→CN=Users,CN=Customers,DC=Northwind,DC=Extranet, login name: zev333, full name:
˓→(null), description: (null)
[11-Sep-2014 16:28:08.354] [DEBUG] UpdateLDAPUsers(): User added: dn: CN=user,

˓→CN=Users,CN=Customers,DC=Northwind,DC=Extranet, login name: user, full name: (null),
˓→ description: (null)
[11-Sep-2014 16:28:08.354] [DEBUG] RemoveDeletedLDAPEntry(): Ldap uid=john,ou=People,

˓→dc=nodomain entry was removed from DB.
[11-Sep-2014 16:28:08.354] [DEBUG] RemoveDeletedLDAPEntry(): Ldap uid=zev,ou=People,

[11-Sep-2014 16:28:08.354] [DEBUG] RemoveDeletedLDAPEntry(): Ldap uid=kasio,ou=People,

[11-Sep-2014 16:28:08.355] [DEBUG] RemoveDeletedLDAPEntry(): Ldap uid=usr1,ou=People,

Login credentials incorrect:
9.4. Integration with LDAP 93


˓→server
[11-Sep-2014 15:49:39.896] [DEBUG] LDAPConnection::loginLDAP(): LDAP could not login.

˓→Error code: Invalid credentials
[11-Sep-2014 15:49:39.896] [DEBUG] LDAPConnection::syncUsers(): Could not login.
Search base is set incorrectly or sync user does not have access to it:
˓→server
[11-Sep-2014 15:54:03.140] [DEBUG] LDAPConnection::syncUsers(): LDAP could not get

˓→search results. Error code: No such object
9.4.5 LDAP configuration examples
Active Directory
Variable Value
LdapConnectionString ldap://10.5.0.35:389
LdapSyncUser CN=user,CN=Users,CN=Customers,DC=Domain,DC=Extranet
LdapSyncUserPassword xxxxxxxx
LdapSearchBase CN=Customers,DC=Domain,DC=Extranet
LdapSearchFilter (objectClass=*)
LdapUserDeleteAction 1
LdapMappingName sAMAccountName
LdapMappingFullName displayName
LdapMappingDescriptiondescription
LdapGroupClass group
LdapUserClass user
LdapGroupUniqueId objectGUID
LdapUserUniqueId objectGUID
LdapSyncInterval 1440
Open LDAP
Variable Value
LdapConnectionString ldap://10.5.0.35:389
LdapSyncUser cn=admin,dc=nodomain
LdapSyncUserPassword xxxxxxxx
LdapSearchBase dc=nodomain
LdapSearchFilter (objectClass=*)
LdapUserDeleteAction 1
LdapMappingName cn
LdapMappingFullName displayName
LdapMappingDescriptiondescription
LdapGroupClass groupOfNames
LdapUserClass inetOrgPerson
LdapGroupUniqueId entryUUID
LdapUserUniqueId entryUUID
LdapSyncInterval 1440

9.5 Managing User Accounts
All NetXMS user accounts can be managed from User Manager view available at Configuration → User Manager in
NetXMS Console. Only users with granted system right Manage users can access User Manager.
• To create new user account, select Create new user from view menu or context menu.
• To create new group, select Create new group from view menu or context menu.
• To delete user account, select it in the list, right-click, and select Delete from pop-up menu. You can delete
multiple accounts at a time.
• To modify properties of user or group, select it in the list, right-click, and select Properties from pop-up menu.
• To reset user’s password, select user account in the list, right-click, and select Change password from pop-up
menu.
9.6 Audit
All important user actions are written to audit log. There are two audit logging modes - internal and external. Internal
audit logging is on by default and writes audit records into table in NetXMS database. External audit logging allows
sending audit records to external system via syslog protocol. External audit logging is off by default. Audit logging
controlled by the following server configuration variables:
Variable Description Default value

AuditLogRetentionTimeRetention time in days for the records in internal audit log. All 90
records older than specified will be deleted by housekeeping pro-
cess.
EnableAuditLog Enable (1) or disable (0) audit logging. 1
ExternalAuditFacility Syslog facility to be used in audit log records sent to external server. 13
ExternalAuditPort UDP port of external syslog server to send audit records to. 514
ExternalAuditServer External syslog server to send audit records to. If set to none, exter- none
nal audit logging is disabled.
ExternalAuditSeverity Syslog severity to be used in audit log records sent to external server. 5
ExternalAuditTag Syslog tag to be used in audit log records sent to external server. netxmsd-audit
9.5. Managing User Accounts 95


CHAPTER
TEN
OBJECT MANAGEMENT
10.1 Object browser
Object browser is a view in in Management Console. It presents all existing objects as a hierarchical structure. Overall
description of objects can be found in concepts part: Objects.
10.1.1 Object browser options
Object browser has a number of options that define how object tree is displayed.
Object browser has following options:
• Show filter CTRL+F2, that shows search line that has special syntaxes for search. Syntaxes description
can be found there: Filters.
• Show status indicator CTRL+F3
• Hide unmanaged objects
• Hide check templates. This option will not show Business Services templates.
10.1.2 Filters
Buy default search is done by node name. In this type of search can be used ‘*’ and ‘?’ symbols for pattern search.
But there are few prefix that can be used for other search options:
• ‘/’ - will search in comments
• ‘>’ - will search by IP address
10.2 Objects
Detailed information about objects, it’s usage, parents and children can be found in concept chapter, Objects. In this
section will be described only actions and properties that can be applied on different object classes.
97
10.2.1 Subnet
Property pages:
Except common properties subnets has Map Appearance and Trusted Nodes tabs. Map Appearance tab defines images
that will be used to display this object on a Network Map and drill-down object (object that will be opened when double
click on this object on Network Map). Trusted Nodes is used to define object list that have access to this object from
the script.
Menu items:
Full subnet can be managed or unmanaged. Management status will be applied to all subnet node. If subnet is deleted
and is the only parent of a node, then node also will be deleted with the subnet. Upload file menu item will upload file
from server to all nodes that have agent and have access to upload directory.
Under Tools menu are available predefined object tools that will be executed on each subnet node. More about object
tool configuration can be found there: Object Tools.
Execute server script will open execute server script view where arbitrary script can be executed. Alarms menu item
will open view with all subnet nodes’ alarms. And 802.1x port state will open table with port authentication states,
that can be exported to CSV.
10.2.2 Node
Property pages:
Except common properties node has Communications tab that is responsible for communication options with this
node(like host name, agent proxy and authentication, SNMP proxy and authentication and ICMP proxy), Polling tab
is responsible for disabling pols for specific node, Location is used to configure location of the node, Map Appearance
tab defines images that will be used to display this object on a Network Map and drill-down object (object that will be
opened when double click on this object on Network Map).
Menu items:
Usually interfaces for nodes are created automatically by Configuration poll results, but they can be also created
manually with help of menu item Create interface. . . This interface is a physical port is used just for information
purposes.
Information about service monitoring and Create network service. . . menu item can be found there: Service monitor-
ing.
When node is unmanaged/managed - all it’s children like interfaces and service monitoring are also unman-
aged/managed. In unmanaged state metrics are not collected and no polls are scheduled.
98 Chapter 10. Object management

Node can be deleted from NetXMS by Delete menu item. Node is not deleted synchronously, but it is scheduled node
deletion. While node deletion all data bout this node is also collected(like metrics).
If zones are enabled, then zone can be changed using Change zone. . . item. File manager will open agent file manager
view. By default this view will be empty, to configure it refer to Agent file management chapter. Upload file can be
used to upload file from server to node. This action can be applied simultaneously to all nodes.
Take screenshot for now halfway implemented functionality. For now screenshot can be taken only from Windows
machines.
Description of Edit agent’s configuration functionality can be found in Edit configuration file remotely chapter.
Poll options:
Poll Name Description

Status
Configuration
Configuration (full)
Instance discovery
Instance names
Topology
Under Tools menu are available predefined object tools that will be executed on selected node. More about object tool
configuration can be found there: Object Tools.
Execute server script will open execute server script view. Were arbitrary script can be executed. Node can be accessed
with $node variable.
MIB Explorer will open MIB explorer view. If geolocation of the node is set, then with help of Geolocation item can be
opened map with shown on it object location. Software Inventory will show full software list for nodes with Windows
systems or Linux systems(that used rpm or deb packages) and have NetXMS agent installed. Service Dependency will
build tree from this node with all container where this node is included. Alarms will open alarm view with alarms only
for this specific node.
Find switch port will open view with log of searches of switch port to which a node is connected. During search the
interfaces will be checked one by one and first successful result will be shown.
802.1x port state will open table with port authentication states, that can be exported to CSV.
Topology menu item contains all options of predefined network maps for this node and some other options:
Routing table IP route from. . . will build network map with route from selected node to node that was selected in
Object selector window. IP route to. . . will build network map with route to selected node from node that was
selected in Object selector window. IP Neighbors will show all IP neighbors of this node.
Switch forwarding database(MAC address table) VLANs Layer 2 Topology
Radio interface Wireless stations
Last values will open Last Values view. Data Collection Configuration will open Data Collection Configuration view,
that is used to configure collected metrics from node.
10.2. Objects 99
10.2.3 Mobile Device
Mobile device objects are added manually. More information about required configuration to monitor mobile devices
can be found there: Monitoring mobile devices.
Property pages:
Mobile Device object has only default property page configuration.
Menu items:
Each phone object can be managed/unmanaged and deleted. In unmanaged state metrics of this device are not collected
and no pols are scheduled. When mobile object is deleted all it’s data is also deleted. No history data will be left.
Execute server script will open execute server script view where arbitrary script can be executed. Geolocation History
will open view were will be shown history of displacement of this device. From the menu can be selected the period
to show on history map. Geolocation will show last known location of this device. Alarms menu item will open view
with all subnet nodes’ alarms.
Last values will open Last Values view. Data Collection Configuration will open Data Collection Configuration view,
that is used to configure collected metrics from node.
10.2.4 Rack
Rack is an object that visualizes server room organization in NetXMS. Node and chassis objects can be assigned to
a rack in node properties, specifying position in the rack, height (number of occupied rack units), orientation (does
it occupy full depth of the rack, or only present on front or back side of the rack). Front and/or rear images can be
selected from Image library.
Rack visualization is available in Object Detail -> Rack view. Left click on a rack unit display a pop-up with brief
information about the node or chassis. Right click will display node or chassis context menu. Double click on a chassis
will open Chassis View in a separate tab.
Status of rack units is denoted with color rectangle on the left edge of the rack.

10.2.5 Chassis
Chassis is an object visualizing a rack-mount chassis that have plug-in modules. Chassis visualization is available in
Object Detail -> Chassis view.
Each node that represents chassis module can have an image that will be displayed atop of chassis image. Status of
each node is denoted with color rectangle in the upper left corner or it’s image. Left click on node will display a
pop-up with brief information about the node. Right click will display node context menu.
It is possible to configure the size of module’s image and it’s position on chassis image. Vertical size and position
could be specified in mm or rack units (RU), while horizontal - in mm or horizontal pitch units (HP). Size calculation
assumes that 1U chassis has 45mm height and 483mm width (including mounting brackets). Position (0, 0) is in the
upper left corner.
10.2. Objects 101

You can use a graphic editor, e.g. Gimp to find position values in mm. Open chassis image in Gimp and set image
width to 483 mm using Image -> Scale image. Now in the bottom left corner you can see current coordinates of mouse
cursor in mm.
Chassis module images should be uploaded using Image Library Image library.
10.2.6 Cluster
Is created to display nodes logical organization in cluster. Cluster nodes may have shared resources and networks, pro-
cesses may move between nodes, so metric collection should be organized accordingly. Cluster object provides option
to aggregate collected data from cluster nodes. More about data aggregation can be found there: Data aggregation.
Besides default property pages cluster has also:
• Cluster Resources - there can be configured IP resources of the cluster. Further on Cluster view of Object
Details will be shown current owner of resources
• Cluster Networks
• Poling
• Dashboards - there dashboard can be associated with object, so on right click associated dashboards will
be displayed in the list
• External Resources
• Location
• Map Appearance
• Trusted Nodes
10.2.7 Interface
10.2.8 Network Service
10.2.9 VPN Connector
10.2.10 Condition
Conditions may represent more complicated status checks because each condition can have a script attached. Interval
for evaluation of condition status is configured in Server Configuration Variables as ConditionPollingInterval with
default value 60 seconds. Input values for the condition script can be set in object properties. Such values are accessible
via $1, $2, . . . variables inside the script. If the script returns 0, an activation event with the defined severity is created.
If the script returns any other value, then a deactivation event is created.
Besides default property pages condition has also:
• Events and Status, were can be set activation and deactivation events, source of this objects and status of
active and inactive condition.
• Data, were can be set DCI’s that’s data will be given to a script for condition status calculation.
• Script tab is used to write script that will calculate if condition should be activated or deactivated.
• Map Appearance tab defines images that will be used to display this object on a Network Map and
drill-down object (object that will be opened when double click on this object on Network Map).
• Trusted Nodes is used to define object list that have access to this object from the script.

Menu items:
Condition can be managed/unmanaged. If condition is unmanaged, evaluation of condition is not run. Condition can
be deleted.
10.2.11 Container
Containers can be created in Infrastructure Services tree. Existing nodes and subnets can be added to containers by
using Bind operation, and removed by using Unbind operation. New nodes, conditions, clusters, containers, mobile
devices and racks can also be created. They can be created using required menu item of container under which this
object should appear. Containers and nodes inside them can be moved by Move to another container menu item or
using drag&drop.
Besides default property pages condition has also:
• Automatic bind about this functionality can be found there
• Location is used to configure location of the node
• Map Appearance tab defines images that will be used to display this object on a Network Map and
drill-down object (object that will be opened when double
click on this object on Network Map).
• Trusted Nodes is used to define object list that have access to this object from the script.
Menu items:
There are special menu item for each object that can be created in container. Objects like rack, container, mobile
device, cluster are manually created objects. Node can be manually created or found by network discovery. In case if
it is required to add already existing object to container use Bind. . . menu item. To remove node from container, but
do not delete it use Unbind. . . menu item.
Using Manage/Unmanage all nodes will be managed/unmanaged under container. Container can be deleted. If deleted
container was the only parent of an object, then this object will be also deleted. Upload file. . . will upload file from
server to all nodes under container, same as each tool under Tools menu item will be executed on each node.
Execute server script will open execute server script view. Where an arbitrary script can be executed. Geolocation
will show location of container on geographic map.
Alarms will open alarm view with all active alarms for all children of this container. 802.1x port state will open table
with port authentication states of all devices that are under this container. This information can be exported to CSV.
Automatic bind option
For each container can be configured automatic binding rules. This can be done in Automatic Bind Rules tab of
container properties.
10.2. Objects 103

There can be defined if script should be used for automatic binding, if script should be used for node unbinding and
can be written script it selves.
This script will be executed each configuration poll of each node.
10.3 Common object properties
10.3.1 General
Each object has General tab in properties. There can be checked object class and ID, and changed object name. Each
object has unique ID in the system. Object can be accessed by this ID.
10.3.2 Custom attributes
Every object can have custom attributes defined either by user or integrated application via NetXMS API. Custom
attributes distinguished by names (an attribute name can contain up to 127 printable characters), and have string
values of unlimited length. However, if you wish to access custom attributes in NXSL scripts as properties of node
object, you should name them conforming to NXSL identifier naming constraints. To create or change value of custom
attribute manually, right-click an object in NetXMS console, and select Properties → Custom Attributes tab.

10.3.3 Status calculation
Each object has it’s own status calculation properties. Status of an object calculated based on:
• Polling results
• Status of child objects (e.g. interfaces of node, nodes under container)
• Active alarms, associated with the object (after an alarm is resolved or terminated, it no longer affects object
status)
• Value of status DCIs (DCI that has Use this DCI for node status calculation property en-
abled)
There are multiple options for status calculation that can be configured for specific objects or globally.
Status calculation has two configuration parts:
• status propagation - the way how status from object is pushed to upper objects;
• status calculation - the way how object is calculating it’s status based on statuses propagated by children objects.
Once child object status is calculated most critical status is taken from status of underlying objects, associated
alarms and status DCIs.
10.3. Common object properties 105

For status propagation the following options are available:

• Default - will take global configuration parameter (unchanged by default)
• Unchanged - will propagate status value without changes
• Fixed value: Normal, Warning, Minor, Major, Fixed - always will return fixed selected status
• Relative with offset - will add or remove some number for
• Severity based - will convert current status based on user configured status mapping table
For status calculation the following options are available:
• Default - will take global configuration parameter (most critical by default)
• Most critical - Most critical status will be taken
• Single threshold (%) - Percentage of objects that should be in status to change status of object
• Multiple thresholds - Same as previous but threshold is set for each status
Example of threshold status calculation
Statuses of nodes in table:

Normal Warning Minor Major Critical

Node 1 1 0 0 0 0
Node 2 1 1 1 1 1
Node 3 1 1 0 0 0
Node 4 1 1 1 0 0
If “Single threshold (%)” option is selected and configuration is next:

• 75%
In this case status of container will be Warning, as 3/4 of nodes have Warning status or worse.
If “Multiple thresholds” is selected and configuration is next:
• Warning 80
• Minor 50
• Major 25
• Critical 35
In this case status of Container will be Major as bot thresholds for Minor and Major are reached and most critical from
them is taken.
10.3.4 Comments
Each object in Object Tree can have comment. Comment can be set in Properties of the object.
10.3. Common object properties 107

10.3.5 Access control
Object access rights controls access to NetXMS objects. Permissions given to an object inherited by all child objects,
unless specifically blocked by turning off Inherit access rights from parent object(s) option in object’s access control
properties. Permissions given at different levels of the object tree summarize to form effective user rights for the
object.
The following object access rights can be granted:


Access control Modify access control list for this object. Please note that user with this access right
can grant any other access rights to own account.
Acknowledge alarms Acknowledge alarms with this object as source.
Control For node objects, execute object tools of type Remote Command.
Create child objects Create child objects (or bind existing) under this object.
Create helpdesk tickets Create ticket in external helpdesk system
Delete Delete this object.
Modify Modify object’s properties (except access control).
Push data Push data for DCIs on this object.
Read View object in the tree and read it’s information. For node objects, read access allows
to view collected DCI data.
Send events Send events on behalf of this object.
Terminate alarms Terminate alarms with this object as source.
View alarms View alarms with this object as source.
Download file Allow user to download files from this node (from paths defined by filemng subagent).
This access right is also checked when downloading or tail of file is done from object
tools.
Upload file Allow user to upload files to this node(from paths defined by filemng subagent)
Manage files Allow user to move, rename, delete files from this node(from paths defined by filemng
subagent)
10.4 Object Details
Object details view provides main information about object. Each object has Overview tab that displays general
information about object (like: ID, GUID, Class, and status of the object) and Comments.
10.4.1 Subnet
10.5 Object Tools
It is possible to create tools that will be executed on objects. Configured object tools are listed under Tools in object
browser’s context menu. A tool can ran a command on NetXMS server or node, obtain data from SNMP or NetXMS
agent, etc. . .
Tools can be managed in Configuration → Object Tools. There are some predefined object tools that are available after
installation of the system.
If an object tool is not needed for some time it can be just disabled and then enabled when required. When object tool
is disabled it is not shown under “Tools” item of context menu. If an image (16x16 px) is configured for an object
tool, it will be displayed next to object tool name in “Tools” menu.
Tool can have input fields, filter depending on execution object, macro substitution and personal access control con-
figuration.
10.4. Object Details 109

10.5.1 Object tool types
Internal
The only operation available for now is wakeup that sends magic packet to wake up a node.
Agent Command
This tool will execute command on an agent node and will show it’s output if Command generates output option is
enabled.

Field name Description

Name Name that will be shown in node menu. Submenu can be created with “->”
notation.
Description Description is shown in “Object Tools” view. Should be used to describe tool
purpose.
Command Name of agent command that will be executed. There is a number of com-
mands built into agent and additional commands can be added by defining them
in agent’s config. If command accepts parameters they are supplied it the fol-
lowing format: commandName param1 param2 param3...
Command generates output If this option is selected then command execution will open a window with it’s
output.
This tool requires confirmation If chosen a Yes/No pop-up with text from “Confirmation message” field will be
before execution shown before execution of tool.
Confirmation message Contains message that will be shown in confirmation pop-up.
Show this tool in node com- If this option is selected, then this tool will be shown for applicable nodes on
mands Object Details view as node command.
Command name Name of the command
Command short name Is used when Command name is too long for display.
Disable Object Tool If chosen, tool is not shown in Object browser’s context menu and Commands
in Object Details.
SNMP Table
SNMP Table is used to get SNMP table from node on which it is executed and then show results in the table form.
10.5. Object Tools 111


notation.
purpose.
Title Title of view where table will be shown.
Use as index for second and This option defines that suffix of columns OID will be used as suffix for columns
subsequent columns OID suffix OID’s to match lines
of first column
Use as index for second and This option defines that value of columns OID will be used as suffix for columns
subsequent columns Value of OID’s to match lines
first column
This tool requires confirmation If chosen, before execution of tool will be shown Yes/No pop-up with text from
before execution “Confirmation message” field.
Confirmation message Can be set the message that will be shown in confirmation pop-up.
Command name This will be shown as a name of the command.
Command short name Is used when usual name is too long for display.
Disable Object Tool If chosen, tool is not shown in node menu.
Agent List
Agent List is used to get agent list from node on which it is executed and then show results in the table form. Regular
expression is used to split received data to columns.


notation.
Description Description is shown in “Object Tools” view. Should be used to describe tool’s
purpose.
Parameter Name of list
Regular expression Regular expression that will parse each line of list to separate it on columns
defined in Columns tab.
Agent Table

Agent Table is used to get agent table from node on which it is executed and then show results in the table form.


notation.
purpose.
Parameter Name of list
URL
URL tool opens URL in web browser.


notation.
purpose.
URL URL that should be passed to browser to be opened.
Local Command
Local Command tool will execute command on the node, where Desktop Management Console is running and will
show it’s output if Command generates output option is enabled.
This tool type is not visible from Web Console as it is not possible to execute command on web page receiver’s
machine.


notation.
purpose.
Command Command that should be executed on a local machine
Command generated output If this option is selected, then command execution will open a window with
output of the command.
Server Command
Server command tool can be used to execute command on the server.


notation.
purpose.
Command Command that should be executed on a server
Command generated output If this option is selected, then command execution will open a window with
output of the command.
Download File
Download file tool can be used to monitor agent logs. This tool will retrieve the content of the file from agent.


notation.
purpose.
Remote File Name Name of file that will be retrieved. In Windows systems should be with double
back slash as a separator(C:\log\log.log). Can be used strftime(3C) macros
Limit initial download size Limits the size of download file. If is set to 500, tool will retrieve last 500 bytes
of requested file. If is set to 0, complete file will be retrieved.
Follow file changes If chosen, “File View” will be updated when file will be populated with new
data.
Server Script
Server Script tool can be used to execute NXSL script from Script Library. This tool provide full range of capabilities
that are available thought NXSL scripting.


notation.
purpose.
Script Name of the script from the Script Library
Command generates output If chosen, new window with script execution result will be opened.
10.5.2 Macro Substitution
Action, file download, local command, and URL tool types allows macro substitution. Any string starting with percent
sign considered macro name and is expanded. The following macros recognized:
Macro Description
%a IP address of event source object.
%g Globally unique identifier (GUID) of event source object.
%i Unique ID of event source object in hexadecimal form. Always prefixed with 0x and
contains exactly 8 digits (for example 0x000029AC).
%I Unique ID of event source object in decimal form.
%n Name of event source object.
%u IP address of event source object for use in URL. Expands into [addr] for IPv6 and
addr for IPv4.
%U User name of user that launched the object tool from user interface
%v NetXMS server’s version.
%[name] Value returned by script. You should specify name of the script from script library.
%{name} Value of custom attribute.
%(name) Value of input field.
%<name> Parameter with given name.
%% Insert % character.
If object tool called from alarm’s pop-up menu the following additional macros are available:

Macro Description
%A Alarm’s text (can be used only in actions to put text of alarm from the same event
processing policy rule).
%c Event’s code.
%m Event’s message text (meaningless in event template).
%N Event’s name.
%s
Event’s severity code as number. Possible values are:
• 0 - Normal
• 1 - Warning
• 2 - Minor
• 3 - Major
• 4 - Critical
%S Event’s severity code as text.

%y
Alarm state as number. Possible values are:
• 0 - Outstanding
• 1 - Acknowledged
• 2 - Resolved
• 3 - Terminated
%Y Alarm’s id.
Internal object tool is special case of object tools. Macro expansions not performed for Internal object tools.
For any unknown macro name system will try to read custom attribute with given name (attribute search is case
sensitive). If attribute with given name not found, empty string will be inserted.
10.5.3 Properties
Filter
Filters are used to chose on which nodes to show object tool. There are 5 types of filtering. Show object tool:
1. if agent available on a node
2. if node supports SNMP
3. if node SNMP OID matches with provided string
4. if nodes OS matches provided comma separated regular expression list
5. if provided template name matches provided comma separated regular expression list

Access Control
In Access Control tab can be defined which users or groups can execute this action. If the list is empty, only adminis-
trator will be able to execute this action.

Columns
Columns tab is used only for Agent List and SNMP Table object tool types.
For SNMP Table it describes name and type of matching OID from response message.


Input fields
There is option to add input fields for object tool commands. This fields are defined on the Input fields view and added
to command in %(name) format. More about formats can be found in Macro Substitution chapter.
Input field can be one of this types:
• Text
• Password
• Number

10.5.4 Predefined Object Tools
NetXMS is delivered with a number of predefined Object Tools. Here is the list of them:

Name Type Description Filter

Connect→Open web URL Open embedded web browser to node
browser
Connect->Open web URL Open embedded web browser to node using
browser (HTTPS) HTTPS
Info->Agent->Loaded Agent Table Show information about loaded subagents NetXMS agent
subagents should be avail-
able
Info->Agent- Agent Table Show information about ICMP targets config- NetXMS agent
>Configured ICMP ured on this agent and ping sub-
targets agent should be
available
Info->Agent- Agent List Show information about actions supported by NetXMS agent
>Supported actions agent should be avail-
able
Info->Agent- Agent List Show list of lists supported by agent NetXMS agent
>Supported lists should be avail-
able
Info->Agent- Agent List Show list of parameters supported by agent NetXMS agent
>Supported should be avail-
parameters able
Info->Agent- Agent List Show list of tables supported by agent NetXMS agent
>Supported tables should be avail-
able
Info->Current pro- Agent Table Show information about currently running pro- NetXMS agent
cesses cesses should be avail-
able
Info->Routing table SNMP Table Show IP routing table NetXMS should
(SNMP) support SNMP
Info->Switch forward- SNMP Table Show switch forwarding database NetXMS should
ing database (FDB) support SNMP
Info->Active user ses- Agent List Show information about active user sessions NetXMS agent
sions should be avail-
able
Info->ARP cache Agent List Show ARP cache NetXMS agent
(Agent) should be avail-
able
Info->Topology table SNMP Table Show topology table (CDP) NetXMS should
(CDP) support SNMP
Info->Topology table SNMP Table Show topology table (LLDP) NetXMS should
(LLDP) support SNMP
Info->Topology table SNMP Table Show topology table (Nortel protocol) NetXMS should
(Nortel) support SNMP
Restart system Action Restart target node via NetXMS agent NetXMS agent
should be avail-
able
Shutdown system Action Shutdown target node via NetXMS agent NetXMS agent
should be avail-
able
Wakeup node Internal Wakeup node using Wake-On-LAN magic
packet
Restart agent Action Restart NetXMS agent on target node NetXMS agent
should be avail-
able
CHAPTER
ELEVEN
NETWORK DISCOVERY
11.1 Introduction
NetXMS is capable of discovering your network automatically. Network discovery module can operate in two modes
- passive and active.
In passive mode, information about new hosts and devices obtained from ARP tables and routing tables of already
known devices. NetXMS starts with it’s own ARP cache and routing table.
In active discovery mode, NetXMS server will send an ICMP echo requests to all IP addresses in given range, and
consider each responding address for adding to database. If zoning is used, server sends echo request only in zone
0, in other zones requests are sent by proxies. For each new device found NetXMS server tries to gather additional
information using SNMP and NetXMS agent, and then adds it to database. By default NetXMS server will add all
discovered devices to database, but you can limit it by using discovery filters. Default SNMP credentials can be set in
Default SNMP credentials.
Default intervals are 2 hours for active discovery and 15 minutes for passive discovery. These values can be changed in
Network Discovery configuration. Number of discovery poller threads changes dynamically and is defined by server
configuration parameters ThreadPool.Discovery.BaseSize and ThreadPool.Discovery.MaxSize.
More information about server configuration parameters can be found here.
11.2 Configuring Network Discovery
To change network discovery settings, go to main menu of management console and choose Configuration → Network
Discovery. Configuration form will open:
127
11.2.1 General
In this section, you can choose network discovery mode, chose if source node of SNMP Trap or syslog source address
should be used for discovery.
11.2.2 Schedule
For passive discovery interval (in seconds) is selected. For active discovery you cen choose either an interval (in
seconds) or cron format schedule (see here for more details).
11.2.3 Filter
In this section, you can define filter for adding new nodes to NetXMS database. Filtering options are following:
No filtering
Any new device found will be added to database. This is the default setting.
Custom script
You can choose NXSL script from the Script Library to work as discovery filter. Custom filtering script will get object
of class NewNode as first parameter (special variable $1), and should return true to allow node inclusion into database.
Automatically generated script
This option can be used if you need only simple filtering. When selected, additional options controls what nodes will
be added to database:
128 Chapter 11. Network discovery

Accept node if it has NetXMS If checked, only nodes with NetXMS agent detected will pass the filter.
agent
Accept node if it has SNMP If checked, only nodes with SNMP agent detected will pass the filter.
agent
Accept node if it is within given Only accept nodes within given address range or subnet. Address ranges can be
range or subnet configured in Address Filters section.
Please note that first two options (NetXMS agent presence and SNMP agent presence) forms OR condition - if both
are checked, any node with either SNMP agent or NetXMS agent will pass. Address range check and first two options
forms AND condition - so if potential node does pass agent presence check, but is not in allowed IP address range,
it will not be accepted. In other words, if all three options are checked, condition for new node to pass filter can be
written as following:
if (node has NetXMS agent or node has SNMP agent) and node within given range then pass
11.2.4 Active Discovery Targets
In this section, you can define address ranges for active discovery. NetXMS server will periodically send ICMP echo
requests to these addresses, and consider for addition to database every responding device. This list has no effect if
active discovery is off.
11.2.5 Address Filters
In this section you can define address ranges for automatically generated discovery filter. This list has no effect if
discovery is off or filter is not set to Automatically generated script.
11.2. Configuring Network Discovery 129

130 Chapter 11. Network discovery

CHAPTER
TWELVE
DATA COLLECTION
12.1 How data collection works
Every node can have many data collection items configured (see Data Collection for detailed description). NetXMS
server has a set of threads dedicated to data collection, called Data Collectors, used to gather information from the
nodes according to DCI configuration. You can control how many data collectors will run simultaneously, by changing
server configuration parameter NumberOfDataCollectors.
All configured DCIs are checked for polling requirement every second and if DCI needs to be polled, appropriate
polling request is placed into internal data polling queue. First available data collector will pick up the request and
gather information from the node according to DCI configuration. If a new value was received successfully, it’s being
stored in the database, and thresholds are checked. After threshold checking, data collector is ready for processing
new request. Processing of a newly received parameter value is outlined on the figure below.
Fig. 1: Newly received parameter processing
It is also possibility to push data to server. If DCI source is set to Push, server just waits for new values instead of
polling from a data source.
New in version 2.0-M5: Agent caching mode
By default DCI data is not collected for the time being while connection between server and agent is broken as poll
request could not get till agent. There is special configuration that allows to collect data and store it on agent till
connection with server is restored and collected data is pushed to the server. This option is available for metrics, table
metrics and proxy SNMP metrics. Not implemented for proxy SNMP table metrics and DCIs with custom schedule.
In case of this configuration agent stores DCI configuration locally and does all metric collection and dispatch on
its own. DCI configuration is synchronized on connect, DCI configuration change or SNMP proxy server change.
Information about configuration options can be found here: Agent caching mode.
131
12.2 DCI configuration
Data collection for a node can be configured using management console. To open data collection configuration win-
dow, right-click on node object in Object Browser or on a Network Map, and click Data Collection Configuration.
You will see the list of configured data collection items. From here, you can add new or change existing parameters to
monitor. Right click on the item will open pop-up menu with all possible actions.
Each DCI have multiple attributes which affects the way data is collected. Detailed information about each attribute is
given below.
12.2.1 General
Fig. 2: DCI configuration general property page
Description
Description is a free-form text string describing DCI. It is not used by the server and is intended for better information
understanding by operators. If you use the Select button to choose a parameter from the list, description field will be
filled automatically.
132 Chapter 12. Data collection

Parameter
Name of the parameter of interest, used for making a request to target node. For NetXMS agent and internal parameters
it will be parameter name, and for SNMP agent it will be an SNMP OID. You can use the Select button for easier
selection of required parameter name.
Available agent parameter names are obtained during Configuration poll.
Origin
Origin of data (method of obtaining data). Possible origins are:
Source Description
Internal Data generated inside NetXMS server process (server statistics, etc.)
NetXMS Agent Data is collected from NetXMS agent, which should be installed on target node.
Server collect data from agent based on schedule.
SNMP SNMP transport will be used. Server collect data based on schedule.
Web service Data is objained from JSON, XML, or plain text retrieved via HTTP
Push Values are pushed by external system (using nxpush or API) or from NXSL
script.
Windows Performance counters Data is collected via NetXMS agent running on Windows machine.
Script Value is generated by NXSL script. Script should be stored in Script Library.
SSH Data is obtained from output of ssh command executed through SSH connec-
tion.
MQTT Data is obtained by subcribing to MQTT broker topics.
Network Device Driver Some SNMP drivers (NET-SNMP, RITTAL as of NetXMS v. 3.8) provide pa-
rameters for data collection. E.g. NET-SNMP provides information about stor-
age this way.
Push Agent origin is different from all others, because it represents DCIs whose values are pushed to server by exter-
nal program (usually via nxapush or nxpush command line tool) instead of being polled by the server based on the
schedule. Values can also be pushed from a NXSL script launced on the server.
Data Type
Data type for the parameter. Can be one of the following: Integer, Unsigned Integer, 64-bit Integer, 64-bit Unsigned
Integer, Float (floating point number), or String. Selected data type affects collected data processing - for example,
you cannot use operations like less than or greater than on strings. If you select parameter from the list
using the Select button, correct data type will be set automatically.
Source node
Source node of metrics collection. This can be used when other node provides information about this node. In this
way collected data can be collected and shown on right nodes.
Other example of usage is virtual nodes (nodes with IP 0.0.0.0). In this case node state can be obtained from the DCI
created on this node but collected from the other one.
Data is collected from the same node if no value set.
12.2. DCI configuration 133

Polling
Polling mode and interval describe schedule type and interval between consecutive polls, in seconds. However, col-
lecting too many values for too long will lead to significant increase of your database size and possible performance
degradation.
Can be selected one of options:
• Fixed intervals (default) - default value will be taken from DefaultDCIPollingInterval server configuration pa-
rameter.
• Fixed intervals (custom) - value entered on the DCI properties page will be taken.
• Use advanced scheduling - schedules configured in Advanced Schedule page will be used
Storage
This attribute specifies how long the collected data should be kept in database, in days. Minimum retention time is
1 day and maximum is not limited. However, keeping too many collected values for too long will lead to significant
increase of your database size and possible performance degradation.
Possible options:
• Use default retention time - default value will be taken from DefaultDCIRetentionTime server configuration
parameter.
• Use default retention time - value entered on the DCI properties page will be taken.
• Do not save collected data to database - will not save collected data to database, but will store last value in
memory
Last option is used when it is required to show latest (every 1 second collected) data on Dashboard, but it is too much
data to store in database. So 2 DCI configurations are created. One to store historical data collected once per minute
and the second one, that is not stored in database, but is collected every second and up to date displayed on dashboards.
Status
DCI status can be one of the following: Active, Disabled, Not Supported. Server will collect data only if the status is
Active. If you wish to stop data collection without removing DCI configuration and collected data, the Disabled status
can be set manually. If requested parameter is not supported by target node, the Not Supported status is set by the
server.
12.2.2 Advanced Schedule
If you turn on this flag, NetXMS server will use custom schedule for collecting DCI values instead of fixed intervals.
This schedule can be configured on the Schedule page. Advanced schedule consists of one or more records; each
representing desired data collection time in cron-style format.
See Cron format for supported cron format options.
For DCI Collection schedule it’s possible to specify optional sixth cron field for resolution in seconds. It’s not rec-
ommended to use seconds in custom schedules as your main data collection strategy though. Use seconds only if it is
absolutely necessary.

12.2.3 Cluster
This section is available only for DCI’s collected on cluster.
Fig. 3: DCI configuration cluster property page
Associate with cluster resource
In this field you can specify cluster resource associated with DCI. Data collection and processing will occur only if
node you configured DCI for is current owner of this resource. This field is valid only for cluster member nodes.
Data aggregation
This section is responsible for cluster data aggregation way. Aggregate values from cluster nodes option means, that
DCI from cluster will be collected on each node separately and aggregated on cluster using one of the aggregation
options.
Aggregation options:
• Total
• Average
• Min
• Max

12.2.4 Data Transformations
In simplest case, NetXMS server collects values of specified parameters and stores them in the database. However,
you can also specify various transformations for original value. For example, you may be interested in a delta value,
not in a raw value of some parameter. Or, you may want to have parameter value converted from bytes to kilobytes.
All transformations will take place after receiving new value and before threshold processing.
Data transformation consists of two steps. On the first step, delta calculation is performed. You can choose four types
of delta calculation:
Function Description
None No delta calculation performed. This is the default setting for newly created DCI.
Simple Resulting value will be calculated as a difference between current raw value and previous raw value.
By raw value is meant the parameter value originally received from host.
Average Resulting value will be calculated as a difference between current raw value and previous raw value,
per second divided by number of seconds passed between current and previous polls.
Average Resulting value will be calculated as a difference between current raw value and previous raw value,
per minute divided by number of minutes passed between current and previous polls.
On the second step, custom transformation script is executed (if presented). By default, newly created DCI does not
have a transformation script. If transformation script is presented, the resulting value of the first step is passed to
the transformation script as a parameter; and a result of script execution is a final DCI value. Transformation script
gets original value as first argument (available via special variable $1), and also has two predefined global variables:
$node (reference to current node object), and $dci (reference to current DCI object).
In case of table DCIs, $1 special variable is an object of type Table.
For more information about NetXMS scripting language, please consult Scripting chapter in this manual.
Transformation script can be tested in the same view, by clicking Test. . . and entering test input data.
Fig. 4: DCI configuration transformation property page

12.2.5 Thresholds
For every DCI you can define one or more thresholds. Each threshold there is a pair of condition and event - if
condition becomes true, associated event is generated. To configure thresholds, open the data collection editor for
node or template. You can add, modify and delete thresholds using buttons below the threshold list. If you need
to change the threshold order, select one threshold and use arrow buttons located on the right to move the selected
threshold up or down.
Fig. 5: DCI configuration threshold property page

Threshold Processing
Fig. 6: Threshold processing algorithm
As you can see from this flowchart, threshold order is very important. Let’s consider the following example: you
have DCI representing CPU utilization on the node, and you wish two different events to be generated - one when
CPU utilization exceeds 50%, and another one when it exceeds 90%. What happens when you place threshold > 50
first, and > 90 second? The following table shows values received from host and actions taken by monitoring system
(assuming that all thresholds initially unarmed):
Value Action
10 Nothing will happen.
55 When checking first threshold (> 50), the system will find that it’s not active, but condition evaluates to
true. So, the system will set threshold state to “active” and generate event associated with it.
70 When checking first threshold (> 50), the system will find that it’s already active, and condition evaluates
to true. So, the system will stop threshold checking and will not take any actions.
95 When checking first threshold (> 50), the system will find that it’s already active, and condition evaluates
to true. So, the system will stop threshold checking and will not take any actions.
Please note that second threshold actually is not working, because it’s masked by the first threshold. To achieve desired
results, you should place threshold > 90 first, and threshold > 50 second.
You can disable threshold ordering by checking Always process all thresholds checkbox. If it is marked, system will
always process all thresholds.

Threshold Configuration
When adding or modifying a threshold, you will see the following dialog:
First, you have to select what value will be checked:
Last Last value will be used. If number of polls set to more then 1, then condition will evaluate to true only
polled if it’s true for each individual value of last N polls.
value
Average An average value for last N polls will be used (you have to configure a desired number of polls).
value
Mean de- A mean absolute deviation for last N polls will be used (you have to configure a desired number of
viation polls). Additional information on how mean absolute deviation calculated can be found here.
Diff with A delta between last and previous values will be used. If DCI data type is string, system will use 0, if
previous last and previous values match; and 1, if they don’t.
value
Data col- An indicator of data collection error. Instead of DCI’s value, system will use 0 if data collection was
lection successful, and 1 if there was a data collection error. You can use this type of thresholds to catch
error situations when DCI’s value cannot be retrieved from agent.
Second, you have to select comparison function. Please note that not all functions can be used for all data types. Below
is a compatibility table:
Type/Function Integer Unsigned Integer Int64 Unsigned Int64 Float String

Less X X X X X X
Less or equal X X X X X X
Equal X X X X X X X
Greater or equal X X X X X X
Greater X X X X X X
Not equal X X X X X X X
Like X
Not like X
Third, you have to set a value to check against. If you use like or not like functions, value is a pattern string

where you can use meta characters: asterisk (*), which means “any number of any characters”, and question mark (?),
which means “any character”.
Fourth, you have to select events to be generated when the condition becomes true or returns to false. By default,
system uses SYS_THRESHOLD_REACHED and SYS_THRESHOLD_REARMED events, but in most cases you will
change it to your custom events.
You can also configure threshold to resend activation event if threshold’s condition remain true for specific period of
time. You have three options - default, which will use server-wide settings, never, which will disable resending of
events, or specify interval in seconds between repeated events.
Thresholds and Events
You can choose any event to be generated when threshold becomes active or returns to inactive state. However, you
should avoid using predefined system events (their names usually start with SYS_ or SNMP_). For example, you
set event SYS_NODE_CRITICAL to be generated when CPU utilization exceeds 80%. System will generate this
event, but it will also generate the same event when node status will change to ::guilabel::CRITICAL. In your event
processing configuration, you will be unable to determine actual reason for that event generation, and probably will
get some unexpected results. If you need custom processing for specific threshold, you should create your own event
first, and use this event in the threshold configuration. NetXMS has some preconfigured events that are intended to be
used with thresholds. Their names start with DC_.
The system will pass the following seven parameters to all events generated as a reaction to threshold violation:
1. Parameter name (DCI’s name attribute)
2. DCI description
3. Threshold value
4. Actual value
5. Unique DCI identifier
6. Instance (DCI’s instance attribute)
7. Repeat flag
And those on table threshold violation:
1. Table DCI name
2. Table DCI description
3. Table DCI ID
4. Table row
5. Instance
For example, if you are creating a custom event that is intended to be generated when file system is low on free space,
and wish to include file system name, actual free space, and threshold’s value into event’s message text, you can use
message template like this:
File system %6 has only %4 bytes of free space (threshold: %3 bytes)
For events generated on threshold’s return to inactive state (default event is SYS_THRESHOLD_REARMED), parameter
list is different:
1. Parameter name (DCI’s name attribute)
2. DCI description
3. Unique DCI identifier

4. Instance (DCI’s instance attribute)

5. Threshold value
6. Actual value
And those on table threshold rearm:
1. Table DCI name
2. Table DCI description
3. Table DCI ID
4. Table row
5. Instance
12.2.6 Instance
Each DCI has an Instance attribute, which is a free-form text string, passed as a 6th parameter to events associated
with thresholds. You can use this parameter to distinguish between similar events related to different instances of the
same entity. For example, if you have an event generated when file system was low on free space, you can set the
Instance attribute to file system mount point.
Sometimes you may need to monitor multiple instances of some entity, with exact names and number of instances not
known or different from node to node. Typical example is file systems or network interfaces. To automate creation of
DCIs for each instance you can use instance discovery mechanism. First you have to create “master” DCI. Create DCI
as usual, but in places where normally you would put instance name, use the special macro {instance}. Then, go to
Instance Discovery tab in DCI properties, and configure instance discovery method and optionally filter script.
Instance discovery creates 2 macros for substitution:
• {instance} - instance name
• {instance-name} - instance user readable description

Fig. 7: DCI configuration instance discovery property page

Discovery Methods
The following instance discovery methods are available:
Method Input Description

Data
Agent List List Read list from agent and use it’s values as instance names.
name
Agent Table Table Read table from agent and use it’s instance column values as instance names. If there are
name several instance columns in that table, a concatenation of values will be used, separated by
~~~ (three tilda characters).
SNMP Base Do SNMP walk starting from given OID and use values of returned varbinds as instance
Walk - OID names.
Values
SNMP Base Do SNMP walk starting from given OID and use IDs of returned varbinds as instance
Walk - OID names.
OIDs
Script Script Instance names are provided by script from script library. The script should return an array
name of instance names.
Windows Path Each sub-element of given path will be considered as separate instance.
Perfor-
mance
Counters
Web Ser- Def- Web service request field contains web service definition name with optional arguments and
vice ini- path to the root element of the document where enumeration will start. Each sub-element
tion:pathof given root element will be considered separate instance.
Internal Ta- Table Read NetXMS server internal table and use it’s instance column values as instance names.
ble name If there are several instance columns in that table, a concatenation of values will be used,
separated by ~~~ (three tilda characters).
Instance Filter
You can optionally filter out unneeded instances and transform instance names using filtering script written in NXSL.
Script will be called for each instance and can return either a binary value or an array.
If binary value is returned, it has the following meaning: TRUE (to accept instance), FALSE (to reject instance).
If an array is returned, only first element of the array is obligatory, the rest elements are optional (but to include an
element, all preceding elements should be included). Array structure:
Data type Description

Boolean TRUE (accept instance), FALSE (reject instance).
String Instance name, that will be available as {instance} macro.
String Instance user-readable description, that will be available as {instance-name} macro
NetObj New in version 3.0.0: Object connected with this DCI

12.2.7 Performance tab
Main information about node(Object Details) can be supplemented with DCI information displayed as text(last value)
on Object Details-> Overview page or in graph way on Object Details->:guilabel:Performance tab.
DCI representation in text way can be configured on Other options. Next will be described only graph DCI represen-
tation configuration on Performance tab of Object Details.
Multiple DCIs can be grouped in one graph. To group them use the same group name in “Group” field.
Fig. 8: DCI configuration instance discovery property page

12.2.8 Access Control
This page provides access control management option to each DCI. If no user set, then access rights are inherited from
node. So any user that is able to read node is able to see last value of this DCI and user that is able to modify node
is able to change and see DCI configuration. When list is not empty, then both access to node and access to DCI are
check on DCI configuration or value request.
Fig. 9: DCI configuration access control property page
12.2.9 Other options
Other available options:

• Show last value in object tooltip - shows DCI last value on tooltip that is shown on network maps.
• Show last value in object overview - shows DCI last value on Object Details->Overview page.
• Use this DCI for node status calculation - Uses value returned by this DCI as a status, that participate in object
status calculation. Such kind of DCI should return integer number from 0 till 4 representing object status.
• Related object - object that is related to collected DCI. Related object can be set by instance discovery filter
script by using Instance() function and accessed in NXSL from DCI object.

Fig. 10: DCI configuration other option property page
12.2.10 Comments
This configuration part can be used for free for text comments. To make additional notes about DCI configuration or
usage.
12.3 Push parameters
NetXMS gives you ability to push DCI values when you need it instead of polling them on specific time intervals. To
be able to push data to the server, you should take the following steps:
1. Set your DCI’s origin to Push Agent and configure other properties as usual, excluding polling interval which is
meaningless in case of pushed data.
2. Create separate user account or pick an existing one and give “Push Data” access right on the DCI owning node
to that user.
3. Use nxapush or nxpush utility or client API for pushing data.

12.4 DCI types
12.4.1 List DCIs
Usually DCIs have scalar values. A list DCI is a special DCI which returns a list of values. List DCIs are mostly
used by NetXMS internally (to get the list of network interfaces during the configuration poll, for example) but can
also be utilized by user in some occasions. NetXMS Management Console does not support list DCIs directly but
their names are used as input parameters for Instance Discovery methods. List DCI values can be also obtained with
nxget command line utility (e.g. for use in scripts).
12.5 Agent caching mode
Agent caching mode allows metric data to be obtained for the time being while connection between server and agent
have been broken. This option is available for metrics, table metrics and proxy SNMP metrics. Not implemented for
proxy SNMP table metrics and DCIs with custom schedule. In the absence of connection to the server collected data
is stored on agent, when connection is restored it is sent to server. Detailed description can be found there: How data
collection works.
Agent side cache is configurable globally, on node level, and on DCI level. By default it’s off.
All collected data goes thought all transformations and thresholds only when it comes to server. To prevent generation
of old events it can be set OffileDataRelivanceTime configuration variable to time period in seconds within which
received offline data still relevant for threshold validation. By default it is set to 1 day.
New in version 2.0-M5: Agent caching mode.
12.5.1 Configuration
It can be configured:
• globally - set configuration parameter DefaultAgentCacheMode to on or off.
• on node level - Agent cache mode can be changed to on, off or default (use global settings) in node
properties on Polling page
• on DCI level - Agent cache mode can be changed to on, off or default (use node level settings) in DCI
properties on General page
12.6 Last DCI values View
Last values view provides information about all data collected on a node: DCI last value, last collection timestamp
and threshold status.
It is possible to check last values or raw last values in textual format or as a chart by right clicking on DCI and selecting
corresponding display format.
12.4. DCI types 147

12.7 Templates
12.7.1 What is template
Often you have a situation when you need to collect same parameters from different nodes. Such configuration
making may easily fall into repeating one action many times. Things may became even worse when you need to
change something in already configured DCIs on all nodes - for example, increase threshold for CPU utilization. To
avoid these problems, you can use data collection templates. Data collection template (or just template for short) is a
special object, which can have configured DCIs similar to nodes.
When you create template and configure DCIs for it, nothing happens - no data collection will occur. Then, you can
apply this template to one or multiple nodes - and as soon as you do this, all DCIs configured in the template object will
appear in the target node objects, and server will start data collection for these DCIs. If you then change something in
the template data collection settings - add new DCI, change DCI’s configuration, or remove DCI - all changes will be

reflected immediately in all nodes associated with the template. You can also choose to remove template from a node.
In this case, you will have two options to deal with DCIs configured on the node through the template - remove all
such DCIs or leave them, but remove relation to the template. If you delete template object itself, all DCIs created on
nodes from this template will be deleted as well.
Please note that you can apply an unlimited number of templates to a node - so you can create individual templates for
each group of parameters (for example, generic performance parameters, MySQL parameters, network counters, etc.)
and combine them, as you need.
12.7.2 Creating template
To create a template, right-click on Template Root or Template Group object in the Object Browser, and click Create
→ Template. Enter a name for a new template and click OK.
12.7.3 Configuring templates
To configure DCIs in the template, right-click on Template object in the Object Browser, and select Data Collection
from the pop-up menu. Data collection editor window will open. Now you can configure DCIs in the same way as the
node objects.
12.7.4 Applying template to node
To apply a template to one or more nodes, right-click on template object in Object Browser and select Apply from
pop-up menu. Node selection dialog will open. Select the nodes that you wish to apply template to, and click OK (you
can select multiple nodes in the list by holding Control key). Please note that if data collection editor is open for
any of the target nodes, either by you or another administrator, template applying will be delayed until data collection
editor for that node will be closed.
12.7.5 Removing template from node
To remove a link between template and node, right-click on Template object in the Object Browser and select Unbind
from pop-up menu. Node selection dialog will open. Select one or more nodes you wish to unbind from template, and
click OK. The system will ask you how to deal with DCIs configured on node and associated with template:
If you select Unbind DCIs from template, all DCIs related to template will remain configured on a node, but association
between the DCIs and template will be removed. Any further changes to the template will not be reflected in these
DCIs. If you later reapply the template to the node, you will have two copies of each DCI - one standalone (remaining
from unbind operation) and one related to template (from new apply operation). Selecting Remove DCIs from node
will remove all DCIs associated with the template. After you click OK, node will be unbound from template.
12.7. Templates 149

12.7.6 Macros in template items
You can use various macros in name, description, and instance fields of template DCI. These macros will be expanded
when template applies to node. Macro started with %{ character combination and ends with } character. The following
macros are currently available:
Macro Expands to
node_id Node unique id
node_name Node name
node_primary_ip Node primary IP address
script:name String returned by script name. Script should be stored in script library
(accessible via Configuration → Script Library). Inside the script, you
can access current node’s properties via $node variable.
For example, if you wish to insert node’s IP address into DCI description, you can enter the following in the description
field of template DCI:
My IP address is %{node_primary_ip}
When applying to node with primary IP address 10.0.0.1, on the node will be created DCI with the following descrip-
tion:
My IP address is 10.0.0.1
Please note that if you change something in the node, name for example, these changes will not be reflected automati-
cally in DCI texts generated from macros. However, they will be updated if you reapply template to the node.
12.8 Working with collected data
Once you setup DCI, data starts collecting in the database. You can access this data and work with it in different ways.
Data can be visualized in three ways: in graphical form, as a historical view(textual format) and as DCI summary
table, this layout types can be combined in Dashboards. More detailed description about visualization and layout can
be found there: Data and Network visualisation.

CHAPTER
THIRTEEN
EVENT PROCESSING
13.1 Introduction
NetXMS is event based monitoring system. Events can come from different sources (polling processes (status, con-
figuration, discovery, and data collection), SNMP traps, from NXSL scripts and directly from external applications via
client library). All events all are forwarded to NetXMS Event Queue.
NetXMS Event Processor can process events from Event Queue in either sequential or parallel mode. In sequential
mode events are processed one-by-one which guarantees that events will be processed in the same sequence as they
arrive onto NetXMS server. For installation where a lot of events could be generated in a short period of time this
mode can be a bottleneck.
Parallel processing mode allows to process events in several parallel threads, thus allowing to scale horizontally and to
increase processing performance. Number of threads for parallel processing is set by Events.Processor.PoolSize server
configuration parameter.
Event Processing Rules can read/write persistent storage and custom attributes, create/terminate alarms, can run scripts
that are checking other node statuses and care should be taken to ensure that no race condition would occur when
performing parallel processing.
Correct operation is ensured by properly setting Events.Processor.QueueSelector server configuration parameter. This
parameter contains macros that are expanded when an event is created. Events that have same QueueSelector string
will be processed sequentially by one and the same event processing thread, thus ensuring that there will be no race
condition between these events.
13.2 Event Processing Policy
Actions taken by event processor for any specific event are determined by a set of rules called Event Processing Policy
(EPP).
Every rule has two parts - matching part (called Condition in the rule configuration dialog), which determines if the
rule is applicable to an event, and action part, which defines actions to be taken for matched events.
Each event passes through all rules in the policy, so if it matches more than one rule, actions specified in all matched
rules will be executed. You can change this behavior by setting Stop Processing flag on a rule. If this flag is set for a
rule and that rule is matched, subsequent rules (with higher rule number) will not be processed.
Event Processing Policy rules are managed using Event Processing Policy Editor. To access the Event Processing
Policy Editor window, press F4 or select Tools → Event Processing Policy menu.
Only one user of NetXMS server can access Event Processing Policy Editor window at a time. Other users will receive
Component locked error message when attempting to open this window.
Changes made in Event Processing Policy Editor are applied at the moment when Save button is clicked.
151
Fig. 1: Event Processing Policy Screen
To expand or collapse a rule, double click on its title or use Expand/collapse button on the right hand side of rule
title.
Event Processing Policy Editor window toolbar buttons have the following meaning (from left to right): Add new rule,
Save changes, Expand all, Collapse all, Horizontal layout, Vertical layout, Cut rule, Copy rule, Paste rule, Delete rule.
To create event policy rule, right click on entry before or after which new Event Processing Policy should appear and
select Insert before or Insert after. Drag and drop can be used for rule reorganization.
Fig. 2: Event Processing Policy item context menu
To edit Event Processing Policy’s properties, click edit button in right corner of an entry, or double-click text in Filter
or Action text.
152 Chapter 13. Event processing

Fig. 3: Edit buttons
Properties of Event Processing Policy rule have the following sections:
Section Description
Condition Sub-sections of Condition section determine, if the rule is applicable to a par-
ticular event. If checkbox Rule is disabled is set, this rule is ignored.
Condition –> Source Objects One or more event’s source objects. This list can be left empty, which matches
any object, or contain nodes, subnets, containers, clusters, etc. . . If you spec-
ify subnet, container, cluster, rack or chassis, any object within it will also be
matched.
Condition –> Events Event code. This field can be left empty, which matches any event, or contain
list of applicable events.
Condition –> Severity Filter Event’s severity. This field contains selection of event severities to be matched.
Condition –> Filtering Script Optional matching script written in NXSL. If this field is empty (or only
contains comments according to NXSL language specification), no additional
checks are performed. Otherwise, the event will be considered as matched only
if the script returns boolean true (or other value that is considered true in
NXSL language, e.g. non-zero number or array). For more information about
NetXMS scripting language please refer to the chapter Scripting in this manual.
Action Sub-sections of Action section determine what actions are performed if an event
meets all conditions of a rule. If checkbox Stop event processing is set, then
subsequent rules (with higher rule number) will not be processed for a given
event. However, actions of given rule will be performed.
Action –> Alarm Action in regard to alarms. Alarm can be created, resolved or terminated or no
action to alarms is done. See Generating and Terminating Alarms from EPP for
more information.
Action –> Persistent Storage NXLS Persistent Storage action like add/update or delete can be performed.
Action –> Server Actions List of predefined actions to be executed. Action execution could be delayed
with ability to cancel a delayed action later on. Execution of action could be
snoozed for a specified period of time. For action configuration refer to Actions
chapter. Delayed execution and snoozing is controlled using timers which can
be referred to using timer key. This allows cancelling a timer or checking, if its
still running from NXSL script.
Action –> Timer Cancellations List of timers to cancel identified by timer keys. This allows to cancel delayed
actions and snooze/blocking timers.
Comments Rule comment which can be multi-line text. The comment is displayed as a
name of the rule.
After all manipulations are done - save changes by pressing save icon.
13.2. Event Processing Policy 153

13.2.1 Examples
This rule defines that for every major or critical event originated from a node named “IPSO” two e-mail actions will
be executed.
Fig. 4: Example 1
13.3 Events
13.4 Alarms
13.4.1 Alarms Overview
As a result of event processing some events can be shown up as alarms. Usually alarm represents something that needs
attention of network administrators or network control center operators, for example low free disk space on a server.
All alarm events are logged to alarm log. The number of days the server keeps alarm history can be config-
ured by “AlarmHistoryRetentionTime” server configuration parameter. Alarm log can be viewed in “Alarm Log
View”(Alt+F8). This view gives option to query for required information from alarm log.

Every alarm has the following attributes:
Attribute Description
Creation time Time when alarm was created.
Last change time Time when alarm was last changed (for example, acknowledged).
State Current state of the alarm, see table bellow
Message Message text (usually derived from originating event’s message text).
Severity Alarm’s severity - Normal, Warning, Minor, Major, or Critical.
Source Source node (derived from originating event).
Key Text string used to identify duplicate alarms and for automatic alarm termination.
Possible alarm states:
13.4. Alarms 155

Outstanding New alarm.

Acknowledged When network administrator sees an alarm, he may acknowledge it to indicate that
somebody already aware of that problem and working on it. A new event with the
same alarm ID will reset the alarm state back to outstanding
Sticky Acknowledged for Alarm will remain acknowledged for given time interval even after new matching
time events, after time will pass alarm will be moved to outstanding state. This option
can be used like snooze. When you know that there will be new matching events,
but it will not change the situation. But after some time someone should check this
problem. For example, if you have problem that cannot be solved until next week, so
this alarm can be sticky acknowledged for 7 days. After 7 days this problem again
will be in outstanding state. This type of acknowledge can be disabled by changing
EnableTimedAlarmAck server configuration parameter.
Sticky Acknowledged Alarm will remain acknowledged event after new matching events. This can be useful
when you know that there will be new matching events, but it will not change the situ-
ation. For example, if you have network device which will send new SNMP trap every
minute until problem solved, sticky acknowledge will help to eliminate unnecessary
outstanding alarms.
Resolved Network administrator sets this state when the problem is solved.
Terminated Inactive alarm. When problem is solved, network administrator can terminate alarm.
This will remove alarm from active alarms list and it will not be seen in console, but
alarm record will remain in database.
There are 2 types of alarm state flows: strict and not strict. This option can be configured in Preference page of Alarms
or on server configuration page, parameter “StrictAlarmStatusFlow”. The difference between them is that in strict
mode Terminate can be done only after Resolve state.
Fig. 5: Not strict(default)

Fig. 6: Strict
13.4.2 Alarm Melodies
On each severity of alarm can be set melody to play. This melody will be played when new alarm in state outstanding
will occur. Melody that should be played should exist on server in wav format. See instruction there: Upload file on
server. By default there are no sounds on alarms.
To set sound open preferences, there select Alarms → Alarm Sounds tab. There in drop-down will be seen all possible
options. If sound will not be chosen, alarm with this severity will come silently.
To configure sounds, open preferences and select Alarms → Alarm Sounds tab. Drop-downs next to each severity level
have a list of available sounds. If no sound is chosen, alarm for given severity will come silently.
13.4. Alarms 157

13.4.3 Alarm Browser
When an alarm is generated it will appear in the Alarm Browser where information about currently active alarms can
be viewed.

Alarm Comments
For each alarm can be created comments in “Alarm Details”
or “Alarm Comments” views.
Comment can be created, edited or deleted. All comments will be deleted after alarm termination.
13.4. Alarms 159

Alarm Summary Emails
It is possible to schedule emails which contain a summary of all currently active alarms, similar to what can be seen
in the Alarm Browser.
To enable Alarm Summary Emails it is required to configure the following server parameters:
Name
SMTPFromAddr
SMTPFromName
SMTPPort
SMTPRetryCount
SMTPServer
EnableAlarmSummaryEmails
AlarmSummaryEmailSchedule
AlarmSummaryEmailRecipients
Further information on server configuration parameters can be found in Server configuration parameters.
13.4.4 Generating and Terminating Alarms from EPP
To generate alarms from events, you should edit Alarm field in appropriate rule of Event Processing Policy. Alarm
configuration dialog will look like this:
You should select Generate new alarm radio button to enable alarm generation from current rule. In the Message field
enter alarm’s text, and in the alarm key enter value which will be used for repeated alarms detection and automatic
alarm termination. In both fields you can use macros described in the Macros for Event Processing section.

You can also configure sending of additional event if alarm will stay in Outstanding state for given period of time.
To enable this, enter desired number of seconds in Seconds field, and select event to be sent. Entering value of 0 for
seconds will disable additional event sending.
Alarms generated by rules can by categorised to limit what alarms can be seen by what users. This can be done
by applying a category in the Alarm Category field, which can be created and configured in the Alarm Category
Configurator.
13.4.5 Alarm Category Configurator
Alarm categories can be created and configured in the Alarm Category Configurator which can be found in Configu-
ration → Alarm Category Configurator menu:
Fig. 7: Alarm Category Configurator
Alarm categories provide the possibility to configure access rights for viewing generated alarms on a per user or per
group basis. When creating an alarm category, it is possible to set the Category name, Description.
13.4. Alarms 161

Fig. 8: Alarm Category properties
Alarm category access rights can be configured by adding users or groups to the access list of the category in the
Access Control property page.

Fig. 9: Alarm Category Access Control
By default, all alarms can be viewed by all users due to the View all alarms system right being set as default to the
Everyone user group. In order to limit the viewing of alarms, this system right should be removed and the access
rights configured in the categories themselves. When the categories have been configured, they can be applied to the
necessary Event Processing Policy rules.
If an alarm category has been applied to an Event Processing Policy rule, it will appear in the Event Processing Policy
Editor when a rule is expanded under the Action section.
13.4. Alarms 163

Fig. 10: Event Processing Policy expanded
13.4.6 Automatic Alarm Termination/Resolve
You can terminate or resolve all active alarms with given key as a reaction for the event. To do this, select Terminate
alarm radio button or Resolve alarm radio button in alarm configuration dialog and enter value for alarm key. For that
field you can use macros described in the Macros for Event Processing chapter.
13.4.7 Escalation
As it was described in Generating and Terminating Alarms from EPP chapter there is possibility to generate new event
if alarm stay in Outstanding state for too long. Escalation is built on this option. When alarm was generated, but
no action was done from operator in predefined time, new event can be generated and this time email or notification
(SMS, instant message) can be sent to operator or to it’s manager. This escalation process can have as many steps as
it is required.
13.5 Actions
In addition to alarm generation server can perform various types of actions as a reaction to an event. Action types
available in NetXMS are described in the following sections. Each action can be separately disabled in action config-
uration.
After the action is added, it can be edited to add delay time and timer key. This option can be used to prevent
notification sending in case if problem solved quickly enough. Key is a free form string that support macro and delay
is the delay time in seconds before action is executed.
The next example shows the configuration for the situation when there is no need to notify anyone if node went down
and back up in just a minute.

13.5.1 Escalation
One EPP rule can contain multiple actions with different delays. Delay timers are canceled by other rule in case of
problem resolution.
The next example shows that if node went down, then
1. after 1 minute responsible person will be notified if the problem still persists
2. after 30 minutes the support manager will be notified if the problem still persists
3. after 1 hour the IT manager will be notified if the problem still persists
13.5.2 Action types
Execute command on management server
Executes provided command on server node. Check that user under which netxmsd process run has permission to
run this command.
Execute command on remote node
Executes provided command name defined in this nodes agent configuration file. To this command can be given
parameters in format: commandName param1 param2 param3... Check that user under which nxagentd
process run has permission to run this command.
As the Remote Host can be used hostname or object name(int format: @objectName). Second option allows action
execution on node behind proxy.
13.5. Actions 165

Send e-mail
Send email to one or more recipients. Multiple recipients can be separated by semicolons. Required server config-
uration parameters to send emails: SMTPFromAddr, SMTPFromName, SMTPRetryCount, SMTPServer. For
detailed description of parameters check Server configuration parameters.
In message text can be used Macros for Event Processing.
Send notification
Send notification, e.g. SMS, to one or more recipients. Multiple recipients can be separated by semicolons. Server
will use Notification channels for actual message sending.
Send XMPP message
Sends XMPP/Jabber message to one or more recipients. Multiple recipients can be separated by semicolons. Required
server configuration parameters to send XMPP message: XMPPLogin, XMPPPassword, XMPPPort, XMPPServer,
EnableXMPPConnector. For detailed description of parameters check Server configuration parameters.
Execute NXSL script
This action executes script form scrip library. In action configuration should be defined name of script. Information
about scripting and library can be found there.
Forward event
NetXMS does not support configuration synchronization between two NetXMS servers(Distributed Monitoring). But
it is possible to forward events from one server to another. This option allow synchronize events between servers but
there are some limitation.
Configuration
Source server configuration:

1. Create new action of type “forward event” - it will have destination server address property.
2. Create a rule in event processing policy with filter for events you want to forward and add forwarding
action as action.
Destination server configuration:
1. Enable EnableISCListener and ReceiveForwardedEvents in server configuration.
2. Open port 4702.
3. Check that receiving server have all events as on a sending server

Limitation
Limitations of event forwarding:

1. Event template with same event code or event name must exist on recipient server
2. Node object with same IP address as event’s source node’s address must exist on recipient server
3. Does not work with zones
Events not met these conditions are discarded. It is possible to check if and why incoming events are discarded by
turning on level 5 debug on receiving server.
There can be used one of two options if it is required to disable polling of sender server nodes on recipient server:
disable all polling protocols or unmanage nodes. Chose depends on how you wish to see node’s status. For unmanaged
node, it always be “unmanaged”, regardless of active alarms. If you disable polling, node’s status will be “unknown”
unless there will be active alarms for that node - in that case node’s status will change to severity of most critical alarm.
13.5.3 Notification channels

NetXMS supports concept of notification channel drivers to provide SMS and instant message sending functionality.
Role of notification channel driver is to provide level of abstraction on top of different notification sending mechanisms
and uniform notification sending interface for server core. It is possible to set up and use several notification channels.
Configuration of notification channels is done in Configuration → Notification channels.
Notification channel driver parameters are specified in Driver configuration input field. Each parameter is given on a
separate line in format: parameter_name=parameter_value. Meaning of parameters is driver dependent and described
separately for each driver. It a parameter is not given, it’s default value will be used.
Once notification channel is created is is seen in channel list with green or read square next to the name - it is channel
status identifier. It should be green if driver initialization was successful or read in other cases. Status column displays
13.5. Actions 167

last sent attempt status and Error message column provide more information about driver initialization or sending
error.
Drivers
The following drivers are provided by default with NetXMS installation:
Driver Description
AnySMS SMS driver for any-sms.biz service (http://any-sms.biz). Configuration parameters:
• login (default: user)
• password (default: password)
• sender (default: NETXMS)
• gateway (default: 28)
DBTable This driver saves notifications to a database. Configuration parameters:

• DBDriver (default: sqlite.ddr)
• DBName (default: netxms)
• DBLogin (default: netxms)
• DBPassword
• DBServer (default: localhost)
• DBSchema
• MaxMessageLength (default: 255)
• MaxNumberLength (default: 32)
• QueryTemplate
Dummy Dummy driver for debugging purposes. Does not send any actual notifications and
only logs them to server log file. This driver has no configuration parameters. It is
necessary to set debug level to debug=6 or higher to get records in the log file.
GSM Driver for serial or USB attached GSM modems with support for standard GSM AT
command set. Configuration parameters:
• BlockSize (default: 8)
• DataBits (default: 8)
• Parity (default: n)
• Port (default: COM1: on Windows platforms, /dev/ttyS0 on other platforms)
• Speed (default: 9600)
• StopBits (default: 1)
• TextMode (1 - text mode, 0 - PDU mode, default: 1)
• UseQuotes (1 - use quotes, 0 - do not use quotes, default: 1)
• WriteDelay (default: 100)


Driver Description
Kannel Driver for Kannel SMS gateway (http://www.kannel.org). Configuration parameters:
• host (default: 127.0.0.1)
• port (default: 13001)
MicfosoftTeams Notification channel driver for Microsoft Teams. Configuration parameters:

• ThemeColor - team color in RGB, default: FF6A00 (optional parameter)
• UseMessageCards - flag if message cards should be used, default: no (optional
parameter)
Optional configuration section “Channels” should contain list of channels in the fol-
lowing format: channelName=URL, where channelName is an arbitrary name later
used as recipient in action configuration. More information about setting up the URL
of incoming webhook available there
#config example
ThemeColor=FF6A00
UseMessageCards = false
[Channels]
Channel=URL
AnotherChannel=URL
MsTeams requires 2 fields in action configuration:
• Recipient name - channel name defined in Channels section or incoming web-
hook URL
• Message - message to be sent
MyMobile SMS driver for MyMobile API gateways. Configuration parameters:

• username
• password
Nexmo SMS driver for Nexmo gateway. Configuration parameters:

• apiKey (default: key)
• apiSecret (default: secret)
• from (default: NetXMS)
NXAgent Similar to gsm.ncd, but sending is done via GSM modem, attached to NetXMS agent.
Configuration parameters:
• hostname (default localhost)
• port (default: 4700)
• timeout (seconds, default: 30)
• secret
• encryption - optional parameter. Encryption policy:
0 = Encryption disabled;
1 = Encrypt connection only if agent requires encryption;
2 = Encrypt connection if agent supports encryption;
3 = Force encrypted connection;
• keyFile - optional parameter. Specify server’s key file, if not specified will take
default path.
13.5. Actions 169


Driver Description
Portech Driver for Portech MV-372 and MV-374 GSM gateways (https://www.portech.com.
tw/p3-product1_1.asp?Pid=14). Configuration parameters:
• secondaryHost
• login (default: admin)
• password (default: admin)
• mode (PDU or TEXT, default: PDU)
Slack Driver for slack.com service. Configuration parameters:

• url
• username
SMSEagle Driver for SMSEagle Hardware SMS Gateway. Configuration parameters:

• port (defalut: 80)
• https (1 - use https, 0 - do not use https)
SMTP Driver to send notifications using SMTP protocol.

• Server (default: localhost)
• RetryCount (default: 1)
• Port (default: 25)
• LocalHostName
• FromName (default: NetXMS Server)
• FromAddr (default: netxms@localhost)
• MailEncoding (default: utf8)
• IsHTML (0 - do not use HTML, 1 - use HTML; default: 0)


Driver Description
SNMPTrap Driver to send notifications as SNMP traps. Driver configuration parameters:
• Community (default: public)
• Port (default: 162)
• ProtocolVersion (possible values: 1, 2c, 3; default: 2c)
Driver configuration parameters applicable to SNMP v3 only:
• AuthMethod (possible values: none, sha1, sha224, sha256, sha384, sha512;
default: none)
• AuthPassword
• PrivMethod (possible values: none, aes, des; default: none)
• PrivPassword
• UseInformRequest (default: false)
• UserName (default: netxms)
Raden Solutions has IANA assigned Private Enterprise Number (57163). MIB files
defining the OIDs (RADENSOLUTIONS-SMI.txt and NETXMS-MIB.txt) are in-
cluded with NetXMS server. It’s also possible to use custom OIDs by setting the
following driver configuration parameters:
• AdditionalDataFieldID (default: .1.3.6.1.4.1.57163.1.1.6.0)
• AlarmKeyFieldID (default: .1.3.6.1.4.1.57163.1.1.5.0)
• MessageFieldID (default: .1.3.6.1.4.1.57163.1.1.3.0)
• SeverityFieldID (default: .1.3.6.1.4.1.57163.1.1.2.0)
• SourceFieldID (default: .1.3.6.1.4.1.57163.1.1.1.0)
• TimestampFieldID (default: .1.3.6.1.4.1.57163.1.1.4.0)
• TrapID (default: .1.3.6.1.4.1.57163.1.0.1)
Recipient’s address should contain host name or IP address the trap is sent to. Mes-
sage and subject are sent as separate fields (MessageFieldID and AdditionalDataFiel-
dID) in the trap message. In addition to that, if subject contains semicolon-separated
key=value pairs or JSON and the key is from below list, additional fields with these
values will be added to trap message. List of supported keys:
• key - alarm key
• source - source object name
• severity - event severity (integer in range 0..4)
• timestamp - original even timestamp as UNIX time
E.g. subject could be key=%K;source=%n;severity=%s;timestamp=%T.
Subject field could be generated using NXSL script that is called using
%[script_name] macro. This is convenient for generating JSON.
JSON data can have more fields in addition to the above mentioned, this allows to
send more information in the trap.
13.5. Actions 171


Driver Description
Telegram Notification channel driver for Telegram messenger. Configuration parameters:
• AuthToken
• DisableIPv4 - true to disable IPv4 usage
• DisableIPv6 - true to disable IPv6 usage
• ParseMode - Text formatting style: Markdown, HTML or MarkdownV2. See
Telegram API documentation on formatting syntax: https://core.telegram.org/
bots/api#formatting-options
• Proxy - proxy url or ip or full configuration if format
[scheme]://[login:password]@IP:[PORT]
• ProxyPort - proxy port
• ProxyType - proxy type: http, https, socks4, socks4a, socks5 or
socks5h
• ProxyUser - proxy user name
• ProxyPassword - proxy user password
Only AuthToken field is mandatory field all others are optional.
It is necessary to create a telegram bot that NetXMS server will use to send messages.
In order to create a new bot it’s necessary to talk to BotFather and get bot authentica-
tion token (AUTH_TOKEN). Set authentication token in notification channel configu-
ration, e.g.: AuthToken=1234567890:jdiAiwdisUsWjvKpDenAlDjuqpx
The bot can:
• Have a private chat with another Telegram user
• Participate a group
• Be channel admin
Telegram’s bot can’t initiate conversations with users in a private chat or a group. A
user must either add bot to a group or send a private message to the bot first.
Chat, group or channel is identified by ID or name (without @ prefix). For private
chats only users who configured a Username can be identified by name (without @
prefix). NetXMS stores the correspondence between ID and name when the bot re-
ceives a message in chat or group (NetXMS server should be running a that moment).
If group, channel name or username is changed, it’s necessary to send any message to
the bot so new correspondence could be stored.
Telegram notification channel requires 2 fields in action configuration:
• Recipient name - It could be name (of a group, channel or username, without
@ prefix) or ID of group, channel or chat.
• Message - text that should be sent
If you want to use ID to identify a recipient, you can get it by opening Tele-
gram API URL in your browser, e.g. https://api.telegram.org/bot1234567890:
jdiAiwdisUsWjvKpDenAlDjuqpx/getUpdates After sending a message to the bot or
adding it to a group you should see chat id there. You might need to temporary decon-
figure Telegram notification channel, otherwise if NetXMS server is running, it will
read data from Telegram API first.
Text2Reach Driver for Text2Reach.com service (http://www.text2reach.com). Configuration pa-
rameters:
• apikey (default: apikey)
• from (default: from)
• unicode (1 or 0, default: 1)
• blacklist (1 or 0, default: 0)
TextFile Notification driver that writes messages to text file. Configuration parameter:
• filePath (default: /tmp/test.txt)


Driver Description
WebSMS Driver for websms.ru service (https://websms.ru). Configuration parameters:
• m_fromPhone
13.6 NXLS Persistent Storage
13.6.1 NXSL
There are 2 functions:

• ReadPersistentStorage(“key”) - read value by key
• WritePersistentStorage(“key”, “value”) - insert or update value by key. If value will be empty - variable
will be deleted.
13.6.2 View
Persistent Storage view (Configuration → Persistent Storage) provide information about current state of Persistent
Storage variables.
13.7 Macros for Event Processing
On various stages of event processing you may need to use macros to include information like event source, severity,
or parameter in your event texts, alarms, or actions. You may use the following macros to accomplish this:
Macro Description
%a IP address of event source object.
%A Alarm’s text. This macro is populated when creating,
resolving or terminating alarm in EPP rule. Macro is
available in that EPP rule for persistent storage and
server action and in subsequent EPP rules. Prior to
version 3.8.314 this macro was available only withing
given EPP rule.
%c Event’s code.
13.6. NXLS Persistent Storage 173


Macro Description
%E List of comma-separated user tags associated with the
event.
%g Globally unique identifier (GUID) of event source ob-
ject.
%i Unique ID of event source object in hexadecimal form.
Always prefixed with 0x and contains exactly 8 digits
(for example 0x000029AC).
%I Unique ID of event source object in decimal form.
%K Alarm’s key (can be used only in actions to put text of
alarm from the same event processing policy rule).
%m Event’s message text (meaningless in event template).
%M Custom message text. Can be set in filtering script by
setting CUSTOM_MESSAGE variable.
%n Name of event source object or name of interface for
intefrace macro expansion.
%N Event’s name.
%s
Event’s severity code as number. Possible values are:
• 0 - Normal
• 1 - Warning
• 2 - Minor
• 3 - Major
• 4 - Critical
%S Event’s severity code as text.

%t Event’s timestamp is a form day-month-year
hour:minute:second.
%T Event’s timestamp as a number of seconds since epoch
(as returned by time() function).
%v NetXMS server’s version.
%z Zone UIN of event source object.
%Z Zone name of event source object.
%[name] Value returned by script. You should specify name of
the script from script library.
%{name} Value of custom attribute.
%{name:default_value} Value of custom attribute. If such custom attribute does
not exists on a particular node, default_value is taken. If
custom attribute exists, but has empty value, this empty
value is taken (if this macro is used somewhere, where
it’s value is converted to numeric value - e.g. as thresh-
old value for a numeric DCI - then empty value will be
converted to 0).
%<name> Event’s parameter with given name.
%1 - %99 Event’s parameter number 1 .. 99.
%% Insert % character.
If you need to insert special characters (like carriage return) you can use the following notations:

Char Description
\t Tab Character (0x09)
\n New line, CR/LF character pair
\\ Backslash character
13.7.1 Event’s parameter with given name
Threshold reached/rearmed named parameters:

• %<dciId>
• %<dciName>
• %<dciDescription>
• %<thresholdValue>
• %<currentValue>
• %<instance>
• %<isRepeatedEvent> - set only for DCI reached events
• %<dciValue>
13.7. Macros for Event Processing 175


CHAPTER
FOURTEEN
DATA AND NETWORK VISUALISATION
14.1 Network maps
Network map objects can be found in “Object browser” under “Network Maps”. There can be created and deleted
maps and map groups. Maps can be organized in groups.
14.1.1 Creating Maps
There are 3 types of map that can be created:

• Custom - will be created empty map.
• Layer 2 Topology - will create map(if possible) with layer 2 topology of selected object. Will be automat-
ically updated on topology change.
• IP Topology - will create map with known IP Topology of selected object. (More about network topology
can be found there Network topology) Will be automatically updated on topology change.
• Internal communication topology - map created based on internal communication between server and node
(will show SNMP, ICMP, ).
177
Fig. 1: Network map layer 2
Type of created map affects only on initial map setup.
14.1.2 Edit Maps
178 Chapter 14. Data and Network visualisation

14.1.3 Adding Objects
Network map can be populated in 2 different ways: automatically and manually. Automatically are populated Layer
2, IP Topology and Internal communication topology. Object filer (in properties of the map) can be created for
automatically populated maps to filter out unrequited nodes.
Objects to map can be added in tow ways:
1. Just drag and drop object to map from object browser.
2. “Add object. . . ” from menu.
To remove object from map:
• Select object, right click and select “Remove from map” option.
14.1.4 Adding Links between Objects
Objects can be linked with a line.

To link objects:
• Select two of objects with help of CTRL button and press “Link selected objects” button.
To remove the link:

• Select line, right click and select “Remove from map” option.
Link properties:
Select line, right click and select “Properties”.
There can be configured:
• Line name
• Line comments shown near each connected object
• Line color
– Default - grey
– Based on object status - object should be selected
– Custom color
• Routing algorithm
– Map Default - will be taken default selection for whole map
– Direct - straight line without bend points
– Manhattan - line with automatic bend points
– Bend points - bend point can be done manually with double click on the line (can be used to do
dual link)
14.1. Network maps 179

• Data Source(there can be configured DCI values and text near them that will be displayed on a link)
– For each Data Source can be configured: Data collection item, name, java format string(like “Text:
%.4f”, syntax http://docs.oracle.com/javase/7/docs/api/java/util/Formatter.html#syntax), in case
of table DCI also column and instance
Example of DCI data displayed on a link:
14.1.5 Decorations
Decorations like picture and group box can be added to maps. To add picture it should be previously be uploaded to
“Image Library”.
When creating group box you should specify it’s size, color and name.

14.1.6 DCI Container
DCI Container is part of decorations. It can be used to display separate dci values on a map.
Container properties:
• Background color
• Text color
• If border should be shown and it’s color
• Data Source - there can be configured DCI values and text near them that will be displayed
– For each Data Source can be configured: Data collection item, name, format string(like “Text: %.4f”),
in case of table DCI also column and instance
More examples:

14.1.7 DCI Image
DCI Image is part of decorations. It can be used to display DCI status change in pictures.
DCI image properties
• Data source - DCI which data will be taken to process picture display rules
• Column - required only for table DCI
• Instance - required only for table DCI
• Default image - image that will be displayed if no rule is applicable on current value
• Rules
– For each rule can be configured: operation, value, comment and image that will be displayed if
this rule is applicable
Hints:
To use image it should be first uploaded to image library.
Rules are processed from up to down, so if you want to describe in rules something like:
• DCI > 3 => image1
They should go in this sequence:
14.1.8 Object Layout and display options
All object layout properties and display options are applicable only on objects, not on decorations.
Grid
• Align to grid - will move all objects to grids

• Snap to grid - all objects will be moved in grids and it will not be possible to place them not inside grid.
• Show grid - will show grid according to which objects are located.

Layout
Objects can be placed manually on a map or can be chosen one of automatic layouts:
• Spring
• Radial
• Horizontal tree
• Vertical tree
• Sparse vertical tree
If there is chosen automatic layout, then after each refresh object best matching place will be recalculated. So if new
object is add - it is just required to refresh map to have correctly placed objects.
If there is chosen manual layout, then after each object movement map should be saved, to save the new place of
object.
Display object as
• Show status background - will display background behind object image according to it’s state.
• Show status icon - will display icon of object state near each object
• Show status frame - will display frame around object icon according to it’s state
• Floor plan - will display nodes as adjustable rectangles. This can be used to display hardware placement on
room plan.
Routing
Default routing type for whole map:

• Direct - objects are connected by links drawn to shortest route
• Manhattan - objects are connected by grid-based links
Zoom
Map can be zoomed in and out with help of top menu buttons and to predefined percentage selected from menu.
Object display options
Objects can be displayed in 3 ways:

• Icons
• Small labels
• Large labels

14.1.9 Map Background
It can be set background for map:

• Colour
• Image - image should be uploaded to “Image Library” before.
• Geographic Map - place on map is chose with help of zoom and coordinates
This can be used to show object physical please on map or on building plan.
Examples:
14.2 Dashboards
Dashboards are defined by administrator and allow to combine any available visualization components with data from
multiple sources in order to create high-level views to see network (or parts of it) health at a glance. For example,
below is a dashboard showing traffic information from core router, as well as CPU usage from vital nodes:

There are two ways to access dashboards:

Open dashboard from Object Browser
• Open dashboard from Object Browser
• Switch to Dashboard perspective and select dashboard with left-click
Dashboards is a special type of objects created in Dashboards tree. To create a new dashboard, right click on Dash-
boards root object or any other existing dashboard and select Create dashboard. To configure dashboard content,
open object’s properties and go to Dashboard Elements:guilabel: page. Here you can define number of columns and
manage list of elements. Press Add:guilabel: to add new element. You will be prompted with element type selection
dialog:
14.2. Dashboards 185

When a new element is added, you can edit it by double-clicking on it’s record in the elements list, or by pressing the
Edit button. Each element have Layout property page which controls the element’s layout inside the dashboard, and
one or more element type specific pages to control element’s appearance and displayed information. The following
element types are available:
Label
Text label with configurable text and colors.

Line Chart
Line chart.
Bar Chart
Bar chart.
Pie Chart
Pie chart.

Tube chart
Tube chart.

Status Chart
Bar chart which shows current status distribution for nodes under given root.
Status Indicator
Shows current status of selected object.
Dashboard
Another dashboard object (or multiple objects) rendered as element of this dashboard.
Network Map
Network map object rendered as dashboard element.
Custom Widget
Custom widget provided by third party console plugin. This options allows to add widget from third party loaded
plugin.

Get Map
Geographic map centered at given location.
Alarm Viewer
List of alarms for given object subtree.
Availability Chart
Pie chart showing availability percentage for given business service

Gauge
Gauge have 3 types of widgets

• Dial is radial gauge with configurable maximum, minimum values. Scale can have fixed color or can be sepa-
rated to 3 color configurable zones.
• Dar is linear gauge with configurable maximum, minimum values. Scale can have fixed color or can be separated
to 3 color configurable zones. (Not yet implemented)
• Text is text gauge, that can be colored using fixed color, changed depending on 3 configurable color zones or
colored using threshold color (severity).
Web Page
Web page at given URL rendered within dashboard.
Bar Chart for Table DCI
Bar chart built from data collected via single table DCI.

Pie Chart for Table DCI
Pie chart built from data collected via single table DCI.
Tube Chart for Table DCI
Tube chart built from data collected via single table DCI.
Separator
Separator, can be shown as line, box, or simply empty space.

Table Value
This widget displays table with last values of Table DCI.
Status Map
Status map has three views: Flat view, Group view and Radial view.
Flat view and Group view display nodes as rectangles, using color to indicate their status. In Flat view nodes are
displayed without grouping, whether in Group view nodes are grouped by containers.
Radial view displays containers and nodes as hierarchical colored radial layout.
DCI Summary Table
DCI Summary Table widget provides summary DCI information about objects under container.
Syslog Monitor
Syslog monitor widget. Has additional option to set root object to filter objects what will be shown in monitor. One
object or a container that contains required objects can be set as root object.

SNMP Trap Monitor
SNMP Trap monitor widget. Has additional option to set root object to filter objects what will be shown in monitor.
One object or a container that contains required objects can be set as root object.
Event monitor
Event monitor widget. Has additional option to set root object to filter objects what will be shown in monitor. One
object or a container that contains required objects can be set as root object.

Service component map
Map displays hierarchy of objects in Infrastructure Service starting from selected root object.
Rack diagram
Shows rack front, back or both views with object placement in it.

Object tools
Shows buttons with pre configured object tools, that are executed on click.

Object query
Shows columns with filtered objects’ information.

Object query has 2 main configurations. Query that filterers objects and provide option to create additional information
about object in columns and Object Properties that lists information that should be shown in table.
Query
It is a script that is executed on each object and should return true if object should be displayed in the table and false if
it should not. It has special syntax that provides option to calculate additional values for columns in Object Properties
section. This syntax is optional and usual NXSL script can be used instead. Usual NXSL script should return true if
node should be shown and false if not, additional self calculated columns can be defined as global variables.
Syntax:
with
varName = { code or expression },
varName = { code or expression }
/* Might be as many blocks as required.
* varName is a name of the variable where result of a code will be assigned.
* It can be used later in the code in expression or to be displayed in table
* using the same name in the Object Properties part.
*/
expression
/* Short circuit evaluated expression. This expression is executed first and if it
˓→contains not yet calculated
* varName then variable is calculated and used in expression. Expression that should
˓→result as true or false
* as a sign if this object should be displayed in table or not. No semicolon at the

˓→end.
*/
This page provides option to configure columns that should be used for ordering, refresh interval and record limit. To
order column write a coma separated list of attribute named or varNames with - sign to order in descending order and
with + sign to order in ascending order.
Object Properties
This property page is used to organize required columns and column order in table. Each column configuration consists
of name of object’s attribute or varName defined in Query page, display name used as a name for a column and data
type of the column.
Example
This example will show how to filter nodes that only have alarms on them, are not in maintenance mode and show
count of critical alarms on the node, order by critical alarm count the list and then by node name. Example shows two
different options how to write the same script so only one of them should be used.
Configuration:

Fig. 2: Option 1. Query script with “with” syntax

Fig. 3: Option 2. Query script with usual NXSL script and global variables

Fig. 4: Configuration of Properties to display will be the same for both scripts
Result:

Port view
Shows ports schematic with each port status. One object or a container that contains required objects can be set as root
object.

14.2.2 Element Property Pages
Chart
Chart page is available for all chart type elements: Bar Chart, Bar Chart for Table DCI, Dial Chart, Line Chart, Pie
Chart, Pie Chart for Table DCI, Tube Chart, and Tube Chart for Table DCI. It defines basic properties of a chart.
Data Sources
Data sources page is available for all DCI based elements: Bar Chart, Dial Chart, Line Chart, Pie Chart, and Tube
Chart. Here you can define what DCIs should be used as data sources for the chart. Up to 16 DCIs can be added to
a single chart. You can configure multiple properties for each data source. To edit data source, either double click on
appropriate item in the list, or press Edit button. Data source configuration dialog looks like following:

Property Description
Data collection item DCI object to be used.
Display name Name for this data source to be used in chart’s legend. If left empty, DCI description
will be used.
Colour Allows you to define specific color for this data source or let system to pick one
automatically.
Area chart This option is valid only for line charts and toggles data source display as filled area
instead of line.
Show thresholds This option is valid only for line charts and toggles display of configured thresholds.
Layout
Property Description
Horizontal alignment Horizontal alignment for this element. Possible values are FILL, CENTER, LEFT,
and RIGHT.
Vertical alignment Vertical alignment for this element. Possible values are FILL, CENTER, TOP, and
BOTTOM.
Horizontal span Specify how many grid cells this element will occupy horizontally.
Vertical span Specify how many grid cells this element will occupy vertically.
Width hint Hint for element’s width in pixels. Default value of -1 means that layout manager
will decide width for element.
Height hint Hint for element’s height in pixels. Default value of -1 means that layout manager
will decide width for element.
See detailed information about layout in section Understanding Element Layout.

Web Page
:guilabel`Web Page` property page is available for web page type elements. Here you can define URL to be displayed
and optional title. If title is not empty, it will be displayed above page content.
14.2.3 Understanding Element Layout
Dashboard uses grid concept to layout it’s elements. Available space is divided into rows and columns, and each
element occupies one or more cells. The number of columns is configured in dashboard object properties, and number
of rows is calculated automatically based on number of columns, elements, and cells occupied by each element.
Elements are laid out in columns from left to right, and a new row is created when there are no space left for next
element on current row. Each element has horizontal and vertical alignment properties. Default for both is FILL.
Possible alignment values are following:
Value Description
FILL Make element to fill whole cell. Also causes to grab excess free space available inside
dashboard. If more than one element is trying to grab the same space, then the excess
space is shared evenly among the grabbing elements.
CENTER Center element within cell.
LEFT/TOP Align element to left/top of the cell.
RIGHT/BOTTOM Align element to right/bottom of the cell.
Fig. 5: Complex layout configuration
This configuration will be rendered into this layout:

14.2.4 Dashboard Rotation
To create configuration when console displays multiple dashboards one by one in a loop, follow these steps:
• Create all dashboards you want to show
• Create additional dashboard object, with single element of type Dashboard inside
• Add all dashboards you want to show to dashboard list of that element and set desired time between changing
dashboards.

Fig. 6: Sample configuration of two dashboards displayed in a loop for 40 seconds each.
14.2.5 Tutorials
Dashboard creation tutorial available on Youtube
14.3 Graphs
You can view collected data in a graphical form, as a line chart. To view values of some DCI as a chart, first open either
Data Collection Editor or Last Values view for a host. You can do it from the Object Browser or map by selection
host, right-clicking on it, and selecting Data collection or Last DCI values. Then, select one or more DCIs (you can
put up to 16 DCIs on one graph), right-click on them and choose Graph from the pop-up menu. You will see graphical
representation of DCI values for the last hour.
When the graph is open, you can do various tasks:
14.3.1 Select different time interval
By default, you will see data for the last hour. You can select different time interval in two ways:
1. Select new time interval from presets, by right-clicking on the graph, and then selecting Presets and appropriate
time interval from the pop-up menu.
2. Set time interval in graph properties dialog. To access graph properties, right-click on the graph, and then select
Properties from the pop-up menu. Alternatively, you can use main application menu: Graph → Properties. In
the properties dialog, you will have two options: select exact time interval (like 12/10/2005 from 10:00
to 14:00) or select time interval based on current time (like last two hours).

14.3.2 Turn on automatic refresh
You can turn on automatic graph refresh at a given interval in graph properties dialog. To access graph properties,
right-click on it, and select Properties from the pop-up menu. Alternatively, you can use main application menu:
Graph → Properties. In the properties dialog, select the Refresh automatically checkbox and enter a desired refresh
interval in seconds in edit box below. When automatic refresh is on, you will see Autoupdate message in the status bar
of graph window.
14.3.3 Change colors
You can change colors used to paint lines and graph elements in the graph properties dialog. To access graph properties,
right-click on it, and select Properties from the pop-up menu. Alternatively, you can use main application menu: Graph
→ Properties. In the properties dialog, click on colored box for appropriate element to choose different color.
14.3.4 Save current settings as predefined graph
You can save current graph settings as predefined graph to allow quick and easy access in the future to information
presented on graph. Preconfigured graphs can be used either by you or by other NetXMS users, depending on settings.
To save current graph configuration as predefined graph, select Save as predefined from graph view menu. The
following dialog will appear:
In Graph name field, enter desired name for your predefined graph. It will appear in predefined graph tree exactly
as written here. You can use -> character pair to create subtree. For example, if you name your graph NetXMS
Server->System->CPU utilization (iowait) it will appear in the tree as following:
You can edit predefined graph by right-clicking on it in predefined graph tree, and selecting Properties from context
menu. On Predefined Graph property page you can add users and groups who will have access to this graph. Note that
user creating the graph will always have full access to it, even if he is not in access list.
If you need to delete predefined graph, you can do it by right-clicking on it in predefined graph tree, and selecting
Delete from context menu.
14.3. Graphs 207

14.3.5 Save current settings as template graph
Current graph settings can be saved as a template graph for an easy template graph creation. The difference between
predefined graphs and template graphs are that template graphs are not configured to view specific DCI`s on a node,
instead they are configured to view DCI names that can be found on many nodes (e.g. FileSystem.FreePerc(/
)). This allows for the creation of certain graph templates to monitor, for example, disk usage that can be reused on
any node to which the appropreate DCI`s are applied on via DCI configuration.
See detailed information on template graphs in the section Template Graph Configuration.
In the Graph name field of the pop-up save dialog, enter the desired name for the template graph by which you can
later identify your it in the Template Graph Configuration which can be found in Configuration→Template Graph
Configuration.

Template graphs can be accessed in the Object Browser as seen on the screenshot above. When a template graph is
created, it will appear in the sub-menus of the nodes found in Object Browser, the rest of the settings can be accessed
by editing a template graph in the Template Graph Configuration.
14.3. Graphs 209

14.3.6 Template Graph Configuration
Template graphs are used to ease the monitoring of a pre-set list of DCI`s on multiple nodes by adding a list of DCI
names to the template source. This allows for the possibility to create templates to monitor specific data on any node
to which the appropriate DCI`s are applied on.
The Template Graph Configuration is used to create and edit template graphs. Properties for already created template
graphs can be brought up by double clicking the template graph you wish to edit and new ones can be added by
pressing the green cross on the top right or by right clicking and selecting Create new template graph.

Fig. 7: Name and access rights of a graph
The above property page provides the possibility to configure the name of the template graph and the access rights.
The user who has created the template graph will have full access to it even though the username will not show up in
the access right list.
14.3. Graphs 211

Fig. 8: General graph properties.
Title:
• The title that the graph will have when opened.
• The title can contain special characters described in Macro Substitution.
Options:
Option Description
Show grid lines Enable or disable grid lines for the graph.
Stacked Stacks the graphs of each value on top of one another to be able to see the
total value easier (e.g. useful when monitoring cpu usage).
Show legend Enable or disable the legend of the graph.
Show extended legend Enable or disable the extended legend of the graph (Max, Avg, Min, Curr).
Refresh automatically Enable or disable auto-refresh.
Logarithmic scale Use the logarithmic scale for the graph.
Translucent Enable or disable the translucency of the graph.
Show host names Show host name of the node from which the value is taken.
Area chart Highlights the area underneath the graph.
Line width Adjust the width of the lines.
Legend position Set the position of the legend.
Refresh interval Set the refresh interval.

Time Period:
Provides the possibility to configure the time period of the graph. It is possible to set a dynamic time frame (Back
from now) and a static time frame (Fixed time frame).
Y Axis Range:
Adjust the range of the Y axis on the graph.
Fig. 9: Template graph filter properties.
It may be necessary to set certain filters for a template graph. This can be useful if the graph contains DCI names that
are only available on NetXMS agent or are SNMP dependant.
More information on filters can be found in Filter.
14.3. Graphs 213

Fig. 10: Template graph sources
There are two options to add sources to the template graph. Sources can be added manually by configuring the Data
Source parameters yourself or by importing data source information from DCI`s that have already been applied to
other nodes.

When adding or editing a source, it is possible to use Java regex in the DCI Name and DCI Description fields. This
can be handy when used with the Multiple match option which will use all DCI`s that match the particular regex. The
order in which the DCI list is searched is first by DCI Name and then by DCI Description.
14.4 History
You can view collected data in a textual form, as a table with two columns - timestamp and value. To view values of
some DCI as a table, first open either Data Collection Editor or Last Values view for a host. You can do it from the
Object Browser or map by selection host, right-clicking on it, and selecting Data collection or Last DCI values. Then,
select one or more DCIs (each DCI data will be shown in separate view), right-click on them and choose Show history
from the pop-up menu. You will see the last 1000 values of the DCI.
14.5 Summary table
It is possible to see DCI data as a table where each line is one node and each column is a DCI. It can be configured for
each summary table which DCIs should be present on it.
14.4. History 215

DCI summary table can be configured in Configuration -> Summary Table.
General:
• Menu path - path where this summary table can be found. You can use -> character pair to create subtree like
“Linux->System information”.
• Title - title of the summary table.
Columns:
• This is the list if DCI’s that will be shown on the summary table. Name is the name of column and DCI Name
is DCI parameter name.
– Multivalued column is intended to present string DCIs that contain several values divided by specified
separator. Each value is presented on a separate line in the column.
– If Use regular expression for parameter name matching is enabled, a regular expression is specified in
DCI name field. If several DCIs will be matched on a node, only one will be displayed.
• Import button allows to select a DCI from existing object.
Filter:
• Filter script is executed for each node to determine, if that node should be included in a summary table.
Filter script is defined with help of NXSL scripting language.

14.5.2 Usage
After DCI summary table is configured it can be accessed in container object (Subnet, container. . . ) context menu
under “Summary tables”.
14.5. Summary table 217


CHAPTER
FIFTEEN
GRAFANA INTEGRATION
NetXMS Grafana integration provides the possibility to display important data using the Grafana platform and the
NetXMS WebAPI.
15.1 Integration with Grafana
The NetXMS Grafana datasource provides an alternative way of monitoring to that of the NetXMS Web and Desktop
consoles or the Android app, by using the Grafana platform and the NetXMS WebAPI.
15.1.1 Requirements
The following prerequisites need to be set-up first:

A running instance of the NetXMS Server. A running instance of the NetXMS WebAPI. A running instance Grafana
(more information in https://grafana.com/get).
15.1.2 Installation
See https://grafana.com/grafana/plugins/radensolutions-netxms-datasource/?tab=installation
For installation from source:
1. Clone the NetXMS Grafana datasource GitHub repository from https://github.com/netxms/grafana.
2. Copy the files from the repository to GRAFANA_HOME/data/plugins/datasources/netxms
3. Restart your Grafana server.
4. Login to your Grafana web interface and add the NetXMS datasource in the Data Sources section.
15.1.3 Features
The datasource currently supports the following functionality:

• Visualization of configured data collection items for objects in graphs and tables.
• Listing of active alarms on a general or a per object basis
219
15.2 Configuration
The data source can be configured in the data source management section in the Grafana web ui. The required settings
are the base URL of the NetXMS WebAPI, the username and the password of an account that exists on your NetXMS
server. It is suggested to create a dedicated account to be used with Grafana.
15.3 Alarm Browser
The data source provides the possibility to view currently active Alarms on all nodes or on a per node basis. To do this,
you need to add a new Table Panel to your Grafana dashboard and then edit the Metrics section of the panel settings.
If the NetXMS data source is set as the default data source, it should have been added to the panel automatically, if
not, select the name of the installed NetXMS data source from the Panel data source list and press Add query to add
the data source.`
220 Chapter 15. Grafana integration

Once the data source is added to the panel, it is necessary to set the necessary type of data for the data source to
provide, in this case - Alarms.
After the data type has been set, you should see the active alarms appear on the table panel. If you wish to view alarms
from specific nodes only, you can add multiple data sources to your table panel and for each specify the node you wish
to see the active alarms of.
15.4 Data Collection Items
15.4. Data Collection Items 221

The data source provides the possibility to visualize metrics collected from data collection items configured on nodes.
This can be achieved by adding a Graph Panel to your Grafana dashboard, adding the NetXMS data source to it and
selecting the DCI data type in the Metrics section of the graph panel settings. Once this is done, it is possible to select
the Target node from the list of targets which will then provide a list of the configured DCI`s for the particular node
in the DCI section. By default, the legend of the data provided by the DCI will be the DCI`s description as configured
on the server, it is also possible to set a legend of your choice by entering it in the Legend section.
It is possible to view multiple DCI`s on the same graph by adding multiple data sources to it.
222 Chapter 15. Grafana integration

CHAPTER
SIXTEEN
OPERATING SYSTEM MONITORING
Most OS-related metrics (file system, CPU, network) are provided by “platform subagent”, which is loaded automati-
cally by the agent on the startup.
List of available subagents:
• linux
• aix
• hpux
• winnt (all Windows flavors)
• sunos (Solaris)
• darwin (MacOS)
• freebsd
• netbsd
• openbsd
In this section we cover only most common metrics. Detailed list available bellow.
16.1 Example
In examples will be shown only DCI configuration with threshold. Generated event processing options can be found
in Event processing chapter.
16.1.1 Process monitoring
In this example monitoring of running “mysqld” process will be configured and one threshold will be added: when
process count is less then 1 (process is not running).
Create DCI for Process.Count(*) metric to monitor “mysqld” process count.
223
Create threshold. It will be triggered when process count is not equal to 1(process is not running). As prerequisite it
was created 2 events.
Fig. 1: Events
224 Chapter 16. Operating System Monitoring

Fig. 2: Threshold 1
As in message of error is used Instance parameter, it should be set in Threshold window.
16.1. Example 225

16.1.2 Disk free space monitoring
In this example monitoring of free space in percents for / disk will be configured and two thresholds will be added:
when disk space less then 15% and less then 7%.
Create DCI for FileSystem.FreePerc(*) metric to monitor space on /.
Create 2 thresholds. One will be triggered when free space is less than 15% and other one when free space is less than
7%. Before threshold creation was created 3 events:

Fig. 3: Events
Fig. 4: Threshold 1
16.1. Example 227

Fig. 5: Threshold 2
Fig. 6: Both

16.1.3 CPU usage
This example will show how to configure monitoring of CPU usage and create event when CPU usage is more than
90% for more than 5 minutes.
Create DCI for System.CPU.LoadAvg metric.
Create threshold that will create event in case if last 5 values are more than 90 (last 5 minutes CPU usage is more than
90%).
16.1. Example 229

Fig. 7: Events
Fig. 8: Threshold

CHAPTER
SEVENTEEN
FILE META INFORMATION
Monitoring of file system is implemented by OS subagents. Full description of this functions can be found there.
There is provided option to get file hash, creation, last edit and other timestamps, file size and number of files in the
directory. In this sections will be shown only the most commonly used configurations.
17.1 Examples
In examples will be shown only DCI configuration with threshold. Generated event processing options can be found
in Event processing chapter.
17.1.1 Example 1
In this example will be shown how to check that specific folder exceed specified size.
Create DCI for File.Size(*) metric to monitor folder size. Required parameters: /path,*,1.
231
In threshold it should be checked that last value is less than 2 GB. That mean that returned value should be less than 2
000 000 000 bytes.
232 Chapter 17. File meta information

Fig. 1: Threshold
17.1.2 Example 2
In this example will be configured monitoring that in exact folder exist files that was modified less then half an hour
ago.
Create DCI for File.Count(*) metric to monitor file count in folder /path, that match any pattern, folder should be
checked recursively, file match any size, files are created less than 30 minutes ago. This conditions will be given to
metric as this parameters: path,*,1,0,-1800.
17.1. Examples 233

In threshold it should be checked that at least one file meeting conditions exists. That mean that file count should be
more than 1. Prerequisite is to create 2 events.

Fig. 2: Events
Fig. 3: Threshold
17.1. Examples 235


CHAPTER
EIGHTEEN
LOG MONITORING
With NetXMS you can monitor changes in text log files, Windows Event Log, and built-in syslog server. All log mon-
itoring done by agents, except for built-in syslog server. In general, most common log processing goes as following:
1. When new line added to log file, it is passed to appropriate log parser
2. If line matched one of the patterns, an event associated with this pattern is sent to NetXMS server.
3. Server receives event and passes it to event processing policy as usual, with event source set to node from which
event was received.
For text log files, agent keeps status information about monitored files in memory only. This means that if the agent
was stopped for a period of time, lines that were added to log file during that time will not be parsed.
For Windows Event Log agent keeps status information in Windows registry. On agent start records that were added
while the agent was stopped will be parsed.
Log parser also provides some additional statistic information through Metrics. More information can be found in Log
parser parameters chapter.
18.1 Agent Configuration for Log Monitoring
To be able to monitor logs with NetXMS agent, you should load LOGWATCH subagent. There are two options to define
parser configuration:
1. Create log parser rule files on the monitored system and define them in LOGWATCH part of agent configuration.
2. Create log parser policy and apply it to all required nodes. In this case file will be automatically created on the
file system and added to processing. More information about Agent Policies
Note: Logs files with same processing rules can be configured in the same parser configuration file.
Example of agent configuration file:
SubAgent = logwatch.nsm
# Below is log parsers definitions

[LOGWATCH]
Parser = C:\log_monitoring_definitions\parser1.xml
Parser = C:\log_monitoring_definitions\parser2.xml
237
18.2 Syslog Monitoring
NetXMS has built-in syslog server, which can be used to receive logs from network devices and servers. It is also
possible to parse incoming syslog messages in a way similar to Windows Event Log monitoring. To parse syslog mes-
sages, LOGWATCH subagent is not required – parsing is done by the server itself. You only need to define monitoring
rules in Configuration → Syslog Parser
18.3 Parser Definition File
Parser definition file is an XML document with the following structure:
<parser>
<file>file name</file>

<macros>
<macro name="name">macro body</macro>

</macros>
<rules>
<rule>
<match>regexp</match>
<id>event id</id>
<level>severity level</level>
<source>event source</source>
<event>event</event>
<context>context</context>
</rule>

</rules>
</parser>
Note: Entire <macros> section can be omitted. Empty <rule> tag will match any line (like <rule>
<match>.*</match> </rule>).
18.4 Global Parser Options
In the <parser> tag you can specify the following options:
Op- Description Default

tion value
pro- If this option set to 1, parser will always pass log record through all rules. If this option set 0
ces- to 0, processing will stop after first match.
sAll
trace Trace level for writing debug information to agent log file. 0
name Parser name that is used in statistic information Metrics. See Log parser parameters for empty
more information.
238 Chapter 18. Log monitoring

18.5 <file> Tag
In the <file> tag you should specify log file to apply this parser to. To specify Windows Event Log, prepend it’s
name with asterisk (*), for example *System. Multiples <file> tags can be used - in this case same rules will be
applied to all files.
In file and folder names the following macros can be used:
• Environment variables as %{ENV_VAR_NAME}
• strftime(3C) macros (e.g. C:\Windows\system32\dhcp\DhcpSrvLog-%a)
• Text inside ` braces will be executed as a command and first line of output will be taken
Option Description Default value

encoding It is possible to specify the encoding of the log By default, the parser will attempt to detect the
file by adding the encoding attribute. File en- encoding by scanning the file`s BOM.
codings that can be defined:
• ACP
• UTF-8
• UCS-2
• UCS-2LE
• UCS-2BE
• UCS-4
• UCS-4LE
• UCS-4BE
When using UCS-2 or UCS-4 values, the endi-
anness of the system will be detected automati-
cally.
preallocated Should be set when log file is preallocated (filled 0
with zeros) before logs get written into it.
snapshot Create VSS snapshot and uses snapshot file for 0
parsing. Can be used when log is opened by other
application as exclusive open. Windows only.
Can highly increase CPU usage.
keepOpen Defines if the file is kept open or reopened on 1
each parsing iteration.
ignoreModificationTime
Ignores modification time of log file 0
rescan When file modification is detected, parse the file 0
from it’s beginning. The file is also parsed on
agent startup and when log parsing policy is reap-
plied.
18.6 Macros
In the <macros> section you can define macros for use in matching rules. For example, it can be useful to define
macro for a timestamp preceding each log record and use it in matching rules instead of actual regular expression. You
can define as many macros as you wish, each within it’s own <macro> tag. Each macro should have unique name,
defined in name attribute, and can be used in matching rules in form @{name}.
Example: you need to parse log file where each line starts with timestamp in format dd/mm/yy HH:MM:SS. You
can define the following macro:
18.5. <file> Tag 239

<macros>
<macro name="timestamp">dd/mm/yy HH:MM:SS</macro>
</macros>
<rules>
<rule>
<match>@{timestamp}.*([A-Za-z]+) failed.*</match>
<event>12345</event>
</rule>
<rule>
<match>@{timestamp}.*error.*</match>
</rule>
</rules>
Please note that <macros> section always should be located before <rules> section in parser definition file.
18.7 Matching rules
In the <rules> section you define matching rules for log records.
18.7.1 <rule> Tag
Each rule is placed inside it’s own <rule> tag. Each rule can have additional options:
Option Description Default value

break If this option set to 1 and current line match to regular expression in the 0
rule, parser will stop processing of current line, even if global parser option
processAll was set to 1. If this option set to 0 (which is default), process-
ing will stop according to processAll option settings.
context Name of the context this rule belongs to. If this option is set, rule will be empty
processed only if given context was already activated with <context> tag in one
of the rules processed earlier (it can be either same line or one of the previous
lines).
name Name of rule that is used in trace empty
Inside the <rule> section there are the following additional tags: <match>, <description>, <event>, and
<context>. Only <match> section is mandatory – it specifies regular expression against which log record should
be matched. All other tags are optional and define parser behavior if a record matches the regular expression.
18.7.2 <match> Tag
Tag <match> contains a PCRE compliant regular expression that is used to match log records. Parts enclosed in
parenthesis are extracted from log record and passed as arguments of generated event. You can use macros defined
in Macros section. Also, it is possible to define inverted match rules (rules when log record considered matching if it
does not match regular expression). Inverted match can be set by setting attribute invert to 1. Other possible option
that can be configured is number of times that expression should be matched to generate event.
Some examples:
<match>^Error: (.*)</match>

This regular expression will match any line starting with word Error:, and everything after this word will be ex-
tracted from the log record for use with an event.
<match repeatCount="3" repeatInterval="120" reset="false">[0-9]{3}</match>
This regular expression will match any line containing at least 3 consecutive digits. And event will be generated only
if this regular expression will be matched 3 or more times in 2 minutes(120 seconds). Matched count won’t be reset
once mark is reached, so if expression is matched more than 3 times in 2 minutes, event will be generated more than
one time.
<match invert="1">abc</match>
This regular expression will match any line not containing character sequence abc.
Possible attributes for tag <match>:
Op- Description De-

tion fault
value
invert If this option set to true, it will be matched any line that does not contain matching expres- false
sion.
repeat- The number of times expression should be matched to generate event. It this option set to 0, 0
Count event will be generated immediately on expression match.
repeat- The time interval during which the expression should be matched. It this option set to 0, event 0
Inter- will be generated immediately on expression match.
val
reset If this option set to true, it will set to zero match repeat count. So if while true
repeatInterval expression have been matched repeatCount times+1 it will not gen-
erate second event.
18.7.3 <id> Tag
Tag <id> can be used to filter records from Windows Event Log by event ID. You can specify either single event ID
or ID range (by using two numbers separated with minus sign). For example:
<id>7</id>
will match records with event ID equal 7, and
<id>10-20</id>
will match records with ID in range from 10 to 20 (inclusive). This tag has no effect for text log files, and can be used
as a synonym for <facility> tag for syslog monitoring.
18.7. Matching rules 241

18.7.4 <source> Tag
Tag <source> can be used to filter records from Windows Event Log by event source. You can specify exact event
source name or pattern with * and ? meta characters.
Some examples:
<source>Tcpip</source>
will match records with event source Tcpip (case-insensitive), and
<source>X*</source>
will match records with event source started from letter X. This tag has no effect for text log files, and can be used as
a synonym for <tag> tag for syslog monitoring.
18.7.5 <level> Tag
Tag <level> can be used to filter records from Windows Event log by event severity level (also called event type in
older Windows versions). Each severity level has it’s own numeric value, and to filter by multiple severity levels you
should specify sum of appropriate values (bitmask). Severity level numerical values are the following:
Severity level Decimal value

Error 1
Warning 2
Information 4
Audit Success 8
Audit Failure 16
Critical (only on Windows 7/Windows Server 2008 and higher) 256
Some examples:
<level>1</level>
will match all records with severity level Error, and
<level>6</level>
will match all records with severity level Warning or Information. This tag has no effect for text log files, and can be
used as a synonym for <severity> tag for syslog monitoring.
18.7.6 <facility> Tag
Tag <facility> can be used to filter syslog records (received by NetXMS built-in syslog server) by facility code.
The following facility codes can be used:

Code Facility
0 kernel messages
1 user-level messages
2 mail system
3 system daemons
4 security/authorization messages
5 messages generated internally by syslogd
6 line printer subsystem
7 network news subsystem
8 UUCP subsystem
9 clock daemon
10 security/authorization messages
11 FTP daemon
12 NTP subsystem
13 log audit
14 log alert
15 clock daemon
16 local use 0 (local0)
You can specify either single facility code or facility code range (by using two numbers separated by minus sign). For
example:
<facility>7</facility>
will match records with facility code equal 7, and
<facility>10-20</facility>
will match records with facility code in range from 10 to 20 (inclusive). This tag has no effect for text log files, and
can be used as a synonym for <id> tag for Windows Event Log monitoring.
18.7.7 <tag> Tag
Tag <tag> can be used to filter syslog records (received by NetXMS built-in syslog server) by content of tag field.
You can specify exact value or pattern with * and ? meta characters.
Some examples:
<tag>httpd</tag>
will match records with tag “httpd” (case-insensitive), and
<tag>X*</tag>
will match records with tag started from letter X. This tag has no effect for text log files, and can be used as a synonym
for <source> tag for Windows Event Log monitoring.
18.7. Matching rules 243

18.7.8 <severity> Tag
Tag <severity> can be used to filter syslog records (received by NetXMS built-in syslog server) by severity level.
Each severity level has it’s own code, and to filter by multiple severity levels you should specify sum of appropriate
codes. Severity level codes are following:
Code Severity
1 Emergency
2 Alert
4 Critical
8 Error
16 Warning
32 Notice
64 Informational
128 Debug
Some examples:
<severity>1</severity>
will match all records with severity level Emergency, and
<severity>6</severity>
will match all records with severity level Alert or Critical. This tag has no effect for text log files, and can be used as
a synonym for <level> tag for Windows Event Log monitoring.
18.7.9 <description> Tag
Tag <description> contains textual description of the rule, which will be shown in parser trace.
18.7.10 <event> Tag
Tag <event> defines event to be generated if current log record match to regular expression defined in <match>
tag. Inside <event> tag you should specify event name or event code to be generated. All matched capture groups
will be given to the event as an event parameters.
Event tag has tag attribute. If the attribute is set, then it will be added to the selected event tag list.
18.7.11 <context> Tag
Tag <context> defines activation or deactivation of contexts. This option can be used for multi line match. First
line sets context and next generates event in case if context was set. Examples can be found further in Examples of
Parser Definition File section.
It has the following format:
<context action="action" reset="reset mode">context name</context>
Possible actions are:

Action Description
clear Deactivate (clear “active” flag of) given context.
set Activate (set “active” flag of) given context.
reset Defines how context will be deactivated
Possible values for reset mode are:
Reset Description
mode
auto Deactivate context automatically after first match in context (match rule with context attribute set
to given context).
manual Context can be deactivated only by explicit <context action="clear"> statement.
Both action and reset attributes can be omitted; default value for action is set, and default value for reset
is auto.
18.7.12 <exclusionSchedules> Tag
Tag <exclusionSchedules> defines time when file should not be parsed. Each cron expression should be defined
in <schedule>. This should be used to define time when file should not be opened. Once time does not match cron
file will be reopened and all added lines will be parsed. See Cron format for supported cron format options.
Example:
<parser>
<file>/var/log/messages</file>
<rules>
<rule>
<match>error</match>
<event>USR_APP_ERROR</event>
</rule>
</rules>
<exclusionSchedules>
<schedule>0-2 0 * * *</schedule>
</exclusionSchedules>
</parser>
18.8 Examples of Parser Definition File
Generate event with name USR_APP_ERROR if line in the log file /var/log/messages contains word error:
<parser>
<file>/var/log/messages</file>
<rules>
<rule>
<match>error</match>
<event>USR_APP_ERROR</event>
</rule>
</rules>
</parser>
18.8. Examples of Parser Definition File 245

Generate event with name SYS_PROCESS_START_FAILED if line in the log file C:\demo.log contains word
process: and is immediately following line containing text process startup failed; everything after word
process: will be sent as event’s parameter:
<parser>
<file>C:\demo.log</file>
<rules>
<rule>
<match>process startup failed</match>
<context action="set" reset="auto">STARTUP_FAILED</context>
</rule>
<rule context="STARTUP_FAILED">
<match>process:(.*)</match>
<event>SYS_PROCESS_START_FAILED</event>
</rule>
</rules>
</parser>
18.9 Passing parameters to events
The log parser can send parameters to events. All capture groups will be sent to the event as parameters. For Windows
additional parameters are provided.
Number Description
1 to n Capture groups
n+1 Windows publisher name
n+2 Windows event id
n+3 Windows severity
n+4 Windows record Id
n+5 to k Windows event strings
Consider the following line is received via syslog, or added to a monitored file:
24.04.2015 12:22:15 1 5 system,error,critical login failure for user testUser from 11.
˓→2.33.41 via ssh
We can extract username and login method from the syslog message, and pass it as parameters to an event with the
following rule:
<match>system,error,critical login failure for user (.*) from .* via (.*)</match>

Username will be sent to the event as %1, IP address will not be sent, and login method will be sent as %2.

18.10 Log parser parameters
Log parser provides some additional statistic information through Metrics. Metrics take name of particular parser as
an argument. If name is not set, then file name is used.
Statistic information is reset on agent startup and when log parser policy is reapplied.
Available parameters:
Name Description
LogWatch.Parser.Status(name)
Parser name status
LogWatch.Parser.MatchedRecords(name)
Number of records matched by parser name
LogWatch.Parser.ProcessedRecords(name)
Number of records processed by parser name
Available list parameters:
Name Description
LogWatch.ParserList
List of parser names. If no name is defined then parser file name will be used.
18.10. Log parser parameters 247


CHAPTER
NINETEEN
WINDOWS EVENT LOG SYNCHRONIZATION
NetXMS can collect and centrally store Windows event logs. Collection is performed by NetXMS agents. It’s possible
to filter by log type, Source and Event IDs at agent side to reduce network traffic consumption.
Windows events received by NetXMS server are stored in the database and can later be viewed in View → Windows
event log. Upon reception event logs can be parsed according to rules and NetXMS events can be generated.
19.1 Agent Configuration for Event Log Synchronization
Agent configuration to enable Windows Event Log Synchronization can be done in two ways:
1. In agent’s configuration file
2. Using Agent Configuration policy. For more information see Agent Policies.
Windows Event Log Synchronization subagent should be enabled in agent configuration:
SubAgent=wineventsync.nsm
Logs that should be monitored (Application, Security, etc) are specified in WinEventSync section:
[WinEventSync]
EventLog=Application
EventLog=Security
EventLog=System
With above configuration all records in the specified logs will be synchronized. It is possible to configure per-log
settings to filter only part of records. Per-log configuration is specified in sections named according to log name, e.g.
WinEventSync/System.
Filtering by Event IDs is done using parameters IncludeEvent and ExcludeEvent. You can configure a range
like 100-200. Comma separated lists are not supported, you can however add multiple Include/ExcludeEvent lines.
By default, if no IncludeEvent or ExcludeEvent are given, all IDs in that log will be synced. Explicit Includes
override Excludes. So if you configure an IncludeEvent=201 and an ExcludeEvent=200-300, you will receive all
Events except 200 and 202-300.
To exclude all Event IDs, use ExcludeEvent=0-65535, then you can use IncludeEvent to select only the IDs
you need.
[WinEventSync/Security]
IncludeEvent=4624-4625
IncludeEvent=4800-4803
ExcludeEvent=0-65535
249
Filtering by Source is done using parameters IncludeSource and ExcludeSource. By default, if no

IncludeSource are ExcludeSource are given, all sources in that log will be synchronized. You can use
ExcludeSource=* to exclude every source and speficy IncludeSource to override the exclude for specific
sources.
[WinEventSync/System]
IncludeSource=Microsoft-Windows-WindowsUpdateClient
ExcludeSource=*
Filtering by severity level (also called event type in older Windows versions) is done using parameter
SeverityFilter. Each severity level has it’s own numeric value, and to filter by multiple severity levels you
should specify sum of appropriate values (bitmask). Or alternatively you can specify severity level names separated
by commas. Below are level names and their values:
Severity level name Hexadecimal Decimal value

value
Error 0x001 1
Warning 0x002 2
Information 0x004 4
AuditSuccess 0x008 8
AuditFailure 0x010 16
Critical 0x100 256
Below examples will have same result of filtering only Warning and Error records:
SeverityFilter = 0x012
SeverityFilter = 18
SeverityFilter = Warning,Error
Agent log mesages related to windows event log synchronization are written with tag winsyncevent. For de-
bugging you can add DebugTags=winsyncevent:6 to agent configuration - this will set debug level 6 for that
tag.
19.2 Server Configuration for Event Log Synchronization
Upon being received on server Windows events are parsed accoriding to rules defined in Configuration → Windows
event parser. Rules can be edites in two ways - using graphical editor or XML editor. When switching from one editor
to another all entered information is automatically converted.
If Process all checkbox is not set, rules are processed until first match. If it’s set, all rules are always processed.
In the Macros section you can define macros for use in matching rules. For example, it can be useful to define macro
for IP address and use it in matching rules instead of actual regular expression. You can define as many macros as you
wish. Each macro should have unique name, and can be used in matching rules in form @{name}.
A rule can have multiple conditions - regular expression match, severity level, Event ID, Source, log type.
Matching regular expression contains a PCRE compliant regular expression that is used to match Windows event
log records. Parts enclosed in parenthesis are extracted from Windows event log record and passed as arguments of
250 Chapter 19. Windows Event Log Synchronization

generated NetXMS event. You can use macros defined in Macros section. If Invert checkbox is set, Windows event
log record will be considered matching if it does not match regular expression.
Level can be used to filter records from Windows Event log by event severity level (also called event type in older
Windows versions). Each severity level has it’s own numeric value, and to filter by multiple severity levels you should
specify sum of appropriate values (bitmask). Severity level numerical values are the following:
Severity level Decimal value

Error 1
Warning 2
Information 4
Audit Success 8
Audit Failure 16
Critical (only on Windows 7/Windows Server 2008 and higher) 256
Id can be used to filter records from Windows Event Log by event ID. You can specify either single event ID (e.g. 7)
or ID range by using two numbers separated with minus sign (e.g. 10-20 will match records with ID in range from
10 to 20 inclusive).
Source can be used to filter records from Windows Event Log by event source. You can specify exact event source name
or pattern with * and ? meta characters. E.g. Tcpip will match records with event source Tcpip (case-insensitive),
and X* will match records with event source started from letter X.
Log name allows to filter records by Windows Event Log name. You can specify exact name or pattern with * and ?
meta characters.
Description contains textual description of the rule. It is printed in parser trace in the log file.
When a rule is mathed the following actions can be performed:
• Generate NetXMS event. Event generation is optional - it could be useful to have rules that work as
exclusion - match specific conditions and do not perform any actions.
• Break. In this case the following rules will not be processed even if Process all is set.
• Do not save to database. If this is set,
mached Windows Event Log record will not be saved to the database.
19.3 Passing parameters to events
The log parser can send parameters to events. All capture groups will be sent to the event as parameters.
Number Description
1 to n Capture groups
19.3. Passing parameters to events 251

252 Chapter 19. Windows Event Log Synchronization

CHAPTER
TWENTY
SSH MONITORING
NetXMS can execute commands via SSH connection and save the output as DCI values.
SSH connection are always established via agent. For this to work, ssh.nsm subagent should be enabled in agent
config file.
Subagent uses built-in libssh. It reads configuration in standard ssh format from ~/.ssh/config. It’s also possible to
specify custom location for configuration file by adding ConfigFile= into [SSH] section of agent configuration
file.
If zoning is not used, agent running on NetXMS server is used for SSH connections. If zoning is used, zone proxies
are used (and if a zone has no proxies configured, agent on NetXMS server is used as last resort).
Username and password are specified in Node properties -> Communications -> SSH. If proxy node is specified on
this property page, connection will be performed via that node only.
In DCI properties SSH origin should be chosen. Parameter is the actual ssh command that is executed.
Only first line of the output is stored as DCI value. For numeric data type output is parsed from beginning till first
non-numeric character.
253
There’s also SSH.Command(*) parameter of origin NetXMS Agent that works in a similar way, but target and
credentials are specified as arguments. It’s also necessary to manually specify Source node, otherwise agent of the
monitored node will be used for establishing ssh connection.
SSH.Command(target,login,password,command) %{node_primary_ip} macro
can be used to specify node’s
primary IP address as target.
254 Chapter 20. SSH monitoring

CHAPTER
TWENTYONE
SERVICE MONITORING
There are two options to add service monitoring: the first one is to add it through menu option Create Network
Service. . . as an object with the status that will be propagated on a node, and the second one is to add it’s monitoring
as DCI.
21.1 Network Service
Object representing network service running on a node (like http or ssh), which is accessible online (via TCP IP).
Network Service objects are always created manually. Currently, the system works with the following protocols -
HTTP, POP3, SMTP, Telnet, SSH and Custom protocol type. For Custom protocol, a user should define the TCP
port number and the system will be checking whether that port is available. For the predefined standard services the
system will also check whether an appropriate response is returned. In case of SMTP, the system will send a test mail,
in case of POP3 – try to log in with a certain user, in case of HTTP – check whether the contents of a desired web
page correspond to a certain given template. As soon as the Network Service object is created, it will be automatically
included into the status poll. Each time when the status poll for the particular node is carried out, all Network Service
objects are polled for a reply. If an object’s reply corresponds to a certain condition, its status is set as NORMAL. If
an object is not responding, it’s status will be changed to CRITICAL. It is possible to create a DCI that will collect
status of Network Service object.
In default configuration request is done with help of Port Check subagent on the server node. If it should be done
through different node is should be changed in it’s properties after service creation by selecting Poller node. There is
also possibility to set quantity of polls that is required to be sure that state have changed.
255
21.2 Service monitoring using DCI
Second option is to use DCI to monitor service. There are 2 subagents that provide service monitoring metrics:
PortCheck and NetSVC. It is recommended to use NetSVC for all curl supported protocols, as it can check not only
availability, but also response. For unsupported protocols Custom check of PortCheck subagent can be used.
For HTTP services there is also option to use ECS subagent. This subagent has only 3 Metrics. Two of them calculate
hash and last one measure time.
21.2.1 PortCheck configuration
This subagent can be used to check TCP ports and specifically implements checks for common services. It is highly
recommended to use netsvc subagent especially for HTTP and HTTPS monitoring.
When loaded, PORTCHECK subagent adds the following Metrics to node Metric list:
256 Chapter 21. Service monitoring

ServiceCheck.Custom(target,port[,timeout]) Check that TCP port is open on
target. Optional argument timeout
specifies timeout in milliseconds,
if it’s not provided, default time-
out from *PORTCHECK section
of agent’s configuration file will be
used. This is a very simple test that
does nothing more than checking if
the port is open.
ServiceCheck.HTTP(target,[port],URI,hostHeader[,regex[,timeout]]) Check that HTTP service is run-
ning on target. Optional argu-
ment port specifies the port to
connect to, otherwise 80 will be
used. The URI is NOT a URL
it is the host header request URI.
As an example to test URL http:
//www.netxms.org/index.html enter
www.netxms.org:/index.html. host-
Header is currently not used, but
may be the Host option at some
point in the request made. Optional
argument regex is PCRE compli-
ant regular expression to check re-
turned from the request, otherwise
“^HTTP/(1.[01]|2) 200 .*” will be
used. Optional argument timeout
specifies timeout in milliseconds.
ServiceCheck.POP3(target,username,password[,timeout) Check that POP3 service is running
on target and that we are able to lo-
gin using the supplied username and
password. Optional argument time-
out specifies timeout in millisec-
onds.
ServiceCheck.SMTP(target,toAddress[,timeout]) Check that SMTP service is running
on target and that it will accept an
e-mail to toAddress. The e-mail will
be from noreply@DomainName us-
ing the DomainName option in the
config file or its default value (see
below). Optional argument timeout
specifies timeout in milliseconds.
ServiceCheck.SSH(target[,port[,timeout]]) Check that SSH service is running
on target. Optional argument port
specifies the port to connect with,
otherwise 22 will be used. Optional
argument timeout specifies timeout
in milliseconds.
ServiceCheck.Telnet(target[,port[,timeout]]) Check that Telnet service is running
on target. Optional argument port
specifies the port to connect with,
otherwise 23 will be used. Optional
argument timeout specifies timeout
in milliseconds.
21.2. Service monitoring using DCI 257

All of the ServiceCheck.* parameters return the following values:
Value Description
0 Success, connection to target was established and expected response was received.
1 Invalid arguments were passed.
2 Cannot connect to target.
3 Invalid / Unexpected response from target.
All configuration parameters related to PORTCHECK subagent should be placed into *PORTCHECK section of
agent’s configuration file. The following configuration parameters are supported:
Parameter Format Description Default

value
DomainName string Set default domain name for processing. Currently this is only used netxms.org
by SMTP check to set the from e-mail address.
Timeout milliseconds Set default response timeout in milliseconds. 3000
# This sample nxagentd.conf instructs agent to:

# 1. Load PORTCHECK subagent
# 2. Set domain name for from e-mail to netxms.demo
# 3. Default timeout for commands set to 5 seconds (5000 milliseconds)
SubAgent = portcheck.nsm
[portCheck]
DomainName = netxms.demo
Timeout = 5000
21.2.2 NetSVC configuration
This subagent can be used to check network services supported by libcurl. More information about syntax can be
found here: http://curl.haxx.se/docs/manpage.html.
This subagent will add this Metrics to node Metric list:
Service.Check(URL[, regex]) Check if data retrieved from ULR matches regular expression regex.
regexcan be omitted, it that case “^HTTP/(1.[01]|2) 200 .*” will be used.
Service.Check parameter returns the following values:
Value Description
0 Success, connection to target was established and expected response was received.
1 Invalid arguments were passed.
2 Cannot connect to target.
3 Invalid / Unexpected response from target.
HTTP check example:

Service.Check(https://inside.test.ru/,^HTTP/(1\\.[01]|2) 200 .*)
“^HTTP/(1.[01]|2) 200 .*” - this is default value and can be omitted in the expression.
Note: If agent is build from sources, then libcurl-dev should be installed to build netsvc subagent.
21.2.3 ECS
This subagent works with HTTP only. It can be used to measure page load time and checking page hash. Request
timeout for this subagent is 30 seconds.
ECS.HttpSHA1(URL) Calculates SHA1 hash of provided URL
ECS.HttpMD5(URL) Calculates MD5 hash of provided URL
ECS.HttpLoadTime(URL) Measure load time for provided URL
Subagent = ecs.nsm
21.2. Service monitoring using DCI 259


CHAPTER
TWENTYTWO
DATA COLLECTION FROM WEB SERVICES
NetXMS has built-in data collection mechanism using web services, allowing to extract data for DCIs from JSON,
XML, or plain text responses to HTTP requests. Data collection from web services is done via NetXMS agent. If
zoning is not used (or for Default zone), agent running on NetXMS server is used. If zoning is used, zone proxies are
used (and if a zone has no proxies configured, agent on NetXMS server is used as last resort).
22.1 Configuring Web Service Data collection
Starting from version 3.8 of NetXMS agent data collection from web services is disabled by default. To enable it, add
EnableWebServiceProxy=yes to agent configuration file and restart the agent.
22.1.2 Web service definitions
Common configuration related to multiple metrics and nodes is set up in web service definition editor accessible via
Configuration -> Web Service Definitions menu.
261
The following information can be configured:

• Web service name
• Web service URL
• Additional HTTP headers
• Authentication data (authentication type, login, password)
• Cache retention time (in seconds)
• Request timeout (in seconds)
Web service URL and additional HTTP headers fields can contain macros that are expanded when actual request is
made. So you can, for example, set URL as %{url} and keep the actual URL in node’s custom attribute url.
22.1.3 DCI Configuration
DCI configuration provides DCI origin “web service”. Parameter name for this origin contains web service definition
name with optional arguments and path to document element that has to be retrieved (or PCRE compliant regex with
one capture group for text responses).
For example:
• WebService1:/system/cpu/usage
• WebService2(eth0):/stat/bytesIn
• WebService3(10,20,30):^(\d*)
Service arguments can be inserted into request URL or headers using macros %1, %2, and so on. For XML and JSON
responses path to document element should start from /. XML response, according to standard, should have only one
upper level tag. For text response, first capture group of regular expression is returned.
262 Chapter 22. Data Collection from Web Services

22.1.4 Instance discovery
For web service discovery “Web Service” instance discovery method can be used. It accepts web service name with
optional arguments and path to the root element of the document where enumeration will start. Each sub-element of
given root element will be considered separate instance.
For example:
• WebService1:/system/cpu will enumerate all elements under “/system/cpu”
• WebService2(eth0):/stat will enumerate all elements under “/stat”
22.2 Data collection process
Data collection process from server point of view should be following:

1. Server finds web service definition by given name, passes any parameters to it, and gets back URL and headers with
all macros expanded.
2. Server determines agent to be used for request (based on zone settings, node settings, agent availability, etc.).
3. Server sends request to selected agent. Request consists of URL, headers, and document path.
4. Server waits for response from agent and processes retrieved data as for any other DCI type. For instance discov-
ery server provides new instance discovery method - “web service” which accepts web service name with optional
arguments and path to the root element of the document where enumeration will start. Each sub-element of given root
element will be considered separate instance.
Actual requests and response parsing is implemented on agent level. This provides necessary flexibility for accessing
services not directly reachable from management server as well as offload response parsing from server to agents.
Data collection process from agent point of view is following:
1. Agent receives web service request (URL, authentication data, headers) and list of elements to retrieve from server.
2. Agent checks document cache if requested URL was already retrieved and data is within configured cache retention
time. If yes, values of requested elements from cached data is returned to server.
3. Agent performs HTTP request using provided service data. If request is successful retrieved document parsed into
tree form and values of requested elements returned to server. No additional configuration should be required on agent
side.
22.2. Data collection process 263

264 Chapter 22. Data Collection from Web Services

CHAPTER
TWENTYTHREE
DATABASE MONITORING
There are several subagents for database monitoring: DB2, Informix, Oracle, MySQL, MongoDB. Below we will
describe how to configure and use these subagents. Besides it’s also possible to monitor other types of databases
supported by NetXMS server(link to supported database list) using database query subagent as these databases sup-
port receiving performance parameters using queries. This subagent details are described in Application Database
Monitoring chapter.
23.1 Oracle
NetXMS subagent for Oracle DBMS monitoring (further referred to as Oracle subagent) monitors one or more in-
stances of Oracle databases and reports various database-related parameters.
All parameters available from Oracle subagent are collected or calculated once per minute thus it’s recommended to
set DCI poll interval for these items to 60 seconds or more. All parameters are obtained or derived from the data
available in Oracle’s data dictionary tables and views through regular select queries. Oracle subagent does not monitor
any of the metrics related to lower level database layers, such as database processes. Monitoring of such parameters
can be achieved through the standard NetXMS functionality.
23.1.1 Pre-requisites
An Oracle user with the role select_catalog_role assigned.

Required rights can be assigned to user with the following query:
grant select_catalog_role to user;
Where user is the user configured in Oracle subagent for database access.
23.1.2 Configuration file
Oracle subagent can be configured using XML configuration file (usually created as separate file in configuration
include directory), or in simplified INI format, usually in main agent configuration file.
Database definition supports the following parameters:
265
Parameter Description Default value

Id Database identifier. It will be used to address this database in parame-
ters.
TnsName Database TNS name or connection string.
ConnectionTTL Time in seconds. When this time gets elapsed, connection to the DB is 3600
closed and reopened again.
Username User name for connecting to database.
Password Database user password. When using INI format, remember to enclose
password in double quotes (“password”) if it contains # character. This
parameter automatically detects and accepts password encrypted with
nxencpasswd tool.
EncryptedPassword Database user password encrypted with nxencpasswd tool. DEPRE-
CATED. Use Password instead.
XML configuration allows to specify multiple databases in the oracle section. Each database description must be
surrounded by database tags with the id attribute. It can be any unique integer and instructs the Oracle subagent about
the order in which database sections will be processed.
Sample Oracle subagent configuration file in XML format:
<config>
<agent>
<subagent>oracle.nsm</subagent>
</agent>
<oracle>
<databases>
<database id="1">
<id>DB1</id>
<tnsname>TEST</tnsname>
<username>NXMONITOR</username>
<password>NXMONITOR</password>
</database>
<database id="2">
<id>DB2</id>
<tnsname>PROD</tnsname>
<username>NETXMS</username>
<password>PASSWORD</password>
</database>
</databases>
</oracle>
</config>
You can specify only one database when using INI configuration format. If you need to monitor multiple databases
from same agent, you should use configuration file in XML format.
Sample Oracle subagent configuration file in INI format:
[ORACLE]
ID = DB1
Name = TEST
Username = dbuser
Password = "mypass123"
266 Chapter 23. Database monitoring

23.1.3 Parameters
When loaded, Oracle subagent adds the following parameters to agent (all parameters require database ID as first
argument):
Oracle.CriticalStats.AutoArchivingOff(dbid) Archive logs enabled but auto archiving off (YES/NO)
Oracle.CriticalStats.DatafilesNeedMediaRecovery(dbid) Number of datafiles that need media recovery
Oracle.CriticalStats.DFOffCount(dbid) Number of offline datafiles
Oracle.CriticalStats.FailedJobs(dbid) Number of failed jobs
Oracle.CriticalStats.FullSegmentsCount(dbid) Number of segments that cannot extend
Oracle.CriticalStats.RBSegsNotOnlineCount(dbid) Number of rollback segments not online
Oracle.CriticalStats.TSOffCount(dbid) Number of offline tablespaces
Oracle.Cursors.Count(dbid) Current number of opened cursors system-wide
Oracle.DataFile.AvgIoTime(dbid, datafile) Average time spent on single I/O operation for datafile in milliseconds
Oracle.DataFile.Blocks(dbid, datafile) datafile size in blocks
Oracle.DataFile.BlockSize(dbid, datafile) datafile block size
Oracle.DataFile.Bytes(dbid, datafile) datafile size in bytes
Oracle.DataFile.FullName(dbid, datafile) datafile full name
Oracle.DataFile.MaxIoReadTime(dbid, datafile) Maximum time spent on a single read for datafile in milliseconds
Oracle.DataFile.MaxIoWriteTime(dbid, datafile) Maximum time spent on a single write for datafile in milliseconds
Oracle.DataFile.MinIoTime(dbid, datafile) Minimum time spent on a single I/O operation for datafile in milliseconds
Oracle.DataFile.PhysicalReads(dbid, datafile) Total number of physical reads from datafile
Oracle.DataFile.PhysicalWrites(dbid, datafile) Total number of physical writes to datafile
Oracle.DataFile.ReadTime(dbid, datafile) Total read time for datafile in milliseconds
Oracle.DataFile.Status(dbid, datafile) datafile status
Oracle.DataFile.Tablespace(dbid, datafile) datafile tablespace
Oracle.DataFile.WriteTime(dbid, datafile) Total write time for datafile in milliseconds
Oracle.DBInfo.CreateDate(dbid) Database creation date
Oracle.DBInfo.IsReachable(dbid) Database is reachable (YES/NO)
Oracle.DBInfo.LogMode(dbid) Database log mode
Oracle.DBInfo.Name(dbid) Database name
Oracle.DBInfo.OpenMode(dbid) Database open mode
Oracle.DBInfo.Version(dbid) Database version
Oracle.Dual.ExcessRows(dbid) Excessive rows in DUAL table
Oracle.Instance.ArchiverStatus(dbid) Archiver status
Oracle.Instance.Status(dbid) Database instance status
Oracle.Instance.ShutdownPending(dbid) Is shutdown pending (YES/NO)
Oracle.Instance.Version(dbid) DBMS Version
Oracle.Objects.InvalidCount(dbid) Number of invalid objects in DB
Oracle.Performance.CacheHitRatio(dbid) Data buffer cache hit ratio
Oracle.Performance.DictCacheHitRatio(dbid) Dictionary cache hit ratio
Oracle.Performance.DispatcherWorkload(dbid) Dispatcher workload (percentage)
Oracle.Performance.FreeSharedPool(dbid) Free space in shared pool (bytes)
Oracle.Performance.Locks(dbid) Number of locks
Oracle.Performance.LogicalReads(dbid) Number of logical reads
Oracle.Performance.LibCacheHitRatio(dbid) Library cache hit ratio
Oracle.Performance.MemorySortRatio(dbid) PGA memory sort ratio
Oracle.Performance.PhysicalReads(dbid) Number of physical reads
Oracle.Performance.PhysicalWrites(dbid) Number of physical writes
Oracle.Performance.RollbackWaitRatio(dbid) Ratio of waits for requests to rollback segments
23.1. Oracle 267


Oracle.Sessions.Count(dbid) Number of sessions opened
Oracle.Sessions.CountByProgram(dbid, program) Number of sessions opened by specific program
Oracle.Sessions.CountBySchema(dbid, schema) Number of sessions opened with specific schema
Oracle.Sessions.CountByUser(dbid, user) Number of sessions opened with specific Oracle user
Oracle.TableSpace.BlockSize(dbid, tablespace) tablespace block size
Oracle.TableSpace.DataFiles(dbid, tablespace) Number of datafiles in tablespace
Oracle.TableSpace.FreeBytes(dbid, tablespace) Free bytes in tablespace
Oracle.TableSpace.FreePct(dbid, tablespace) Free space percentage in tablespace
Oracle.TableSpace.Logging(dbid, tablespace) tablespace logging mode
Oracle.TableSpace.Status(dbid, tablespace) tablespace status
Oracle.TableSpace.TotalBytes(dbid, tablespace) Total size in bytes of tablespace
Oracle.TableSpace.Type(dbid, tablespace) tablespace type
Oracle.TableSpace.UsedBytes(dbid, tablespace) Used bytes in tablespace
Oracle.TableSpace.UsedPct(dbid, tablespace) Used space percentage in tablespace
23.1.4 Lists
When loaded, Oracle subagent adds the following lists to agent:
List Description
Oracle.DataFiles(dbid) All known datafiles in database identified by dbid.
Oracle.DataTags(dbid) All data tags for database identified by dbid. Used only for internal diagnostics.
Oracle.TableSpaces(dbid) All known tablespaces in database identified by dbid.
23.1.5 Tables
When loaded, Oracle subagent adds the following tables to agent:
Table Description
Oracle.DataFiles(dbid) Datafiles in database identified by dbid.
Oracle.Sessions(dbid) Open sessions in database identified by dbid.
Oracle.TableSpaces(dbid) Tablespaces in database identified by dbid.
23.2 DB2
NetXMS subagent for DB2 monitoring is designed to provide a way to extract various parameters known as Data
Collection Items (DCI) from an instance or several instances of DB2 database.

DB2 subagent can be configured in two ways. The first one would be a simple INI file and the second one would be
an XML configuration file. Please note that to use the XML configuration, you first need to declare the XML file in
the DB2 section of the INI configuration file. The details are below.
Database definition supports the following parameters:
Parameter Format Description Default value

DBName string The name of the database to connect to
DBAlias string The alias of the database to connect to
UserName string The name of the user for the database to connect to
Password string The password for the database to connect to. When using
INI format, remember to enclose password in double quotes
(“password”) if it contains # character. This parameter au-
tomatically detects and accepts password encrypted with nx-
encpasswd tool.
EncryptedPassword
string Database user password encrypted with nxencpasswd tool.
DEPRECATED. Use Password instead.
QueryInterval seconds The interval to perform queries with 60
ReconnectIntervalseconds The interval to try to reconnect to the database if the connec- 30
tion was lost or could not be established
Sample DB2 subagent configuration file in INI format:
SubAgent = db2.nsm
[DB2]
DBName = dbname
DBAlias = dbalias
UserName = dbuser
Password = "mypass123"
QueryInterval = 60
ReconnectInterval = 30
XML configuration allows the monitoring of several database instances.

To be able to use the XML configuration file, you first need to specify the file to use in the DB2 section of the INI file.
The syntax is as follows:
SubAgent = db2.nsm
[DB2]
ConfigFile = /myhome/configs/db2.xml
Parameter Format Description Default value

ConfigFile string The path to the XML configuration file
The XML configuration file itself should look like this:
<config>
<db2sub>
<db2 id="1">
<dbname>dbname</dbname>
23.2. DB2 269


<dbalias>dbalias</dbalias>
<username>dbuser</username>
<password>mypass123</password>
<queryinterval>60</queryinterval>
<reconnectinterval>30</reconnectinterval>
</db2>
<db2 id="2">
<dbname>dbname1</dbname>
<dbalias>dbalias1</dbalias>
<username>dbuser1</username>
<password>mypass456</password>
<queryinterval>60</queryinterval>
<reconnectinterval>30</reconnectinterval>
</db2>
</db2sub>
</config>
As you can see, the parameters are the same as the ones from the INI configuration. Each database declaration must
be placed under the db2sub tag and enclosed in the db2 tag. The db2 tag must have a numerical id which has to be
a positive integer greater than 0.
Provided parameters
To get a DCI from the subagent, you need to specify the id from the db2 entry in the XML configuration file (in case
of INI configuration, the id will be 1). To specify the id, you need to add it enclosed in brackets to the name of the
parameter that is being requested (e.g., db2.parameter.to.request(**1**)). In the example, the parameter
db2.parameter.to.request from the database with the id 1 will be returned.
Parameter Arguments Return Description

type
DB2.Instance.Version(*) Database id DCI_DT_STRING
DBMS version
DB2.Table.Available(*) Database id DCI_DT_INT The number of available tables
DB2.Table.Unavailable(*) Database id DCI_DT_INT The number of unavailable tables
DB2.Table.Data.LogicalSize(*)Database id DCI_DT_INT64Data object logical size in kilobytes
DB2.Table.Data.PhysicalSize(*)Database id DCI_DT_INT64Data object physical size in kilobytes
DB2.Table.Index.LogicalSize(*)
Database id DCI_DT_INT64Index object logical size in kilobytes
DB2.Table.Index.PhysicalSize(*)
Database id DCI_DT_INT64Index object physical size in kilobytes
DB2.Table.Long.LogicalSize(*)Database id DCI_DT_INT64Long object logical size in kilobytes
DB2.Table.Long.PhysicalSize(*)
Database id DCI_DT_INT64Long object physical size in kilobytes
DB2.Table.Lob.LogicalSize(*) Database id DCI_DT_INT64LOB object logical size in kilobytes
DB2.Table.Lob.PhysicalSize(*)Database id DCI_DT_INT64LOB object physical size in kilobytes
DB2.Table.Xml.LogicalSize(*)Database id DCI_DT_INT64XML object logical size in kilobytes
DB2.Table.Xml.PhysicalSize(*)Database id DCI_DT_INT64XML object physical size in kilobytes
DB2.Table.Index.Type1(*) Database id DCI_DT_INT The number of tables using type-1 indexes
DB2.Table.Index.Type2(*) Database id DCI_DT_INT The number of tables using type-2 indexes
DB2.Table.Reorg.Pending(*) Database id DCI_DT_INT The number of tables pending reorganization
DB2.Table.Reorg.Aborted(*) Database id DCI_DT_INT The number of tables in aborted reorganization state
DB2.Table.Reorg.Executing(*)Database id DCI_DT_INT The number of tables in executing reorganization
state
DB2.Table.Reorg.Null(*) Database id DCI_DT_INT The number of tables in null reorganization state
DB2.Table.Reorg.Paused(*) Database id DCI_DT_INT The number of tables in paused reorganization state


type
DB2.Table.Reorg.Alters(*) Database id DCI_DT_INT The number of reorg recommend alter operations
DB2.Table.Load.InProgress(*) Database id DCI_DT_INT The number of tables with load in progress status
DB2.Table.Load.Pending(*) Database id DCI_DT_INT The number of tables with load pending status
DB2.Table.Load.Null(*) Database id DCI_DT_INT The number of tables with load status neither in
progress nor pending
DB2.Table.Readonly(*) Database id DCI_DT_INT The number of tables in Read Access Only state
DB2.Table.NoLoadRestart(*) Database id DCI_DT_INT The number of tables in a state that won’t allow a
load restart
DB2.Table.Index.Rebuild(*) Database id DCI_DT_INT The number of tables with indexes that require re-
build
DB2.Table.Rid.Large(*) Database id DCI_DT_INT The number of tables that use large row IDs
DB2.Table.Rid.Usual(*) Database id DCI_DT_INT The number of tables that don’t use large row IDs
DB2.Table.Rid.Pending(*) Database id DCI_DT_INT The number of tables that use large row Ids but not
all indexes have been rebuilt yet
DB2.Table.Slot.Large(*) Database id DCI_DT_INT The number of tables that use large slots
DB2.Table.Slot.Usual(*) Database id DCI_DT_INT The number of tables that don’t use large slots
DB2.Table.Slot.Pending(*) Database id DCI_DT_INT The number of tables that use large slots but there
has not yet been an offline table reorganization or
table truncation operation
DB2.Table.DictSize(* Database id DCI_DT_INT64Size of the dictionary in bytes
DB2.Table.Scans(*) Database id DCI_DT_INT64The number of scans on all tables
DB2.Table.Row.Read(*) Database id DCI_DT_INT64The number of reads on all tables
DB2.Table.Row.Inserted(*) Database id DCI_DT_INT64The number of insertions attempted on all tables
DB2.Table.Row.Updated(*) Database id DCI_DT_INT64The number of updates attempted on all tables
DB2.Table.Row.Deleted(*) Database id DCI_DT_INT64The number of deletes attempted on all tables
DB2.Table.Overflow.Accesses(*)
Database id DCI_DT_INT64The number of r/w operations on overflowed rows
of all tables
DB2.Table.Overflow.Creates(*)Database id DCI_DT_INT64The number of overflowed rows created on all tables
DB2.Table.Reorg.Page(*) Database id DCI_DT_INT64The number of page reorganizations executed for all
tables
DB2.Table.Data.LogicalPages(*)
Database id DCI_DT_INT64The number of logical pages used on disk by data
DB2.Table.Lob.LogicalPages(*)Database id DCI_DT_INT64The number of logical pages used on disk by LOBs
DB2.Table.Long.LogicalPages(*)
Database id DCI_DT_INT64The number of logical pages used on disk by long
data
DB2.Table.Index.LogicalPages(*)
Database id DCI_DT_INT64The number of logical pages used on disk by in-
dexes
DB2.Table.Xda.LogicalPages(*)Database id DCI_DT_INT64The number of logical pages used on disk by XDA
(XML storage object)
DB2.Table.Row.NoChange(*) Database id DCI_DT_INT64The number of row updates that yielded no changes
DB2.Table.Lock.WaitTime(*) Database id DCI_DT_INT64The total elapsed time spent waiting for locks (ms)
DB2.Table.Lock.WaitTimeGlob(*)
Database id DCI_DT_INT64The total elapsed time spent on global lock waits
(ms)
DB2.Table.Lock.Waits(*) Database id DCI_DT_INT64The total amount of locks occurred
DB2.Table.Lock.WaitsGlob(*) Database id DCI_DT_INT64The total amount of global locks occurred
DB2.Table.Lock.EscalsGlob(*)Database id DCI_DT_INT64The number of lock escalations on a global lock
DB2.Table.Data.Sharing.Shared(*)
Database id DCI_DT_INT The number of fully shared tables
DB2.Table.Data.Sharing.BecomingShared(*)
Database id DCI_DT_INT The number of tables being in the process of becom-
ing shared
DB2.Table.Data.Sharing.NotShared(*)
Database id DCI_DT_INT The number of tables not being shared
23.2. DB2 271


type
DB2.Table.Data.Sharing.BecomingNotShared(*)
Database id DCI_DT_INT The number of tables being in the process of becom-
ing not shared
DB2.Table.Data.Sharing.RemoteLockWaitCount(*)
Database id DCI_DT_INT64The number of exits from the NOT_SHARED data
sharing state
DB2.Table.Data.Sharing.RemoteLockWaitTime(*)
Database id DCI_DT_INT64The time spent on waiting for a table to become
shared
DB2.Table.DirectWrites(*) Database id DCI_DT_INT64The number of write operations that don’t use the
buffer pool
DB2.Table.DirectWriteReqs(*)Database id DCI_DT_INT64The number of request to perform a direct write op-
eration
DB2.Table.DirectRead(*) Database id DCI_DT_INT64The number of read operations that don’t use the
buffer pool
DB2.Table.DirectReadReqs(*) Database id DCI_DT_INT64The number of request to perform a direct read op-
eration
DB2.Table.Data.LogicalReads(*)
Database id DCI_DT_INT64The number of data pages that are logically read
from the buffer pool
DB2.Table.Data.PhysicalReads(*)
Database id DCI_DT_INT64The number of data pages that are physically read
DB2.Table.Data.Gbp.LogicalReads(*)
Database id DCI_DT_INT64The number of times that a group buffer pool (GBP)
page is requested from the GBP
DB2.Table.Data.Gbp.PhysicalReads(*)
page is read into the local buffer pool (LBP)
DB2.Table.Data.Gbp.InvalidPages(*)
page is requested from the GBP when the version
stored in the local buffer pool (LBP) is invalid
DB2.Table.Data.Lbp.PagesFound(*)
Database id DCI_DT_INT64The number of times that a data page is present in
the local buffer pool (LBP)
DB2.Table.Data.Lbp.IndepPagesFound(*)
Database id DCI_DT_INT64The number of group buffer pool (GBP) indepen-
dent pages found in a local buffer pool (LBP)
DB2.Table.Xda.LogicalReads(*)
Database id DCI_DT_INT64The number of data pages for XML storage objects
(XDA) that are logically read from the buffer pool
DB2.Table.Xda.PhysicalReads(*)
Database id DCI_DT_INT64The number of data pages for XML storage objects
(XDA) that are physically read
DB2.Table.Xda.Gbp.LogicalReads(*)
Database id DCI_DT_INT64The number of times that a data page for an XML
storage object (XDA) is requested from the group
buffer pool (GBP)
DB2.Table.Xda.Gbp.PhysicalReads(*)
dependent data page for an XML storage object
(XDA) is read into the local buffer pool (LBP)
DB2.Table.Xda.Gbp.InvalidPages(*)
Database id DCI_DT_INT64The number of times that a page for an XML storage
objects (XDA) is requested from the group buffer
pool (GBP) because the version in the local buffer
pool (LBP) is invalid
DB2.Table.Xda.Lbp.PagesFound(*)
Database id DCI_DT_INT64The number of times that an XML storage objects
(XDA) page is present in the local buffer pool (LBP)
DB2.Table.Xda.Gbp.IndepPagesFound(*)
Database id DCI_DT_INT64The number of group buffer pool (GBP) indepen-
dent XML storage object (XDA) pages found in the
local buffer pool (LBP)
DB2.Table.DictNum(*) Database id DCI_DT_INT64The number of page-level compression dictionaries
created or recreated


type
DB2.Table.StatsRowsModified(*)
Database id DCI_DT_INT64The number of rows modified since the last RUN-
STATS
DB2.Table.ColObjectLogicalPages(*)
Database id DCI_DT_INT64The number of logical pages used on disk by
column-organized data
DB2.Table.Organization.Rows(*)
Database id DCI_DT_INT The number of tables with row-organized data
DB2.Table.Organization.Cols(*)
Database id DCI_DT_INT The number of tables with column-organized data
DB2.Table.Col.LogicalReads(*)Database id DCI_DT_INT The number of column-organized pages that are log-
ically read from the buffer pool
DB2.Table.Col.PhysicalReads(*)
Database id DCI_DT_INT The number of column-organized pages that are
physically read
DB2.Table.Col.Gbp.LogicalReads(*)
Database id DCI_DT_INT The number of times that a group buffer pool (GBP)
dependent column-organized page is requested from
the GBP
DB2.Table.Col.Gbp.PhysicalReads(*)
Database id DCI_DT_INT The number of times that a group buffer pool (GBP)
dependent column-organized page is read into the
local buffer pool (LBP) from disk
DB2.Table.Col.Gbp.InvalidPages(*)
Database id DCI_DT_INT The number of times that a column-organized page
is requested from the group buffer pool (GBP) when
the page in the local buffer pool (LBP) is invalid
DB2.Table.Col.Lbp.PagesFound(*)
Database id DCI_DT_INT The number of times that a column-organized page
is present in the local buffer pool (LBP)
DB2.Table.Col.Gbp.IndepPagesFound(*)
Database id DCI_DT_INT The number of group buffer pool (GBP) indepen-
dent column-organized pages found in the local
buffer pool (LBP)
DB2.Table.ColsReferenced(*) Database id DCI_DT_INT The number of columns referenced during the exe-
cution of a section for an SQL statement
DB2.Table.SectionExecutions(*)
Database id DCI_DT_INT The number of section executions that referenced
columns in tables using a scan
23.3 MongoDB
New in version 2.0-M3.

NetXMS subagent for MongoDB monitoring. Monitors one or more instances of MongoDB databases and reports
various database-related parameters.
All parameters available from MongoDB subagent gathered or calculated once per minute thus it’s recommended to
set DCI poll interval for these items to 60 seconds or more. It is supposed that only databases with same version are
monitored by one agent.
23.3. MongoDB 273

23.3.1 Building mongodb subagent
Use --with-mongodb=/path/to/mongoc driver parameter to include MongoDB subagent in build. Was

tested with mongo-c-driver-1.1.0.
23.3.2 Agent Start
While start of subagent at least one database should be up and running. Otherwise subagent will not start. On start
subagent requests serverStatus to get list of possible DCI. This list may vary from version to version of MongoDB.
23.3.4 Parameters
There are 2 types of parameters: serverStatus parameters, that are generated from response on a subagent start and
predefined for database status.
Description of serverStatus parameters can be found there: serverStatus. In this type of DCI should be given id of
server from where parameter should be taken.
Description of database status parameters can be found there: dbStats.
MongoDB.collectionsNum(id,databaseName)
Contains a count of the number of collections in that database.
MongoDB.objectsNum(id,databaseName)
Contains a count of the number of objects (i.e. documents) in the database
across all collections.
MongoDB.avgObjSize(id,databaseName)
The average size of each document in bytes.
MongoDB.dataSize(id,databaseName)The total size in bytes of the data held in this database including the padding
factor.
MongoDB.storageSize(id,databaseName)
The total amount of space in bytes allocated to collections in this database
for document storage.
MongoDB.numExtents(id,databaseName)
Contains a count of the number of extents in the database across all collec-
tions.
MongoDB.indexesNum(id,databaseName)
Contains a count of the total number of indexes across all collections in the
database.
MongoDB.indexSize(id,databaseName)The total size in bytes of all indexes created on this database.
MongoDB.fileSize(id,databaseName) The total size in bytes of the data files that hold the database.
MongoDB.nsSizeMB(id,databaseName) The total size of the namespace files (i.e. that end with .ns) for this database.
23.3.5 List
MongoDB.ListDatabases(id) Returns list of databases existing on this server

23.4 Informix
NetXMS subagent for Informix (further referred to as Informix subagent) monitors one or more Informix databases
and reports database-related parameters.
All parameters available from Informix subagent are collected or calculated once per minute, thus its recommended
to set DCI poll interval for these items to 60 seconds or more. All parameters are obtained or derived from the data
available in Informix system catalogs. Informix subagent does not monitor any of the metrics related to lower level
database layers, such as database processes. Monitoring of such parameters can be achieved through the standard
NetXMS functionality.
A database user must have access rights to Informix system catalog tables.
You can specify multiple databases in the informix section. Each database description must be surrounded by database
tags with the id attribute. Id can be any unique integer, it instructs the Informix subagent about the order in which
database sections will be processed.
Each database definition supports the following parameters:
Id Database identifier. It will be used to address this database in parameters.
DBName Database name. This is a name of Informix DSN.
DBServer Name of the Informix server.
DBLogin User name for connecting to database.
DBPassword The password for the database to connect to. When using INI format, re-
member to enclose password in double quotes (“password”) if it contains #
character. This parameter automatically detects and accepts password en-
crypted with nxencpasswd tool.
Configuration example in INI format:

Subagent=informix.nsm
[informix]
ID=db1
DBName = instance1
DBLogin = user
DBPassword = "password"
Configuration example in XML format:

<config>
<agent>
<subagent>informix.nsm</subagent>
</agent>
<informix>
<databases>
<database id="1">
<id>DB1</id>
23.4. Informix 275


<DBName>TEST</DBName>
<DBLogin>NXMONITOR</DBLogin>
<DBPassword>NXMONITOR</DBPassword>
</database>
<database id="2">
<id>DB2</id>
<DBName>PROD</DBName>
<DBLogin>NETXMS</DBLogin>
<DBPassword>PASSWORD</DBPassword>
</database>
</databases>
</informix>
</config>
Provided parameters
To get a DCI from the subagent, you need to specify the id from the informix entry in configuration file. To specify
the id, you need to add it enclosed in brackets to the name of the parameter that is being requested (e.g., informix.
parameter.to.request(**1**)). In the example, the parameter informix.parameter.to.request
from the database with the id 1 will be returned.

type
Informix.Session.Count(*) Database id DCI_DT_INT Number of sessions opened
Informix.Database.Owner(*) Database id DCI_DT_STRING
The database creation date
Informix.Database.Logged(*) Database id DCI_DT_INT Returns 1 if the database is logged, 0 - otherwise
Informix.Dbspace.Pages.PageSize(*)
Database id DCI_DT_INT A size of a dbspace page in bytes
Informix.Dbspace.Pages.PageSize(*)
Database id DCI_DT_INT A number of pages used in the dbspace
Informix.Dbspace.Pages.Free(*)Database id DCI_DT_INT A number of free pages in the dbspace
Informix.Dbspace.Pages.FreePerc(*)
Database id DCI_DT_INT Percentage of free space in the dbspace
23.5 MySQL
NetXMS subagent for MySQL monitoring. Monitors one or more instances of MySQL databases and reports various
database-related parameters.
MySQL subagent requires MySQL driver to be available in the system.
You can specify one or multiple databases in the MySQL section. In case of single database definition simply set all
required parameters under [mysql] section. In multi database configuration define each database under mysql/
databases/<name> section with unique <name> for each database. If no id provided <name> of the section will
be used as a database id.
Each database definition supports the following parameters:


Id Database identifier. It will be used to address this localdb - for single DB definition; last part of sec-
database in parameters. tion name - for multi database definition
Database Database name. This is a name of MySQL DSN. information_schema
Server Name or IP of the MySQL server. 127.0.0.1
ConnectionTTL
Time in seconds. When this time gets elapsed, 3600
connection to the DB is closed and reopened
again.
Login User name for connecting to database. netxms
Password Database user password. When using INI format,
remember to enclose password in double quotes
(“password”) if it contains # character. This pa-
rameter automatically detects and accepts pass-
word encrypted with nxencpasswd tool.
Single database configuration example:
Subagent=mysql.nsm
[mysql]
Id=db1
Database = instance1
Login = user
Password = password
Multi database configuration example:
Subagent=mysql.nsm
[mysql/databases/somedatabase]
Database = instance1
Login = user
Password = password
Server = netxms.demo
[mysql/databases/local]
Database = information_schema
Login = user
Password = encPassword
Server = 127.0.0.1
23.5.2 Provided parameters
MySQL.Connections.Aborted(id) aborted connections
MySQL.Connections.BytesReceived(id)
bytes received from all clients
MySQL.Connections.BytesSent(id) bytes sent to all clients
MySQL.Connections.Current(id) number of active connections
MySQL.Connections.CurrentPerc(id) connection pool usage (%)
MySQL.Connections.Failed(id) failed connection attempts
MySQL.Connections.Limit(id) maximum possible number of simultaneous connections
23.5. MySQL 277


MySQL.Connections.Max(id) maximum number of simultaneous connections
MySQL.Connections.MaxPerc(id) maximum connection pool usage (%)
MySQL.Connections.Total(id) cumulative connection count
MySQL.InnoDB.BufferPool.Dirty(id) InnoDB used buffer pool space in dirty pages
MySQL.InnoDB.BufferPool.DirtyPerc(id)
InnoDB used buffer pool space in dirty pages (%)
MySQL.InnoDB.BufferPool.Free(id) InnoDB free buffer pool space
MySQL.InnoDB.BufferPool.FreePerc(id)
InnoDB free buffer pool space (%)
MySQL.InnoDB.BufferPool.Size(id) InnoDB buffer pool size
MySQL.InnoDB.BufferPool.Used(id) InnoDB used buffer pool space
MySQL.InnoDB.BufferPool.UsedPerc(id)
InnoDB used buffer pool space (%)
MySQL.InnoDB.DiskReads(id) InnoDB disk reads
MySQL.InnoDB.ReadCacheHitRatio(id) InnoDB read cache hit ratio (%)
MySQL.InnoDB.ReadRequest(id) InnoDB read requests
MySQL.InnoDB.WriteRequest(id) InnoDB write requests
MySQL.IsReachable(id) is database reachable
MySQL.MyISAM.KeyCacheFree(id) MyISAM key cache free space
MySQL.MyISAM.KeyCacheFreePerc(id) MyISAM key cache free space (%)
MySQL.MyISAM.KeyCacheReadHitRatio(id)
MyISAM key cache read hit ratio (%)
MySQL.MyISAM.KeyCacheSize(id) MyISAM key cache size
MySQL.MyISAM.KeyCacheUsed(id) MyISAM key cache used space
MySQL.MyISAM.KeyCacheUsedPerc(id) MyISAM key cache used space (%)
MySQL.MyISAM.KeyCacheWriteHitRatio(id)
MyISAM key cache write hit ratio (%)
MySQL.MyISAM.KeyDiskReads(id) MyISAM key cache disk reads
MySQL.MyISAM.KeyDiskWrites(id) MyISAM key cache disk writes
MySQL.MyISAM.KeyReadRequests(id) MyISAM key cache read requests
MySQL.MyISAM.KeyWriteRequests(id) MyISAM key cache write requests
MySQL.OpenFiles.Current(id) open files
MySQL.OpenFiles.CurrentPerc(id) open file pool usage (%)
MySQL.OpenFiles.Limit(id) maximum possible number of open files
MySQL.Queries.Cache.HitRatio(id) query cache hit ratio (%)
MySQL.Queries.Cache.Hits(id) query cache hits
MySQL.Queries.Cache.Size(id) query cache size
MySQL.Queries.ClientsTotal(id) number of queries executed by clients
MySQL.Queries.Delete(id) number of DELETE queries
MySQL.Queries.DeleteMultiTable(id) number of multitable DELETE queries
MySQL.Queries.Insert(id) number of INSERT queries
MySQL.Queries.Select(id) number of SELECT queries
MySQL.Queries.Slow(id) slow queries
MySQL.Queries.SlowPerc(id) slow queries (%)
MySQL.Queries.Total(id) number of queries
MySQL.Queries.Update(id) number of UPDATE queries
MySQL.Queries.UpdateMultiTable(id)number of multitable UPDATE queries
MySQL.Server.Uptime(id) server uptime
MySQL.Sort.MergePasses(id) sort merge passes
MySQL.Sort.MergeRatio(id) sort merge ratio (%)
MySQL.Sort.Range(id) number of sorts using ranges
MySQL.Sort.Scan(id) number of sorts using table scans
MySQL.Tables.Fragmented(id) fragmented tables
MySQL.Tables.Open(id) open tables


MySQL.Tables.OpenLimit(id) maximum possible number of open tables
MySQL.Tables.OpenPerc(id) table open cache usage (%)
MySQL.Tables.Opened(id) tables that have been opened
MySQL.TempTables.Created(id) temporary tables created
MySQL.TempTables.CreatedOnDisk(id)
temporary tables created on disk
MySQL.TempTables.CreatedOnDiskPerc(id)
temporary tables created on disk (%)
MySQL.Threads.CacheHitRatio(id) thread cache hit ratio (%)
MySQL.Threads.CacheSize(id) thread cache size
MySQL.Threads.Created(id) threads created
MySQL.Threads.Running(id) threads running
23.6 PostgreSQL
NetXMS subagent for PostgreSQL monitoring. Monitors one or more instances of PostgeSQL servers and reports
various database-related parameters.
PostgreSQL subagent requires PostgreSQL driver to be available in the system.
A PostgreSQL user with CONNECT right to al least one database on the server.
If the PostgreSQL.DatabaseSize parameter should be monitored the user must have the CONNECT right to other
databases on the server too.
Starting from the PostgreSQL version 10, the user must have the he role pg_monitor assigned.
Required role can be assigned to user with the following query:
GRANT pg_monitor TO user;
Where user is the user configured in PostgreSQL subagent for database access.
You can specify one or multiple PostgreSQL server instances in the PostgreSQL section. In case of single server
definition simply set all required parameters under [pgsql] section. In multi server configuration define each server
instance under pgsql/servers/<name> section with unique <name> for each server. If no id provided <name>
of the section will be used as a server id.
It is not necessary to configure connections to more than one database on the same PostgreSQL server instance.
Each server definition supports the following parameters:
23.6. PostgreSQL 279


Id Server identifier. It will be used to address this localdb - for single server definition
server connection in parameters. last part of section name - for multi server defini-
tion
Database Maintenance database name. This is a name of postgres
the database on the server the subagent is con-
nected to.
Server Name or IP of the PostgreSQL server. 127.0.0.1
If the sever uses differnt than default port (5432)
the :port must be added to the server name or IP.
ConnectionTTL
Time in seconds. When this time gets elapsed, 3600
connection to the DB is closed and reopened
again.
Login User name for connecting to database. netxms
Password Database user password.
When using INI format, remember to enclose
password in double quotes (“password”) if it con-
tains # character.
This parameter automatically detects and accepts
password encrypted with nxencpasswd tool.
Single server configuration example:
Subagent=pgsql.nsm
[pgsql]
Id=db1
Database = database1
Login = user
Password = password
Multi server configuration example:
Subagent=pgsql.nsm
[pgsql/servers/mynetxms]
ID=monitor
Database = netxms
Login = user
Password = password
Server = netxms.demo
[pgsql/servers/local]
Login = user
Password = encPassword

23.6.3 Parameters
When loaded, PostgreSQL subagent adds two types of parameters to the agent.
Database server parameters are common for all databases on the server. These parameters require one argument which
is server id from the configuration.
Database parameters are independent for each database on the server. These parameters require to arguments. The
first one is server id from the configuration the second one is name of the database. If the second argument is missing
the name of the maintenance database from the configuration is used.
Alternatively, these two arguments can be specified as one argument in following format: datanase_name@server_id.
This format is returned by the PostgreSQL.AllDatabases list.
Following table shows the database server parameters:
Parameter Type Description

PostgreSQL.IsReachable(id) String Is database server instance reachable
PostgreSQL.Version(id) String Database server version
PostgreSQL.Archiver.ArchivedCount(id)
Integer Number of WAL files that have been successfully archived
64-bit
PostgreSQL.Archiver.FailedCount(id)
Integer Number of failed attempts for archiving WAL files
64-bit
PostgreSQL.Archiver.IsArchiving(id)
String Is archiving running
PostgreSQL.Archiver.LastArchivedAge(id)
Integer Age of the last successful archive operation
PostgreSQL.Archiver.LastArchivedWAL(id)
String Name of the last WAL file successfully archived
PostgreSQL.Archiver.LastFailedAge(id)
Integer Age of the last failed archival operation
PostgreSQL.Archiver.LastFailedWAL(id)
String Name of the WAL file of the last failed archival operation
PostgreSQL.BGWriter.BuffersAlloc(id)
Integer Cumulative number of buffers allocated
64-bit
PostgreSQL.BGWriter.BuffersBackend(id)
Integer Cumulative number of buffers written directly by a backend
64-bit
PostgreSQL.BGWriter.BuffersBackendFsync(id)
Integer Cumulative number of times a backend had to execute its own
64-bit fsync call
PostgreSQL.BGWriter.BuffersClean(id)
Integer Cumulative number of buffers written by the background writer
64-bit
PostgreSQL.BGWriter.BuffersCheckpoint(id)
Integer Cumulative number of buffers written during checkpoints
64-bit
PostgreSQL.BGWriter.CheckpointsReq(id)
Integer Cumulative number of requested checkpoints that have been per-
64-bit formed
PostgreSQL.BGWriter.CheckpointsTimed(id)
Integer Cumulative number of scheduled checkpoints that have been per-
64-bit formed
PostgreSQL.BGWriter.CheckpointSyncTime(id)
Float Total amount of time that has been spent in the portion of check-
point processing where files are synchronized to disk, in millisec-
onds
PostgreSQL.BGWriter.CheckpointWriteTime(id)
Float Total amount of time that has been spent in the portion of check-
point processing where files are written to disk, in milliseconds
PostgreSQL.BGWriter.MaxWrittenClean(id)
Integer Cumulative number of times the background writer stopped a
64-bit cleaning scan because it had written too many buffers
PostgreSQL.GlobalConnections.AutovacuumMax(id)
Integer Maximal number of autovacuum backends
PostgreSQL.GlobalConnections.Total(id)
Integer Total number of connections
PostgreSQL.GlobalConnections.TotalMax(id)
Integer Maximal number of connections
PostgreSQL.GlobalConnections.TotalPct(id)
Integer Used connections (%)
PostgreSQL.Replication.InRecovery(id)
String Is recovery in progress (from version 9.6.0)


PostgreSQL.Replication.IsReceiver(id)
String Is the server WAL receiver
PostgreSQL.Replication.Lag(id) Integer Replication lag in seconds (from version 10.0)
PostgreSQL.Replication.LagBytes(id)
Float Replication lag in bytes (from version 10.0)
PostgreSQL.Replication.WALSenders(id)
Integer Number of WAL senders
64-bit
PostgreSQL.Replication.WALFiles(id)
Integer Number of the WAL files (from version 10.0)
64-bit
PostgreSQL.Replication.WALSize(id)
Float Size of the WAL files (from version 10.0)
Following table shows the database parameters:

PostgreSQL.DBConnections.Active(id*[,
Integer Number of backends for this database executing a query
*database])
PostgreSQL.DBConnections.Autovacuum(id*[,
Integer Number of autovacuum backends for this database
*database])
PostgreSQL.DBConnections.FastpathFunctionCall(id*[,
Integer Number of backends for this database executing a fast-path func-
*database]) tion
PostgreSQL.DBConnections.Idle(id*[,
Integer Number of backends for this database waiting for a new client
*database]) command
PostgreSQL.DBConnections.IdleInTransaction(id*[,
Integer Number of backends for this database in a transaction, but is not
*database]) currently executing a query
PostgreSQL.DBConnections.IdleInTransactionAborted(id*[,
Integer Number of backends for this database in a transaction, but is not
*database]) currently executing a query and one of the statements in the trans-
action caused an error
PostgreSQL.DBConnections.OldestXID(id*[,
Integer Age of the oldest XID
*database])
PostgreSQL.DBConnections.Total(id*[,
Integer Total number of backends for connections to this database
*database])
PostgreSQL.DBConnections.Waiting(id*[,
Integer Number of waiting backends for this database
*database])
PostgreSQL.Locks.AccessExclusive(id*[,
Integer Number of AccessExclusive locks for this database
*database]) 64-bit
PostgreSQL.Locks.AccessShare(id*[,
Integer Number of AccessShare locks for this database
*database]) 64-bit
PostgreSQL.Locks.Exclusive(id*[,Integer Number of Exclusive locks for this database
*database]) 64-bit
PostgreSQL.Locks.RowExclusive(id*[,
Integer Number of RowExclusive locks for this database
*database]) 64-bit
PostgreSQL.Locks.RowShare(id*[,Integer Number of RowShare locks for this database
*database]) 64-bit
PostgreSQL.Locks.Share(id*[, Integer Number of Share locks for this database
*database]) 64-bit
PostgreSQL.Locks.ShareRowExclusive(id*[,
Integer Number of ShareRowExclusive locks for this database
*database]) 64-bit
PostgreSQL.Locks.ShareUpdateExclusive(id*[,
Integer Number of ShareUpdateExclusive locks for this database
*database]) 64-bit
PostgreSQL.Locks.Total(id*[, Integer Total number of locks for this database
*database]) 64-bit


PostgreSQL.Stats.BlkWriteTime(id*[,
Float Cumulative time spent writing data file blocks by backends in this
*database]) database, in milliseconds
PostgreSQL.Stats.BlockReadTime(id*[,
Float Cumulative time spent reading data file blocks by backends in this
*database]) database, in milliseconds
PostgreSQL.Stats.BlocksRead(id*[,Integer Cumulative number of disk blocks read in this database
*database]) 64-bit
PostgreSQL.Stats.BloksHit(id*[, Integer Cumulative number of times disk blocks were found already in the
*database]) 64-bit buffer cache
PostgreSQL.Stats.CacheHitRatio(id*[,
Float Query cache hit ratio (%)
*database])
PostgreSQL.Stats.Conflicts(id*[, Integer Cumulative number of queries canceled due to conflicts with re-
*database]) 64-bit covery in this database (stanby servers only)
PostgreSQL.Stats.DatabaseSize(id*[,
Integer Disk space used by the database
*database]) 64-bit
PostgreSQL.Stats.Deadlocks(id*[,Integer Cumulative number of deadlocks detected in this database
*database]) 64-bit
PostgreSQL.Stats.ChecksumFailures(id*[,
Integer Cumulative number of data page checksum failures detected in this
*database]) 64-bit database (from version 12.0)
PostgreSQL.Stats.NumBackends(id*[,
Integer Number of backends currently connected to this database
*database])
PostgreSQL.Stats.RowsDeleted(id*[,
Integer Cumulative number of rows deleted by queries in this database
*database]) 64-bit
PostgreSQL.Stats.RowsFetched(id*[,
Integer Cumulative number of rows fetched by queries in this database
*database]) 64-bit
PostgreSQL.Stats.RowsInserted(id*[,
Integer Cumulative number of rows inserted by queries in this database
*database]) 64-bit
PostgreSQL.Stats.RowsReturned(id*[,
Integer Cumulative number of rows returned by queries in this database
*database]) 64-bit
PostgreSQL.Stats.RowsUpdated(id*[,
Integer Cumulative number of rows updated by queries in this database
*database]) 64-bit
PostgreSQL.Stats.TempBytes(id*[,Integer Total amount of data written to temporary files by queries in this
*database]) 64-bit database
PostgreSQL.Stats.TempFiles(id*[,Integer Cumulative number of temporary files created by queries in this
*database]) 64-bit database
PostgreSQL.Stats.TransactionCommits(id*[,
Integer Cumulative number of transactions in this database that have been
*database]) 64-bit committed
PostgreSQL.Stats.TransactionRollbacks(id*[,
Integer Cumulative number of transactions in this database that have been
*database]) 64-bit rolled back
PostgreSQL.Transactions.Prepared(id*[,
Integer Number of prepared transactions for this database
*database]) 64-bit

23.6.4 Lists
When loaded, PostgreSQL subagent adds the following lists to agent:
List Description
PostgreSQL.DBServers All configured servers (server ids).
PostgreSQL.Databases(id) All databases on server identified by id.
PostgreSQL.AllDatabases All databases on configured servers. The format of the list items is
datanase_name@server_id.
PostgreSQL.DataTags(id) All data tags for server identified by id. Used only for internal diagnostics.
23.6.5 Tables
When loaded, PostgreSQL subagent adds the following tables to agent:
Table Description
PostgreSQL.Backends(id) Connection backends on server identified by id.
PostgreSQL.Locks(id) Locks on server identified by id.
PostgreSQL.PreparedTransactions(id) Prepared transactions on server identified by id.

CHAPTER
TWENTYFOUR
APPLICATION MONITORING
24.1 Process monitoring
Platform subagents support process monitoring. Process metrics have “Process.*” format. Metrics differ between
different OS. Detailed description of each metric can be found in List of supported metrics.
24.2 Application Database Monitoring
For application database monitoring can be used database monitoring subagents or database query subagents. Infor-
mation about database monitoring subagents can be found there. In this chapter will be described only DBQuery
subagents usage and configuration. This subagent supports all databases that are supported by NetXMS server link to
supported database list.
This type of Metrics provide DBQuery subagent. This subagent has 2 types of Metrics: one that periodically ex-
ecutes SQL queries and returns results and error codes as Metric parameters and second execute queries by Metric
request(synchronously). SQL queries are specified in the agent configuration. Background query can be also executed
per request. Synchronously executed query can have parameters that are passes to it by DCI configuration.
New in version 2.5: Synchronously executed queries
For time consuming SQL requests it is highly recommended to use background execution. Heavy SQL can cause
request timeout for synchronous execution.
24.2.1 Parameters
When loaded, DBQuery subagent adds the following parameters to agent:
DB.Query(dbid,query)
Result of immediate execution of the query query in database identified by dbid. Database with
given name must be defined in configuration file.
DB.QueryResult(name)
Last result of execution of the query name. Query with given name must be defined in configu-
ration file.
DB.QueryStatus(name)
Status of last execution of the query name. Query with given name must be defined in configu-
ration file. Value returned is native SQL error code.
DB.QueryStatusText(name)
Status of last execution of the query name as a text. Query with given name must be defined in
configuration file.
queryName Result of immediate execution of query defined in agent config file with name queryName.
query- Result of immediate execution of query defined in agent config file with name queryName like
Name(param1, ConfigurableQuery parameter. Where param1, param2. . . are parameters to bind into defined
param2. . . ) query.
285
24.2.2 Tables
When loaded, DBQuery subagent adds the following tables to agent:
Table Description
DB.Query(dbid,query)
Result of immediate execution of the query query in database identified by dbid. Database with
given name must be defined in configuration file.
DB.QueryResult(name)
Last result of execution of the query name. Query with given name must be defined in configu-
ration file.
queryName Result of immediate execution of query defined in agent config file with name queryName.
query- Result of immediate execution of query defined in agent config file with name queryName like
Name(param1, ConfigurableQuery parameter. Where param1, param2. . . are parameters to bind into defined
param2. . . ) query.
All configuration parameters related to DBQuery subagent should be placed into *DBQUERY section of agent’s
configuration file. The following configuration parameters are supported:
ParameterFormat Description
Database semicolon sep- Define new database connection (See database connection options section below).
arated option
list
Query Define new query. This parameter can be specified multiple times to define multiple
name:dbid:interval:query
queries. Fields in query definition have the following meaning:
• name Query name which will be used in parameters to retrieve collected
data.
• dbid Database ID (defined by Database parameter)
• interval Polling interval in seconds.
• query SQL query to be executed.
ConfigurableQuery Define new query. This parameter can be specified multiple times to define multiple
name:dbid:description:query
queries. Fields in query definition have the following meaning:
• name Query name which will be used in parameters to retrieve collected
data.
• dbid Database ID (defined by Database parameter)
• description Description that will be shown in agents parameter description.
• query SQL query to be executed.
286 Chapter 24. Application monitoring

24.2.4 Database connection options
Name Sta- Description

tus
dbname op- Database name.
tional
driver manda- Database driver name. Available drivers are: - db2.ddr - informix.ddr - mssql.ddr -
tory mysql.ddr - odbc.ddr - oracle.ddr - pgsql.ddr - sqlite.ddr
encrypted- op- Database password in encrypted form (use nxencpasswd command line tool to encrypt
Password tional passwords). This option takes precedence over password option.
id manda- Database connection ID which will be used to identify this connection in configuration
tory and parameters.
login op- Login name.
tional
password op- Database password in clear text form.
tional
server op- Database server name or IP address.
tional
24.2.5 Configuration Example

# 1. load DBQuery subagent
# 2. Define two databases - db1 (Oracle) and db2 (MySQL).
# 3. Execute query "SELECT f1 FROM table1" in database db1 every 60 seconds
# 4. Execute query "SELECT f1 FROM table2 WHERE f2 LIKE ':%'" on DSN2 every 15
˓→seconds
SubAgent = dbquery.nsm
*DBQUERY
Database = id=db1;driver=oracle.ddr;server=10.0.0.2;login=netxms;
˓→encryptedPassword=H02kxYckADXCpgp+8SvHuMKmCn7xK8e4wqYKfvErx7g=
Database = id=db2;driver=mysql.ddr;server=10.0.0.4;dbname=test_db;login=netxms;
˓→password=netxms1
Query = query1:db1:60:SELECT f1 FROM table1

Query = query2:db2:15:SELECT f1 FROM table2 WHERE f2 LIKE ':%'
ConfigurableQuery = query3:db2:Comment in param:SELECT name FROM images WHERE name
˓→like ?
24.3 Log monitoring
Application logs can be added to monitoring. For log monitoring configuration refer to Log monitoring chapter.
24.3. Log monitoring 287

24.4 External Metrics
It is possible to define External metrics that will get metric data from the script that is executed on the agent. This
option can be used to get status from some command line tools or from self made scripts. Information about options
and configuration is available in Agent External Metrics chapter.
288 Chapter 24. Application monitoring

CHAPTER
TWENTYFIVE
ICMP PING
The following options exist to monitor systems using ICMP pings:

• ICMP response statistic collection
• Metrics provided by ping subagent
25.1 ICMP response statistic collection
NetXMS can periodically perform ICMP polls and calculate node availability statistics. This functionality can be
controlled globally via server configuration parameter ICMP.CollectPollStatistics or locally on each node.
ICMP polling interval and statistic calculation period (expressed in number of polls), timeout and ICMP packet size
are configured via server configuration parameters, see Server configuration parameters.
ICMP requests are sent to node’s primary IP address. Additional targets can be specified in node’s properties. It’s also
possible to set node’s interfaces as targets by enabling Collect ICMP response statistic for this interface in properties
of the interface (enabling this for interface that corresponds to primary IP address will lead to pinging this address
twice).
ICMP polling is performed from server, from a zone proxy if zoning is used or from specific proxy if it’s configured
in node properties. Proxying agent should have ping.nsm subagent enabled.
Results of ICMP response statistic collection for primary IP address are visible in Object Details -> Overview and are
available as internal parameters:
• ICMP.ResponseTime.Average
• ICMP.PacketLoss
• ICMP.ResponseTime.Last
• ICMP.ResponseTime.Max
• ICMP.ResponseTime.Min
Results of ICMP response statistic collection for additional targets and interfaces are available as internal parameters:
• ICMP.ResponseTime.Average(*)
• ICMP.PacketLoss(*)
• ICMP.ResponseTime.Last(*)
• ICMP.ResponseTime.Max(*)
• ICMP.ResponseTime.Min(*)
289
For example, ICMP.PacketLoss(8.8.8.8) parameter will provide packet loss for target with IP address 8.8.8.8.
No historical data is stored by default. It’s necessary to configure DCIs using above mentioned internal parameters to
store historical data.
25.2 Ping subagent
This subagent can be used to measure ICMP ping response times from one location to another. Measurements can be
either scheduled by the agent itself or requested by the server.
Metrics scheduled by the agent (based on “PacketRate” parameter):
• ICMP.AvgPingTime
• ICMP.LastPingTime
• ICMP.PacketLoss
• ICMP.PingStdDev
These metrics can be either defined in agent configuration file (using one or more “Target” parameters), or registered
automatically on first request from server. If targets are registered automatically, default packet size is used. First
request to non-existing target will return “0” as a value. Automatically registered targets are automatically removed
after a timeout, if server stops requesting metrics for that target.
Metrics available on demand:
• ICMP.Ping
25.2.1 Metrics
When loaded, PING subagent adds the following parameters to agent:
Pa- Description
ram-
e-
ter
Icmp.AvgPingTime(target)
Average ICMP ping response time from target for last minute. Argument target can be either IP address or
name specified in Target configuration record (see below).
Icmp.LastPingTime(target)
Last ICMP ping response time from target. Argument target can be either IP address or name specified in
Target configuration record (see below).
Icmp.PacketLoss(target)
ICMP ping packet loss (in percents) for target for last minute. Argument target can be either IP address or
name specified in Target configuration record (see below).
Icmp.Ping(target,
ICMP ping response time from target. Agent will send echo request as soon as it receives request for
time- parameter’s value, and will return response time for that particular request. Argument target should be an IP
out, address. Optional argument timeout specifies timeout in milliseconds. Default timeout is 1 second. Optional
psize) argument psize specifies packet size in bytes, including IP header. If this argument is omitted, value from
DefaultPacketSize configuration parameter will be used.
Please note that other parameters just return result of background ping process, while this parameter waits
for actual ping completion and then returns the result. Because of this behavior, it is not recommended to use
Icmp.Ping parameter for instant monitoring, only for occasional tests. For instant monitoring, you should
configure targets for background ping and use Icmp.AvgPingTime or Icmp.LastPingTime parameters to
retrieve results.
Icmp.PingStdDev(target)
Standard deviation of the response time for the target for last minute. Argument target can be either IP
address or name specified in Target configuration record (see below).
290 Chapter 25. ICMP ping

25.2.2 Tables
Table Description
Icmp.Targets Table of configured ping targets. Columns:
• IP address
• Last response time (milliseconds)
• Average response time (milliseconds)
• Packet loss (percents)
• Configured packet size
• Name
• DNS name
• Automatic
25.2.3 Lists
List Description
Icmp.Targets List of configured ping target names.
All configuration parameters related to PING subagent should be placed into [PING] section of agent’s configuration
file. The following configuration parameters are supported:
Pa- For- Description De-

ram- mat fault
eter value
De- bytes Set default packet size to bytes. 46
fault-
Pack-
et-
Size
Pack- pack- Set ping packet rate per minute. Allowed values are from 1 to 60 and values below or 4
e- ets above will be adjusted automatically.
tRate
Tar- Add target with IP address ip to background ping target list and assign an optional name
ip:name:psize none
get name to it. Target will be pinged using packets of psize bytes size. Name and packet size
fields are optional and can be omitted. This parameter can be given multiple times to add
multiple targets.
Time- mil- Set response timeout to milliseconds. Allowed values are from 500 to 5000 and values 3000
out lisec- below or above will be adjusted automatically.
onds

# 1. load PING subagent
# 2. Ping target 10.0.0.1 with default size (46 bytes) packets and 10.0.0.2 with
˓→1000 bytes packets
25.2. Ping subagent 291


# 3. Timeout for ping set to 1 second and pings are sent 12 times per minute (each
˓→5 seconds)
SubAgent = ping.nsm
[PING]
Timeout = 1000
PacketRate = 12 # every 5 seconds
Target = 10.0.0.1:target_1
Target = 10.0.0.2:target_2:1000
Note: Response time of 10000 indicate timeout
292 Chapter 25. ICMP ping

CHAPTER
TWENTYSIX
HARDWARE(SENSOR) MONITORING
NetXMS has subagents that allow to monitor hardware sensors.

• lm-sensors - Can collect data from all sensors that are supported by lm-sensors drivers on Linux.
• DS18x20 - This subagent collects temperature data from ds18x20 sensors. Linux only.
• RPI - This subagent is created for Raspberry Pi. It can collect data from DHT22 sensor and get status of
any GPIO pin.
26.1 lm-sensors
This subagent can be used to read hardware status using lm_sensors package.
Package lm_sensors should be installed and configured properly. Output of sensors command should produce mean-
ingful output (see example below).
alk@b08s02ur:~$ sensors
w83627dhg-isa-0290
Adapter: ISA adapter
Vcore: +1.14 V (min = +0.00 V, max = +1.74 V)
in1: +1.61 V (min = +0.05 V, max = +0.01 V) ALARM
AVCC: +3.31 V (min = +2.98 V, max = +3.63 V)
VCC: +3.31 V (min = +2.98 V, max = +3.63 V)
in5: +1.26 V (min = +0.05 V, max = +1.67 V)
3VSB: +3.30 V (min = +2.98 V, max = +3.63 V)
Vbat: +3.18 V (min = +2.70 V, max = +3.30 V)
fan1: 3308 RPM (min = 1188 RPM, div = 8)
fan2: 6250 RPM (min = 84375 RPM, div = 8) ALARM
temp1: +39.0°C (high = +4.0°C, hyst = +1.0°C) ALARM sensor = diode
temp2: +17.0°C (high = +80.0°C, hyst = +75.0°C) sensor = diode
temp3: +124.5°C (high = +80.0°C, hyst = +75.0°C) ALARM sensor = thermistor
cpu0_vid: +2.050 V
coretemp-isa-0000
293

Core 0: +37.0°C (high = +76.0°C, crit = +100.0°C)
coretemp-isa-0001
Core 1: +37.0°C (high = +76.0°C, crit = +100.0°C)
26.1.2 Parameters
When loaded, lm_sensors subagent adds the following parameters:
LMSensors.Value(chip, label) Current value returned by hardware sensor
All configuration parameters related to lm_sensors subagent should be placed into *LMSENSORS section of agent’s
configuration file. The following configuration parameters are supported:
Parame- For- Description Default value

ter mat
Use- Boolean If set to “yes”, all temperature reading will be con- no
Fahren- verted to Fahrenheit
heit
Config- String Path to sensors.conf none, use system default (usually
File /etc/sensors3.conf)
26.1.4 Configuration example
SubAgent = lmsensors.nsm
[LMSENSORS]
UseFahrenheit = yes
ConfigFile = /etc/sensors.netxms.conf
26.1.5 Sample usage
(based on output of “sensors” from Pre-requisites section)
alk@b08s02ur:~$ nxget netxms.demo 'LMSensors.Value(coretemp-isa-0001,Core 1)'

38.000000
alk@b08s02ur:~$ nxget netxms.demo 'LMSensors.Value(w83627dhg-isa-0290,AVCC)'
3.312000
294 Chapter 26. Hardware(sensor) monitoring

26.2 DS18x20
This subagent collects temperature from DS18x20 sensor. Subagent available for Linux only. To use this subagent
1-Wire driver should be installed.
26.2.1 Parameters
Parameter Type Meaning

Sensor.Temperature(*)
Float Sensor temperature
All configuration parameters related to lm_sensors subagent should be placed into *DS18X20 section of agent’s con-
figuration file. The following configuration parameters are supported:
Sensor String Sensor identification in format sensorName:uniqueID
SubAgent = DS18X20.nsm
[DS18X20]
Sensor = sensorName:uiniqueID123456788990
26.3 RPI
This subagent collects data from Raspberry Pi DHT22 sensor and status of GPIO pins.
26.3.1 Parameters

GPIO.PinState(pinNumber) Integer State of pin with given number. This pin number should be enabled in
agent configuration file.
Sensors.Humidity Integer Sensors data for humidity
Sensors.Temperature Integer Sensors data for temperature
26.2. DS18x20 295

All configuration parameters related to lm_sensors subagent should be placed into *RPI section of agent’s configura-
tion file. The following configuration parameters are supported:
DisableDHT22
Boolean Disables dht22 sensor if yes. By default no.
EnabledPins
Coma separated List of pins that are enabled for status check.
list of numbers
SubAgent = rpi.nsm
[RPI]
DisableDHT22 = no
EnabledPins = 1,4,5,8
26.4 MQTT
This is a subagent that can be used to collect data from devices and sensors that use MQTT protocol for communication.
The subagent can be used to connect to existing MQTT brokers, listen to user specified topics, map posted data to
metrics and generate events.
These are the necessary configuration sections and parameters for the MQTT subagent:
Section Parameters Format Description

[MQTT/Brokers/broker_name] Hostname, String This section holds the data needed to
Port, Login, connect to the MQTT broker
Password
[MQTT/Brokers/broker_name/Events] EVENT_NAME String This section is for specifying MQTT
topic and event matching
[MQTT/Brokers/broker_name/Metrics] Metric. Dot sepa- This section is for mapping data posted
Name rated string to MQTT topics to metrics
SubAgent = mqtt.nsm
[MQTT/Brokers/Office]
Hostname = mqtt.office.radensolutions.com
[MQTT/Brokers/Office/Events]
MQTT_METERHUB_RAW_DATA = "cmnd/5C:CF:7F:25:79:D6/#"


[MQTT/Brokers/Office/Metrics]
MeterHub.Telemetry.RSSI = "tele/5C:CF:7F:25:79:D6/RSSI"
MeterHub.Telemetry.Time = "tele/5C:CF:7F:25:79:D6/TIME"
This configuration will connect to an MQTT broker Office at the Hostname. Whenever data is published to the topic
cmnd/5C:CF:7F:25:79:D6/#, the event MQTT_METERHUB_RAW_DATA will be triggered. It will also provide
two metrics, MeterHub.Telemetry.RSSI and MeterHub.Telemetry.Time which will report data received
on the topics tele/5C:CF:7F:25:79:D6/RSSI and tele/5C:CF:7F:25:79:D6/TIME respectively.
26.4. MQTT 297


CHAPTER
TWENTYSEVEN
UPS MONITORING
There are two options to monitor UPS: first is through USB or serial connection with help of subagent and second one
is through the network with help of SNMP.
Subagent can be used for monitoring UPS (Uninterruptible Power Supply) attached to serial or USB port on computer
where NetXMS agent is running. USB-attached devices currently supported only on Windows platform, serial is
supported on all platforms. One subagent can monitor multiple attached devices.
27.1 USB or serial UPS monitoring
You can monitor UPS devices attached to the hosts via serial cable or USB via UPS subagent. Once you have your
UPS attached to the host and NetXMS agent installed, you should configure UPS subagent. First, add the following
line to agent’s configuration file main section:
SubAgent = ups.nsm
Second, configure attached UPS devices. Create UPS section, and for each UPS device attached to the host add line
in the following format:
Device = id:port:protocol
id is an arbitrary but unique number in range 0 to 127, which is used to distinguish multiple UPS devices in further
requests.
device is either name of the serial port (e.g. COM1: or /dev/ttyS0) or serial number of the USB device (keyword
ANY can be used instead of exact serial number to select first available).
protocol specify which communication protocol should be used. Supported protocols:
• APC
• BCMXCP - Some of the HP/Compaq, PowerWare, etc.
• MEGATEC
• METASYS
• MICRODOWELL
• USB - HID UPS devices (currently Windows only)
Sample configuration section for two devices attached via serial ports, one is APC device (configured as device 0) and
one is HP device (configured as device 1):
299
# UPS subagent configuration section

[UPS]
Device = 0:/dev/ttyS0:APC
Device = 1:/dev/ttyS1:BCMXCP
Once UPS subagent is configured, you can start to monitor UPS devices status via parameters provided by it:

UPS.BatteryLevel(*)Integer Battery charge level in percents.
UPS.BatteryVoltage(*)
Float Current battery voltage.
UPS.ConnectionStatus(*
Integer
Connection status between agent and device. Can have the following values:
• 0 - Agent is communication with the device

• 1 - Communication with the device has been lost
UPS.EstimatedRuntime(*)
Integer Estimated on-battery runtime in minutes.
UPS.Firmware(*) String Device’s firmware version.
UPS.InputVoltage(*)Float Input line voltage.
UPS.LineFrequency(*)
Integer Input line frequency in Hz.
UPS.Load(*) Integer Device load in percents.
UPS.MfgDate(*) String Device manufacturing date.
UPS.Model(*) String Device model name.
UPS.NominalBatteryVoltage(*)
Float Nominal battery voltage.
UPS.OnlineStatus(*)Integer
Device online status. Can have the following values:
• 0 - Device is online.
• 1 - Device is on battery power.
• 2 - Device is on battery power and battery level is low.
UPS.OutputVoltage(*)
Float Output line voltage.
UPS.SerialNumber(*)String Device’s serial number.
UPS.Temperature(*)Integer Internal device temperature.
Please note that not all parameters supported by all UPS devices. Many old or simple models will support only
basic things like UPS.OnlineStatus parameter. Most typical approach is to monitor UPS.OnlineStatus for going to
1 or 2, and then send notifications to administrators and shutdown affected hosts if needed. You can also monitor
UPS.EstimatedRuntime parameter for the same purposes if your devices support it.
27.2 SNMP UPS monitoring
Other option to monitor UPS is using SNMP. NetXMS already includes MIBs for some UPS, like APC UPS and
standard UPS MIB. Description for possible OIDs and some additional information for APC UPS configuration can
be found on a NetXMS wiki.
Please check Import MIB for MIB loading and DCI configuration for metric collection.
300 Chapter 27. UPS monitoring

CHAPTER
TWENTYEIGHT
CLUSTER MONITORING
28.1 Introduction
Cluster monitoring provides aspects of monitoring needed in high availability setups. There is a special class of object
in NetXMS - Cluster.
DCIs defined on cluster object are automatically applied to it’s nodes. Cluster allows to aggregate data from it’s nodes,
e.g. to calculate sum or average for a metric that is collected from all nodes. Cluster can adequately collect data from
services as they move from from one node to another, providing uninterrupted data collection.
301
302 Chapter 28. Cluster monitoring

CHAPTER
TWENTYNINE
JVM MONITORING
NetXMS has Java plugin that allow to monitor JVM. This subagent is build using JMX functionality.
303
304 Chapter 29. JVM monitoring

29.1 Metrics
29.1.1 Parameters
Metric Type Meaning

JMX.ObjectAttribute(name,object,attribute,[item])
String Get attribute of any connection, object. Optional attribute item is used when
attribute is a list.
JMX.Memory.ObjectsPendingFinalization(name)
Unsigned JVM objects pending finalization
integer
JMX.Memory.Heap.Committed(name)
Unsigned JVM committed heap memory
integer
64
JMX.Memory.Heap.Current(name)
Unsigned JVM current heap size
integer
64
JMX.Memory.Heap.Init(name)
Unsigned JVM initial heap size
integer
64
JMX.Memory.Heap.Max(name)
Unsigned JVM maximum heap size
integer
64
JMX.Memory.NonHeap.Committed(name)
Unsigned JVM committed non-heap memory
integer
64
JMX.Memory.NonHeap.Current(name)
Unsigned JVM current non-heap memory size
integer
64
JMX.Memory.NonHeap.Init(name)
Unsigned JVM initial non-heap memory size
integer
64
JMX.Memory.NonHeap.Max(name)
Unsigned JVM maximum non-heap memory size
integer
64
JMX.Threads.Count(name)
Unsigned JVM live threads count
integer
JMX.Threads.DaemonCount(name)
Unsigned JVM daemon threads count
integer
JMX.Threads.PeakCount(name)
Unsigned JVM peak number of threads
integer
JMX.Threads.TotalStarted(name)
Unsigned JVM total threads started
integer
JMX.VM.BootClassPath(name)
String JVM boot class path
JMX.VM.ClassPath(name)
String JVM class path
JMX.VM.LoadedClassCount(name)
Unsigned JVM loaded class count
integer
JMX.VM.Name(name) String JVM name
JMX.VM.SpecVersion(name)
String JVM specification version
JMX.VM.TotalLoadedClassCount(name)
Unsigned JVM total loaded class count
integer
JMX.VM.UnloadedClassCount(name)
Unsigned JVM unloaded class count
integer
JMX.VM.Uptime(name)Unsigned JVM uptime
integer
JMX.VM.Vendor(name)String JVM vendor
29.1. Metrics 305
JMX.VM.Version(name)
String JVM version
29.1.2 Lists
Metric Meaning
JMX.Domains(name) List of JVM domains
JMX.Objects(name) List of JVM objects
JMX.ObjectAttributes(name)
List of JVM object’s attributes
29.2 Configuration
It is required to define java subagent and it’s configurations before JMX plugin configuration. More information about
Java subagent and it’s configuration can be found in Java subagent section. JMS has only one configuration parameter
“Server”. It is used to define JMX server connection string.
JMS server connection string declaration options:
• name:url
• name:login@url
• name:login/password@url
In example are defined 2 JMS connections: name and serverName2.
SubAgent=java.nsm
[JAVA]
jvm = /usr/lib/jvm/java-8-oracle/jre/lib/amd64/server/libjvm.so
Plugin = jmx.jar
[JMX]
Server=name:login/password@localhost
Server=serverName2:admin/pwd123@server1
306 Chapter 29. JVM monitoring

CHAPTER
THIRTY
HYPERVISOR MONITORING
NetXMS has subagents that allow to monitor hypervisors. This subagent is build using libvirt functionality. Due to
the fact that libvirt is poorly supported on Windows platforms, vmgr subagent is not provided on Windows.
When installing NetXMS from packages, vmgr subagent is provided as a separate package named netxms-agent-vmgr.
If building from source, ./configure should be ran with –with-vmgr.
30.1 Configuration
Configuration is separated into two parts: vmgr section defines all monitored hosts, and each host configuration is
defined in separate section for each host.
Each host configuration should contain connection URL. Login and password parameters are optional. URL creation
rules for each vitalization solution type can be found in libvirt documentation.
Not all api functions are supported by all hypervisors in libvirt. See libvirt API support matrix for more information.
In this example two hosts are defined: localESX1 and test. localESX1 connection details are described in section
vmgr:localESX1 and test connection details are described in section vmgr:test.
SubAgent = vmgr.nsm
[vmgr]
host = localESX1
host = test
[vmgr:localESX1]
Url = esx://root@10.5.0.21/?no_verify=1
Login = root
Password = password
[vmgr:test]
Url = test:///default
307
30.2 Metrics
30.2.1 Parameters
Metric Type Description

VMGR.Host.CPU.Arch(hostName)
String Host CPU architecture
VMGR.Host.CPU.MaxCount(hostName)
Unsigned Host maximum virtual CPU count
integer
VMGR.Host.FreeMemory(hostName)
Unsigned Host free memory
integer
64
VMGR.Host.MemorySize(hostName)
Unsigned Host memory size
integer
64
VMGR.Host.CPU.Model(hostName)
String Host CPU model name
VMGR.Host.CPU.Frequency(hostName)
Unsigned Host CPU frequency
integer
VMGR.Host.ConnectionType(hostName)
String Connection type
VMGR.Host.LibraryVersion(hostName)
Unsigned Library version
integer
64
VMGR.Host.ConnectionVersion(hostName)
Unsigned Connection version
integer
64
VMGR.VM.Memory.Used(hostName,vmName)
Unsigned Memory currently used by VM
integer
64
VMGR.VM.Memory.UsedPrec(hostName,vmName)
Unsigned Percentage of currently memory usage by VM
integer
VMGR.VM.Memory.Max(hostName,vmName)
Unsigned Maximum VM available memory
integer
64
VMGR.VM.CPU.Time(hostName,vmName)
Unsigned Maximum VM CPU time
integer
64
30.2.2 Tables
Metric Description
VMGR.VM(hostName)Connection VM table
VMGR.InterfaceList(hostName)
Connection interface list
VMGR.VMDisks(hostName,vmName)
VM Disks
VMGR.VMController(hostName,vmName)
VM Controllers
VMGR.VMInterface(hostName,vmName)
VM Interfaces
VMGR.VMVideo(hostName,vmName)
VM Video adapter settings
VMGR.Networks(hostName)
Networks table
VMGR.Storages(hostName)
Storages table
308 Chapter 30. Hypervisor monitoring

30.2.3 Lists
Metric Description
VMGR.VMHost List of hosts
VMGR.VMList(hostName)
List of VM for the host
30.2. Metrics 309

310 Chapter 30. Hypervisor monitoring

CHAPTER
THIRTYONE
ASTERISK MONITORING
NetXMS can be used to monitor health and performance of Asterisk PBX. All monitoring data collected and provided
by subagent asterisk.nsm. One agent can collect data from multiple Asterisk systems.
31.1 Configuration
All Asterisk systems should be defined in subagent configuration. For simplified setup for single system monitor-
ing subagent supports “local” system. Configuration for local system can be defined in Asterisk section of agent
configuration file. For each additional system new section should be created in configuration file named Aster-
isk/Systems/SystemName (SystemName should be replaced with unique name). Each section can have the following
parameters:

value
Hostname DNS name or IP address of Asterisk PBX 127.0.0.1
Login Login name root
Password Password empty
Port TCP port number for AMI connection 5038
It is also possible to configure subagent to periodically perform SIP registration tests. Each test should be config-
ured in separate configuration section named Asterisk/SIPRegistrationTests/TestName for local system and Aster-
isk/Systems/SystemName/SIPRegistrationTests/TestName for other systems. SystemName and TestName should
be replaced with unique system and test names respectively. Each test configuration section can have the following
parameters:

value
Domain Domain name used for registration empty
Interval Check interval in seconds 300
Login SIP login name netxms
Password SIP password netxms
Proxy SIP proxy sip:Asterisk
IP address
311
31.1.1 Configuration Examples
Local system without SIP tests:
SubAgent = asterisk.nsm
[Asterisk]
Login = root
Password = password1
Local system with two SIP tests:
[Asterisk]
Login = root
[Asterisk/SIPRegistrationTests/104]
Login = 104
Password = 12345
Domain = demo.netxms
Login = 115
Password = 12345
Interval = 60
Local system and remote system (named Remote1) on address 10.0.0.1 with one SIP test each:
[Asterisk]
Login = root
Login = 104
Password = 12345
[Asterisk/Systems/Remote1]
Hostname = 10.0.0.1
Login = root
[Asterisk/Systems/Remote1/SIPRegistrationTests/120]
Login = 120
Password = 12345
Domain = remote.netxms
312 Chapter 31. Asterisk monitoring

31.2 Metrics
31.2.1 Parameters
All parameters accept system name as first argument. Name for default local system is LOCAL. If system name is
omitted local system is assumed. If system name is the only argument braces can be omitted as well.
Metric Type Meaning

Asterisk.AMI.Status(system)
Integer AMI connection status (1 if AMI session is ready, 0 if not)
Asterisk.AMI.Version(system)
Integer AMI version
Asterisk.Channels.Active(system)
Integer Number of active channels
Asterisk.Channels.Busy(system)
Integer Number of busy channels
Asterisk.Channels.Dialing(system)
Integer Number of dialing channels
Asterisk.Channels.OffHook(system)
Integer Number of off-hook channels
Asterisk.Channels.Reserved(system)
Integer Number of reserved channels
Asterisk.Channels.Ringing(system)
Integer Number of ringing channels
Asterisk.Channels.Up(system)
Integer Number of up channels
Asterisk.Channels.CurrentCalls(system)
Integer Number of currently active calls
Asterisk.Events.CallBarred(system)
Integer Global cumulative counter of “call barred” events
Asterisk.Events.CallRejected(system)
Integer Global cumulative counter of “call rejected” events
Asterisk.Events.ChannelUnavailable(system)
Integer Global cumulative counter of “channel unavailable” events
Asterisk.Events.Congestion(system)
Integer Global cumulative counter of “congestion” events
Asterisk.Events.NoRoute(system)
Integer Global cumulative counter of “no route” events
Asterisk.Events.SubscriberAbsent(system)
Integer Global cumulative counter of “subscriber absent” events
Asterisk.Peer.Events.CallBarred(system,
Integer Cumulative counter of “call barred” events for given peer
peer)
Asterisk.Peer.Events.CallRejected(system,
Integer Cumulative counter of “call rejected” events for given peer
peer)
Asterisk.Peer.Events.ChannelUnavailable(system,
Integer Cumulative counter of “channel unavailable” events for given peer
peer)
Asterisk.Peer.Events.Congestion(system,
Integer Cumulative counter of “congestion” events for given peer
peer)
Asterisk.Peer.Events.NoRoute(system,
Integer Cumulative counter of “no route” events for given peer
peer)
Asterisk.Peer.Events.SubscriberAbsent(system,
Integer Cumulative counter of “subscriber absent” events for given peer
peer)
Asterisk.Peer.RTCP.AverageJitter(system,
Integer Average jitter for given peer in milliseconds (moving average over last 180 mea-
peer) surements)
Asterisk.Peer.RTCP.AveragePacketLoss(system,
Integer Average packet loss for given peer (moving average over last 180 measurements)
peer)
Asterisk.Peer.RTCP.AverageRTT(system,
Integer Average round trip time in milliseconds for given peer (moving average over last
peer) 180 measurements)
Asterisk.Peer.RTCP.LastJitter(system,
Integer Last reported jitter for given peer in milliseconds
peer)
Asterisk.Peer.RTCP.LastPacketLoss(system,
Integer Last reported packet loss for given peer
peer)
Asterisk.Peer.RTCP.LastRTT(system,
Integer Last reported round trip time in milliseconds for given peer
peer)
Asterisk.Peer.RTCP.MaxJitter(system,
Integer Maximum reported jitter for given peer in milliseconds
peer)
31.2. Metrics 313


Metric Type Meaning
Asterisk.Peer.RTCP.MaxPacketLoss(system,
Integer Maximum reported packet loss for given peer
peer)
Asterisk.Peer.RTCP.MaxRTT(system,
Integer Maximum reported round trip time in milliseconds for given peer
peer)
Asterisk.Peer.RTCP.MinJitter(system,
Integer Minimum reported jitter for given peer in milliseconds
peer)
Asterisk.Peer.RTCP.MinPacketLoss(system,
Integer Minimum reported packet loss for given peer
peer)
Asterisk.Peer.RTCP.MinRTT(system,
Integer Minimum reported round trip time in milliseconds for given peer
peer)
Asterisk.SIP.Peer.Details(system,
String Value of specific tag from SIPshowpeer AMI message
peer, tag)
Asterisk.SIP.Peer.IPAddress(system,
String SIP peer IP address
peer)
Asterisk.SIP.Peer.Status(system,
String SIP peer status
peer)
Asterisk.SIP.Peer.Type(system,
String SIP peer type
peer)
Asterisk.SIP.Peer.UserAgent(system,
String SIP peer user agent information
peer)
Asterisk.SIP.Peer.VoiceMailbox(system,
String SIP peer voice mailbox information
peer)
Asterisk.SIP.Peers.Connected(system)
Integer Number of connected SIP peers
Asterisk.SIP.Peers.Total(system)
Integer Total count of configured SIP peers
Asterisk.SIP.Peers.Unknown(system)
Integer Number of SIP peers in unknown state
Asterisk.SIP.Peers.Unmonitored(system)
Integer Number of unmonitored SIP peers
Asterisk.SIP.Peers.Unreachable(system)
Integer Number of unreachable SIP peers
Asterisk.SIP.RegistrationTest.ElapsedTime(system,
Integer Elapsed time for last run of given registration test
test)
Asterisk.SIP.RegistrationTest.Status(system,
Integer Status of last run of given registration test
test)
Asterisk.SIP.RegistrationTest.Timestamp(system,
Integer Timestamp last run of given registration test as UNIX time (number of seconds
test) since 1.1.1970 00:00:00 UTC)
Asterisk.SIP.TestRegistration(system,
Integer Status of ad-hoc registration
login, password,
domain)
Asterisk.TaskProcessor.HighWatermark(system,
Integer High watermark for given task processor
processor)
Asterisk.TaskProcessor.LowWatermark(system,
Integer Low watermark for given task processor
processor)
Asterisk.TaskProcessor.MaxDepth(system,
Integer Maximum queue depth for given task processor
processor)
Asterisk.TaskProcessor.Processed(system,
Integer Number of processed tasks for given task processor
processor)
Asterisk.TaskProcessor.Queued(system,
Integer Number of queued tasks for given task processor
processor)
Asterisk.Version(system)
String Asterisk version

31.2.2 Tables
All tables accept system name as first argument. Name for default local system is LOCAL. If system name is omitted
local system is assumed. If system name is the only argument braces can be omitted as well.
Metric Description
Asterisk.Channels(system)
Active channels
Asterisk.CommandOutput(system,
Output of given Asterisk console command
command)
Asterisk.SIP.Peers(system)
SIP peers
Asterisk.SIP.RegistrationTests(system)
Configured SIP registration tests
Asterisk.TaskProcessors(system)
Task processors
31.2.3 Lists
All lists accept system name as first argument. Name for default local system is LOCAL. If system name is omitted
local system is assumed. If system name is the only argument braces can be omitted as well.
Metric Description
Asterisk.Channels(system)
Active channels
Asterisk.CommandOutput(system,
Output of given Asterisk console command
command)
Asterisk.SIP.Peers(system)
SIP peers
Asterisk.SIP.RegistrationTests(system)
Configured SIP registration tests
Asterisk.Systems Configured Asterisk systems
Asterisk.TaskProcessors(system)
Task processors
31.2. Metrics 315


CHAPTER
THIRTYTWO
MONITORING MOBILE DEVICES
NetXMS has mobile agent for Android devices running version 2.2. and later. Currently, a very limited set of info can
be monitored and reported to a NetXMS server.
32.1 Metrics
Unlike other metrics mobile ones are provided with Internal origin as they are not collected by server, but pushed from
mobile agent.
MobileDevice.BattaryLevel Battery charging level in percents.
MobileDevice.DeviceId Id of device
MobileDevice.LastReportTime Last time device reported data
MobileDevice.Model Phone model
MobileDevice.OS.Name Operating system mane
MobileDevice.OS.Version Operating system version
MobileDevice.SerialNumber Serial number
MobileDevice.UsedId
MobileDevice.Vendor Mobile device vendor
317
32.2 GUI
32.2.1 Main Window
Sections:
1. Agent status. In case agent is active, reports the basic info about configuration such as scheduler for new
location acquisition and connection to server where to update info collected.
2. Last location section reports info about the last location acquired (date/time, source provider, geo coordi-
nates and estimated accuracy.
3. Last connection section reports info about the status of last connection: date/time and status of connection
to the server:port specified in the configuration section. In case of errors during connection, here is reported
also the error message.
4. Next connection section reports info about the next scheduled connection.
5. Device ID section reports the device ID (IMEI in case of devices with phone).
6. Device Serial section reports the device serial number.
318 Chapter 32. Monitoring mobile devices

32.2.2 Main menu
• Reconnect: select this item to force a reconnection to the server to send new collected data.
• Disconnect & Exit: select this item to stop the agent and exit from the app.
• Settings: select this item to configure the agent.
32.2.3 Settings
This section is used to configure the behavior of the agent.
32.2.4 Global settings
• Activate agent: when set makes the agent operational.

• Autostart on boot: automatically starts the agent on boot (to be effective, agent must be set to be active).
• Scheduler: provides the ability to define a “one range” daily on which the agent is operational. Out of the specified range t
1. Daily activation on: start time for daily activation.

2. Daily activation off : stop time for daily activation.
32.2.5 Connection
• Parameters: allows selecting the parameters used to connect to the server:

1. Server: address of the server (IP or name).
2. Port: port of the server (default 4747).
3. User name: username to connect to the server.
4. Password: password to connect to the server.
5. Encrypt connection: when selected challenges an encryption strategy with the server (depending on
supported/configured providers).
• Frequency: amount of time, in minutes, that has to elapse between each tentative of connection to the server to
send the gathered info.
• Override frequency: when selected overrides the previous frequency values and forces a new connection to the
server (thus resetting the timer) every time a new connection is detected. NB if you are in a situation where
connection is not stable it is advised to clear this flag to avoid multiple connections that will drain the battery.
32.2.6 Location
• Force position update: when cleared instruct the agent to relay on position updates made from other apps in the
system (this means that position can be very old if no other apps are trying to get a new fix). When set, instructs
the agent to try to gather a new position.
• Frequency (min): amount of time, in minutes, that has to elapse before trying to acquire a new position (Force
position update set) or before trying to check if someone else updated a position.
• Duration (min): maximum amount of time, in minutes, that has to elapse before giving up on acquiring a new
position.
32.2. GUI 319

• Location strategy: allows selecting the source provider that has to be used to acquire a new position, allowed providers:
1. Network only: tries to acquire position from network provider. Network provider is usually fast in
acquiring a new position but it is not much accurate, especially using data connection (range from
1Km to 2Km, depending on antennas deployment), the service is not available all around the world.
Wi-Fi connection seems to guarantee much higher precision due to a correlation between last known
position acquired from GPS.
2. GPS only: tries to acquire position from GPS provider. GPS provider is usually slow in acquiring a
new position, time depends on several factors such as how much time has elapsed since last position,
number of satellites in free view (inside buildings can be really had to get a position).
3. Network and GPS: tries to acquire a position from Network provider or GPS provider, the first one
that gives a position is considered ok. There is no special algorithm to evaluate accuracy, the unique
criteria is the speed of the fix.
Note: Please note that on 2G networks (GPRS/EDGE) data connection is not available while you are busy in a
conversation, position acquisition will fail. On 3G networks (UMTS/HSxPA) data connection is available and so the
position acquisition. However, if the agent is not able to get a new fix within the time-frame specified, it will try to
gather a position from any available provider that has a valid cached position to provide.
32.2.7 Notification
Toast notification: when set allows the agent to display “toast” notifications to the user (such as pushing data to the
server, inform user about the start of the agent, etc.).
320 Chapter 32. Monitoring mobile devices

CHAPTER
THIRTYTHREE
NETWORK TOPOLOGY
33.1 Introduction
NetXMS server automatically creates and maintains network model on different layers. All necessary information
taken from ARP cache, routing tables, and switch forwarding database of managed nodes. Topology data provided
by CDP, LLDP, and NDP (SONMP) protocols also used in building network model. Having network model instantly
available allows NetXMS users to perform various network topology tasks much faster and easier.
Requirements to build network topology:
• All network equipment should be registered in NetXMS system
• Equipment should response to SNMP
• Equipment should have at least STP
• There will be more information if equipment will have LLDP or CDP
Manual topology poll can be started on the network equipment to heave information about information availability.
Based on network topology network correlation is done. Network correlation reduce number of alerts and increase
problem resolution speed.
Currently there are 3 states/events regarding connectivity:
• down (event SYS_NODE_DOWN) - when server cannot contact the node and has no topology information for
event correlation or it is really problem with that node
• unreachable (SYS_NODE_UNREACHABLE) - when server knows that node cannot be contacted due to inter-
mediate router/interface failure
• up (SYS_NODE_UP) - when node is reachable
So when node becomes unreachable, either SYS_NODE_DOWN or SYS_NODE_UNREACHABLE event is gener-
ated, depending on root cause. But when node became reachable again, SYS_NODE_UP being generated.
33.2 How topology information is built
33.3 Find where node is connected
It is possible to find switch port where any given node is connected (sometimes called “connection point” in manage-
ment console). To find out node’s connection point, right-click on node object, and select Find switch port in pop-up
menu. Message box with search results will pop up, and if port is found, search results view will be opened (or updated
if already open). Search results view looks like this:
321
Columns have the following meaning:
Seq. Search result sequence number

Node Name of end node object
Interface Name of node’s interface object
MAC Interface’s MAC address
IP Interface’s IP address
Switch Name of switch node object
Port Name of interface object representing switch port
Type Connection type - direct or indirect. Direct connection type means that NetXMS
server did not detect any other devices on same switch port, and most likely end
node connected directly to the switch. Indirect means that some other devices was
detected on same switch port. Virtual machines and virtual machine host will always
be detected as indirect.
33.4 Find MAC address
It is possible to find location of any known MAC address in the network. To do this, select Tools → Find MAC address.
Results of a search will be displayed in the same results view. It is not necessary that node with given MAC address
be managed by NetXMS server, but if it is, appropriate details will be displayed.
322 Chapter 33. Network topology

33.5 Find IP address
It is possible to find location of any known IP address in the network. To do this, select Tools → Find IP address.
Results of a search will be displayed in the same results view. It is not necessary that node with given IP address be
managed by NetXMS server, but if it is, appropriate details will be displayed.
33.5. Find IP address 323

324 Chapter 33. Network topology

CHAPTER
THIRTYFOUR
BUSINESS SERVICES AND SLA
34.1 Introduction
In a nutshell, Business Services is a tool for availability monitoring of logical services. Company email, web site,
server farm, call center - all are examples of logical services. Moreover, the services can be combined together
to define a “broader” logical service. Company email, web site, name server and firewall all can be referred to as
“Company Internet Services” and monitored for availability as a whole. So if the name server goes down then the
“Company Internet Services” do not function properly as a whole. This feature can be used both for internal QA and
external Service Level Agreement (SLA) monitoring.
34.2 Services, node links, service checks
34.2.1 Service
Business Services represented with a tree-like hierarchy of nested logical services, nodes and service checks. One can
think of a service as a container consisting of other services, service checks and nodes linked to service checks. In
NetXMS terminology the last is called node link. For each service in the hierarchy, NetXMS calculates availability
percentage and keeps track of all downtime cases. To check availability at any particular level, select it in the Object
Browser or choose Availability Chart from the context menu.
34.2.2 Node link
Node link is a reference to any node with one or more service checks attached to this node.
34.2.3 Service check
Service check is a test whose result is used to define the state of the service. A service check may belong to the specific
node (node link) or directly to the service. A service check object contains NXSL script which either returns success
(the test result ok) or failure (the service has failed). There are the following special variables and constants which can
be used in NXSL scripts for service checks:
• $node - points to the current node the check is being executed for
• $reason - the script may set the reason of failure
• OK - constant, indicates success
• FAIL - constant, indicates failure
325
Service check templates
To avoid redefinition of the same service check multiple times (for multiple nodes) you can create service check
templates. The principle behind service check template is very similar to Templates. There are two notable differences
though:
• A service check template is always applied automatically to every new node (node link) added to the service
• A service check template is applied to nodes in the current level in the service tree and in all levels below
34.3 Configuration and usage
For both configuration and monitoring use Business Service container in the Object Browser view.
Fig. 1: Object Browser with Services
To define a new service select Create business service from the context menu in Object Browser and enter the service
name. Then under newly created service you may want to define other services, checks or node links. You can examine
or alter properties of the service.
If your service check relies on specific nodes then you need to create node links by selecting Create node link from
the context menu:
Fig. 2: Create Node Link
One or more service checks must be defined for every node link. Service check can be also defined at a business
service level. In the latter case it is not connected to any particular node and can be used for some general calculations
326 Chapter 34. Business services and SLA

(e.g. based on some server stats). To create a check select Create service check from the context menu, enter the check
name and navigate to Script tab in object properties:
Fig. 3: Service Check Properties
34.3.2 Monitoring
All business service calculations performed in real time. The system calculates uptime values for a day, a week and a
month for each business service defined. As soon as the uptime value changes it shows in the Object Details screen
for the service:
Alternatively you can view the availability screen in a slightly different format by selecting Availability chart from the
context menu.
34.3. Configuration and usage 327

328 Chapter 34. Business services and SLA

CHAPTER
THIRTYFIVE
REMOTE FILE MANAGEMENT
35.1 Agent file management
35.1.1 Introduction
This section describes possibilities to manage files on remote nodes using agent and required configuration for it.
35.1.2 Required Configuration
Subagent configuration
To do any manipulations with files on a node it is required to load filemng subagent and configure accessible paths. It
provides possibility to upload, download, delete, move and rename files.
All configuration parameters related to filemng subagent should be placed into *filemgr section of agent’s configura-
tion file. The following configuration parameters are supported:
Param- Description
eter
Root- Path to the folder which should be exposed. If “;ro” is appended to path - agent will reject any write
Folder operations with this folder
Agent’s configuration file example:
SubAgent = filemgr.nsm
[filemgr]
RootFolder = /home/zev # read/write access
RootFolder = /home/zev/etc # read/write access
RootFolder = /logs;ro # read only access
329
Access rights
To view File Manager View it’s enough to have “Read” access to node.
To download files from file manager of through multiple file download there should be “Download file” access for this
node and for multiple download “Read server files” access.
To upload file from subagent there should be “Upload file” access for this node.
For moving, renaming and deleting files from node it is required “Manage files” access to node.
35.1.3 File Manager view
For each configured node it is possible to open File Manager. It will display all configured root folders and allow to
browse into these folders.
File menu
• Download. . . : downloads file to selected folder on local computer

• Show : shows file with tail option ‘on’
• Rename : renames file
• Delete : deletes file
330 Chapter 35. Remote file management

Folder menu
• Upload file. . . : uploads local file to selected folder in view

• Upload folder. . . : uploads local folder to selected folder in view (not supported on web console)
• Download. . . : download folder to selected folder on local computer (on web console will be advised to save as
a zip of the selected folder)
• Rename : renames folder
• Delete : deletes folder and all it’s content
• Refresh this folder : refreshes content of selected folder in view
Other options
• It is possible to move files and folders with help of drag and drop.
• To refresh all view should be used view refresh button (not form folder menu). But in this case all expanded
folders will be closed.
35.2 Advanced File Management
There are options to run multiple file upload to agents, file upload jobs on hold and scheduled file upload jobs. All
this options are available uploading file from server to agent. That means that before upload file should be uploaded
to server for instruction check Upload file on server section.
Advanced file upload can be accessed selecting required nodes (can be selected more than one with help of ‘Ctrl’ key)
and in object menu selecting Upload file. . . .
35.2. Advanced File Management 331

Job configuration:
• File that should be uploaded on the agent(s).
• Remote file path(If destination will not be set then as a destination will be taken from agent’s config
parameter ‘FileStore’). If path is set agent will check if there is access to this folder. Access is configured
by filemgr subagent, check Agent file management.
• Job can be created “on hold”. This mean that job will be created, but not started. After creation it can be
manually started selecting job in Server Jobs view and clicking Unhold.
• Other option is to schedule file upload job. It can scheduled to be executed once at exact time (One time
execution) or to be executed according to schedule(Cron schedule). See Cron format for supported cron
format options.
Result of file upload job can be checked in Server Jobs view. It can be accessed by clicking View → Server Jobs.
35.3 Server File Management
35.3.1 Access Rights
There are 2 access rights that can be granted:

• Read server files : possibility to see files that are download on server
• Manage server files : possibility to remove or upload on server files
35.3.2 Upload file on server
It can be done in “Server File List” view

or “Tools”->”Upload file to server. . . ”.
35.3. Server File Management 333


CHAPTER
THIRTYSIX
REPORTING
Reporting module is an optional component, build on top of well known JasperReports library, which can produce
pixel-perfect documents in variety of formats based on historical data collected by NetXMS.
Reporting module consist of two main parts: user interface and standalone Reporting Server, which handles all
scheduling, execution, and optional document delivery to end users.
Report generation is two step process: first step is to collect and process input data, then render output files in desired
format. This separation exist for a reason: unlike rendering step, data collection could take hours to complete and it
make no sense to repeat same processing process to render Excel file instead of PDF. When first step is finished, all
processed information is saved into intermediate file on the reporting server and available for rendering at any time
(e.g. user can render and download report from last year, even if source data is already purged).
Reports execution and rendering can be initiated both manually and on schedule.
36.1 User Interface
All reporting-related operations are available in separate Reporting perspective. Perspective contains two main areas –
list of available reports on the left and report details view on the right. Details view show information about currently
selected report.
Fig. 1: Reporting perspective.
Details view contains tree main areas: Parameters, Schedules, and Results.
335
36.1.1 Parameters
Fig. 2: Execution parameters for report (in this example: Start date)
In this section, user can set all input parameters required for report execution, for example data range or list of objects
which should be included in the report. List of required parameters is extracted from report definition file and can be
empty, if particular report do not require any input data to operate.
36.1.2 Schedules
Each report can have one or more schedules, which define when it should be executed, and optionally rendered.
Reporting server can also notify users that new report is executed and available for download, or send resulting file as
an attachment.
Fig. 3: List of scheduled executions
To add new schedule, click on Add Schedule down below, this will open schedule editor.
Fig. 4: Schedule editor with two tabs, General and Notifications
General tab contains four scheduling options:

1. Once - execute report once at specified date and time
2. Daily - execute report every day at specified time
336 Chapter 36. Reporting

3. Weekly - execute report every week on selected days of week at specified time
4. Monthly - execute report every month on selected days at specified time
Fig. 5: Notifications tab of Schedule editor
Notification tab allows to control email notifications and report delivery to list of recipients. To enable notifications,
select Send notification on job completion checkbox.
If checkbox Attach rendered report checkbox is enabled, report will be rendered into selected format and attached to
notification email.
36.1.3 Results section
Fig. 6: List of generated reports
This section contains list of all generated reports, which are stored on the server and can be rendered on request. To
render report in desired format, right click on the record and select Render to PDF or Render to Excel.
If report is no longer needed, right click on record and select Delete to completely remove it from server.
36.1. User Interface 337

36.2 Configuration
36.2.1 NetXMS Server
NetXMS server maintain persistent connection with reporting server on localhost:4710, but if can be changed in
configuration.
Configuration Parameter Description Default Value

EnableReportingServer Boolean on/off switch which enable integration 0
ReportingServerHostname IP address or hostname of the reporting server localhost
ReportingServerPort Port number of the reporting server 4710
36.2.2 Reporting Server
Report definitions are loaded from the file system by scanning workspace folder, expected structure: $WORKSPACE/
definitions/$REPORT_GUID. Each report folder should contain file main.jrxml, any additional files (im-
ages, translation files) should be referenced in main.jrxml with relative paths. Sample directory listing:
workspace/definitions/6eb9c41c-e9f0-4e17-ac57-de747e16e480/i18n.properties
workspace/definitions/6eb9c41c-e9f0-4e17-ac57-de747e16e480/main.jrxml
workspace/definitions/6eb9c41c-e9f0-4e17-ac57-de747e16e480/logo.png
Server behaviour is controlled by two files: logback.xml (logger configuration) and nxreporting.
properties.
Format of logback.xml is described in Logback manual.
nxreporting.properties is a standard Java property file in key=value format.
nxreporting.workspace Path to workspace with deployed reports
system.datasource.driverClassNameJDBC class name, for example org.postgresql.Driver
system.datasource.url JDBC connection string, for example jdbc:postgresql://127.0.0.
1/netxms
system.datasource.dialect Hibernate dialect, for example org.hibernate.dialect.
PostgreSQLDialect. More information in JavaDoc
system.datasource.username
system.datasource.password
report.datasource.driverClassName
report.datasource.url
report.datasource.username
report.datasource.password
org.quartz.jobStore.dataSource
org.quartz.dataSource.myDS.driver
org.quartz.dataSource.myDS.URL
org.quartz.dataSource.myDS.user
org.quartz.dataSource.myDS.password
org.quartz.dataSource.myDS.maxConnections

36.2.3 Access Control
36.3 Installation Manual
36.3.1 Setup
1. Unpack netxms-reporting-server-2.0-M2.zip into some folder, in this example - /opt/nxreporting

2. Create directory “conf”
3. (Optional)Create logger configuration: conf/logback.xml (sample attached), detailed description here: http:
//logback.qos.ch/manual/configuration.html#syntax
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<appender name="FILE" class="ch.qos.logback.core.rolling.
˓→RollingFileAppender">
<file>/opt/nxreporting/log/nxreporting</file>
<rollingPolicy class="ch.qos.logback.core.rolling.
˓→FixedWindowRollingPolicy">
<fileNamePattern>/opt/nxreporting/log/nxreporting.%i.gz</
˓→fileNamePattern>
<minIndex>1</minIndex>
<maxIndex>5</maxIndex>
</rollingPolicy>
<triggeringPolicy class="ch.qos.logback.core.rolling.
SizeBasedTriggeringPolicy">
˓→
<maxFileSize>16MB</maxFileSize>
</triggeringPolicy>
<encoder>
<pattern>%d %5p | %t | %-55logger{55} | %m %n</pattern>
</encoder>
</appender>
4. Create configuration file for reporting server: conf/nxreporting.xml

<config>
<workspace>/opt/nxreporting/workspace</workspace>
<netxmsdConfig>/opt/netxms/etc/netxmsd.conf</netxmsdConfig>
<datasources>
<datasource>
<id>secondary</id>
<type>postgresql</type>
<url>jdbc:postgresql://127.0.0.1/netxms</url>
<username>netxms</username>
<password>netxms</password>
</datasource>
</datasources>
<smtp>
<server>127.0.0.1</server>
<from>noreply@netxms.org</from>
</smtp>
<netxms>
<server>127.0.0.1</server>
<login>admin</login>
36.3. Installation Manual 339


<password>netxms</password>
</netxms>
</config>
In most cases (when reports are using only single datasource), setting “netxmsdConfig” is enough,
database type and credentials will loaded automatically from netxmsd.conf. “netxms” section of the
config is required for reports, which load data not from SQL datasource, but using NetXMS API
instead (connection is maintained by reporting server).
5. Create workspace directory (as set by “workspace” parameter), it will contain both report definitions (in “defi-
nitions” directory) and intermediate report data (in “output” directory).
6. Put report definition jars into workspace/definitions/, for example:
AirAlk:~() $ ls -al /opt/nxreporting/workspace/definitions/*.jar

-rw-r--r-- 1 alk wheel 3729 Mar 11 15:31 /opt/nxreporting/workspace/
˓→definitions/alarm-history-1.0.0.jar

˓→definitions/alarm-resolution-time-1.0.0.jar

˓→definitions/alarm-resolution-time-statistics-by-users-1.0.0.jar

˓→definitions/dci-1.0.0.jar

˓→definitions/epp-1.0.0.jar
...
7. Enable reporting server connector, set EnableReportingServer to 1 (either in GUI - server configuration, or using
command line: “nxdbmgr set EnableReportingServer 1”), then restart netxmsd.
8. Create additional tables by executing both scripts for your type of database from sql folder, for example:
nxdbmgr batch sql/postgres/nxreporting.sql

nxdbmgr batch sql/postgres/quartz.sql
It may be required to comment out “drop table” statements in the beginning of quartz.sql file.
9. Start reporting server:
cd /opt/nxreporting
java -jar nxreporting-2.0-M2.jar
When started with “-jar” option, java will automatically find configuration files in conf/ and all li-
braries in lib/. However, you can run it differently (and omit “cd /opt/nxreporting”):
java -cp /opt/nxreporting/lib/\*.jar:/opt/nxreporting/conf:/opt/

˓→nxreporting/nxreporting-2.0-M2.jar com.radensolutions.reporting.Launcher
or, if you are running windows:
java -cp /opt/nxreporting/lib/\*.jar:/opt/nxreporting/conf:/opt/

˓→nxreporting/nxreporting-2.0-M2.jar com.radensolutions.reporting.Launcher
In under 10 seconds, netxmsd should connect to reporting server and list of available reports will be
visible in “Reporting” perspective.

Resulting directory structure
/opt/nxreporting:
total 5728
drwxr-xr-x 6 alk wheel 204 Apr 7 20:31 .
drwxr-xr-x 14 alk wheel 476 Apr 3 20:07 ..
drwxr-xr-x 4 alk wheel 136 Apr 7 20:31 conf
drwxr-xr-x 79 alk wheel 2686 Jan 23 10:29 lib
-rw-r--r-- 1 alk wheel 2929061 Jan 23 10:29 nxreporting-2.0-M2.jar
drwxr-xr-x 4 alk wheel 136 Mar 11 15:06 workspace
/opt/nxreporting/conf:
total 16
drwxr-xr-x 4 alk wheel 136 Apr 7 20:31 .
-rw-r--r-- 1 alk wheel 1367 Apr 7 20:21 logback.xml
-rw-r--r-- 1 alk wheel 764 Apr 7 13:21 nxreporting.xml
/opt/nxreporting/lib:
total 109528
...
/opt/nxreporting/workspace:
total 0
drwxr-xr-x 4 alk wheel 136 Mar 11 15:06 .
drwxr-xr-x 32 alk wheel 1088 Mar 11 15:43 definitions
drwxr-xr-x 8 alk wheel 272 Mar 11 15:42 output
/opt/nxreporting/workspace/definitions:
total 248
drwxr-xr-x 4 alk wheel 136 Mar 11 15:06 ..
-rw-r--r-- 1 alk wheel 3729 Mar 11 15:31 alarm-history-1.0.0.jar
-rw-r--r-- 1 alk wheel 5607 Mar 11 15:31 alarm-resolution-time-1.0.0.jar
-rw-r--r-- 1 alk wheel 4570 Mar 11 15:31 alarm-resolution-time-statistics-by-
˓→users-1.0.0.jar
...
/opt/nxreporting/workspace/output:
total 0
drwxr-xr-x 4 alk wheel 136 Mar 11 15:06 ..
drwxr-xr-x 4 alk wheel 136 Mar 11 15:44 01827cdb-cb23-4b06-b607-fd02c4279add
drwxr-xr-x 4 alk wheel 136 Mar 7 22:04 52ce4398-a131-4a79-887e-672cc73d5d34
drwxr-xr-x 3 alk wheel 102 Mar 11 15:44 8a7c025c-84c8-4914-b2bf-3b4cde27a224
...
36.3. Installation Manual 341

36.3.2 Report definitions
On startup, reporting server scan workspace/definitions directory for *.jar files. Each file is unpacked into it’s own
folder based on jar name (e.g. “report1.jar” will be unpacked into “report1”). Each archive should contain at least one
file – “main.jrxml”, which is main report definition. It can also contain subreports, images – or anything else, supported
by Jasper Reports. Any additional resources should be referenced using paths relative to root folder of unpacked report,
which is set as additional parameter “SUBREPORT_DIR” (e.g. “$P{SUBREPORT_DIR}/logo.png”).
Archive can also contain java code, which will be used as data provider (instead of querying SQL
database). Reporting server will try to load class “report.DataSource”, which should implement interface
“com.radensolutions.reporting.custom.NXCLDataSource” (attached sample: Event Processing Policy). Query string
language in jrxml should be set to “nxcl” (default - SQL).
Simplest way to create jar files are using Maven, empty project is provided in samples archive. Running “mvn pack-
age” will produce complete jar file in “target” directory.

CHAPTER
THIRTYSEVEN
IMAGE LIBRARY
All images used on maps or as rack, chassis or chassis module image should be uploaded to Image Library first. It is
possible to upload, delete and update images. They can be organized by categories.
Tips:
• Images on maps are displayed without scaling.
343
344 Chapter 37. Image library

CHAPTER
THIRTYEIGHT
MOBILE CONSOLE
NetXMS mobile console is a monitoring tool for Android devices running version 2.2. and later.
Currently, only a small subset of the functions present in the Desktop/Web edition are implemented, mainly read/only
operations. The next paragraphs briefly describes each section.
38.1 Main window
Here you can see how appears the main window and the underneath levels.
345
346 Chapter 38. Mobile Console

38.1. Main window 347

From the main window it is possible to get access to the following menu items:
• Settings: select this item to configure the console.
• Reconnect: select this item to force a reconnection to the server to gather new collected data.
• Disconnect & Exit: select this item to stop the console and exit from the app.
Underneath levels have menu that are context dependent, a detailed description can be found in each section.
38.2 Alarms
Alarms section is used to list and manage all pending alarms, eventually filtered on a particular node/container.
Through this view it is possible to manage alarms:
• Actions:
– Acknowledge: acknowledge the alarm.
– Sticky acknowledge: sticky acknowledge the alarm.
– Resolve: resolve the alarm.
– Terminate: terminate the alarm.
– View last values: jump to the node info section to view the last values for the node that generated the
alarm.
• Sort:
– Sort by severity ascending: sort list using event severity as criteria, ascending.
– Sort by severity descending: sort list using event severity as criteria, descending.

– Sort by date ascending: sort list using date of event as criteria, ascending.
– Sort by date descending: sort list using date of event as criteria, descending.
– Sort by node name ascending: sort list using node name that generated the event as criteria, ascending.
– Sort by node name descending: sort list using node name that generated the event as criteria, descend-
ing.
• Select all: select all the alarms from the list
• Unselect all: clear any selection of alarms from the list
38.3 Dashboard
Dashboards are defined by administrator and allow to combine any available visualization components with data from
multiple sources in order to create high-level views to see network (or parts of it) health at a glance. Not all elements
are currently available for the mobile console, dashboards are properly refreshed according to their schedule. Due to
dashboard size, keep in mind that Smartphones cannot be the best device to show them, a tablet is much more suitable
device. Here an example:
38.3. Dashboard 349

38.4 Nodes
This section is used to list and manage all nodes (all network infrastructure monitored by NetXMS are represented as
a set of objects. Each object represents one physical or logical entity, or group of them). Objects can be organized
into hierarchical structure, the Nodes section is used to explore them. In the right bottom corner of the icon there is
a symbol that indicates the status of the node/container following the same symbology used on the desktop console.
Clicking on a container will show the items inside, continuing to click up to an object will show a set of swipeable
pages:
• Overview: here are presented the main info associated to this node, such as the name, the primary IP, the status,
etc.
• Alarms: here are presented the list of pending alarms (if any) for this node, with the possibility to manage them
with the following commands:
– Actions:
* Acknowledge: acknowledge the alarm.

* Sticky acknowledge: sticky acknowledge the alarm.
* Resolve: resolve the alarm.
* Terminate: terminate the alarm.
* View last values: jump to the node info section to view the last values for the node that generated the
alarm.
– Select all: select all the alarms from the list
– Unselect all: clear any selection of alarms from the list
• Last values: here are presented the DCI collected for this node, as well as the possibility to draw the following
graphics (for one or more values):
– Last half hour: draw one or more line graphs for the last half hour collected values
– Last hour: draw one or more line graphs for the last hour collected values
– Last two hours: draw one or more line graphs for the last two hours collected values
– Last four hours: draw one or more line graphs for the last four hours collected values
– Last day: draw one or more line graphs for the last day collected values
– Last week: draw one or more line graphs for the last week collected values
– Bar chart: draw a bar chart with the last collected value
– Pie chart: draw a pie chart with the last collected value
• Interfaces: here are presented all the interfaces associated to this node. For each interface it is possible to instruct
the following commands:
– Manage: interface will be put in manage state
– Unmanage: interface will be put in unmanaged state
– Change expected state: change the expected interface state, possible values:
* UP: interface expected state will be put in UP state

* DOWN: interface expected state will be put in DOWN state
* IGNORE: interface expected state will be put in IGNORE state
• Find switch port: will start the search for a connection point (if available)

38.4. Nodes 351


38.5 Graphics
Predefined graphics are defined by administrator and can be used to view collected data in a graphical form (as a line
chart). Currently, the mobile console doesn’t autorefresh the content of the graphic selected. Here an example of a
predefined graphs:
38.6 MACaddress
This section is used to list previously searched MAC addresses or to start a new search by scanning a barcode value
(this feature needs the installation of Barcode Scanner from Zxing Team – freely available on the Google Play), by
input it manually or by getting it directly from a node via the “Find Switch port” command.
38.5. Graphics 353

38.7 Settings
This section is used to configure the behavior of the console.
38.8 Global settings
• Autostart on boot: check to automatically start the agent on boot (to be effective, app must not be moved to SD
card).
38.9 Connection
38.9.1 Parameters
Allows selecting the parameters used to connect to the server:

• Server: address of the server (IP or name).
• Port: port of the server (default 4701).
• User name: username to connect to the server.
• Password: password to connect to the server.
• Encrypt connection: when selected challenges an encryption strategy with the server (depending on sup-
ported/configured providers).
38.9.2 Scheduler
Enables the possibility to define periodic connections to the server. If the scheduler is not enabled the app will try to
connect to the server every time it detects a new connection (data or WiFi) and remains always connected as far as the
connection remains active:
• Enable scheduler: check this to enable the scheduler.
• Frequency (min): amount of time, in minutes, that has to elapse between each tentative of connection to the
server to send the gathered info.
• Duration (min): amount of time, in minutes, that has to elapse before disconnect from the server.
• Daily scheduler: provides the ability to define a “one range” daily on which the agent is operational. Out of the specified ra
– Daily activation on: start time for daily activation.

– Daily activation off : stop time for daily activation.

38.10 Notifications
38.10.1 Connection status
This section is to manage the notifications related to the connection status.

• Notification behavior: defines which kind of action should trigger notifications to the user. Possible options:
– Never: ignore connection status

– When connected: notify when connection is successful
– When disconnected: notify when connection is unsuccessful
– Always: notify either connection successful and connection unsuccessful
• Toast notification: provides connection notification via “toast” , behavior is defined by “Notification behav-
ior”.<br />
• Icon notification: provides connection notification via icon in the status bar, behavior is defined by “Notification
behavior”.
38.10.2 Alarms
• Alarms notification: select to enable alarms notification in the status bar.

• Alarms sound by severity: for each of the following categories:
– Normal
– Warning
– Minor
– Major
– Critical
38.11 Interface
38.11.1 Multipliers
Allows to select the preferred multipliers to be used to show values. Allowed options: * None: do not apply multiplier,
values are extended. * Decimal: applies a decimal multiplier (power of 10, e.g. 1000 -> 1K, 1000000 -> 1M, . . . ) *
Binary: applies a binary multiplier (power of 2, e.g. 1024 -> 1Ki, 1048576 -> 1Mi, . . . )
38.10. Notifications 355

38.11.2 Graph text size
Allows to set the text size to be used for axis labels (if the default value is too small for high density devices).
38.11.3 Show legend in graphs
Allows to select to show or not the legend in the top right angle of the graphs. Since legend can be intrusive, especially
when there are several lines plotted, user can select to disable the legend.

CHAPTER
THIRTYNINE
ADVANCED TOPICS
39.1 Zones
As NetXMS server keeps track of an IP topology, it is important to maintain the configuration in which IP addresses
do not overlap and that two IP addresses from same subnet are really within one subnet. Sometimes, however, it is
needed to monitor multiple sites with overlapping IP address ranges. To correctly handle such situation, zoning must
be used. Zone in NetXMS is a group of IP subnets which form non-overlapping IP address space. There is always zone
0 which contains subnets directly reachable by management server. For all other zones server assumes that subnets
within that zones are not reachable directly, and proxy must be used.
39.1.1 Enable Zoning
Zoning support is off by default. To turn it on you must set server’s configuration variable EnableZoning to 1
and restart server. After restart, server will create default zone with UIN (unique identification number) 0 and put all
existing subnets into that zone. Subnet tree will looks like this:
357
39.1.2 Setting communication options for zones
Server have to know proxy nodes to be able to communicate with nodes in remote zones. Default proxy settings for
all nodes in the zone can be set on Communications page in zone object properties:
On this page you can set default proxy node for NetXMS agents, SNMP, and ICMP. Note that proxy node must be in
default zone and must have primary IP reachable by NetXMS server.
39.1.3 Moving nodes between zones
To move existing node to another zone, select Change zone from nodes context menu, then select target zone in zone
selection dialog that will appear. After move to another zone, server will immediately do configuration poll on the
node.
39.1.4 Integration with external HelpDesk
NetXMS provides possibility to create issues in external helpdesk system directly from NetXMS management con-
sole, based on pending alarms. In this situation NetXMS and external helpdesk system will have synchronized issue
workflow.
For now integration is done only with JIRA.
358 Chapter 39. Advanced topics

39.1.5 JIRA Module
This module provide integration between NetXMS and JIRA.
Required NetXMS configuration
For NetXMS is required to configure server parameters(they should be created by user) and restart the server.
Parameter name Description

HelpDeskLink For JIRA integration should be set to “jira.hdlink” (without quotes)
JiraIssueType Name of the JIRA issue type, which will be used by NetXMS. Sample value: “Task”
(without quotes)
JiraLogin Login of the JIRA user(This user should exist in JIRA system with with permissions
to create issues in project(JiraProjectCode) and comment on own issues)
JiraPassword Password of the JIRA user
JiraProjectCode Project Key in JIRA. (Project should exist)
JiraServerURL URL of JIRA installation. Example: “http://localhost:8080/jira”. Please note, that
trailing slash (“/”) should be removed!
If all configuration was successfully done after rester in console should be present:
[25-Apr-2014 14:16:07.894] [INFO ] Helpdesk link module JIRA (version 1.2.14) loaded
˓→successfully
Required JIRA configuration
NetXMS JIRA plugin should be deployed to JIRA and configured. REST API should be enabled in JIRA configuration
(enabled in default configuration).
To access configuration page for the plugin, go to “System → Advanced” and select “NetXMS Integration” tab:
Possible configuration options:
39.1. Zones 359

1. “Plugin Enabled” — global on/off switch, plugin completely cease any activity when turned off (default).
2. “Force Save” — by default, plugin will verify configuration before saving (connectivity to all servers, creden-
tials). This checkbox allows to bypass this step completely and save configuration even if one of more NetXMS
servers are rejecting provided credentials or do not respond at all)
3. “Project Key” — Key of the project, where issues from NetXMS will be created. This key will be also used in
workflow operations — plugin will process events related to this project:
4. “Servers” — addresses of up to a 3 NetXMS servers, can be either IP address or hostname.

5. “Log In” — user login in NetXMS (User should exist in NetXMS with Read, View Alarms, Acknowledge
Alarms, Terminate Alarms to all nodes)
6. “Password” — user password in NetXMS
Plugin will verify configuration and provide feedback. If one or more NetXMS servers are not responding (e.g. they
are not configured yet), you can select “Force Save” to overrule verification process and save configuration.
Workflow configuration
Since JIRA workflow can be much more sophisticated than alarm states in NetXMS, JIRA Administrator should decide
which workflow transition should change NetXMS alarm state.
NetXMS supports four alarm states:
1. Outstanding — initial state, can’t be set from JIRA side
2. Acknowledged — operator is aware of the problem and it’s in progress (“Acknowledge” action)
3. Resolved — problem is resolved but alarm stays in the list until verified and terminated by supervisor (“Resolve”
action)
4. Terminated — problem is resolved and verified, alarm is removed from the list (“Terminate” action)
Sample workflow (JIRA default workflow):

Sample mapping:
Transition NetXMS post-function action

Start Progress Acknowledge
Resolve Issue Resolve
Close Issue Terminate
All other transitions Ignored
Configure workflow in JIRA:

1. Create new Workflow Schema if required
2. Copy existing or create new Workflow
3. Assign Workflow to the project, where NetXMS will create issues
4. Modify transitions to call plugin’s post-function and change related alarm in NetXMS
a. Click on a “cog” icon on a transition and select “View Post Functions”:
39.1. Zones 361

b. Click on “Add a new post function to the unconditional result of the transition”:
c. Select “NetXMS Modify Alarm” and click “Add”:
d. Select desired alarm action (Acknowledge / Resolve / Terminate) and click “Add”:

e. Repeat for all required transitions

5. Publish workflow changes
Ticket creation
Tickets are created from from alarms manually. To create ticket user should have “Create helpdesk tickets” access for
required objects.
Steps to create ticket:
1. Right click on alarm in NetXMS and select “Create ticket in helpdesk system”:
2. In a moment, issue will be created and Helpdesk ID will be show in corresponding column:
3. Right click on the alarm and select “Show helpdesk ticket in web browser” to navigate to the issue in JIRA:
39.1. Zones 363

39.2 Hooks
Sometimes it is required to add some additional functionality after poll, object creation or other action - for this purpose
hooks were created. Hook is manually created script in Script Library that is executed at a special condition like end
of the poll or interface creation.
More about poll types and purposes can be found there and about script creation there.
To be recognized as a hook script should have special name. It should be named according to convention:
Hook::hook_name.
Example: Hook::ConfigurationPoll
Full list of hooks:

Hook name Description Parameters Return value

Hook::StatusPoll Hook that is executed at $object - current ob- none
the end of status poll ject, one of ‘NetObj’
subclasses
$node - current object if it
is ‘Node’ class
Hook::ConfigurationPoll Hook that is executed at $object - current ob- none
the end of configuration ject, one of ‘NetObj’
poll subclasses
is ‘Node’ class
Hook::InstancePoll Hook that is executed $object - current ob- none
after instance discovery ject, one of ‘NetObj’
poll. subclasses
is ‘Node’ class
Hook::TopologyPoll Hook that is executed at $node - current node, ob- none
the ens of topology poll ject of ‘Node’ type
Hook::CreateInterface Hook that is executed af- $node - current node, ob- true/false - boolean -
ter new interface is cre- ject of ‘Node’ type whether interface should
ated. $1 - current interface, ob- be created
ject of ‘Interface’ type
Hook::AcceptNewNode Hook that is executed on a $ipAddr - IP address of true/false - boolean -
new node add. This script the node being processed whether node should be
should return 1 if node $ipNetMask - netmask of created
should be added. In case the node being processed
if script returns nothing or $macAddr - MAC address
something other than 1 - of the node being pro-
node will not be added. cessed
$zoneId - zone ID of the
node being processed
Hook::DiscoveryPoll Hook that is executed at $node - current node, ob- none
the ens of discovery poll ject of ‘Node’ type
Hook::PostObjectCreate Hook that is executed af- $object - current ob- none
ter object is created ject, one of ‘NetObj’
subclasses
is ‘Node’ class
Hook::CreateSubnet Hook that is executed af- $node - current node, ob- true/false - boolean -
ter creation of a subnet ject of ‘Node’ class whether subnet should be
$1 - current subnet, object created
of ‘Subnet’ class
Hook::UpdateInterface Hook that is executed at $node - current node, ob- none
the ens of interface update ject of ‘Node’ type
$interface - current inter-
face, object of ‘Interface’
type
Hook::EventProcessor Hook that is executed for $object - event source ob- none
each event prior to it’s ject, one of ‘NetObj’ sub-
processing by Event Pro- classes
cessing Policies. $node - event source ob-
ject if it is ‘Node’ class
$event - event being pro-
cessed (object of ‘Event’
class)
39.2. Hooks
Hook::AlarmStateChange Hook that is executed on $alarm - alarm being pro- none 365
alarm state change (alarm cessed (object of ‘Alarm’
gets acknowledged, re- class)
solved or terminated)
Usually hooks are used for automatic actions that need to be done on node. For example automatic remove change of
expected state of interface depending on some external parameters.
39.3 Troubleshooting
39.3.1 Resetting “system” user password
Warning: Server (“netxmsd”) should be stopped while performing password reset operation!
Passwords in NetXMS are stored in hashed, not-reversible way, so there are no way to recover it, but it can be reset.
Use following procedure to reset password and unlock account:
1. stop netxmsd
2. run “nxdbmgr reset-system-account” to unlock “system” account and change it’s password to default
(“netxms”).
3. start netxmsd
4. login as “system” using password “netxms”
5. In user manager change password for any admin user account
6. login as admin user and disable “system” user account
39.3.2 Enable Crash Dump Generation
When running on Windows server is capable of creating crash dumps. To enable crash dump generation, add the
following options to netxmsd.conf file:
CreateCrashDumps = yes
DumpDirectory = path
DumpDirectory must point to directory writable by server process. After each crash server will create two files:
info and mdmp. Info file contains basic information about crash, server version, and call stack of current thread.
Mdmp file is a minidump which can be read and analyzed using debugger.
39.3.3 Force Crash Dump Creation
It is possible to force creation of crash dump. To do that you’ll need access to server debug console. You can access
it using nxadm tool or via Tools → Server Console menu in management console. Once in server debug console,
you can run command dump or raise access. First command works only on Windows and will produce process
dump without stopping it. Second command will cause access violation exception which will lead to process crash
and crash dump generation.

39.3.4 SNMP Device not recognized as SNMP-capable
Common issues:
1. Invalid community string or credentials
2. Access control on the device or firewall prevent connections from NetXMS server
3. Device do not support System (.1.3.6.1.2.1.1) or Interfaces (.1.3.6.1.2.1.2) MIBs, which are used to detect
SNMP-capable devices. To override OIDs used for detection, set node’s custom attribute snmp.testoid to
any OID supported by device.
39.4 Automatic actions on a new node
On a new node creation is generated SYS_NODE_ADDED event. So any automatic actions that should be done on
a node can be done by creating EPP rule on on this event, that will run script. In such way can be done node bind to
container, template auto apply and other automatic actions.
39.5 Autologin for Management Console

Starting from version 1.2.4, it is possible to connect management console (nxmc) or web management console to server
automatically without login dialog. This chapter describes additional command line options and URL parameters for
that.
39.5.1 Desktop Console
Command line option Description

-auto Connect to server automatically without login dialog
-dashboard=dashboard Automatically open given dashboard after login (either dashboard object ID or
name can be specified)
-login=login Set login name
-password=password Set password, default is empty
-server=address Set server name or IP address
For example, to connect management console to server 10.0.0.2 as user guest with empty password, use command
nxmc -auto -server=10.0.0.2 -login=guest
39.5.2 Web Console
URL parameters Description

auto Connect to server automatically without login dialog
dashboard=dashboard Automatically open given dashboard after login (either dashboard object ID or
name can be specified)
login=login Set login name
password=password Set password, default is empty
server=address Set server name or IP address
39.4. Automatic actions on a new node 367

For example, to connect web management console to server 10.0.0.2 as user guest with empty password and open
dashboard called “SystemOverview”, use URL
http://server/nxmc?auto&server=10.0.0.2&login=guest&dashboard=SystemOverview
39.6 NetXMS data usage in external products
NetXMS provides next options to use data in other applications:

• Use autologin and dashboard name in URL to add dashboard to your company documentation(where URL usage
is possible).
• Use Grafana for graph creation and further usage
• Get data through Web API
39.7 Web API/Rest API
The NetXMS WebAPI is being developed to support larger integration possibilities for the NetXMS server and is based
on the RESTful philosophy. API calls are REST-like (although not purely RESTful) and uses JSON for data exchange.
The API currently supports Grafana integration and some additional parameters for integration. The NetXMS WebAPI
is currently in very early development!
Information about Grafana configuration can be found here.
39.7.1 Requirements
• A running instance of the NetXMS server.

• Access to a web server.
39.7.2 Setup
1. Download netxms-websvc-VERSION.war (example: netxms-websvc-2.2.15.war) file from http://www.netxms.

org/download page.
2. Copy the downloaded .war file to your web server.
3. Create a nxapisrv.properties file and place it in the property file location of your web server and specify
the NetXMS Server address with the property.
Localhost address will be used if no address was set. Server configuration example:
netxms.server.address=sever.office.radensolutions.com
If the server is running on a non-standard port, specify it with the following property:
netxms.server.port=

39.7.3 Implemented functionality
Authentication
Login
Any user account configured in NetXMX can be used to authenticate to Rest API, however this user should have
access right to objects that will be requested through the API.
There are 3 implemented options of authentication:
1. Basic authentication for Rest API session creation, more information can be found on Wikipedia
2. Through POST request for Rest API session creation
3. Through POST request to allow external software user authentication using NetXMS user accounts. To be able
to login using this authentication type, user account should have “External tool integration account” access right
set.
Creating Rest API session:
Request type: POST

JSON data:
{"login":"admin","password":"netxms"}
Request path: API_HOME/sessions

Return data:
On success server will set cookie session_handle and json with session GUID and server version. When
performing subsequent requests, session GUID should be provided in Session-Id: field of request’s header
or the cookie should be passed.
Performing external authentication:
Request type: POST

JSON data:
{"login":"admin","password":"netxms"}
Request path: API_HOME/authenticate

Return data:
The API will return a 200 response if the credentials are correct, a 400 response if either login or password
is not provided or 401 if the provided credentials are incorrect.
Authentication used to gain Rest API session.
39.7. Web API/Rest API 369

Logout
To log out request with given session ID.

Request type: DELETE
Request path: API_HOME/sessions/{sid}
Return data:
The API will return a 200 response if log out succeed.
Objects
Get multiple objects with filters
Request to get all objects available to this user or to get objects that fulfill filter requirements and are available to this
user.
Request type: GET
Request path: API_HOME/objects
Filter options:
• area=geographical area
• class=comma-separated class list
• name=pattern or regex, if useRegex=true
• parent=parent object id
• topLevelOnly=boolean - select top level objects only. false by default
• useRegex=boolean - treat name and custom attribute value as regex. false by default
• zone=comma-separated list of zone UINs
• @custom_attribute_name=pattern or regex, if useRegex=true
Return data:
Will return filtered objects or all objects available to user.
Get object by id
Request to get exact object identified by ID or GUID.

Request type: GET
Request path: API_HOME/objects/{object-id}
Return data:
Object information identified by provided ID or GUID.

Alarms
Full scope of currently active alarms can be obtained or object specific list.
Get multiple alarms with filters
Request to get all active alarms available to this user or to get active alarms that fulfill filter requirements and are
available to this user.
Request type: GET
Request path: API_HOME/alarms
Filter options:
• alarm=list of alarm states. Possible values: outstanding, acknowledged, resolved
• createdBefore=UNIX timestamp
• createdAfter=UNIX timestamp
• objectId=ID or related object
• objectGuid=GUID or related object
• includeChildObjects=boolean. Set to true to get alarms of container child objects
• resolveReferences=resolve IDs into human readable data
• updatedBefore=UNIX timestamp
• updatedAfter=UNIX timestamp
Return data:
Will return filtered active alarms or all active alarms available to user.
Alarm by id
Request to get an alarm by it’s ID.

Request type: GET
Request path: API_HOME/alarms/{alarm-id}
Return data:
Will return alarm specified by ID.
DCI Data
There are 2 options to get DCI last values. First is to get last values for one DCI and the second one is to create adhoc
summary table with required values for all nodes under container.
39.7. Web API/Rest API 371

DCI last values
Request to get last values of DCI identified by ID for exact object identified by ID or GUID.
Request type: GET
Request path: API_HOME/objects/{object-id}/datacollection/{dci-id}/values
Filter options:
• from=requested period start time as unix timestamp
• to=requested period end time as unix timestamp
• timeInterval=requested time interval in seconds
• itemCount=number of items to be returned
Return data:
Will return last values for requested node and DCI limited by filters.
Adhoc summary table
Option to get last values for multiple nodes(for all nodes under provided container) for the same DCIs. Required DCIs
and container are provided in request.
Request type: POST
Request path: API_HOME/summaryTable/adHoc
POST request JSON
{
"baseObject":"ContainerName",
"columns": [
{
"columnName":"Free form name that will be used in return table for this column
˓→",
"dciName":"Name of DCI, that will be used for filtering"

},
{
"columnName":"Name2",
"dciName":"DCIName2"
}
]
}
Return data:
Will return adhoc summary table configured accordingly to request json.

39.8 Find Object
Management console has an option to filter objects by defined by user criteria. Filter can be access by Tools->Find
Object. Filter can be used in two different modes: filter and query.
39.8.1 Filter
Filter will search object using class filter, zone filter, IP range and search string that will be checked for each object in
all it’s text fields (name, comments, custom attributes, Location, etc.).
39.8.2 Query
There can be written any script that will be executed on all objects and if stript returns true - object will be shown in
the resulting table. There can be used the same syntax as for Object query Dashboard element, but variables will not
be added as additional columns for table in this case.
39.8. Find Object 373


CHAPTER
FORTY
SCHEDULED TASKS
NetXMS provide option to schedule different tasks. Each task have it’s own parameter count and type. The only
common parameter is node on which task will be executed. Schedule time can be set in two ways as one time schedule
or as a cron task (see Cron format for supported cron format options).
Information about available tasks can be found there:

1. File Upload
2. Script Execution
3. Maintenance
40.1 File Upload
Task is named Upload.File. This task uploads server file to agent. Upload file should exist in server file storage. Task
can be created in Schedules view or in Upload file. . . dialog.
Parameters:
1. File name that should be uploaded
2. Path and file name where this file should be uploaded on agent
Example: Warning-C.wav,/destination/location/Warning-C.wav
375
40.2 Script Execution
Task is named Execute.Script. This task executes script from library. Selected node is set as $node variable in the
script.
Parameters:
1. Server script name
40.3 Maintenance
Tasks are named Maintenance.Enter and Maintenance.Leave. This tasks turn on and turn off maintenance mode for
selected node. More about maintenance mode can be found there.
This task does not require parameters.
40.4 Access Rights
Access rights for schedules can be separated into two parts. Rights that are required to create, edit, delete tasks at all
and rights that are required to schedule exact task type. Task can be created by user or by system.
Overall access rights:
Access right Description

Manage user scheduled Option to add, view, edit, delete users’ tasks
tasks
Manage own scheduled Option to add, view, edit, delete tasks created by this user
tasks
Manage all scheduled Option to add, view, edit, delete tasks created by user and system
tasks
Task specific access rights:
Schedule type Required access right

File Upload Schedule file upload task
Script Execution Schedule script task
Maintenance Schedule object maintenance
For some tasks like File.Upload there is also checked if this user has right to upload file to this node and if there is
an access to the specific folder. Access rights like this are checked while task execution, not while scheduling. If user
does not have access, then task will just fail.
376 Chapter 40. Scheduled tasks

CHAPTER
FORTYONE
SCRIPTING
41.1 Scripting library
Script Library is used to store scripts that can be afterwards executed as macros, part of other script or just from server
console. Scripts can be added, deleted and modified in in this view.
41.1.1 Usage
Scripts from Script Library can be accessed as:

1. a macros $[scriptName]
2. used in other script in format: “use scriptName”
3. executed from server console “execute scriptName”
4. executed as post action for pols - then script name should start from “Hook::” and then should be name of
poll like “Hook::ConfigurationPoll”.
41.2 Execute Server Script
This view allows to execute arbitrary script. Script can be manually created just before execution, and afterwards
saved, can be taken from the script library, can be used modified script from the script library and afterwards saved or
saved as. If this view is opened on a node, then in the script is available $node variable with node object.
377
41.3 NXSL
41.3.1 Overview
In many parts of the system, fine tuning can be done by using NetXMS built-in scripting language called NXSL
(stands for NetXMS Scripting Language). NXSL was designed specifically to be used as embedded scripting lan-
guage within NetXMS, and because of this has some specific features and limitations. Most notable is very limited
access to data outside script boundaries – for example, from NXSL script you cannot access files on server, nor call
external programs, nor even access data of the node object other than script is running for without explicit permission.
NXSL is interpreted language – scripts first compiled into internal representation (similar to byte code in Java), which
is then executed inside NXSL Virtual Machine. Language syntax and available functions can be found in NXSL
documentation.
378 Chapter 41. Scripting

41.4 NXShell
NxShell is based on Jython and provide access to NetXMS Java API using interactive shell. NxShell is build as single
jar file, which includes all required libraries.
Download: http://www.netxms.org/download/nxshell-VERSION.jar (example: http://www.netxms.org/download/
nxshell-1.2.13.jar)
41.4.1 Usage
There are two options of this jar usage:

1. it can be started as interactive shell;
java -jar nxshell-1.2.15.jar
2. it can be started with the script name as a first parameter. Then it will just execute this script and exit. Example:
java -jar nxshell-1.2.15.jar test.py
When NxShell is started, it tries to get server IP, login and password from Java properties. In interactive mode, user
will be asked for details, otherwise default values will be used.
Start as interactive shell, with IP and Login provided (password will be asked):
java -Dnetxms.server=127.0.0.1 -Dnetxms.login=admin -jar nxshell-1.2.15.jar
Properties
These properties should be set with JVM’s “-D” option. Please make sure that all “-D” options are before “-jar”.
Parameter Default Value

netxms.server 127.0.0.1
netxms.login admin
netxms.password netxms
netxms.encryptSession true
41.4.2 Scripting
For details on API please refer to javadoc at http://www.netxms.org/documentation/javadoc/latest/.

NxShell provide user with already connected and synchronized session to simplify scripting. Most required packages
are imported as well to minimize typing.
Global Variables
Variable Type Notes

session org.netxms.client.NXCSession
s org.netxms.client.NXCSession Alias for “session”
41.4. NXShell 379

Helper Functions
Example
More examples can be found on a NetXMS wiki.
parentId = objects.GenericObject.SERVICEROOT # Infrastructure Services root

cd = NXCObjectCreationData(objects.GenericObject.OBJECT_CONTAINER, "Sample Container",
˓→ parentId);
containerId = session.createObject(cd) # createObject return ID of newly created

˓→object
print '"Sample Container" created, id=%d' % (containerId, )
flags = NXCObjectCreationData.CF_DISABLE_ICMP | \
NXCObjectCreationData.CF_DISABLE_NXCP | \
NXCObjectCreationData.CF_DISABLE_SNMP
for i in xrange(0, 5):
name = "Node %d" % (i + 1, )
cd = NXCObjectCreationData(objects.GenericObject.OBJECT_NODE, name, containerId);
cd.setCreationFlags(flags);
cd.setPrimaryName("0.0.0.0") # Create node without IP address
nodeId = session.createObject(cd)
print '"%s" created, id=%d' % (name, nodeId)
380 Chapter 41. Scripting

CHAPTER
FORTYTWO
APPENDIX
42.1 Cron format
Record has five fields, separated by spaces: minute, hour, day of month, month, and day of week. In DCI Collection
Schedule only, an optional the sixth field can be specified for resolution in seconds (this is a non-standard extension
which is not compatible with a regular cron format).
Allowed values and special characters for each field are:
Field Allowed values Allowed special characters

minute 0 - 59 *,-/
hour 0 - 23 *,-/
day of month 1 - 31 *,-/L
month 1 - 12 *,-/
day of week 0 - 7 (0 and 7 is Sunday) *,-/L
seconds (for DCI collection only, optional) 0 - 59 (0 - unlimited for %) *,-/%
A field may be an asterisk (*), which always stands for “any”.

Commas (,) are used to separate items of a list. For example, using 1,3,4 in the 5th field (day of week) means
Mondays, Wednesdays and Fridays.
Hyphens (-) define ranges. For example, using 6-8 in 4th field (month) means June, July and August.
Slashes (/) can be combined with ranges to specify step values. For example, */5 in the minutes field indicates every
5 minutes. If a step value does not evenly divide it’s range, there will be an inconsistent “short” period at the end of
time-unit.
L stands for “last”. When used in the day-of-week field, it allows to specify constructs such as “the last Friday” (“5L”)
of a given month. In the day-of-month field, it specifies the last day of the month.
The sixth field (but not others) supports additional stepping syntax with a percent sign (%), which means that the
step in seconds calculated in absolute seconds since the Unix epoch (00:00:00 UTC, 1st of January, 1970). It’s not
recommended to use seconds in custom schedules as your main data collection strategy though. Use seconds only if it
is absolutely necessary.
381
Fig. 1: DCI configuration custom schedule property page
42.1.1 Examples
Run five minutes after midnight, every day:

5 0 * * *
Run at 14:15 on the first day of every month:
15 14 1 * *
Run every 5 minutes:
*/5 * * * *
Run every minute on 10th second:
* * * * * 10
Run twice a minute (on seconds 0 and 45):
* * * * * */45
Run every 45 seconds from Monday till Friday:
* * * * 1-5 *%45
382 Chapter 42. Appendix

42.2 SMS Drivers
Deprecated since version 3.0.

SMS driver functionality replaces by notification channel functionality. More can be found in Notification channels
section.
42.3 Agent configuration file (nxagentd.conf)
Parameter Description Default Value

Action Define action, which can be later executed by No defaults
management server. Parameters to the action can
be provided from the server. They can be ac-
cessed as $1, $2. . . variables. On Windows
platform system process execution API’s Cre-
ateProcess() is used to run the command, it will
search in PATH, but the command should be
with file extension, e.g. command.exe.
ActionShellExec Same as Action, but on Windows platform agent No defaults
will use shell to execute command instead of
normal process creation. There is no difference
between Action and ActionShellExec on UNIX
platforms. Parameters to the action can be pro-
vided from the server. They can be accessed as
$1, $2. . . variables.
AppAgent The registered name of application with built No defaults
in subagent library that can be as subagent by
agent.
AutoStartUserAgent Enable (yes) or disable (no) automatic start of no
User Support Application (Windows only). If
enabled, Agent will check on it’s start, if User
Support Application is running in each user ses-
sion and will start it if needed. For this to work,
Agent should be started under local SYSTEM
user.
BackgroundLogWriter Enable (yes) or disable (no) log writer as sepa- no
rate background thread. Has no effect if logging
is done through syslog or Windows Event Log.
CodePage Code page used by NetXMS agent. Has no effect Depends on your system, usu-
on Windows or if agent was compiled without ally ISO8859-1
iconv support.
ConfigIncludeDir Folder containing additional configuration files. See Additional configuration
This parameter can only be specified in mas- files for information on default
ter configuration file and will be ignored if value.
found in additional configuration files or con-
figuration policy.
42.2. SMS Drivers 383


ControlServers A list of management servers, which can exe- Empty list
cute actions on agent and change agent’s config.
Hosts listed in this parameter also have read ac-
cess to the agent. Both IP addresses and DNS
names can be used. Multiple servers can be spec-
ified in one line, separated by commas. If this
parameter is used more than once, servers listed
in all occurrences will have access to agent.
CreateCrashDumps Enable (yes) or disable (no) creation of agent’s no
crash dumps. Windows only
DataDirectory Directory where additional agent files (log file UNIX-like systems: If
monitoring policy files, agent configuration pol- $NETXMS_HOME envi-
icy files, user agent configuration, local agent ronment variable is set:
database, etc) will be stored. This parameter $NETXMS_HOME/var/lib/
can only be specified in master configuration netxms, otherwise /var/
file and will be ignored if found in additional lib/netxms. Windows:
configuration files or configuration policy. 'AppData'\nxagentd
where ‘AppData’ is AppData
folder for the user account
under which NetXMS agent
is started. If agent runs
under local SYSTEM user
account, data directory is
C:\Windows\System32\
config\systemprofile\
AppData\Local\
nxagentd.
DailyLogFileSuffix Log file name suffix used when %Y%m%d
LogRotationMode is set to 1 (daily),
can contain strftime(3C) macros
DebugLevel Set agent debug logging level (0 - 9). Value of 0
0 turns off debugging, 9 enables very detailed
logging. Can also be set with command line “-
D<level>” option.
DebugTags Set agent debug logging level (0 - 9) for exact log
tag or log tag mask. Value of 0 turns off debug-
ging, 9 enables very detailed logging. Configu-
ration should look like debugTag:logLevel
(like db.conn:6). To configure multiple log
tags, you should use multiple DebugTags param-
eters or write them coma separated (like proc.
spexec:8,tunnel.*:4,db.conn:6).
DisabeIPv4 Disables (yes) or enables(no) IPv4 support. no
DisabeIPv6 Disables (yes) or enables(no) IPv6 support. no
DumpDirectory Directory for storing crash dumps (Windows C:\
only).
EnableActions Enable (yes) or disable (no) action execution by yes
agent.


Not yet implemented. Enables server to run
EnableArbitraryCommandExecution no
any shell command on the agent without speci-
fying it as action in agent’s config file. Enabling
this adds System.Execute action (and also Sys-
tem.ExecuteInAllSessions on Windows).
EnabledCiphers Controls what ciphers agent can use for connec- 63
tion encryption. A value for this parameter is a
cipher code. To enable more than one cipher, the
codes should be summed up.
Possible cipher codes:
• 1 - “AES-256”
• 2 - “BLOWFISH-256”
• 4 - “IDEA”
• 8 - “3DES”
• 16 - “AES-128”
• 32 - “BLOWFISH-128”
Example (enable AES-256 and IDEA):
EnabledCiphers = 5
EnableControlConnector Enables named pipe used by the agent to re- yes
ceive shutdown and delayed restart commands.
A command is sent by another instance of agent,
launched with -k or -K parameter. Used on Win-
dows during upgrade process.
EnableProxy Enable (yes) or disable (no) agent proxy func- no
tionality.
EnablePushConnector Enables named pipe / unix socket used by the yes
agent to receive data sent by nxapush command
line tool.
EnableSNMPProxy Enable (yes) or disable (no) SNMP proxy func- no
tionality.
EnableSNMPTrapProxy Enable (yes) or disable (no) SNMP Trap proxy no
functionality.
EnableSSLTrace Enable (yes) or disable (no) additional debug no
messages from SSL library.
EnableSubagentAutoload Enable (yes) or disable (no) automatic loading of yes
subagent(s) depending on the platform on which
the agent is running.
EnableSyslogProxy Enable (yes) or disable (no) Syslog proxy func- no
tionality.
EnableTCPProxy Enable TCP proxy functionality that allows to no
forward TCP connections inside the connection
between NetXMS server and agent. An example
utility called TcpProxyApp that forwards local
ports is provided.
EnableWatchdog Enable (yes) or disable (no) automatic agent no
restart in case of unexpected shutdown.
EnableWebServiceProxy Enable (yes) or disable (no) web service data no
collection proxy functionality.
ExecTimeout Timeout in milliseconds for external metric exe- 2000
cution.
42.3. Agent configuration file (nxagentd.conf) 385


ExternalList Add list handled by external command. To No defaults
add multiple parameters, you should use multi-
ple``ExternalList`` entries.
ExternalMasterAgent ID that is checked when external subagent con- No defaults
nects to master agent. Should have same value
as ExternalSubagent parameter in external
subagent configuration file.
ExternalParameter Adds metric handled by external command. To No defaults
add multiple parameters, you should use multi-
ple ExternalParameter entries. On Win-
dows platform system process execution API’s
CreateProcess() is used to run the command, it
will search in PATH, but the command should
be with file extension, e.g. command.exe.
ExternalParameterShellExec ExternalParameterShellExec has same meaning No defaults
as ExternalParameter with exception that agent
will use shell to execute specified command in-
stead of system process execution API. This dif-
ference presented only on Windows system, on
other systems ExternalParameter and External-
ParameterShellExec behaves identically.
ExternalParametersProvider Adds list of metrics that are cached by the agent No defaults
and returned to server per request. Metrics
should be returned in metric=value format each
pair in new line.
ExternalParameterProviderTimeout
Timeout in seconds for external parameters 30
provider execution
ExternalSubagent ID of external subagent. Should be same No defaults
as ExternalMasterAgent in master agent
configuration file.
ExternalTable Adds table metric handled by external com- No defaults
mand. To add multiple parameters, you should
use multiple ExternalTable entries. See
Agent External Metrics for more information.
FileStore Directory to be used for storing files uploaded by /tmp on UNIX C:\ on Win-
management server(s). It’s value is set to envi- dows
ronment variable NETXMS_FILE_STORE that
is available to all processed launched by agent.
FullCrashDumps Enable (yes) or disable (no) full crash dump gen- no
eration. Windows only
GroupId GroupId under which NetXMS agent is started No defaults
(Unix only). See also UserId parameter.
ListenAddress IP address that the agent should listen on. If 0.0.0.0
0.0.0.0 or * is specified as listen address, agent
will listen on all available IP addresses.
ListenPort TCP port to be used for incoming requests. 4700
LogFile Agent’s log file. To write log to syslog (or Event /var/log/nxagentd on
Log on Windows), use {syslog} as file name. UNIX syslog on Windows
LogHistorySize Defines how many old log files should be kept 4
after log rotation.


LogRotationMode Define log rotation mode. Possible values are: 2
• 0 - No rotation;
• 1 - Daily rotation (log will be rotated every
midnight);
• 2 - Rotation by size (log will be rotated
when it’s size will exceed value defined by
MaxLogSize parameter).
LogUnresolvedSymbols If set to yes, all dynamically resolved symbols, no

which failed to be resolved, will be logged.
LongRunningQueryThreshold Expressed in milliseconds. If a query to agent’s 250
local database or DBQuery subagent query takes
longer then this time, the query will be logged to
agent log file.
MasterServers List of management servers, which have full ac- Empty list
cess to agent. Hosts listed in this group can up-
load files to agent and initiate agent upgrade,
as well as perform any task allowed for hosts
listed in Servers and ControlServers. Both IP
addresses and DNS names can be used. Multi-
ple servers can be specified in one line, separated
by commas. If this parameter is used more than
once, servers listed in all occurrences will have
access to agent.
MaxLogSize Maximum log size, in bytes. When log file 16M
reaches this limit, log rotation occurs. Use 0 to
disable log rotation. This parameter supports (K,
M, G, T suffixes).
MaxSessions Maximum number of simultaneous communica- 32
tion sessions. Possible value can range from 2 to
1024.
OfflineDataExpirationTime Applicable only if Agent Cache Mode is on. De- 10
fines the duration (in days) for how collected
data will be stored in agent’s database if there
is no connection to NetXMS server.
PlatformSuffix String to be added as suffix to the value of Empty string
System.PlatformName parameter.
RequireAuthentication If set to yes, a host connected to an agent has to no
provide correct shared secret before issuing any
command.
RequireEncryption If set to yes, a host connected to an agent will be no
forced to use encryption, and if encryption is not
supported by a remote host, the connection will
be dropped. If an agent was compiled without
encryption support, this parameter has no effect.
ServerConnection IP address or host name of NetXMS server for No defaults
tunnel agent connection. Several such parame-
ters can be present, in this case agent will estab-
lish tunnel connection to more then one server.
42.3. Agent configuration file (nxagentd.conf) 387


Servers A list of management servers, which have read Empty list
access to this agent. Both IP addresses and DNS
names can be used. Multiple servers can be spec-
ified in one line, separated by commas. If this
parameter is used more than once, servers listed
in all occurrences will have access to agent.
SessionIdleTimeout Communication session idle timeout in seconds. 60
If an agent will not receive any command from
peer within the specified timeout, session will be
closed.
SharedSecret Agent’s shared secret used for remote peer au- admin
thentication. If RequireAuthentication
set to no, this parameter has no effect.
EncryptedSharedSecret Agent’s shared secret used for remote peer au-
thentication, encrypted using “nxencpasswd -a”.
If RequireAuthentication set to no, this
parameter has no effect.
SNMPProxyThreadPoolSize SNMP proxy thread pool size 128
SNMPTimeout Timeout in milliseconds for SNMP requests sent 3000
by agent
SNMPTrapListenAddress Interface address which should be used by server *
to listen for incoming SNMP trap connections.
Use value 0.0.0.0 or * to use all available inter-
faces.
SNMPTrapPort Port that will be used to listen SNMP traps 162
StartupDelay Number of seconds that agent should wait on 0
startup before start servicing requests. This pa-
rameter can be used to prevent false reports
about missing processes or failed services just
after monitored system startup.
SubAgent Subagent to load. To load multiple subagents, No defaults
you should use multiple SubAgent parameters.
Subagents will be loaded in the same order as
they appear in configuration file.
SyslogListenPort Listening port number for syslog proxy func- 514
tionality.
SystemName If tunnel agent connection is used, the system ap- localhost is used by default
pears in Agent Tunnel Manager under that name.
TunnelKeepaliveInterval Interval (in seconds) between keepalive packets 30
over tunnel agent connection.
UserAgentExecutable Name of User Support Application executable nxuseragent.exe
used by AutoStartUserAgent and UserAgent-
Watchdog parameters.
UserAgentWatchdog Enable (yes) or disable (no) automatic restart of no
User Support Application (Windows only). If
enabled, Agent will check once per minute, if
User Support Application is running in each user
session and will start it if needed. For this to
work, Agent should be started under local SYS-
TEM user.


UserId Username under which NetXMS agent is started No defaults
(Unix only). See also GroupId parameter.
WaitForProcess If specified, an agent will pause initialization un- No defaults
til given process starts.
WriteLogAsJson Enable (yes) or disable (no) writing log file in no
JSON format.
ZoneUIN Allows to set agent’s zone explicitly. This can No defaults
be useful when agent forwards syslog or SNMP
traps of devices, that belong to a particular zone.
Agent will include zone UIN along with the
trap message that will allow correct matching of
traps.
Note: All boolean parameters understand “Yes/No”, “On/Off” and “True/False” values.
42.4 Server configuration file (netxmsd.conf)

CodePage Code page used by NetXMS server. Has no effect Depends on your system, usu-
on Windows or if server was compiled without iconv ally ISO8859-1
support.
CreateCrashDumps Control creation of server’s crash dumps. Possible No
values: yes or no. Has effect only on Windows plat-
forms.
DailyLogFileSuffix Log file name suffix used when %Y%m%d
LogRotationMode is set to 1 (daily), can
contain strftime(3C) macros
DataDirectory Directory where server looks for compiled MIB On UNIX-like platforms:
files, keep server encryption key, etc. 'prefix'/var/lib/
netxms. ‘prefix’ is set
during build configuration
with --prefix='prefix'
parameter. If that parameter
was not specified during build,
/usr/local is used. If
installed from .deb packages:
/var/lib/netxms. On
Windows: 'Installation
folder'\netxms\var
where ‘Installation folder’ is
the folder to which NetXMS
server is installed.
DBDriver Database driver to be used. No default value
DBEncryptedPassword Hashed password, as produced by “nxencpass” none
DBDrvParams Additional driver-specific parameters. Empty string
DBLogin Database user name. netxms
42.4. Server configuration file (netxmsd.conf) 389


DBName Database name (not used by ODBC driver). netxms_db
DBPassword Database user’s password. When using INI configu- Empty password
ration file remember to enclose password in double
qoutes (“password”) if it contains # character.
DBSchema Schema name not set
DBSessionSetupSQLScriptPath to a plain text file containing a list of SQL Empty string
commands which will be executed on every new
database connection, including initial connection on
server startup.
DBServer Database server (ODBC source name for ODBC localhost
driver).
DebugLevel Set server debug logging level (0 - 9). Value of 0 0
turns off debugging, 9 enables very detailed logging.
Can also be set with command line -D <level>
option.
DebugTags Set server debug logging level (0 - 9) for exact log
tag or log tag mask. Value of 0 turns off debug-
ging, 9 enables very detailed logging. Configura-
tion should look like debugTag:logLevel (like
agent.tunnel.*:4). To configure multiple log
tags, you should use multiple DebugTags parameters
or write them coma separated (like crypto.*:8,
agent.tunnel.*:4).
DumpDirectory Directory for storing crash dumps. “/” or “C:”
FullCrashDumps Write full crash dump instead of minidump (Win- no
dows only)
LibraryDirectory Defines location of library folder where drivers(ndd
files) are stored. It’s highly recommended not to use
this parameter.
ListenAddress Interface address which should be used by server to 0.0.0.0
listen for incoming connections. Use value 0.0.0.0
or * to use all available interfaces.
LogFile Server’s log file. To write log to syslog (or Event {syslog}
Log on Windows), use {syslog} as file name.
LogHistorySize Number rotated files to keep, older will be discarded 4
LogRotationMode Define log rotation mode. Possible values are: 2
• 0 - No rotation;
• 1 - Daily rotation (log will be rotated every
midnight);
• 2 - Rotation by size (log will be rotated when
it’s size will exceed value defined by MaxLog-
Size parameter).
MaxLogSize Maximum log file size in bytes, used only if 16777216

LogRotationMode is set to 2
Module Additional server module to be loaded at server No default value
startup. To load multiple modules, add additional
Module parameters.
PerfDataStorageDriver


ProcessAffinityMask Sets a processor affinity mask for the netxmsd pro- 0xFFFFFFFF
cess (Windows only). A process affinity mask is a bit
vector in which each bit represents a logical proces-
sor on which the threads of the process are allowed
to run. See this MSDN article for more details.
StartupSQLScript Path to a plain text file containing a list of SQL com- Empty string
mands which will be executed on server startup.
Note: All boolean parameters accept “Yes/No”, “On/Off” and “True/False” values.
42.5 Server configuration parameters
These parameters can be changed in Configuration → Server Configuration
Parameter Description Default Require

Value Restart
Agent.RestartWaitTime Period of time (in seconds) after agent restart for 0 No
which server will not perform status, congira-
tion, and other polls on the agent.
AgentCommandTimeout Timeout in milliseconds for commands sent to 2000 Yes
agent. If agent did not respond to command
within this time, command considered as failed.
AgentTunnels.ListenPort TCP port number to listen on for incoming agent 4703 Yes
tunnel connections
AgentTunnels.NewNodesContainer Name of the container where nodes that were No
created automatically for unbound tunnels will
be placed. If several containers with that name
are present, it is not guaranteed, which container
will be selected. If empty, such nodes will be
created in infrastructure services root.
AgentTunnels.UnboundTunnelTimeout Unbound agent tunnels inactivity timeout. If 3600 No
tunnel has not been bound or closed af-
ter that timeout, action defined by Agent-
Tunnels.UnboundTunnelTimeoutAction param-
eter will be taken.
AgentTunnels.UnboundTunnelTimeoutAction
Action to be taken when unbound agent tunnel Reset No
timeout expires. Tunnel
AgentUpgradeWaitTime Maximum wait time in seconds for agent restart 600 No
after upgrade. If agent cannot be contacted after
this time period, upgrade process is considered
as failed.
AlarmHistoryRetentionTime Number of days the server keeps alarm history 180 No
in the database.
Alarms.IgnoreHelpdeskState If set, alarm helpdesk state will be ignored when 0 No
resolving or terminating.
42.5. Server configuration parameters 391


Value Restart
Alarms.ResolveExpirationTime Expiration time (in seconds) for resolved 0 No
alarms. If set to non-zero, resolved and un-
touched alarms will be terminated automatically
after given timeout.
AlarmSummaryEmailRecipients A semicolon separated list of e-mail addresses No
to which the alarm summary will be sent.
AlarmSummarySchedule Schedule for sending alarm summary e-mails in 00*** No
cron format. See Cron format for supported cron
format options.
AllowedCiphers A bitmask for encryption algorithms allowed in 63 Yes
the server (sum of the values to allow multiple
algorithms at once):
• 1 - AES256
• 2 - Blowfish-256
• 4 - IDEA
• 8 - 3DES
• 16 - AES128
• 32 - Blowfish-128
ApplyDCIFromTemplateToDisabledDCI Set to 1 to apply all DCIs from a template to the 1 Yes

node, including disabled ones.
AuditLogRetentionTime Retention time in days for the records in au- 90 No
dit log. All records older than specified will be
deleted by housekeeping process.
Beacon.Hosts Comma-separated list of hosts to be used as bea- Yes
cons for checking NetXMS server network con-
nectivity. Either DNS names or IP addresses can
be used. This list is pinged by NetXMS server
and if none of the hosts have responded, server
considers that connection with network is lost
and generates specific event.
Beacon.PollingInterval Interval in milliseconds between beacon hosts 1000 Yes
polls.
Beacon.Timeout Timeout in milliseconds to consider beacon host 1000 Yes
unreachable.
BlockInactiveUserAccounts Inactivity time after which user account will be 0 No
blocked (0 to disable blocking).
CAS.AllowedProxies Comma-separated list of allowed CAS (Central No
Authentication Service) proxies.
CAS.Host CAS server DNS name or IP address. localhost No
CAS.Port CAS server TCP port number. 8443 No
CAS.Service Service to validate (usually NetXMS web UI https: No
URL). //127.0.0.
1/nxmc
CAS.TrustedCACert File system path to CAS server trusted CA cer- No
tificate.
CAS.ValidateURL URL for service validation on CAS server. /cas/serviceValidate
No
CaseInsensitiveLoginNames Enable/disable case insensitive login names. 0 Yes


Value Restart
CheckTrustedNodes Enable/disable checking of trusted nodes list for1 No
cross-node data collection (using Proxy Node
DCI attribute).
Client.AlarmList.DisplayLimit Maximum alarm count that will be displayed on 4096 No
Alarm Browser page. Alarms that exceed this
count will not be shown.
Client.MinViewRefreshInterval Minimal interval between view refresh in mil- 300 No
liseconds (hint for client).
Client.ObjectBrowser.AutoApplyFilter Enable/disable object browser”s filter applying 1 No
as user types (if disabled, user has to press EN-
TER to apply filter).
Client.ObjectBrowser.FilterDelay Delay (in milliseconds) between typing in object 300 No
browser”s filter and applying it to object tree.
Client.ObjectBrowser.MinFilterStringLength
Minimal length of filter string in object browser 1 No
required for automatic apply.
ClientListenerPort The server port for incoming client connections 4701 Yes
(such as management console).
ClusterContainerAutoBind Enable/disable container auto binding for clus- 0 No
ters.
ClusterTemplateAutoApply Enable/disable template auto apply for clusters. 0 No
ConditionPollingInterval Interval in seconds between polling (re- 60 Yes
evaluating) of condition objects.
ConfigurationPollingInterval Interval in seconds between node configuration 3600 Yes
polls.
DashboardDataExportEnableInterpolationEnable/disable data interpolation in dashboard 1 Yes
data export.
DataCollection.OnDCIDelete.TerminateRelatedAlarms
Enable/disable automatic termination of related 1 No
alarms when data collection item is deleted.
DataCollection.ScriptErrorReportIntervalMinimal interval (seconds) between reporting 86400 No
errors in data collection related script.
DataCollection.StartupDelay Enable/disable randomized data collection de- 0 Yes
lays on server startup for more even server load
distribution.
DBConnectionPoolBaseSize Number of connections to the database created 10 Yes
on the server startup.
DBConnectionPoolCooldownTime Inactivity time (in seconds) after which database 300 Yes
connection will be closed.
DBConnectionPoolMaxLifetime Maximum lifetime (in seconds) for a database 14400 Yes
connection.
DBConnectionPoolMaxSize Maximum number of connections in the connec- 30 Yes
tion pool.
DBWriter.DataQueues Number of queues for DCI data writer. 1 Yes
DBWriter.HouseKeeperInterlock Controls if server should block background Auto No
write of collected performance data while
housekeeper deletes expired records. Auto en-
ables this feature is server is running on MsSQL
database.


Value Restart
DBWriter.MaxQueueSize Maximum size for DCI data writer queue (0 0 No
to disable size limit). If writer queue size
grows above that threshold any new data will be
dropped until queue size drops below threshold
again.
DBWriter.MaxRecordsPerStatement Maximum number of records per one SQL state- 100 Yes
ment for delayed database writes
DBWriter.MaxRecordsPerTransaction Maximum number of records per one transac- 1000 Yes
tion for delayed database writes
DefaultAgentCacheMode Default agent cache mode Off Yes
DefaultAgentProtocolCompressionMode Default agent protocol compression mode Enabled No
DefaultConsoleDateFormat Default format to display date in console GUI. dd.MM.yyyy No
DefaultConsoleShortTimeFormat Default format to display time in a short way in HH:mm No
console GUI.
DefaultConsoleTimeFormat Default format to display time in a long way in HH:mm:ss No
console GUI.
DefaultDCIPollingInterval Default polling interval for newly created DCI 60 No
(in seconds).
DefaultDciRetentionTime Default retention time for newly created DCI (in 30 No
days).
DefaultEncryptionPolicy Set the default encryption policy for communi- Allowed Yes
cations with agents: 0 - encryption disabled, 1 -
allowed, 2 - preferred, 3 - required.
DefaultMapBackgroundColor Default background color for new network map 0xffffff No
objects (as RGB value).
DefaultMapBackgroundColor Default background color for new network map 0xffffff No
objects (as RGB value).
DefaultNotificationChannel.SMTP.Html Default notification channel for SMTP HTML SMTP- Yes
formatted messages. HTML
DefaultNotificationChannel.SMTP.Text Default notification channel for SMTP text for- SMTP- Yes
matted messages. Text
DefaultSubnetMaskIPv6 Default mask for synthetic IPv6 subnets. 64 No
DeleteAlarmsOfDeletedObject Enable/disable automatic alarm removal of an 1 No
object when it is deleted.
DeleteEmptySubnets Enable/disable automatic deletion of subnet ob- 0 Yes
jects that have no nodes within. When enabled,
empty subnets will be deleted by housekeeping
process.
DeleteEventsOfDeletedObject Enable/disable automatic event removal of an 1 No
object when it is deleted.
DeleteUnreachableNodesPeriod Delete nodes which were unreachable for a 0 Yes
number of days specified by this parameter. If
this parameter is set to 0 then unreachable nodes
will never be deleted.
DiscoveryFilter Name of discovery filter script from script li- none No
brary. This setting is changed by Network Dis-
covery Configuration GUI


Value Restart
DiscoveryFilterFlags Discovery filter settings. This setting is 0 No
changed by Network Discovery Configura-
tion GUI
EnableAgentRegistration Enable/disable agents self-registration. 1 No
EnableAlarmSummaryEmails Enable/disable alarm summary emails. Sum- 0 No
mary emails will be sent via notification
channel specified in DefaultNotificationChan-
nel.SMTP.Html server configuration parameter.
EnableAuditLog Enable/disable audit log. 1 Yes
EnableISCListener Enable/disable Inter-Server Communications 0 Yes
Listener.
EnableReportingServer Enable/disable reporting server 0 Yes
EnableTimedAlarmAck Enable/disable ability to acknowledge an alarm 1 Yes
for a specific time.
EnableXMPPConnector This parameter displays if XMPP connector 0 Yes
should be enabled on a server start. It is required
to enable XMPP message sending.
EnableZoning Enable/disable zoning support. 0 Yes
EscapeLocalCommands Enable/disable TAB and new line characters re- 0 No
placement by t n r in execute command on man-
agement server action.
EventLogRetentionTime Retention time in days for the records in event 90 No
log. All records older than specified will be
Events.Correlation.TopologyBased Enable/disable topology based event correlation. 1 Yes
Events.Processor.PoolSize Number of threads for parallel event processing. 1 Yes
Events.Processor.QueueSelector Queue selector for parallel event processing. In Yes %z
parallel processing server ensures that events
having same queue selector will be processed in
one queue.
EventStorm.Duration Time period for events per second to be above 15 Yes
threshold that defines event storm condition.
EventStorm.EnableDetection Enable/disable event storm detection. 0 Yes
EventStorm.EventsPerSecond Threshold for number of events per second that 1000 Yes
defines event storm condition.
ExtendedLogQueryAccessControl Enable/disable extended access control in log 0 No
queries. When enabled, server will check user’s
access to objects and only select those log
records where user has read access to related ob-
ject. Please note that enabling this option can
cause slow and inefficient SQL queries depend-
ing on number of objects and actual access right
assignment.
ExternalAuditFacility Syslog facility to be used in audit log records 13 Yes
sent to external server.
ExternalAuditPort UDP port of external syslog server to send audit 514 Yes
records to.


Value Restart
ExternalAuditServer External syslog server to send audit records to. none Yes
If set to ‘’none”, external audit logging is dis-
abled.
ExternalAuditSeverity Syslog severity to be used in audit log records 5 Yes
sent to external server.
ExternalAuditTag Syslog tag to be used in audit log records sent to netxmsd- Yes
external server. audit
FixedStatusValue Value for status propagation if ‘’StatusPropaga- 0 Yes
tionAlgorithm” server configuration parameter
is set to ‘’2 - Fixed”.
GraceLoginCount Number of times a user can login if password 5 No
has been expired.
HelpDeskLink Helpdesk driver name. If ‘’none”, then no none Yes
helpdesk driver is in use.
Housekeeper.DisableCollectedDataCleanup
Disable automatic cleanup of collected DCI data 0 No
during housekeeper run.
Housekeeper.StartTime Time when housekeeper starts. Housekeeper 02:00 Yes
deletes expired log recored and DCI data as well
as cleans removed objects.
Housekeeper.Throttle.HighWatermark If database writer queue length (in queue ele- 250000 No
ments) exceeds this number, housekeeper pro-
cess is paused.
Housekeeper.Throttle.LowWatermark If housekeeper got paused due to 50000 No
DB writer queue reaching House-
keeper.Throttle.HighWatermark, it will resume
operation when DB writer queue becomes lower
then this setting.
ICMP.CollectPollStatistics Collect ICMP poll statistics for all nodes by de- 1 No
fault. See ICMP ping chapter for information.
ICMP.PingSize Size of ICMP packets (in bytes, excluding IP 46 Yes
header size) used for status polls.
ICMP.PingTimeout Timeout for ICMP ping used for status polls (in 1500 Yes
milliseconds).
ICMP.PollingInterval Interval between ICMP statistic collection polls 60 No
(in seconds)
ICMP.StatisticPeriod Time period for collecting ICMP statistics (in 60 No
number of polls).
ImportConfigurationOnStartup Import configuration (templates, events, object Only Yes
tools, etc) on server startup. Configuration is missing
imported from files located on NetXMS server elements
in share/templates. Missing elements are identi-
fied by GUID.
InstancePollingInterval Instance polling interval (in seconds). 600 Yes
InstanceRetentionTime Default retention time (in days) for missing DCI 0 Yes
instances.
InternalCA Enable/disable internal certificate authority. 0 Yes
IntruderLockoutThreshold Number of incorrect password attempts after 0 No
which a user account is temporarily locked.


Value Restart
IntruderLockoutTime Duration of user account temporarily lockout (in 30 No
minutes) if allowed number of incorrect pass-
word attempts was exceeded.
JiraIssueType Jira issue type Task No
JiraLogin Jira login netxms Yes
JiraPassword Jira password Yes
JiraProjectCode Jira project code NETXMS No
JiraProjectComponent Jira project component No
JiraServerURL The URL of Jira server http: Yes
//localhost
KeepAliveInterval Interval in seconds between sending keep alive 60 Yes
packets to connected clients.
LDAP.ConnectionString The LdapConnectionString configuration pa- ldap:// No
rameter may be a comma- or whitespace- localhost:
separated list of URIs containing only the 389
schema, the host, and the port fields. Apart from
ldap, other (non-standard) recognized values of
the schema field are ldaps (LDAP over TLS),
ldapi (LDAP over IPC), and cldap (connection-
less LDAP). If other fields are present, the be-
havior is undefined. Format: schema://host:port.
For more information refer to Integration with
LDAP chapter.
LDAP.GroupClass Specifies which object class represents group No
objects. If found entry will not be of a user or
group class, it will be ignored.
LDAP.GroupMappingName The name of an attribute whose value will be No
used as group’s login name
LDAP.GroupUniqueId Unique identifier for LDAP group object. If not No
set, LDAP users are identified by DN.
LDAP.MappingDescription The name of an attribute whose value will be No
used as a user’s description.
LDAP.MappingFullName The name of an attribute whose value will be displayName No
used as a user’s full name.
LDAP.PageSize The maximum amount of records that can be re- 1000 No
turned in one search page.
LDAP.SearchBase The DN of the entry at which to start the search. No
LDAP.SearchFilter A string representation of the filter to apply in No
the search.
LDAP.SyncInterval The synchronization interval (in minutes) be- 0 No
tween the NetXMS server and the LDAP server.
If the parameter is set to 0, no synchronization
will take place.
LDAP.SyncUser User login for LDAP synchronization No
LDAP.SyncUserPassword User password for LDAP synchronization No
LDAP.UserClass The object class which represents user objects. No
If the found entry is not of user or group class, it
will be ignored.


Value Restart
LDAP.UserDeleteAction This parameter specifies what should be done 1 No
while synchronization with deleted from LDAP
user/group. 0 - if user should be just deleted
from NetXMS DB. 1 - if it should be disabled.
If it is chosen to disable user, then on LDAP
sync user will be disabled and it’s description
will be change on “LDAP entry was deleted.”
Afterwards this user/group can be detached from
LDAP and enabled if it is required or just deleted
manually.
LDAP.UserMappingName The name of an attribute whose value will be No
used as a user’s login name.
LDAP.UserUniqueId Unique identifier for LDAP user object. If not No
set, LDAP users are identified by DN.
LongRunningQueryThreshold Threshold in milliseconds to report long running 0 Yes
SQL queries (0 to disable). Queries are logged
to NetXMS server log file on debug level 3.
MailEncoding Encoding for mails generated by NetXMS utf8 No
server.
MessageOfTheDay Message to be shown when a user logs into the No
console.
MinPasswordLength Default minimum password length for a 0 No
NetXMS user. The default applied only if per-
user setting is not defined.
MobileDeviceListenerPort Listener port for connections from NetXMS mo- 4747 Yes
bile agent.
NetworkDeviceDrivers.BlackList Comma separated list of blacklisted network de- Yes
vice drivers.
NetworkDiscovery.ActiveDiscovery.BlockSize
Size of address block to which ICMP ping re- 1024 No
quests are sent simultaneously during active dis-
covery.
NetworkDiscovery.ActiveDiscovery.InterBlockDelay
Pause in milliseconds between scanning of 0 No
blocks during active discovery. Together with
BlockSize this allows to slow down active dis-
covery if network equipment treats large number
of ICMP requests as flood.
NetworkDiscovery.ActiveDiscovery.Interval
Interval in seconds between active network dis- 7200 No
covery polls. This setting is changed by Net-
work Discovery Configuration GUI
NetworkDiscovery.ActiveDiscovery.Schedule
Active network discovery poll schedule in cron No
format. This setting is changed by Network
Discovery Configuration GUI
NetworkDiscovery.EnableParallelProcessing
Enable/disable parallel processing of discovered 0 No
addresses.
NetworkDiscovery.MergeDuplicateNodesEnable/disable merging of duplicate nodes (that 0 No
may be created due to parallel processing of dis-
covered addresses).


Value Restart
NetworkDiscovery.PassiveDiscovery.Interval
Interval in seconds between passive network dis-
900 No
covery polls. This setting is changed by Net-
work Discovery Configuration GUI
NetworkDiscovery.Type Defines enabled modes of network discovery. Disabled No
This setting is changed by Network Discovery
Configuration GUI
NumberOfUpgradeThreads The number of threads used to perform agent 10 No
upgrades (i.e. maximum number of parallel up-
grades).
NXSL.EnableContainerFunctions
NXSL.EnableFileIOFunctions Enable/disable server-side NXSL functions for 0 No
file I/O (such as OpenFile, DeleteFile, etc.).
Objects.Interfaces.DefaultExpectedState Default expected state for new interface objects. 1 Yes
Objects.Interfaces.NamePattern Custom name pattern for interface objects. No
This field supports macros. E.g. if set to
%n%{suffix}, interface name will be com-
posed from original name and node’s custom at-
tribute suffix.
Objects.Interfaces.UseAliases 0 (Always No
Control usage of interface aliases (or descriptions).
use Possible
name) values are:
• 0 - Always use name (Don’t use

aliases)
• 1 - Use aliases instead of names,
when possible
• 2 - Concatenate alias and name to
form interface object name
• 3 - Concatenate name and alias to
form interface object name
Objects.Interfaces.UseIfXTable Enable/disable the use of SNMP ifXTable in- 1 No

stead of ifTable for interface configuration
polling. See SNMP for more information.
Objects.Nodes.CapabilityExpirationGracePeriod
Grace period (in seconds) for capability expi- 3600 No
ration after node recovered from unreachable
state.
Objects.Nodes.CapabilityExpirationTimeTime (in seconds) before capability (NetXMS 604800 No
Agent, SNMP, EtherNet/IP, etc) expires if node
is not responding for requests via appropriate
protocol.
Objects.Nodes.FallbackToLocalResolver Enable/disable fallback to server”s local re- 0 No
solver if node address cannot be resolved via
zone proxy.
Objects.Nodes.ResolveDNSToIPOnStatusPoll
Enable/disable resolve DNS to IP on status poll. 0 Yes
Objects.Nodes.ResolveNames Resolve node name using DNS, SNMP system 1 No
name, or host name if current node name is it’s
IP address.
Objects.Nodes.SyncNamesWithDNS Enable/disable synchronization of node names 0 No
with DNS on each configuration poll.


Value Restart
OfflineDataRelevanceTime Time period in seconds within which received 86400 Yes
offline data still relevant for threshold validation
PasswordComplexity Set of flags to enforce password complexity (see 0 No
Password Policy for more details).
PasswordExpiration Password expiration time in days. If set to 0, 0 No
password expiration is disabled.
PasswordHistoryLength Number of previous passwords to keep. Users 0 No
are not allowed to set password if it matches one
from previous passwords list.
PollCountForStatusChange The number of consecutive unsuccessful polls 1 Yes
required to declare interface as down.
RADIUSAuthMethod RADIUS authentication method to be used PAP No
(PAP, CHAP, MS-CHAPv1, MS-CHAPv2).
RADIUSNumRetries The number of retries for RADIUS authentica- 5 No
tion.
RADIUSPort Port number used for connection to primary RA- 1645 No
DIUS server.
RADIUSSecondaryPort Port number used for connection to secondary 1645 No
RADIUS server.
RADIUSSecondarySecret Shared secret used for communication with sec- netxms No
ondary RADIUS server.
RADIUSSecondaryServer Host name or IP address of secondary RADIUS none No
server.
RADIUSSecret Shared secret used for communication with pri- netxms No
mary RADIUS server.
RADIUSServer Host name or IP address of primary RADIUS none No
server.
RADIUSTimeout Timeout in seconds for requests to RADIUS 3 No
server
ReceiveForwardedEvents Enable/disable reception of events forwarded by 0 No
another NetXMS server. Please note that for ex-
ternal event reception ISC listener should be en-
abled as well.
ReportingServerHostname The hostname of the reporting server. localhost Yes
ReportingServerPort The port of the reporting server. 4710 Yes
RoamingServer Enable/disable roaming mode for server (when 0 No
server can be disconnected from one network
and connected to another or IP address of the
server can change)
RoutingTableUpdateInterval Interval in seconds between reading routing ta- 300 Yes
ble from node.
Scheduler.TaskRetentionTime Period (in seconds) after which non-recurring 86400 No
scheduled tasks (e.g. Maintenance enter / Main-
tenance leave) are deleted.
ServerColor Identification color for this server. Used in status No
bar of management console.
ServerCommandOutputTimeout Time (in seconds) to wait for output of a local 60 No
command object tool.


Value Restart
ServerName Name of this server. Displayed in status bar of No
management console.
SMTP.FromAddr The address used for sending mail from. netxms@localhost
No
SMTP.FromName The name used as the sender. NetXMS No
Server
SMTP.LocalHostName Local host name used in HELO command. If No
empty then fully qualified name of local system
will be used.
SMTP.Port TCP port for SMTP server. 25 No
SMTP.RetryCount Number of retries for sending mail. 1 No
SMTP.Server An SMTP server used for sending mail. localhost No
SNMP.Traps.AllowVarbindsConversion Allows/disallows conversion of SNMP trap 1 No
OCTET STRING varbinds into hex strings if
they contain non-printable characters.
SNMP.Discovery.SeparateProbeRequestsUse separate SNMP request for each test OID. 0 No
SNMP.RequestTimeout Timeout in milliseconds for SNMP requests sent 1500 Yes
by NetXMS server.
SNMP.Traps.LogAll Log all SNMP traps (even those received from 0 No
addresses not belonging to any known node).
SNMP.TrapLogRetentionTime The time how long SNMP trap logs are retained. 90 No
SNMP.Traps.Enable Enable/disable SNMP trap processing. A dedi- 1 Yes
cated thread will be created if set to 1.
SNMP.Traps.ListenerPort Port used for SNMP traps. 162 Yes
SNMP.Traps.ProcessUnmanagedNodes Enable/disable processing of SNMP traps re- 0 No
ceived from unmanaged nodes.
SNMP.Traps.RateLimit.Duration Time period (in seconds) for SNMP traps per 15 No
second to be above threshold that defines SNMP
trap flood condition.
SNMP.Traps.RateLimit.Threshold Threshold for number of SNMP traps per second 0 No
that defines SNMP trap flood condition. Detec-
tion is disabled if 0 is set.
StatusCalculationAlgorithm Default alghorithm for calculation object status 1 - Most Yes
from it’s DCIs, alarms and child objects. Possi- critical
ble values are:
• 1 - Most critical
• 2 - Single threshold. Threshold value is
defined by StatusSingleThreshold param-
eter.
• 3 - Multiple thresholds. Threshold values
are defined by StatusThresholds parame-
ter.
StatusPollingInterval Interval in seconds between status polls. 60 Yes



Value Restart
StatusPropagationAlgorithm Default algorithm for status propagation (how 1 - Un- Yes
object’s status is affected by it’s child object sta- changed
tuses). Possible values are:
• 1 - Unchanged
• 2 - Fixed. Status value is defined by
FixedStatusValue parameter.
• 3 - Relative with offset. Offset value is
defined by StatusShift parameter.
• 4 - Translated. Status translation is de-
fined by StatusTranslation parameter.
StatusShift Status shift value for Relative propagation algo- 0 Yes

rithm.
StatusSingleThreshold Threshold value (in %) for Single threshold sta- 75 Yes
tus calculation algorithm.
StatusThresholds Threshold values for Multiple thresholds status 503C2814 Yes
calculation algorithm. Every byte (from left to (80%,
right) of this hex number express threshold val- 60%,
ues for warning, minor, major and critical sta- 40%,
tuses. 20%)
StatusTranslation Values for Translated status propagation algo- 01020304 Yes
rithm. Every byte (form left to right) of this hex
number defines status translation for Warning,
Minor, Major and Critical statuses. Status val-
ues are:
• 1 - Warning
• 2 - Minor
• 3 - Major
• 4 - Critical
StrictAlarmStatusFlow This parameter describes if alarm status flow 0 No

should be strict (alarm can be terminated only
after it was resolved).
SyncInterval Interval in seconds between writing object 60 Yes
changes to the database.
Syslog.EnableListener Enable/disable receiving of syslog messages. 0 Yes
Syslog.EnableStorage Enable/disable local storage of received syslog 1 No
messages in NetXMS database.
Syslog.IgnoreMessageTimestamp Ignore timestamp received in syslog messages 0 No
and always use server time.
Syslog.ListenPort UDP port used by built-in syslog server. 514 Yes
Syslog.NodeMatchingPolicy Node matching policy for built-in syslog dae- 0 Yes
mon. Possible values are:
• 0 - syslog message source IP address, then
hostname
• 1 - hostname, then syslog message source
IP address


Value Restart
Syslog.RetentionTime Retention time in days for stored syslog mes- 90 No
sages. All messages older than specified will be
ThreadPool.Agent.BaseSize This parameter represents base thread pool size 4 Yes
for threads that receive data, traps, events, etc
from agents. This is minimal number of threads
that will always run.
ThreadPool.Agent.MaxSize This parameter represents maximum thread pool 4 Yes
size for threads that receive data, traps, events,
etc from agents. In case of high load on existing
threads server will increase number of threads
up to this value. When load come back to nor-
mal, number of threads will be automatically de-
creased to base size.
ThreadPool.DataCollector.BaseSize This parameter represents base thread pool size 10 Yes
for data collector threads. This is minimal num-
ber of threads that will always run.
ThreadPool.DataCollector.MaxSize This parameter represents maximum thread pool 250 Yes
size for data collector threads. In case of high
load on existing threads server will increase
number of threads up to this value. When load
come back to normal, number of threads will be
automatically decreased to base size.
ThreadPool.Discovery.BaseSize This parameter represents base thread pool size 1 Yes
for network discovery threads. This is minimal
number of threads that will always run.
ThreadPool.Discovery.MaxSize This parameter represents maximum thread pool 16 Yes
size for network discovery threads. In case of
high load on existing threads server will increase
number of threads up to this value. When load
come back to normal, number of threads will be
automatically decreased to base size.
ThreadPool.Main.BaseSize This parameter represents base thread pool size 8 Yes
for threads that perform general system tasks.
This is minimal number of threads that will al-
ways run.
ThreadPool.Main.MaxSize This parameter represents maximum thread pool 156 Yes
size for threads that perform general system
tasks. In case of high load on existing threads
server will increase number of threads up to this
value. When load come back to normal, num-
ber of threads will be automatically decreased
to base size.
ThreadPool.Poller.BaseSize This parameter represents base thread pool size 10 Yes
for threads that perform all types of polls: Status
poll, Configuration poll, etc. except DCI collec-
tion. This is minimal number of threads that will
always run.


Value Restart
ThreadPool.Poller.MaxSize This parameter represents maximum thread pool 250 Yes
size for threads that perform all types of polls:
Status poll, Configuration poll, etc. except DCI
collection. In case of high load on existing
threads server will increase number of threads
up to this value. When load come back to nor-
mal, number of threads will be automatically de-
creased to base size.
ThreadPool.Scheduler.BaseSize This parameter represents base thread pool size 1 Yes
for scheduler threads. This is minimal number
of threads that will always run.
ThreadPool.Scheduler.MaxSize This parameter represents maximum thread pool 64 Yes
size for scheduler threads. In case of high load
on existing threads server will increase number
of threads up to this value. When load come
back to normal, number of threads will be au-
tomatically decreased to base size.
ThreadPool.Syncer.BaseSize This parameter represents base thread pool size 1 Yes
for threads that perform object synchronization
to the database. This is minimal number of
threads that will always run.
ThreadPool.Syncer.MaxSize This parameter represents maximum thread pool 1 Yes
size for threads that perform object synchroniza-
tion to the database. In case of high load on
existing threads server will increase number of
threads up to this value. When load come back
to normal, number of threads will be automat-
ically decreased to base size. Value of 1 will
disable pool creation.
ThresholdRepeatInterval System-wide interval in seconds for resending 0 Yes
threshold violation events. Value of 0 disables
event resending.
TileServerURL The base URL for the tile server used to draw http://tile. No
maps. netxms.
org/osm/
Topology.AdHocRequest.ExpirationTimeAd-hoc network topology request expiration 900 No
time. Server will use cached result of previous
request if it is newer than given interval.
Topology.DefaultDiscoveryRadius Default number of hops from seed node to be 5 No
added to topology map.
Topology.PollingInterval Interval in seconds between topology polls. 1800 Yes
TrapSourcesInAllZones Enable/disable search of all zones to match 0 Yes
trap/syslog source address to node.
UseDNSNameForDiscoveredNodes Enable/disable use of DNS name instead of IP 0 No
address as primary name for newly discovered
nodes. If enabled, server will do back resolve of
IP address, and then resolve obtained name back
to IP address. Only if this IP address will match
the original one, DNS name will be used.


Value Restart
UseFQDNForNodeNames Enable/disable use of fully qualified domain 1 Yes
names as primary names for newly discovered
nodes.
UserAgent.DefaultMessageRetentionTimeDefault user agent message retention time (in 10800 No
minutes).
UserAgent.RetentionTime User agent message historical data retention 30 No
time (in days).
UseSNMPTrapsForDiscovery This parameter defines if trap information 1 Yes
should be used for new node discovery.
UseSyslogForDiscovery Enable/disable use of syslog messages for new 0 Yes
node discovery.
WindowsEvents.EnableStorage Enable/disable local storage of received Win- 1 No
dows events in NetXMS database.
WindowsEvents.LogRetentionTime Retention time in days for records in Windows 90 No
event log. All records older than specified will
be deleted by housekeeping process.
XMPPLogin Login name that will be used for authentication netxms@localhost
Yes
on XMPP server.
XMPPPassword Password that will be used for authentication on netxms Yes
XMPP server.
XMPPPort XMPP connection port 5222 Yes
XMPPServer XMPP connection server localhost Yes
42.6 Bundled Subagents
42.7 Command line tools
NetXMS provide some additional command line tools. Each tool serves its own purpose.
42.7.1 DB Manager
This is tool used to make manipulations with NetXMS database.
Usage: nxdbmgr [<options>] <command>
Valid commands are:
42.6. Bundled Subagents 405

batch <file> Run SQL batch file

check Check database for errors
export <file> Export database to file
get <name> Get value of server configuration variable
import <file> Import database from file
init <file> Initialize database
migrate <source> Migrate database from given source
reset-system-account Unlock user “system” and reset it’s password to default (“netxms”). Warning: server
(“netxmsd”) should be stopped while performing password reset operation! See Re-
setting “system” user password for detailed procedure.
set <name> <value> Set value of server configuration variable
unlock Forced database unlock
upgrade Upgrade database to new version
Valid options are:
-c <config> Use alternate configuration file. Default is {search}

-d Check collected data (may take very long time).
-D Migrate only collected data.
-f Force repair - do not ask for confirmation.
-h Display help and exit.
-I MySQL only - specify TYPE=InnoDB for new tables.
-M MySQL only - specify TYPE=MyISAM for new tables.
-N Do not replace existing configuration value (“set” command only).
-q Quiet mode (don’t show startup banner).
-s Skip collected data during migration.
-t Enable trace mode (show executed SQL queries).
-v Display version and exit.
-X Ignore SQL errors when upgrading (USE WITH CAUTION!!!)
Database initialization
nxdbmgr init initialization.file
Is used to initialize first time database. Database and user should already exist. Credentials of connection are taken
from server configuration file.
Database migration
nxdbmgr migrate old.configuration.file
Is used to migrate NetXMS database between different database management system from NetXMS supported list.
While migration nxdbmgr should use new configuration file(with new DB credentials) and as a parameter should be
given the old configuration file.
In best practises of migration is to do database check with command “nxdbmgr check”.

42.7.2 nxaction
42.7.3 nxadm
42.7.4 nxalarm
42.7.5 nxap
42.7.6 nxappget
42.7.7 nxapush
This tool has same usage as nxpush, but it sends data through local agent.
When new version of NetXMS is released - version of server protocol is changed. Change of version affects on server
communication with other tools like nxpush. So after each server update nxpush tool also should be updated. In case
of usage nxapush - only agent should be updated as this tool uses agent protocol to send data.
42.7.8 nxdevcfg
42.7.9 nxencpasswd
This tool can be used to encrypt passwords stored in server and agent configuration files.
42.7.10 nxevent
This tool can be used to push events to NetXMS server.
42.7.11 nxget
This tool is intended to get values of Metric from NetXMS agent.

Syntax:
nxget [options] host [parameter [parameter ...]]
Where host is the name or IP address of the host running NetXMS agent; and parameter is a parameter, list or table
name, depending on given options. By default, nxget will attempt to retrieve the value of only one given parameter,
unless -b option is given.
42.7. Command line tools 407

Valid options for nxget
Option Description
-a auth
Authentication method. Valid methods are “none”, “plain”, “md5” and “sha1”. De-
fault is “none”.
-A auth Authentication method for proxy agent.

-b Batch mode - get all parameters listed on command line.
-C Get agent’s configuration file
-d delimiter Print table content as delimited text.
-D level Set debug level (default is 0).
-e policy Set encryption policy. Possible values are:
0 = Encryption disabled; 1 = Encrypt connection only if agent
requires encryption; 2 = Encrypt connection if agent supports
encryption; 3 = Force encrypted connection;
Default value is 1.
-E file Take screenshot. First parameter is file name, second (optional) is session name.
-h Display help and exit.
-i seconds Get specified parameter(s) continuously with given interval.
-I Get list of supported parameters.
-K file
Specify server’s key file (default is /opt/netxms/var/lib/netxms/.server_key).
-l Requested parameter is a list.

-n Show parameter’s name in result.
-o proto Protocol number to be used for service check.
-O port Proxy agent’s port number. Default is 4700.
-p port Agent’s port number. Default is 4700.
-P port Network service port (to be used with -S option).
-r string Service check request string.
-R string Service check expected response string.
-s secret Shared secret for authentication.
-S addr Check state of network service at given address.
-t type
Set type of service to be checked. Possible types are - custom, ssh, pop3, smtp, ftp,
http, https, telnet.
-T Requested parameter is a table.

-v Display version and exit.
-w seconds Set command timeout (default is 5 seconds).
-W seconds Set connection timeout (default is 30 seconds).
-X addr Use proxy agent at given address.
-Z secret Shared secret for proxy agent authentication.

Examples
Get value of Agent.Version metric from agent at host 10.0.0.2:
nxget 10.0.0.2 Agent.Version
Get list of supported parameters from agent at host 10.0.0.2:
nxget 10.0.0.2 -I
Get list of supported lists from agent at host 10.0.0.2:
nxget 10.0.0.2 Agent.SupportedLists -l
Get list of supported tables from agent at host 10.0.0.2:
nxget 10.0.0.2 Agent.SupportedTables -l
Get value of Agent.Uptime and System.Uptime parameters in one request, with output in parameter = value form:
nxget -bn 10.0.0.2 Agent.Uptime System.Uptime
Get agent configuration file from agent at host 10.0.0.2:
nxget -C 10.0.0.2
Get value of System.PlatformName parameter from agent at host 10.0.0.2, connecting via proxy agent at 172.16.1.1:
nxget -X 172.16.1.1 10.0.0.2 System.PlatformName
Get value of Agent.SupportedParameters enum from agent at host 10.0.0.10, forcing use of encrypted connection:
nxget -e 3 -l 10.0.0.10 Agent.SupportedParameters
Check POP3 service at host 10.0.0.4 via agent at host 172.16.1.1:
nxget -S 10.0.0.4 -t 2 -r user:pass 172.16.1.1
Useful lists for debugging purpose
List name Description

Agent.ActionList List of defined actions
Agent.SubAgentList List of loaded subagents
Agent.SupportedLists List of supported lists
Agent.SupportedParametersList of supported parameters
Agent.SupportedPushParameters
List of supported push parameters
Agent.SupportedTables List of supported table parameters
Agent.ThreadPools List of thread pools
42.7. Command line tools 409

42.7.12 nxmibc
42.7.13 nxpush
nxpush is a tool that allows to push DCI daca from command line.
There are different options how this tool can be used:
• with help of this tool data collected with different monitoring system can be pushed also to netxms
• can be used on nodes where agent can not be installed(not the case for nxapush)
• can be used on nodes behind NAT with no port forwarding option
Usage: ./nxapush [OPTIONS] [@batch_file] [values]
Options:
-h Display this help message.

-o <id> Push data on behalf of object with given id.
-q Suppress all messages.
-v Enable verbose messages. Add twice for debug
-V Display version information.
Notes:
• Values should be given in the following format: dci=value where dci can be specified by it’s name
• Name of batch file cannot contain character = (equality sign)
Examples: Push two values:
nxapush PushParam1=1 PushParam2=4
Push values from file:
nxapush @file
Required server configurations are described there: Push parameters
42.7.14 nxscript
42.7.15 nxsms
42.7.16 nxsnmpget
This tool can be used to get SNMP Metric from node.

42.7.17 nxsnmpset
42.7.18 nxsnmpwalk
42.7.19 nxupload
42.8 List of supported metrics
In this chapter will be described Agent and OS Subagent provided metrics.
42.8.1 Agent.AcceptedConnections
Data type: Unsigned Integer

Supported Platforms: Windows, Linux, Solaris, AIX, HP-UX, FreeBSD, NetBSD, OpenBSD
Cumulative counter of connections accepted by agent
42.8.2 Agent.AcceptErrors

Cumulative counter of agent’s accept() system call errors
42.8.3 Agent.ActiveConnections

Number of active connections to agent
42.8.4 Agent.AuthenticationFailures

Cumulative counter of failed AUTH commands (due to invalid secret)
42.8.5 Agent.ConfigurationServer
Data type: String

Configuration server address set on agent startup.
42.8. List of supported metrics 411

42.8.6 Agent.FailedRequests

Cumulative counter of requests with errors in processing (others than unsupported parameters)
42.8.7 Agent.GeneratedTraps
Note: Depricated
Data type: Unsigned Integer 64-bit

Nuber of traps generated by agent
42.8.8 Agent.IsSubagentLoaded(*)
Data type: Integer

Parameters:
1. subagent name
Check if given subagent is loaded. Return 1 if loaded and 0 if not.
42.8.9 Agent.LastTrapTime
Note: Depricated

Timestamp of last generated trap
42.8.10 Agent.IsUserAgentInstalled

Check if user support application is installed

42.8.11 Agent.LocalDatabase.FailedQueries

Agent local database: failed queries
42.8.12 Agent.LocalDatabase.LongRunningQueries

Agent local database: long running queries
42.8.13 Agent.LocalDatabase.Status

Agent local database: status
42.8.14 Agent.LocalDatabase.TotalQueries

Agent local database: total queries executed
42.8.15 Agent.LogFile.Status

Agent log status
42.8.16 Agent.Notification.QueueSize

Agent notification queue size

42.8.17 Agent.ProcessedRequests

Cumulative counter of successfully processed requests
42.8.18 Agent.Registrar
Data type: String

Registrar server address set on agent startup
42.8.19 Agent.RejectedConnections

Cumulative counter of connections rejected due to authentication failure
42.8.20 Agent.SentTraps
Note: Depricated

Number of traps successfully sent to server
42.8.21 Agent.SourcePackageSupport
Data type: Integer

Non-zero if system is capable of building agent from source
42.8.22 Agent.SupportedCiphers
Data type: String

List of ciphers supported by agent

42.8.23 Agent.SyslogProxy.IsEnabled

Check if syslog proxy is enabled
42.8.24 Agent.SyslogProxy.ReceivedMessages

Number of syslog messages received by agent
42.8.25 Agent.ThreadPool.ActiveRequests(*)

Parameters:
1. Thread pool name. Possible options: MAIN, AGENT, POLLERS, SCHEDULER
Count of active requests for specified agent thread pool.
42.8.26 Agent.ThreadPool.CurrSize(*)

Parameters:
Current size of specified agent thread pool.
42.8.27 Agent.ThreadPool.Load(*)

Parameters:
Current load of specified agent thread pool. It’s active requests divided by current thread count in precent.

42.8.28 Agent.ThreadPool.LoadAverage(*)

Parameters:
2. optional Normalization flag. If it is set to 1, then the value is divided to max thread count.
Active request moving average load of specified agent thread pool for last minute.
42.8.29 Agent.ThreadPool.LoadAverage5(*)

Parameters:
Active request moving average of specified agent thread pool for last 5 minutes.
42.8.30 Agent.ThreadPool.LoadAverage15(*)

Parameters:
Active request moving average load of specified agent thread pool for last 15 minutes.
42.8.31 Agent.ThreadPool.MaxSize(*)

Parameters:
Maximum size of specified agent thread pool.

42.8.32 Agent.ThreadPool.MinSize(*)

Parameters:
Maximum size of specified agent thread pool.
42.8.33 Agent.ThreadPool.Usage(*)

Parameters:
Current usage of specified agent thread pool. The value is equal to current thread count divided by max thread count
in percent.
42.8.34 Agent.TimedOutRequests

Cumulative counter of timed out requests
42.8.35 Agent.UnsupportedRequests

Cumulative counter of requests for unsupported parameters
42.8.36 Agent.Uptime

Number of seconds since agent start

42.8.37 Agent.Version
Data type: String

Agent’s version
42.8.38 File.Count(*)

Parameters:
1. Path is the only mandatory argument. It specifies base directory for search.
2. Pattern - If pattern is given, only files whose names matched against it will be counted. Since version
3.8.314 it’s possible to invert the mask by prefixing this parameter with “!”. In this case files NOT maching
the mask will be counted.
3. Recursive - determines if agent should count files in subdirectories. To enable recursion, use values 1 or
true.
4. Size filter. If parameter < 0, only files with size less than abs(value) will match. If parameter > 0, only files
with size greater than value will match.
5. Age filter. If parameter < 0, only files created after now - abs(value) will match. If parameter > 0, only
files created before now - value will match.
Number of files in directory
42.8.39 File.FolderCount(*)

Parameters:
1. Path is the only mandatory argument. It specifies base directory for search.
2. Pattern - If pattern is given, only folders whose names matched against it will be counted.
3. Recursive - determines if agent should count folders in subdirectories. To enable recursion, use values 1
or true.
4. Size filter. If parameter < 0, only folders with size less than abs(value) will match. If parameter > 0, only
folders with size greater than value will match.
5. Age filter. If parameter < 0, only folders created after now - abs(value) will match. If parameter > 0, only
folders created before now - value will match.
Number of folders in directory

42.8.40 File.Hash.CRC32(*)

Parameters:
1. Path - it specifies path to file
CRC32 hash of given file
42.8.41 File.Hash.MD5(*)
Data type: String

Parameters:
MD5 hash of given file
42.8.42 File.Hash.SHA1(*)
Data type: String

Parameters:
SHA1 hash of given file
42.8.43 File.Size(*)

Parameters:
1. Path is the only mandatory argument. It specifies either single file or base directory for calculation.
2. If pattern is given, only files whose names matched against it will be counted.
3. Recursive determines if agent should count files in subdirectories. To enable recursion, use values 1 or
true.
4. Size filter. If parameter < 0, only files with size less than abs(value) will match. If parameter > 0, only files
with size greater than value will match.
5. Age filter. If parameter < 0, only files created after now - abs(value) will match. If parameter > 0, only
files created before now - value will match.
Size in bytes of single file or all files in given directory.

42.8.44 File.Time.Access(*)

Parameters:
File’s last access time in seconds since epoch (1 Jan 1970 00:00:00 UTC)
42.8.45 File.Time.Change(*)

Parameters:
File’s last status change time in seconds since epoch (1 Jan 1970 00:00:00 UTC)
42.8.46 File.Time.Modify(*)

Parameters:
File’s last modification time in seconds since epoch (1 Jan 1970 00:00:00 UTC)
42.8.47 FileSystem.Avail(*)

Supported Platforms: Linux, Solaris, AIX, HP-UX, FreeBSD, NetBSD, OpenBSD
Parameters:
1. Mountpoint, device name (linux only) or disk name (for Windows)
Available space on file system in bytes
42.8.48 FileSystem.AvailPerc(*)
Data type: Float

Supported Platforms: Linux, Solaris, AIX, HP-UX, FreeBSD, NetBSD, OpenBSD
Parameters:
Percentage of available space on file system

42.8.49 FileSystem.Free(*)

Parameters:
Free space on file system in bytes
42.8.50 FileSystem.FreePerc(*)
Data type: Float

Parameters:
Percentage of free space on file system
42.8.51 FileSystem.Total(*)

Parameters:
Total number of bytes on file system
42.8.52 FileSystem.Type(*)
Data type: String

Parameters:
1. Mountpoint or disk name (for Windows)
Type of file system
42.8.53 FileSystem.Used(*)

Parameters:
Used space on file system in bytes

42.8.54 FileSystem.UsedPerc(*)
Data type: Float

Parameters:
Percentage of used space on file system
42.8.55 Net.Interface.AdminStatus(*)
Data type: Integer

Parameters:
1. Interface name or interface index. Index can be obtained from Net.InterfaceList list.
Network interface administrative status (1 = enabled, 2 = disabled, 3 = testing)
42.8.56 Net.Interface.BytesIn(*)

Parameters:
Number of input bytes on interface
42.8.57 Net.Interface.BytesOut(*)

Parameters:
Number of output bytes on interface
42.8.58 Net.Interface.Description(*)
Data type: String

Supported Platforms: Windows, Linux, Solaris, AIX, HP-UX
Parameters:
Description of interface

42.8.59 Net.Interface.InErrors(*)

Parameters:
Number of input errors on interface
42.8.60 Net.Interface.Link(*)
Data type: Integer

Parameters:
Link status of interface
42.8.61 Net.Interface.MTU(*)
Data type: Integer

Supported Platforms: Windows, AIX, HP-UX
Parameters:
42.8.62 Net.Interface.OperStatus(*)
Data type: Integer

Supported Platforms: Windows, Linux, Solaris, HP-UX, FreeBSD, NetBSD, OpenBSD
Parameters:
Network interface operational status (0 = down, 1 = up)
42.8.63 Net.Interface.OutErrors(*)

Parameters:
Number of output errors on interface

42.8.64 Net.Interface.PacketsIn(*)
Data type: UInt32

Parameters:
Number of input packets on interface
42.8.65 Net.Interface.PacketsOut(*)
Data type: UInt32

Parameters:
Number of output packets on interface
42.8.66 Net.Interface.Speed(*)
Data type: UInt32

Supported Platforms: Windows, Solaris, AIX, HP-UX
Parameters:
42.8.67 Net.IP.Forwarding
Data type: Int32

Supported Platforms: Windows, Linux, HP-UX, FreeBSD, NetBSD, OpenBSD
IP forwarding status (1 = forwarding, 0 = not forwarding)
42.8.68 Net.IP6.Forwarding
Data type: Int32

Supported Platforms: Linux, HP-UX, FreeBSD, NetBSD, OpenBSD
IPv6 forwarding status (1 = forwarding, 0 = not forwarding)

42.8.69 Net.IP.NextHop(*)
Data type: String

Next hop for given destination address according to host’s routing table
42.8.70 Net.RemoteShareStatus(*)
Data type: Int32

Supported Platforms: Windows
Parameters:
1. Correct UNC path
2. Domain
3. Login
4. Password
Status of remote shared resource
42.8.71 Net.RemoteShareStatusText(*)
Data type: String

Parameters:
1. Correct UNC path
2. Domain
3. Login
4. Password
Status of remote shared resource as text
42.8.72 Net.Resolver.AddressByName(*)
Data type: String

Parameters:
1. Name to resolve
Resolves host name to IP address

42.8.73 Net.Resolver.NameByAddress(*)
Data type: String

Parameters:
1. Address to resolve
Resolves IP address to host name
42.8.74 PDH.CounterValue(*)
Data type: UInt32

Parameters:
1. Counter path. It should start with single backslash character and not include machine name.
2. Optional second argument specifies if counter requires two samples to calculate value (typical example of
such counters is CPU utilization). Two samples will be taken if this argument is set to 1.
Current value of given PDH counter.
42.8.75 PDH.Version
Data type: UInt32

Version of PDH.DLL (as returned by PdhGetDllVersion() call).
42.8.76 Process.Count(*)
Data type: UInt32

Parameters:
1. Process name
Number of processes with given name
42.8.77 Process.CountEx(*)
Data type: UInt32

Supported Platforms: Windows, Linux, Solaris, FreeBSD, NetBSD
Parameters:
1. Process name
2. Optional parameter that accepts process’s command line regular expression, that should match cmd argu-
ment. If not set it means “match any”.

3. Optional parameter that accepts process’s main window title regular expression. If not set it means “match
any”. Process’s window title can be checked only on Windows platform.
Number of processes matching filter
42.8.78 Process.CPUTime(*)

Supported Platforms: Windows, Linux, Solaris, AIX, HP-UX, FreeBSD, NetBSD
Parameters:
1. Process name
2. Function - is the function that is used to measure data in case if there are more than one process with given
name. By default it is used sum function. This parameter can have this options:
• min - minimal value among all processes named proc
• max - maximal value among all processes named proc
• avg - average value for all processes named proc
• sum - sum of values for all processes named proc
Total execution time for process
42.8.79 Process.GDIObjects(*)

Parameters:
1. Process name
GDI objects used by process

42.8.80 Process.IO.OtherB(*)

Parameters:
1. Process name
42.8.81 Process.IO.OtherOp(*)

Parameters:
1. Process name

42.8.82 Process.IO.ReadB(*)

Parameters:
1. Process name
42.8.83 Process.IO.ReadOp(*)

Parameters:
1. Process name

42.8.84 Process.IO.WriteB(*)

Parameters:
1. Process name
42.8.85 Process.IO.WriteOp(*)

Parameters:
1. Process name

42.8.86 Process.KernelTime(*)

Supported Platforms: Windows, Linux, Solaris, AIX, HP-UX, NetBSD
Parameters:
1. Process name
Total execution time in kernel mode for process
42.8.87 Process.PageFaults(*)

Parameters:
1. Process name
Page faults for process

42.8.88 Process.Syscalls(*)
Data type: UInt64

Supported Platforms: Solaris
Parameters:
1. Process name
Number of system calls made by process
42.8.89 Process.Threads(*)
Data type: UInt64

Supported Platforms: Linux, Solaris, AIX, HP-UX, FreeBSD, NetBSD
Parameters:
1. Process name
Number of threads in process

42.8.90 Process.UserObjects(*)
Data type: UInt64

Parameters:
1. Process name
USER objects used by process
42.8.91 Process.UserTime(*)
Data type: UInt64

Parameters:
1. Process name
Total execution time in user mode for process

42.8.92 Process.VMSize(*)
Data type: UInt64

Supported Platforms: Windows, Linux, Solaris, AIX, HP-UX, FreeBSD, NetBSD
Parameters:
1. Process name
Virtual memory used by process
42.8.93 Process.WkSet(*)
Data type: UInt64

Supported Platforms: Windows, Linux, Solaris, HP-UX, FreeBSD, NetBSD
Parameters:
1. Process name
Physical memory used by process

42.8.94 System.AppAddressSpace
Data type: UInt32

Address space available to applications (MB)
42.8.95 System.ConnectedUsers
Data type: Int32

Supported Platforms: Windows, Linux
Number of users connected to system
42.8.96 System.CPU.Count
Data type: Int32

Supported Platforms: Windows, Linux, Solaris, AIX, FreeBSD, NetBSD, OpenBSD, MacOS
Number of CPUs in the system
42.8.97 System.CPU.LoadAvg
Data type: Float

Supported Platforms: Windows, Linux, Solaris, AIX, HP-UX, FreeBSD, NetBSD, OpenBSD, MacOS
CPU load average for last minute
Note: On Windows this metric is provided by winperf subagent
42.8.98 System.CPU.LoadAvg5
Data type: Float

CPU load average for last 5 minutes

42.8.99 System.CPU.LoadAvg15
Data type: Float

CPU load average for last 15 minutes
42.8.100 System.CPU.Usage
Data type: Float

Supported Platforms: Windows, Linux, Solaris, AIX, HP-UX, MacOS
Average CPU usage for last minute (percents, all CPUs)
42.8.101 System.CPU.Usage(*)
Data type: Float

Supported Platforms: Windows, Linux, Solaris, AIX, MacOS
Parameters:
1. Zero-based index of CPU.
Average CPU usage for last minute (percents, specific CPU)
42.8.102 System.CPU.Usage5
Data type: Float

Average CPU usage for last 5 minutes (percents, all CPUs)

42.8.103 System.CPU.Usage5(*)
Data type: Float

Parameters:
Average CPU usage for last 5 minutes (percents, specific CPU)
42.8.104 System.CPU.Usage15
Data type: Float

Average CPU usage for last 15 minutes (percents, all CPUs)
42.8.105 System.CPU.Usage15(*)
Data type: Float

Parameters:
Average CPU usage for last 15 minutes (percents, specific CPU)
42.8.106 System.CPU.Usage.Idle
Data type: Float

Supported Platforms: Linux, AIX, MacOS
Average CPU usage (IDLE) for last minute (percents, all CPUs)

42.8.107 System.CPU.Usage.Idle(*)
Data type: Float

Parameters:
Average CPU usage (IDLE) for last minute (percents, specific CPU)
42.8.108 System.CPU.Usage5.Idle
Data type: Float

Average CPU usage (IDLE) for last 5 minutes (percents, all CPUs)
42.8.109 System.CPU.Usage5.Idle(*)
Data type: Float

Parameters:
Average CPU usage (IDLE) for last 5 minutes (percents, specific CPU)
42.8.110 System.CPU.Usage15.Idle
Data type: Float

Average CPU usage (IDLE) for last 15 minutes (percents, all CPUs)
42.8.111 System.CPU.Usage15.Idle(*)
Data type: Float

Parameters:
Average CPU usage (IDLE) for last 15 minutes (percents, specific CPU)

42.8.112 System.CPU.Usage.IOWait
Data type: Float

Supported Platforms: Linux, AIX
Average CPU usage (IOWAIT) for last minute (percents, all CPUs)
42.8.113 System.CPU.Usage.IOWait(*)
Data type: Float

Parameters:
Average CPU usage (IOWAIT) for last minute (percents, specific CPU)
42.8.114 System.CPU.Usage5.IOWait
Data type: Float

Average CPU usage (IOWAIT) for last 5 minutes (percents, all CPUs)
42.8.115 System.CPU.Usage5.IOWait(*)
Data type: Float

Parameters:
Average CPU usage (IOWAIT) for last 5 minutes (percents, specific CPU)
42.8.116 System.CPU.Usage15.IOWait
Data type: Float

Average CPU usage (IOWAIT) for last 15 minutes (percents, all CPUs)

42.8.117 System.CPU.Usage15.IOWait(*)
Data type: Float

Parameters:
Average CPU usage (IOWAIT) for last 15 minutes (percents, specific CPU)
42.8.118 System.CPU.Usage.IRQ
Data type: Float

Supported Platforms: Linux
Average CPU usage (IRQ) for last minute (percents, all CPUs)
42.8.119 System.CPU.Usage.IRQ(*)
Data type: Float

Parameters:
Average CPU usage (IRQ) for last minute (percents, specific CPU)
42.8.120 System.CPU.Usage5.IRQ
Data type: Float

Average CPU usage (IRQ) for last 5 minutes (percents, all CPUs)
42.8.121 System.CPU.Usage5.IRQ(*)
Data type: Float

Parameters:
Average CPU usage (IRQ) for last 5 minutes (percents, specific CPU)

42.8.122 System.CPU.Usage15.IRQ
Data type: Float

Average CPU usage (IRQ) for last 15 minutes (percents, all CPUs)
42.8.123 System.CPU.Usage15.IRQ(*)
Data type: Float

Parameters:
Average CPU usage (IRQ) for last 15 minutes (percents, specific CPU)
42.8.124 System.CPU.Usage.Nice
Data type: Float

Supported Platforms: Linux, MacOS
Average CPU usage (NICE) for last minute (percents, all CPUs)
42.8.125 System.CPU.Usage.Nice(*)
Data type: Float

Parameters:
Average CPU usage (NICE) for last minute (percents, specific CPU)
42.8.126 System.CPU.Usage5.Nice
Data type: Float

Average CPU usage (NICE) for last 5 minutes (percents, all CPUs)

42.8.127 System.CPU.Usage5.Nice(*)
Data type: Float

Parameters:
Average CPU usage (NICE) for last 5 minutes (percents, specific CPU)
42.8.128 System.CPU.Usage15.Nice
Data type: Float

Average CPU usage (NICE) for last 15 minutes (percents, all CPUs)
42.8.129 System.CPU.Usage15.Nice(*)
Data type: Float

Parameters:
Average CPU usage (NICE) for last 15 minutes (percents, specific CPU)
42.8.130 System.CPU.Usage.SoftIRQ
Data type: Float

Average CPU usage (SOFTIRQ) for last minute (percents, all CPUs)
42.8.131 System.CPU.Usage.SoftIRQ(*)
Data type: Float

Parameters:
Average CPU usage (SOFTIRQ) for last minute (percents, specific CPU)

42.8.132 System.CPU.Usage5.SoftIRQ
Data type: Float

Average CPU usage (SOFTIRQ) for last 5 minutes (percents, all CPUs)
42.8.133 System.CPU.Usage5.SoftIRQ(*)
Data type: Float

Parameters:
Average CPU usage (SOFTIRQ) for last 5 minutes (percents, specific CPU)
42.8.134 System.CPU.Usage15.SoftIRQ
Data type: Float

Average CPU usage (SOFTIRQ) for last 15 minutes (percents, all CPUs)
42.8.135 System.CPU.Usage15.SoftIRQ(*)
Data type: Float

Parameters:
Average CPU usage (SOFTIRQ) for last 15 minutes (percents, specific CPU)
42.8.136 System.CPU.Usage.Steal
Data type: Float

Average CPU usage (STEAL) for last minute (percents, all CPUs)

42.8.137 System.CPU.Usage.Steal(*)
Data type: Float

Parameters:
Average CPU usage (STEAL) for last minute (percents, specific CPU)
42.8.138 System.CPU.Usage5.Steal
Data type: Float

Average CPU usage (STEAL) for last 5 minutes (percents, all CPUs)
42.8.139 System.CPU.Usage5.Steal(*)
Data type: Float

Parameters:
Average CPU usage (STEAL) for last 5 minutes (percents, specific CPU)
42.8.140 System.CPU.Usage15.Steal
Data type: Float

Average CPU usage (STEAL) for last 15 minutes (percents, all CPUs)
42.8.141 System.CPU.Usage15.Steal(*)
Data type: Float

Parameters:
Average CPU usage (STEAL) for last 15 minutes (percents, specific CPU)

42.8.142 System.CPU.Usage.System
Data type: Float

Average CPU usage (SYSTEM) for last minute (percents, all CPUs)
42.8.143 System.CPU.Usage.System(*)
Data type: Float

Parameters:
Average CPU usage (SYSTEM) for last minute (percents, specific CPU)
42.8.144 System.CPU.Usage5.System
Data type: Float

Average CPU usage (SYSTEM) for last 5 minutes (percents, all CPUs)
42.8.145 System.CPU.Usage5.System(*)
Data type: Float

Parameters:
Average CPU usage (SYSTEM) for last 5 minutes (percents, specific CPU)
42.8.146 System.CPU.Usage15.System
Data type: Float

Average CPU usage (SYSTEM) for last 15 minutes (percents, all CPUs)

42.8.147 System.CPU.Usage15.System(*)
Data type: Float

Parameters:
Average CPU usage (SYSTEM) for last 15 minutes (percents, specific CPU)
42.8.148 System.CPU.Usage.User
Data type: Float

Average CPU usage (USER) for last minute (percents, all CPUs)
42.8.149 System.CPU.Usage.User(*)
Data type: Float

Parameters:
Average CPU usage (USER) for last minute (percents, specific CPU)
42.8.150 System.CPU.Usage5.User
Data type: Float

Average CPU usage (USER) for last 5 minutes (percents, all CPUs)
42.8.151 System.CPU.Usage5.User(*)
Data type: Float

Parameters:
Average CPU usage (USER) for last 5 minutes (percents, specific CPU)

42.8.152 System.CPU.Usage15.User
Data type: Float

Average CPU usage (USER) for last 15 minutes (percents, all CPUs)
42.8.153 System.CPU.Usage15.User(*)
Data type: Float

Parameters:
Average CPU usage (USER) for last 15 minutes (percents, specific CPU)
42.8.154 System.CurrentTime
Data type: Float

Current system time
42.8.155 System.Hostname
Data type: String

Host name
42.8.156 System.IO.BytesReadRate
Data type: Int64

Supported Platforms: Linux, Solaris, AIX, HP-UX
Average number of bytes read per second for last minute
42.8.157 System.IO.BytesReadRate(*)
Data type: Int64

Parameters:
1. Device name
Average number of bytes read per second on specific device for last minute

42.8.158 System.IO.BytesWriteRate
Data type: Int64

Average number of bytes written per second for last minute
42.8.159 System.IO.BytesWriteRate(*)
Data type: Int64

Parameters:
1. Device name
Average number of bytes written per second on specific device for last minute
42.8.160 System.IO.DiskQueue
Data type: Float

Supported Platforms: Windows, Linux, Solaris, AIX, HP-UX
Average disk queue length for last minute
42.8.161 System.IO.DiskQueue(*)
Data type: Float

Parameters:
1. Device name
Average disk queue length for last minute for specific device
42.8.162 System.IO.DiskTime
Data type: Float

Supported Platforms: Windows, Linux
Average disk busy time for last minute (percents)

42.8.163 System.IO.DiskTime(*)
Data type: Float

Parameters:
1. Device name
Average disk busy time for last minute for specific device (percents)
42.8.164 System.IO.ReadRate
Data type: Float

Average number of read operations per second for last minute
42.8.165 System.IO.ReadRate(*)
Data type: Float

Parameters:
1. Device name
Average number of read operations per second on specific device for last minute
42.8.166 System.IO.TransferRate
Data type: Float

Supported Platforms: AIX, HP-UX
Average number of data transfers per second for last minute
42.8.167 System.IO.TransferRate(*)
Data type: Float

Parameters:
1. Device name
Average number of data transfers per second on specific device for last minute

42.8.168 System.IO.OpenFiles
Data type: Int32

Supported Platforms: HP-UX
Number of open files
42.8.169 System.IO.WaitTime
Data type: UInt32

Average I/O wait time in milliseconds for last minute
42.8.170 System.IO.WaitTime(*)
Data type: UInt32

Parameters:
1. Device name
Average I/O wait time on specific device in milliseconds for last minute
42.8.171 System.IO.WriteRate
Data type: Float

Average number of write operations per second for last minute
42.8.172 System.IO.WriteRate(*)
Data type: Float

Parameters:
1. Device name
Average number of write operations per second on specific device for last minute

42.8.173 System.KStat(*)
Data type: Undefined

Supported Platforms: Solaris
Parameters:
1. Module
2. Instance
3. Name
4. Statistic
Solaris kstat data. More information can be found in kstat man.
42.8.174 System.Memory.Physical.Available
Data type: UInt64

Available physical memory in bytes
42.8.175 System.Memory.Physical.AvailablePerc
Data type: Uint

Percentage of available physical memory
42.8.176 System.Memory.Physical.Free
Data type: UInt64

Free physical memory in bytes
42.8.177 System.Memory.Physical.FreePerc
Data type: Uint

Supported Platforms: Windows, Linux, Solaris, AIX, HP-UX, FreeBSD
Percentage of free physical memory

42.8.178 System.Memory.Physical.Total
Data type: UInt64

Total amount of physical memory in bytes
42.8.179 System.Memory.Physical.Used
Data type: UInt64

Used physical memory in bytes
42.8.180 System.Memory.Physical.UsedPerc
Data type: Float

Supported Platforms: Windows, Linux, Solaris, AIX, HP-UX, FreeBSD
Percentage of used physical memory
42.8.181 System.Memory.Swap.Free
Data type: UInt64

Supported Platforms: Linux, AIX, HP-UX, FreeBSD, NetBSD, OpenBSD
Free swap space in bytes
42.8.182 System.Memory.Swap.FreePerc
Data type: Float

Supported Platforms: Linux, AIX, HP-UX, FreeBSD
Percentage of free swap space
42.8.183 System.Memory.Swap.Total
Data type: UInt64

Total amount of swap space in bytes

42.8.184 System.Memory.Swap.Used
Data type: UInt64

Used swap space in bytes
42.8.185 System.Memory.Swap.UsedPerc
Data type: Float

Supported Platforms: Linux, AIX, HP-UX, FreeBSD
Percentage of used swap space
42.8.186 System.Memory.Virtual.Active
Data type: UInt64

Supported Platforms: AIX
Active virtual memory
42.8.187 System.Memory.Virtual.ActivePerc
Data type: Float

Supported Platforms: AIX
Percentage of active virtual memory
42.8.188 System.Memory.Virtual.Free
Data type: UInt64

Supported Platforms: Windows, Linux, AIX, HP-UX, FreeBSD, NetBSD, OpenBSD
Free virtual memory in bytes
42.8.189 System.Memory.Virtual.FreePerc
Data type: Float

Supported Platforms: Windows, Linux, AIX, HP-UX, FreeBSD
Percentage of free virtual memory

42.8.190 System.Memory.Virtual.Total
Data type: UInt64

Total amount of virtual memory in bytes
42.8.191 System.Memory.Virtual.Used
Data type: UInt64

Used virtual memory in bytes
42.8.192 System.Memory.Virtual.UsedPerc
Data type: Float

Supported Platforms: Windows, Linux, AIX, HP-UX, FreeBSD
Percentage of used virtual memory
42.8.193 System.PlatformName
Data type: String

Unified platform name (used by agent upgrade component)
42.8.194 System.ProcessCount
Data type: UInt32

Total number of processes in system
42.8.195 System.ServiceState(*)
Data type: Int32

Parameters:
1. Windows service name
State of system service. Possible values:
• 0 - service running
• 1 - service paused
• 2 - service starting (start pending)
• 3 - service pausing (pause pending)

• 4 - service starting after pause (continue pending)

• 5 - service stopping (stop pending)
• 6 - service stopped
• 255 - unable to get current service state
42.8.196 System.ThreadCount
Data type: UInt32

Supported Platforms: Windows, Linux, AIX, FreeBSD, NetBSD
Total number of threads in system
42.8.197 System.Uname
Data type: String

Output of uname command
42.8.198 System.Uptime
Data type: Int32

Number of seconds since system boot


CHAPTER
FORTYTHREE
GLOSSARY
802.1x IEEE 802.1X (also known as Dot1x) is an IEEE Standard for Port-based Network Access Control (PNAC). It
is part of the IEEE 802.1 group of networking protocols. It provides an authentication mechanism to devices
wishing to attach to a LAN or WLAN. More details in Wikipedia
Action Configurable operation which can be executed by the system when Event is passing thru Event Processing
Policy. Multiple action types are supported, including email or notifications (SMS, instant messages), executing
OS commands and forwarding events to another instance of NetXMS server.
Alarm Outstanding issue which require operator attention. Alarms are created by the system as a result of Event
passing thru Event Processing Policy.
Alarm Browser View in user interface, which shows all active alarms in the system and allow user to interact with
them.
ARP The Address Resolution Protocol (ARP) is a telecommunication protocol used for resolution of network layer
addresses into link layer addresses, a critical function in multiple-access networks. More details in Wikipedia
Business Service An IT Service that directly supports a Business Process, as opposed to an Infrastructure Service
which is used internally by the IT Service Provider and is not usually visible to the Business.
CA Certification authority is an entity that issues digital certificates. More details in Wikipedia
CDP Cisco Discovery Protocol is a Cisco proprietary protocol that runs between direct connected network entities
(routers, switches, remote access devices, IP telephones etc.). The purpose of the protocol is to supply a network
entity with information about its direct connected neighbors. More details in Wikipedia.
Condition (Create condition in infrastructure services)
Container Object that can store other containers and nodes.
CSR Certificate signing request is a message sent from an applicant to a certificate authority in order to apply for a
digital identity certificate. More details in Wikipedia
Dashboard Manually generated Object that can combine any available visualization components with data from
multiple sources in order to create high-level views to see network or parts of it, and it’s health.
Data Collection Item Configuration entity of a single Metric.
DCI Abbreviation for Data Collection Item
DNS Domain Name System. More details in Wikipedia
Entire Network Automatically generated object hierarchy that contains all nodes and IP subnets known to NetXMS.
EPP Abbreviation for Event Processing Policy
Event TBD A change of state which has significance for the management of IT Service.
Event Processing Policy List of rules which defines system reaction on events. All events are matched against list of
rules in Event Processing Policy, if match is found – configured actions are executed.
457
Event Template TBD

GPL GNU General Public License. Full text of the License, version 2 <http://www.gnu.org/licenses/gpl-2.0.html>
GUID A Globally Unique Identifier is a unique reference number used as an identifier in computer software. More
details in Wikipedia
ICMP The Internet Control Message Protocol (ICMP) is one of the main protocols of the Internet Protocol Suite. It
is used by network devices, like routers, to send error messages indicating, for example, that a requested service
is not available or that a host or router could not be reached. More details in Wikipedia.
Infrastructure services System container which can be used by Administrator to define logical structure of the net-
work.
LAN A local area network (LAN) is a computer network that interconnects computers within a limited area such as
a home, school, computer laboratory, or office building, using network media. The defining characteristics of
LANs, in contrast to wide area networks (WANs), include their smaller geographic area, and non-inclusion of
leased telecommunication lines. More details in Wikipedia.
LDAP The Lightweight Directory Access Protocol (LDAP) is an open, vendor-neutral, industry standard application
protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP)
network. More details in Wikipedia
LLDP The Link Layer Discovery Protocol (LLDP) is a vendor-neutral link layer protocol in the Internet Protocol
Suite used by network devices for advertising their identity, capabilities, and neighbors on an IEEE 802 local
area network, principally wired Ethernet. The protocol is formally referred to by the IEEE as Station and
Media Access Control Connectivity Discovery specified in standards document IEEE 802.1AB. More details in
Wikipedia
MAC address A media access control address (MAC address) is a unique identifier assigned to network interfaces
for communications on the physical network segment. MAC addresses are used as a network address for most
IEEE 802 network technologies, including Ethernet and WiFi. Logically, MAC addresses are used in the media
access control protocol sublayer of the OSI reference model. More details in Wikipedia.
Management Console NetXMS user interface. Available in form of rich client for both desktop and mobile or as
web service.
Metric One entity of collected data
MIB Explorer View in user interface, which allows to navigate SNMP MIB tree and run SNMP walk on nodes.
Mobile Device Object Special type of Node that represents monitored mobile device.
Monitoring Agent NetXMS or SNMP agent that provides information to NetXMS Server.
NDP The Neighbor Discovery Protocol (NDP) is a protocol in the Internet protocol suite used with Internet Protocol
Version 6 (IPv6). More details in Wikipedia
Network Discovery Network investigation in order to find new nodes. There are 2 types of discovery: active and
passive. In passive mode, information about new hosts and devices obtained from ARP tables and routing tables
of already known devices. In active discovery mode, NetXMS server will send an ICMP echo requests to all IP
addresses in given range, and consider each responding address for adding to database.
Network Map Visual representation of network topology.
Node Object that represents server or device.
NXSL NetXMS Scripting Language.
Object Representation of logical or physical entity.
Object tool Configurable operation that can be executed on Node.
Package Manager View that manages update packages for NetXMS agents.
458 Chapter 43. Glossary

Perspective A perspective defines the initial set and layout of views in the Eclipse Workbench window.
Policy Configuration parameter set that can be applied on a Node.
Polling Polling is process of gathering information by server from nodes. This is usually done automatically at
specified intervals of time, but can be triggered manually also. There are different types of polling: Status,
Configuration, Topology, Discovery and Routing.
NetXMS Agent NetXMS daemon that is installed on monitored Node to provide additional monitoring options.
Proxy Agent NetXMS Agent capable of forwarding requests to nodes which are not directly accessible to NetXMS
server. Agent support proxying of native agent protocol as well as SNMP.
Push parameter Type of DCI, where collected data is pushed into the server by the agent.
RADIUS Remote Authentication Dial In User Service (RADIUS) is a networking protocol that provides centralized
Authentication, Authorization, and Accounting (AAA) management for users who connect and use a network
service. More details in Wikipedia
SMCLP Server Management Command Line Protocol
SNMP Simple Network Management Protocol (SNMP) is an “Internet-standard protocol for managing devices on
IP networks”. Devices that typically support SNMP include routers, switches, servers, workstations, printers,
modem racks and more. SNMP is used mostly in network management systems to monitor network-attached
devices for conditions that warrant administrative attention. SNMP is a component of the Internet Protocol
Suite as defined by the Internet Engineering Task Force (IETF). It consists of a set of standards for network
management, including an application layer protocol, a database schema, and a set of data objects. More details
in Wikipedia.
SNMP Trap Asynchronous notification from SNMP agent to SNMP manager. SNMP traps enable an agent to no-
tify the management station of significant events by way of an unsolicited SNMP message. More details in
Wikipedia.
STP The Spanning Tree Protocol (STP) is a network protocol that ensures a loop-free topology for any bridged
Ethernet local area network. The basic function of STP is to prevent bridge loops and the broadcast radiation
that results from them. Spanning tree also allows a network design to include spare (redundant) links to provide
automatic backup paths if an active link fails, without the danger of bridge loops, or the need for manual
enabling/disabling of these backup links. More details in Wikipedia
Subagent Extension module (shared library) which can be loaded into NetXMS agent to provide additional function-
ality.
Syslog Widely used standard for message logging. More details in Wikipedia.
Template A preset of one or more DCIs that can be applied on Node.
Threshold Part of DCI configuration, which define events to be generated when collected value is outside of expected
range.
TLS Transport Layer Security is a cryptographic protocols that provide communications security over a computer
network. More details in Wikipedia.
Trim Stack View Stack in minimized state, represented as a set of buttons, one for each View in the stack.
UPS An uninterruptible power supply, also uninterruptible power source, UPS or battery/flywheel backup, is an
electrical apparatus that provides emergency power to a load when the input power source, typically mains
power, fails. More details in Wikipedia
URL A uniform resource locator (URL) is a reference to a resource that specifies the location of the resource on a
computer network and a mechanism for retrieving it. More details in Wikipedia
View In the Eclipse Platform a view is typically used to navigate a hierarchy of information, open an editor, or display
properties for the active editor.
459
View Stack Multiple views combined into single one, with tab navigation on top of it.
VLAN In computer networking, a single layer-2 network may be partitioned to create multiple distinct broadcast
domains, which are mutually isolated so that packets can only pass between them via one or more routers; such
a domain is referred to as a virtual local area network, virtual LAN or VLAN. More details in Wikipedia.
VPN A virtual private network (VPN) extends a private network across a public network, such as the Internet. It
enables a computer or network-enabled device to send and receive data across shared or public networks as if it
were directly connected to the private network, while benefiting from the functionality, security and management
policies of the private network. A VPN is created by establishing a virtual point-to-point connection through
the use of dedicated connections, virtual tunneling protocols, or traffic encryptions. Major implementations of
VPNs include OpenVPN and IPsec. More details in Wikipedia.
VRRP The Virtual Router Redundancy Protocol (VRRP) is a computer networking protocol that provides for auto-
matic assignment of available Internet Protocol (IP) routers to participating hosts. This increases the availability
and reliability of routing paths via automatic default gateway selections on an IP subnetwork. More details in
Wikipedia
Zone Zone in NetXMS is a group of IP subnets which form non-overlapping IP address space. There is always zone
0 which contains subnets directly reachable by management server. For all other zones server assumes that
subnets within that zones are not reachable directly, and proxy must be used. It is used to monitor subnets with
overlapping IP address space.
460 Chapter 43. Glossary

INDEX
Symbols LDAP, 458

802.1x, 457 LLDP, 458
A M
Action, 457 MAC address, 458
Alarm, 457 Management Console, 458
Alarm Browser, 457 Metric, 458
ARP, 457 MIB Explorer, 458
Mobile Device Object, 458
B Monitoring Agent, 458
Business Service, 457
N
C NDP, 458
CA, 457 Network Discovery, 458
CDP, 457 Network Map, 458
Condition, 457 Node, 458
Container, 457 NXSL, 458
CSR, 457
O
D Object, 458
Dashboard, 457 Object tool, 458
Data Collection Item, 457
DCI, 457 P
DNS, 457 Package Manager, 458
Perspective, 459
E Policy, 459
Entire Network, 457 Polling, 459
EPP, 457 product_name Agent, 459
Event, 457 Proxy Agent, 459
Event Processing Policy, 457 Push parameter, 459
Event Template, 458
R
G RADIUS, 459
GPL, 458
GUID, 458 S
SMCLP, 459
I SNMP, 459
ICMP, 458 SNMP Trap, 459
Infrastructure services, 458 STP, 459
Subagent, 459
L Syslog, 459
LAN, 458
461
T
Template, 459
Threshold, 459
TLS, 459
Trim Stack, 459
U
UPS, 459
URL, 459
V
View, 459
View Stack, 460
VLAN, 460
VPN, 460
VRRP, 460
Z
Zone, 460
462 Index

Netxms Admin

Uploaded by

Copyright:

Available Formats

Netxms Admin

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Netxms Admin

Uploaded by

Copyright:

Available Formats

NetXMS Administrator Guide

Raden Solutions, SIA

Jun 16, 2021

11 Network discovery 127

12 Data collection 131

13 Event processing 151

14 Data and Network visualisation 177

15 Grafana integration 219

16 Operating System Monitoring 223

17 File meta information 231

18 Log monitoring 237

19 Windows Event Log Synchronization 249

20 SSH monitoring 253

21 Service monitoring 255

22 Data Collection from Web Services 261

24 Application monitoring 285

25 ICMP ping 289

26 Hardware(sensor) monitoring 293

27 UPS monitoring 299

28 Cluster monitoring 301

29 JVM monitoring 303

30 Hypervisor monitoring 307

31 Asterisk monitoring 311

32 Monitoring mobile devices 317

33 Network topology 321

34 Business services and SLA 325

35 Remote file management 329

37 Image library 343

38 Mobile Console 345

39 Advanced topics 357

40 Scheduled tasks 375

This document covers installation, configuration, and use of NetXMS.

1.1 Product Support

Contact us if you run into a problem or found a bug.

The following typographical conventions are used in this manual.

Complete change log for each product release is available at http://www.netxms.org/download/ChangeLog.

2.1 Architecture overview

Object Class Description Valid Child Objects

Zone Object representing group of (usually interconnected)

Table 1 – continued from previous page

Container Grouping object which can contain any type of objects

Cluster Object representing cluster consisting of two or more

Rack Object representing a rack. It has the same purpose as

Chassis Object representing a chassis, e.g. a blade server enclo-

continues on next page

Table 1 – continued from previous page

Template Group Grouping object which can contain templates or other

Template Data collection template. See Data collection section

Network Map Grouping object which can contain network maps or

Network Map Network map.

Dashboard Dashboard. Can contain other dashboards.

Business Service Abstract object representing root of your business ser-

Business Service Object representing single business service. Can con-

2.2.1 Object status

Each object has a status. Status of an object calculated based on:

Nr. Status Description

0 Normal Object is in normal state.

1 Warning Warning(s) exist for the object.

2 Minor Minor problem(s) exist for the object.

3 Major Major problem(s) exist for the object.