Geneos ["Geneos"]
You are currently viewing an older version of the documentation. You can find the latest documentation here.
["Geneos > Gateway"]["Technical Reference"]

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:

  1. Select the Probes top-level section. If this section does not exist, double-click to create it.
  2. Select New Probe.
  3. 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.
  4. 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.
  5. Configure the probe Port. This should be the Netprobe listen port. If not specified, the Gateway connects using the default port.
  6. 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:

  1. Select the Probes top-level section. If this section does not exist, double-click to create it.
  2. Select New Virtual probe.
  3. 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:

  1. Select the Probes top-level section. If this section does not exist, double-click to create it.
  2. Select New Floating probe.
  3. 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:

  1. Right-click the Probes top-level section and select the New probeGroup menu option. This creates a new group section.
  2. In the Name box, name the probe group. This can be a descriptive name e.g. "Windows Probes".
  3. 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.
  4. 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.

Caution: Dynamic entities settings specified on a Probe group are not merged. Instead, settings specified on Probes take precedence.

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:

probes > probeGroup > name

Specifies the name of the probe group. This name is not read by gateway, and can be used for descriptive purposes.

Mandatory: Yes

probes > probe

The definition of a probe that gateway should connect to. The probe must have unique name among all other probe entries in the probes section.

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.

Mandatory: Yes

probes > probe > hostname

Specifies the hostname (or IP address) of the host that the Netprobe is running on.

Mandatory: Yes

probes > probe > port

The port that the Netprobe is listening on which the gateway should connect to.

Mandatory: No
Default: 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.

Mandatory: No
Default: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.

Mandatory: No
Default: Uses the same timezone as the Gateway.

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.

Mandatory: No
Default: None

probes > probe > description

Optionally specifies a description. See Descriptions for more details.

Mandatory: No
Default: None

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).

Mandatory: No
Default: (original name of the probe)

probes > probe > licensingGroup

Specifies a licensing group that the probe belongs to.

Mandatory: No

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.

Mandatory: No
Default: (no password - disables commands)

probes > probe > permissions

Permission settings controlling which RMS commands can be executed on this Netprobe.

Mandatory: No
Default: (no permissions)

probes > probe > permissions > RMSGET

Boolean value controlling the RMS GET command:

  • True — command can be executed
  • False — 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.

Mandatory: No
Default: false

probes > probe > permissions > RMSPUT

Boolean value controlling the RMS PUT command:

  • True — command can be executed
  • False — 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.

Mandatory: No
Default: false

probes > probe > permissions > RMSEXEC

Boolean value controlling the RMS EXEC command:

  • True — command can be executed
  • False — command cannot be executed.
Mandatory: No
Default: 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.

Mandatory: No
Default: (if unspecified, all hosts can connect to the API plug-in)

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.

Mandatory: No
Default: (uses value as set on Netprobe, typically 10 MB)

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.

Mandatory: No
Default: 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.

Mandatory: No
Default: /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.

Mandatory: No
Default: 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.

Mandatory: No
Default: 70

probes > probe > connectWait

Similar to the gateway operatingEnvironment > connectWait setting, this setting is sent down to the Netprobe and controls Netprobe behaviour.

Mandatory: No
Default: 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.

Mandatory: No
Default: 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.

Mandatory: No
Default: 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
Mandatory: No
Default: 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.

Mandatory: No
Default: 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.

Mandatory: No
Default: 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.

Mandatory: No
Default: 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:

Mandatory: No
Default: 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.

Mandatory: No
Default: 0

probes > probe > CyberArk application id

Name used to identify the CyberArk permissions for the Netprobe. This determines which passwords can be requested and must be configured in the CyberArk web interface.

Note: To enable Netprobes to use external passwords, you must additionally install the local agent on each probe host and configure your Gateway's Operating Environment settings to use the CyberArk Local CP as it's external provider. For more information about CyberArk, see CyberArk Local Credential Provider in Secure Passwords.

Mandatory: No

Default: ITRS-Geneos

probes > probe > CyberArk sdk path Unix

Path to the Application Password SDK installed on the Netprobe Unix host. The path must be fully specified and cannot embed any references to environment variables.

If no path is specified, the default CyberArk installation directory will be used. On a Unix system this is /opt/CARKaim/sdk/clipasswordsdk.

Mandatory: No

Default: None

probes > probe > CyberArk sdk path Windows

Path to the Application Password SDK installed on the Netprobe Windows host. The path must be fully specified and cannot embed any references to environment variables.

