If you are currently using version 5.x.x, we advise you to upgrade to the latest version before the EOL date. You can find the latest documentation here.
Probes
Overview
A probe represents a single Netprobe process running on a host. Netprobe connection settings are configured in the Probes top-level section of the gateway setup.
Operation
Basic configuration
Configuration consists of a list of probe definitions, each containing as a minimum the hostname and port that the gateway should connect to. Each probe is identified by a user-supplied name, which must be unique among all other probes to prevent ambiguity.
How to create and configure a new standard probe
This section describes how to create a normal Netprobe. Virtual Probes and Floating Probes are described below.
To create a new probe using the Gateway Setup Editor, follow these steps:
- Select the Probes top-level section. If this section does not exist, double-click to create it.
- Select New Probe.
- In the Name box, give the new probe a unique name. This name is used to reference the probe in the managed entity, and also for configuring rules and database logging. Names are case sensitive and must be unique across all probes.
- In the Hostname box, specify the hostname for the Netprobe. Gateway connects to the Netprobe on this machine, sends down the sampler setup and receives monitoring data.
- Configure the probe Port. This should be the Netprobe listen port. If not specified, the Gateway connects using the default port.
- The default probe port can optionally be configured here. If not specified, gateway will use the default port of 7036.
Once these steps have been completed, a new probe is available and can be referenced from a managed entity. See Managed Entities and Managed Entity Groups.
Virtual Probes
Virtual probes can also be configured. These appear in the directory structure as regular probes but do not make a TCP connection to an external Netprobe process.
Virtual probes are intended to be used to configure gateway plug-ins and for creating user-defined dataviews using compute engine.
How to create and configure a new virtual probe
To create a new virtual probe using the Gateway Setup Editor, follow these steps:
- Select the Probes top-level section. If this section does not exist, double-click to create it.
- Select New Virtual probe.
- In the Name box, give the new probe a unique name. This name is used to reference the probe in the managed entity, and also for configuring rules and database logging. Names are case sensitive and must be unique across all probes.
Virtual probes do not require network configuration parameters.
Floating Probes
Floating probes can also be configured. These are the same as regular probes except no TCP connection details are required, and instead the netprobe is configured to connect to the gateway when it starts up. This allows probes to be configured to follow monitored application in a cloud computing environment.
How to create and configure a new floating probe
To create a new floating probe using the Gateway Setup Editor, follow these steps:
- Select the Probes top-level section. If this section does not exist, double-click to create it.
- Select New Floating probe.
- In the Name box, give the new probe a unique name. This name is used to reference the probe in the managed entity, and also for configuring rules and database logging. Names are case sensitive and must be unique across all probes.
Floating probes do not require network configuration parameters.
Grouping
Probes can be grouped in the Gateway Setup Editor for ease of management using a probe group. These groups are ignored by gateway and have no effect on the resulting directory structure produced by the setup.
To create a probe group using the GSE, follow these steps:
- Right-click the Probes top-level section and select the New probeGroup menu option. This creates a new group section.
- In the Name box, name the probe group. This can be a descriptive name e.g. "Windows Probes".
- Add probes by dragging and dropping them on to the probe group folder in the navigation tree. Probes can be removed using the same technique.
- New probes can be created in the group using the New probe, New Virtual probe, or New Floating probe buttons.
Probe runtime states
The Probe object represents a TCP connection from
the gateway to a netprobe process on a remote
machine. It has a number of runtime states that can
be used if required for alerting which are set as a
runtime parameter "ConState"
:
Name | Meaning |
---|---|
Unknown
|
The gateway has just started or the Probe has just been added and the true state has not been established. |
Up
|
The gateway is connected to a netprobe process and has sent monitoring configuration. |
Down
|
The gateway contacted the configured machine but there is no process running on the specified port. |
Unreachable
|
The gateway could not make contact with the specified machine. |
Rejected
|
The gateway connected to the netprobe
process but this gateway was rejected. When in
this state additional runtime parameters
"RejectionReason" and
"RejectionMessage" will be
set to contain the message and reason for
rejection. |
Removed
|
The probe is set to this state for a short period of time when it is deleted or disabled from the setup. |
Unannounced
|
The gateway is waiting for the floating probe to announce itself and provide connection details. |
Suspended
|
The probe is set to this state if the probe to gateway connection is suspended |
WaitingForProbe
|
The gateway is waiting for the floating probe to connect |
Note: Runtime parameters of data-items can be viewed from the ActiveConsole front end or accessed by rules for alerting.
Configuration
probes
The probes top-level section contains the configuration details of all the probes gateway should connect to and monitor.
probes > probeGroup
A probe group allows grouping of probe definitions for ease of management in the GSE. A probe group can contain probe definitions or other probe groups.
Probe group settings
You can organise Gateway setup configurations into logical groups. Settings specified in a group are inherited by their children. Inherited settings are merged with settings specified in individual setups so that both are applied.
You can specify all options available to Probe on a Probe group, with the exception of: Group
, Description
, Display name
, and Licensing group
.
Additionally, the following settings are available:
Probe settings- Basic tab
These settings are found under the Basic tab for a normal (i.e. not Virtual or Floating) probe.
probes > probe > name
Specifies the name for the probe. This name must be unique among all other configured probes, to avoid ambiguity when the probe is referenced by other part of the gateway setup (e.g. managed entities).
The probe name is case-sensitive.
probes > probe > hostname
Specifies the hostname (or IP address) of the host that the Netprobe is running on.
probes > probe > port
The port that the Netprobe is listening on which the gateway should connect to.
7036
probes > probe > secure
Setting this flag indicates that the gateway should connect to the probe using secure protocol.
The probe must be have been started using the
-secure
flag. See
Secure Communications for more details.
false
probes > probe > timezone
The timezone in which the probe is running.
If this is not set, the probe is assumed to be running in the same timezone as the Gateway.
Currently this is primarily used by Publishing to convert the published date/times to UTC in ISO 8601 format.
Probe settings - Advanced tab
These settings are found under the Advanced tab for a normal (i.e. not Virtual or Floating) probe.
probes > probe > group
Optionally specifies a group name. See Groups for more details.
probes > probe > description
Optionally specifies a description. See Descriptions for more details.
probes > probe > displayName
Defines a name that is displayed by the Active Console in place of the actual name of the probe in the State Tree view. Other views such as Metrics view are not affected.
This name is used for display purposes only - the original name of the probe must be used for all references to the data view (e.g. in rules).
probes > probe > licensingGroup
Specifies a licensing group that the probe belongs to.
probes > probe > encodedPassword
A password encoded using the UNIX crypt command-line utility, which is then requested when users attempt to execute a Netprobe command.
The
password can only be configured on the Netprobe by
Gateway when the ALLOW_ENCODED_PASSWORD_DOWNLOAD
Netprobe environment variable has been set.
probes > probe > permissions
Permission settings controlling which RMS commands can be executed on this Netprobe.
probes > probe > permissions > RMSGET
Boolean value controlling the RMS GET command:
True
— command can be executedFalse
— command cannot be executed.
This permission is only applied when running the RMS GET command to obtain files from outside of the probe directory. No permission is required to use RMS GET to obtain a file that is located from inside the Netprobe directory.
false
probes > probe > permissions > RMSPUT
Boolean value controlling the RMS PUT command:
True
— command can be executedFalse
— command cannot be executed.
This permission is only applied when running the RMS PUT command to place files outside of the probe directory. No permission is required to use RMS PUT to place a file inside the Netprobe directory.
false
probes > probe > permissions > RMSEXEC
Boolean value controlling the RMS EXEC command:
True
— command can be executedFalse
— command cannot be executed.
false
probes > probe > trustedAPIHosts
Specifies an optional list of hostnames that are permitted to the API plug-in on this Netprobe.
If specified, hosts not in this list are rejected. See the API plug-in documentation for more details.
probes > probe > maxLogFileSize
The maximum file size of the Netprobe log file in megabytes. Must be an integer in the range 1-4096 inclusive.
Once this size is exceeded the current log file is archived and a new empty log is created.
probes > probe > processListCommand
A probe-wide setting that affects all PROCESSES plug-ins for legacy Netprobes.
This setting specifies a command to obtain process details for a legacy Netprobe.
ps -ef
(varies according to target
operating system)
probes > probe > wideProcessListCommand
A probe-wide setting which affects all PROCESSES plug-ins running on a Solaris Netprobe. This setting specifies the command to obtain the full process name for processes with names longer than 75 characters.
/usr/ucb/ps -axww
probes > probe > cacheProcessNames
A Boolean value specifying whether to cache process names on Linux.
Set to false
if process
names can change during execution.
true
probes > probe > heartbeatInterval
Similar to the Gateway operatingEnvironment > heartbeatInterval setting, this setting is sent down to the Netprobe and controls Netprobe behaviour.
The valid range for the heartbeat interval is 20-300 seconds inclusive.
70
probes > probe > connectWait
Similar to the gateway operatingEnvironment > connectWait setting, this setting is sent down to the Netprobe and controls Netprobe behaviour.
15
probes > probe > maxDatabaseConnections
The maximum number of connections a netprobe can make to any database.
For example, if managed
entity 1
belonging to probe 1
uses 3 SQL-TOOLKIT
plug-ins, 1 Sybase plug-in, and 1 Oracle plug-in, and
managed entity 2
belonging to probe 1
uses the same, there are 10 database connections in
total.
If probe is using the default value this means no more database connections could be made.
10
probes > probe > disableSelfAnnounce
A Boolean value specifying the behaviour of the Netprobe self-announcing feature.
If
false
, the Netprobe self-announces.
By default, Netprobes does not self-announce.
true
probes > probe > caseInsensitiveFilename
A probe-specific boolean indicating if filename matching in Unix based operating systems is case insensitive.
This setting affects the way probe detects files for monitoring. When checked, the latest among the case-insensitive filename matches is selected, regardless of the existence of a file that matches the exact case of the configured filename.
If set to true
(ticked), the processing of filenames for the following plugins are affected:
- FTM
- FKM
- Fidessa
- GL SLC
- GL SLC Relay
- GL SLE
- Sets SLC
- IX-MA
- GL Greffon
- Trading Technologies
false
probes > probe > commandTimeOut
This sets the maximum time (in seconds) the netprobe waits for a user command to finish before it resumes and continues sampling.
30
probes > probe > fkmLockFilePath
A probe-wide setting that affects all FKM plug-ins running on a Netprobe.
This sets the path where FKM plug-ins look for sampler and Netprobe lock files to check if FKM sampling on a sampler or an entire probe should be suspended.
The default path is the current working directory of the Netprobe. The setting does not apply to single lock files used to suspend FKM sampling on individual files.
None
probes > probe > maxToolkitProcesses
A probe-wide setting which affects all toolkit plug-ins running on a Netprobe. Each toolkit spawns a thread that executes the specified script. This setting controls the maximum number of toolkit threads that can execute at the same time.
Setting the value to 1 executes the toolkit threads one-by-one. This means that the Netprobe waits until the first toolkit script is finished or timed-out before executing the next script.
Setting the value to a value greater than 1 allows the Netprobe to execute a number of toolkit scripts in parallel depending on the value set by the user in this setting. If the user has X toolkits, and set Y as the max toolkit processes, Y toolkits would be executed in parallel, while (X - Y) toolkits would be executed one-by-one.
Minimum value is set to 1, while the maximum value is set to 32768.
1
probes > probe > restApiHttpPort
Insecure port where content is ingested by the REST API plug-in. This port is used by all REST API samplers running on the probe.
By default, the REST API plug-in listens only on this port. If you create a REST API sampler without configuring any listening port, then this default behaviour applies.
If you configure both insecure and secure ports, then the REST API sampler listens on both ports concurrently.
Caution: If you set the same value for both HTTP and HTTPS ports, then the Netprobe only starts the REST API HTTPS server. If the SSL certificate or key is invalid for the server, then the Netprobe does not start the HTTP server.
Note: Updating the port causes all REST API samplers on the probe to reload.
To disable the port, click the field, then click .
Mandatory: No
Default: 7136
probes > probe > restApiHttpsPort
Secure port where content is ingested by the REST API plug-in. This port is used by all REST API samplers running on the probe.
This setting requires an SSL certificate and SSL certificate key.
If you configure this port without configuring the insecure port, then the REST API sampler listens only on the secure port.
If you configure both insecure and secure ports, then the REST API sampler listens on both ports concurrently.
Caution: If you set the same value for both HTTP and HTTPS ports, then the Netprobe only starts the REST API HTTPS server. If the SSL certificate or key is invalid for the server, then the Netprobe does not start the HTTP server.
When you use HTTPS for the REST API plug-in, follow these guidelines:
- The common name must be the REST API server host name associated with the SSL certificate.
- As a best practice, use the same certificate authority (CA) as is used for other Netprobe certificates.
- The certificate created is used by the REST API plug-in as well as the Netprobe to communicate with the Gateway. The Netprobe only uses the certificate if it is in secure mode.
Note: Updating the port causes all REST API samplers on the probe to reload.
To disable the port, click the field, then click .
Note: If this option is set, then the REST API plug-in uses the SSL certificate and SSL certificate key as specified in the -ssl-certificate
and -ssl-certificate-key
command-line parameters, respectively. For more information, see Netprobe Command-line Options.
Mandatory: No
Default: 7137
probes > probe > pluginConnectionsToApplications > connectionFailureThreshold
A probe-wide setting that manages how a connection back off strategy for a probe's plugins behaves (if applicable).
This setting is a positive integer indicating the number of connection failures that will be allowed before going initiating a back off. The actual behaviour for the back off may vary, depending on the type of plugin. If this is not set or set to zero, back off is be disabled.
A connection failure back off strategy has been implemented for the following:
0
probes > probe > pluginConnectionsToApplications > connectionFailureStopTime
A probe-wide setting that manages how a connection back off strategy for a probe's plugins behaves (if applicable).
This setting is a positive integer indicating the number of seconds to back off from attempting new connections when the connection failure threshold has been reached. The actual behaviour for the back off may vary, depending on the type of plugin. If this is not set or set to zero, back off is be disabled.
0
probes > virtualProbe > name
Specifies the name for the virtual probe.
This name must be unique among all other configured probes, to avoid ambiguity when the probe is referenced by other part of the gateway setup (e.g. managed entities).
The probe name is case-sensitive.
Virtual probe settings - Advanced tab
These settings are found under the Advanced tab for a Virtual probe.
probes > virtualProbe > group
Optionally specifies a group name. See Groups for more details.
probes > virtualProbe > description
Optionally specifies a description. See Descriptions for more details.
probes > virtualProbe > displayName
Defines a name that is displayed by the Active Console in place of the actual name of the probe in the State Tree view. Other views such as Metrics view are not affected.
This name is used for display purposes only - the original name of the probe must be used for all references to the data view (e.g. in rules).
probes > floatingProbe > name
Specifies the name for the floating probe. This name must be unique among all other configured probes, to avoid ambiguity when the probe is referenced by other part of the gateway setup (e.g. managed entities). The probe name is case-sensitive.
probes > floatingProbe > timezone
The timezone in which the floating probe is running.
If this is not set, the probe is assumed to be running in the same timezone as the Gateway.
Currently this is primarily used by Publishing to convert the published date/times to UTC in ISO 8601 format.
Floating Probe settings - Advanced tab
These settings are found under the Advanced tab for a Floating probe.
probes > floatingProbe > group
Optionally specifies a group name. See Groups for more details.
probes > floatingProbe > description
Optionally specifies a description. See Descriptions for more details.
probes > floatingProbe > displayName
Defines a name that is displayed by the Active Console in place of the actual name of the probe in the State Tree view. Other views such as Metrics view are not affected. This name is used for display purposes only - the original name of the probe must be used for all references to the data view (e.g. in rules).
probes > floatingProbe > encodedPassword
A password encoded using the UNIX crypt
command-line utility, which is then requested when
users attempt to execute a Netprobe command. The
password can only be configured on the Netprobe by
gateway when the ALLOW_ENCODED_PASSWORD_DOWNLOAD
Netprobe environment variable has been set.
probes > floatingProbe > permissions
Permission settings controlling which RMS commands can be executed on this Netprobe.
probes > floatingProbe > permissions > RMSGET
Boolean value controlling the RMS GET command. True means that this command can be executed and false means it cannot.
This permission is only applied when running the RMS GET command to obtain files from outside of the probe directory. No permission is required to use RMS GET to obtain a file that is located from inside the netprobe directory.
probes > floatingProbe > permissions > RMSPUT
Boolean value controlling the RMS PUT command. True means that this command can be executed and false means it cannot.
This permission is only applied when running the RMS PUT command to place files outside of the probe directory. No permission is required to use RMS PUT to place a file inside the netprobe directory.
probes > floatingProbe > permissions > RMSEXEC
Boolean value controlling the RMS EXEC command. True means that this command can be executed and false means it cannot.
probes > floatingProbe > trustedAPIHosts
Specifies an optional list of hostnames which are permitted to the API plug-in on this Netprobe. If specified, hosts not in this list will be rejected. See the API plug-in documentation for more details.
probes > floatingProbe > maxLogFileSize
The maximum file size of the Netprobe log file in megabytes. This must be an integer in the range 1-4096 inclusive. Once this size is exceeded the current log file is archived and a new empty log is created.
probes > floatingProbe > processListCommand
A probe-wide setting which affects all PROCESSES plug-ins for legacy Netprobes. This setting specifies a command to obtain process details for a legacy Netprobe.
probes > floatingProbe > wideProcessListCommand
A probe-wide setting which affects all PROCESSES plug-ins running on a Solaris Netprobe. This setting specifies the command to obtain the full process name for processes with names longer than 75 characters.
probes > floatingProbe > cacheProcessNames
A Boolean value specifying whether to cache
process names on Linux. Set to false
if process names can
change during execution.
probes > floatingProbe > heartbeatInterval
Similar to the Gateway operatingEnvironment > heartbeatInterval setting, this setting is sent down to the Netprobe and controls Netprobe behaviour. The minimum is 20.
probes > floatingProbe > connectWait
Similar to the gateway operatingEnvironment > connectWait setting, this setting is sent down to the Netprobe and controls Netprobe behaviour.
probes > floatingProbe > maxDatabaseConnections
This sets the maximum amount of connections that a netprobe can make to any database.
For example, if managed
entity 1
belonging to probe 1
uses 3 SQL-TOOLKIT
plug-ins, 1 Sybase plug-in, and 1 Oracle plug-in, and
managed entity 2
belonging to probe 1
uses the same, there are 10 database connections in
total.
If probe is using the default value this means no more database connections could be made.
10
probes > floatingProbe > disableSelfAnnounce
A Boolean value specifying whether the Netprobe self-announcing feature should be disabled.
If false, the Netprobe self-announces.
By default, Netprobes does not self-announce.
true
probes > floatingProbe > casesensitiveFilename
A probe-specific boolean indicating if filename matching in Unix based operating systems is case insensitive.
This setting affects the way probe detects files for monitoring. When checked, the latest among the case-insensitive filename matches is selected, regardless of the existence of a file that matches the exact case of the configured filename.
If set to true
(ticked), the processing of filenames for the following plugins are affected:
- FTM
- FKM
- Fidessa
- GL SLC
- GL SLC Relay
- GL SLE
- Sets SLC
- IX-MA
- GL Greffon
- Trading Technologies
false
probes > floatingProbe > commandTimeOut
This sets the maximum time (in seconds) the netprobe waits for a user command to finish before it resumes and continues sampling.
30
probes > floatingProbe > fkmLockFilePath
A probe-wide setting that affects all FKM plug-ins running on a Netprobe.
This sets the path where FKM plug-ins look for sampler and Netprobe lock files to check if FKM sampling on a sampler or an entire probe should be suspended.
The default path is the current working directory of the Netprobe. The setting does not apply to single lock files used to suspend FKM sampling on individual files.
None
probes > floatingProbe > maxToolkitProcesses
A probe-wide setting which affects all toolkit plug-ins running on a Netprobe. Each toolkit spawns a thread that executes the specified script. This setting controls the maximum number of toolkit threads that can execute at the same time.
Setting the value to 1 executes the toolkit threads one-by-one. This means that the Netprobe waits until the first toolkit script is finished or timed-out before executing the next script.
Setting the value to a value greater than 1 allows the Netprobe to execute a number of toolkit scripts in parallel depending on the value set by the user in this setting. If the user has X toolkits, and set Y as the max toolkit processes, Y toolkits would be executed in parallel, while (X - Y) toolkits would be executed one-by-one.
Minimum value is set to 1, while the maximum value is set to 32768.
1
probes > floatingProbe > pluginConnectionsToApplications > connectionFailureThreshold
A probe-wide setting that manages how a connection back off strategy for a probe's plugins behaves (if applicable).
This setting is a positive integer indicating the number of connection failures that will be allowed before going initiating a back off. The actual behaviour for the back off may vary, depending on the type of plugin. If this is not set or set to zero, back off is be disabled.
A connection failure back off strategy has been implemented for the following:
0
probes > floatingProbe > pluginConnectionsToApplications > connectionFailureStopTime
A probe-wide setting that manages how a connection back off strategy for a probe's plugins behaves (if applicable).
This setting is a positive integer indicating the number of seconds to back off from attempting new connections when the connection failure threshold has been reached. The actual behaviour for the back off may vary, depending on the type of plugin. If this is not set or set to zero, back off is be disabled.
0