Advanced topics
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.
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:
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.
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.
Integration with external HelpDesk
NetXMS provides possibility to create issues in external helpdesk system directly from NetXMS management client, 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.
JIRA Module
This module provide integration between NetXMS and JIRA.
Required NetXMS configuration
For NetXMS is required to configure server parameters and restart the server.
Parameter name |
Description |
---|---|
HelpDeskLink |
For JIRA integration should be set to “jira.hdlink” (without quotes) |
Jira.IssueType |
Name of the JIRA issue type, which will be used by NetXMS. Sample value: “Task” (without quotes) |
Jira.Login |
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) |
Jira.Password |
Password of the JIRA user |
Jira.ProjectCode |
Project Key in JIRA. (Project should exist) |
Jira.ProjectComponent |
Jira project component. (Project should exist) |
Jira.ResolvedStatus |
Comma separated list of issue status codes indicating that issue is resolved. Default is “Done”. |
Jira.ServerURL |
URL of JIRA installation. Example: “http://localhost:8080/jira”. Please note, that trailing slash (“/”) should be removed! |
Jira.Webhook.Path |
Path part of Jira webhook URL (must start with /). Example: “/jira-webhook”. |
Jira.Webhook.Port |
Jira webhook listener port (0 to disable webhook). Default: “8008”. |
Note
Starting from version 4.1.283 NetXMS version Webhook can be used for Jira to NetXMS integration. Not a jira plugin.
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:
“Plugin Enabled” — global on/off switch, plugin completely cease any activity when turned off (default).
“Force Save” — by default, plugin will verify configuration before saving (connectivity to all servers, credentials). 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)
“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:
“Servers” — addresses of up to a 3 NetXMS servers, can be either IP address or hostname.
“Log In” — user login in NetXMS (User should exist in NetXMS with Read, View Alarms, Acknowledge Alarms, Terminate Alarms to all nodes)
“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:
Outstanding — initial state, can’t be set from JIRA side
Acknowledged — operator is aware of the problem and it’s in progress (“Acknowledge” action)
Resolved — problem is resolved but alarm stays in the list until verified and terminated by supervisor (“Resolve” action)
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:
Create new Workflow Schema if required
Copy existing or create new Workflow
Assign Workflow to the project, where NetXMS will create issues
Modify transitions to call plugin’s post-function and change related alarm in NetXMS
Click on a “cog” icon on a transition and select “View Post Functions”:
Click on “Add a new post function to the unconditional result of the transition”:
Select “NetXMS Modify Alarm” and click “Add”:
Select desired alarm action (Acknowledge / Resolve / Terminate) and click “Add”:
Repeat for all required transitions
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:
Right click on alarm in NetXMS and select “Create ticket in helpdesk system”:
In a moment, issue will be created and Helpdesk ID will be show in corresponding column:
Right click on the alarm and select “Show helpdesk ticket in web browser” to navigate to the issue in JIRA:
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 the end of status poll |
$object - current object, one of ‘NetObj’ subclasses $node - current object if it is ‘Node’ class |
none |
Hook::ConfigurationPoll |
Hook that is executed at the end of configuration poll |
$object - current object, one of ‘NetObj’ subclasses $node - current object if it is ‘Node’ class |
none |
Hook::InstancePoll |
Hook that is executed after instance discovery poll. |
$object - current object, one of ‘NetObj’ subclasses $node - current object if it is ‘Node’ class |
none |
Hook::TopologyPoll |
Hook that is executed at the ens of topology poll |
$node - current node, object of ‘Node’ type |
none |
Hook::CreateInterface |
Hook that is executed after new interface is created. |
$node - current node, object of ‘Node’ type $1 - current interface, object of ‘Interface’ type |
true/false - boolean - whether interface should be created |
Hook::AcceptNewNode |
This hook is executed by discovery process, after a new node is found and it’s checked that no node with give IP address is present in the system and before any network discovery filters. |
$ipAddr - IP address of the node being processed $ipNetMask - netmask of the node being processed $macAddr - MAC address of the node being processed $zoneUIN - zone UIN of the node being processed |
true/false - boolean - whether node should be created |
Hook::DiscoveryPoll |
Hook that is executed at the end of discovery poll |
$node - current node, object of ‘Node’ type |
none |
Hook::PostObjectCreate |
Hook that is executed after object is created |
$object - current object, one of ‘NetObj’ subclasses $node - current object if it is ‘Node’ class |
none |
Hook::CreateSubnet |
Hook that is executed on subnet creation |
$node - current node, object of ‘Node’ class $1 - current subnet, object of ‘Subnet’ class |
true/false - boolean - whether subnet should be created |
Hook::UpdateInterface |
Hook that is executed at the end of interface update |
$node - current node, object of ‘Node’ type $interface - current interface, object of ‘Interface’ type |
none |
Hook::EventProcessor |
Hook that is executed for each event prior to it’s processing by Event Processing Policies. |
$object - event source object, one of ‘NetObj’ subclasses $node - event source object if it is ‘Node’ class $event - event being processed (object of ‘Event’ class) |
none |
Hook::AlarmStateChange |
Hook that is executed on alarm state change (alarm gets acknowledged, resolved or terminated) |
$alarm - alarm being processed (object of ‘Alarm’ class) |
none |
Hook::UnboundTunnelOpened |
Hook that is executed when tunnel connection is established, but not bound to a node. |
$tunnel - incoming tunnel information (object of ‘Tunnel’ class) |
none |
Hook::BoundTunnelOpened |
Hook that is executed when tunnel connection bound to a node is established. |
$node - node this tunnel was bound to (object of ‘Node’ class) $tunnel - incoming tunnel information (object of ‘Tunnel’ class) |
none |
Hook::LDAPSynchronization |
Hook executed for each LDAP record (user or group) during LDAP synchronization. |
$ldapObject - LDAP object being synchronized (object of ‘LDAPObject’ class) |
true/false - boolean - whether processing of this LDAP record should continue |
Hook::Login |
Hook executed prior to user login |
$user - user object (object of ‘User’ class) $session - session object (object of ‘ClientSession’ class) |
true/false - boolean - whether login for this session should continue |
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.
Troubleshooting
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:
stop netxmsd
run “nxdbmgr reset-system-account” to unlock “system” account and change it’s password to default (“netxms”).
start netxmsd
login as “system” using password “netxms”
In user manager change password for any admin user account
login as admin user and disable “system” user account
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.
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
menu in management client. 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.
SNMP Device not recognized as SNMP-capable
Common issues:
Invalid community string or credentials
Access control on the device or firewall prevent connections from NetXMS server
Device do not support
System
(.1.3.6.1.2.1.1) orInterfaces
(.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 attributesnmp.testoid
to any OID supported by device.
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.
Autologin for Management Client
It is possible to connect management client (nxmc) or web management client to server automatically without login dialog. This chapter describes additional command line options and URL parameters for that.
Desktop Management Client
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 client to server 10.0.0.2 as user guest with empty password, use command
nxmc -auto -server=10.0.0.2 -login=guest
Web Management Client
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 |
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
NetXMS data usage in external products
NetXMS provides next options to use data in other applications:
Find Object
Management client has an option to filter objects by defined by user criteria. Filter can be access by
. Filter can be used in two different modes: filter and query.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.).
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.
Audit log forwarding
Syslog
NetXMS allows to forward audit log to another syslog server to have all data in one place.
Next configuration parameters should be set in order to forward audit log to external syslog server:
Name |
Description |
---|---|
ExternalAuditFacility |
Syslog facility to be used in audit log records sent to external server. |
ExternalAuditPort |
UDP port of external syslog server to send audit records to. |
ExternalAuditServer |
External syslog server to send audit records to. If set to “none”, external audit logging is disabled. |
ExternalAuditSeverity |
Syslog severity to be used in audit log records sent to external server. |
ExternalAuditTag |
Syslog tag to be used in audit log records sent to external server. |
LEEF
LEEF server module provides functionality to send audit log to IBM Security QRadar. The Log Event Extended Format (LEEF) is a customized event format for IBM Security QRadar. More about it can be found there.
LEEF server module should be enabled in server configuraiton file by adding “Module=leef.nxm” line to netxmsd.conf
file.
Additionaly to module configuration “LEEF” section should be added with required configurations.
Name |
Description |
---|---|
Server |
Server address |
Port |
Server port |
EventCode |
LEEF event code |
RFC5424Timestamp |
“No” if RFC5424 Timestamp format should not be used (default value is Yes) |
Facility |
Facility as facility in syslog |
Severity |
Severity as severity in syslog |
Product |
LEEF product field, by default will be “NetXMS” |
ProductVersion |
LEEF product version field, by default will be server version |
Vendor |
LEEF vendor field, default it “Raden Solutions” |
Separator |
LEEF separator character as a char or in numeric format: “xHH”, where HH is hexdecimal digit |
Additional fields can be configured in ExtraData sub section in the same key=value format.
Example:
[LEEF]
Server = 127.0.0.1
Port = 514
Facility = 13
Severity = 5
EventCode =
Separator = ^
[LEEF/ExtraData]
key = value
key2 = value2