If no path is specified, the default CyberArk installation directory will be used. On a Windows system this is %ProgramFiles(x86)%\CyberArk\ApplicationPasswordSdk\clipasswordsdk.

Mandatory: No

Default: None

Dynamic Entities tab

Note: Beginning Geneos 5.1, the Collection Agent is included in the Netprobe binaries for Windows and generic Linux platforms.

probes > Dynamic Entities > Collection Agent > Start

If ticked, the Netprobe starts an instance of the Collection Agent as a Java process.

If you disable this option, then the Netprobe stops any running managed Collection Agent process. This applies whether or not the Collection Agent is running in detached mode.

Caution: If you are using a 5.2 Gateway, then the Netprobe running in normal or floating mode must also be version 5.2. Otherwise, the Collection Agent will not start.

Mandatory: No

probes > Dynamic Entities > Collection Agent > JVM args

Specifies additional JVM options for when the Collection Agent starts.

By default, the Collection Agent runs with the following JVM options:

  • -Xms512M — allocates the initial heap size.
  • -Xmx512M — allocates the maximum heap size.
  • -Dlogback.configurationFile=collection_agent/logback.xml — specifies the file path to the Logback configuration for for the Collection Agent logs.

If the Collection Agent cannot access logback.xml for any reason, then it writes to standard output (stdout) and standard error (stderr), and outputs the log file in the Netprobe's working directory.

Caution: This fallback behaviour is not supported on Windows.

Mandatory: No

probes > Dynamic Entities > Collection Agent > Health port

Specifies the Collection Agent port that the Netprobe communicates with for health checks.

For more information, see Health checks in Run Collection Agent with Netprobe.

By default, the port is 9136.

Mandatory: No

probes > Dynamic Entities > Collection Agent > Reporter port

Specifies the port the Netprobe should listen on to communicate with the Collection Agent using the TcpReporter.

By default, the port is 9137.

Mandatory: No

probes > Dynamic Entities > Collection Agent > Detached

If enabled, then the managed Collection Agent keeps running even if the Netprobe stops.

When detached mode is enabled, the managed Collection Agent only stops when you disable its start option.

For more information, see Detached mode in Run Collection Agent with Netprobe.

probes > Dynamic Entities > Dynamic entities > Mapping type

Specifies the mapping type used to generate Dynamic Entities for this probe.

Mandatory: No

Virtual probe settings - Basic tab

This setting is found under the Basic tab for a Virtual probe.

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.

Mandatory: Yes

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.

Mandatory: No
Default: (no group)

probes > virtualProbe > description

Optionally specifies a description. See Descriptions for more details.

Mandatory: No
Default: (no description)

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).

Mandatory: No
Default: (original name of the probe)

Floating Probe settings - Basic tab

This setting is found under the Basic tab for a Floating probe.

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.

Mandatory: Yes

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.

Mandatory: No
Default: Uses the same timezone as the Gateway.

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.

Mandatory: No
Default: (no group)

probes > floatingProbe > description

Optionally specifies a description. See Descriptions for more details.

Mandatory: No
Default: (no description)

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).

Mandatory: No
Default: (original name of the probe)

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.

Mandatory: No
Default: (no password - disables commands)

probes > floatingProbe > permissions

Permission settings controlling which RMS commands can be executed on this Netprobe.

Mandatory: No
Default: (no permissions)

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.

Mandatory: No
Default: false

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.

Mandatory: No
Default: false

probes > floatingProbe > permissions > RMSEXEC

Boolean value controlling the RMS EXEC command. True means that this command can be executed and false means it cannot.

Mandatory: No
Default: false

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.

Mandatory: No
Default: (if unspecified, all hosts can connect to the API plug-in)

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.

Mandatory: No
Default: (uses value as set on Netprobe, which is typically 10 MB)

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.

Mandatory: No
Default: ps -ef (varies according to target operating system)

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.

Mandatory: No
Default: /usr/ucb/ps -axww

probes > floatingProbe > cacheProcessNames

A Boolean value specifying whether to cache process names on Linux. Set to false if process names can change during execution.

Mandatory: No
Default: true

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.

Mandatory: No
Default: 70

probes > floatingProbe > connectWait

Similar to the gateway operatingEnvironment > connectWait setting, this setting is sent down to the Netprobe and controls Netprobe behaviour.

Mandatory: No
Default: 15

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.

Mandatory: No
Default: 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.

Mandatory: No
Default: 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
Mandatory: No
Default: 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.

Mandatory: No
Default: 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.

Mandatory: No
Default: 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.

Mandatory: No
Default: 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:

Mandatory: No
Default: 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.

Mandatory: No
Default: 0