Geneos ["Geneos"]
You are currently viewing an older version of the documentation. End of life for version 5.x.x is scheduled for 30 September 2025.
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.
["Geneos > Netprobe"]["User Guide"]

Introduction to Netprobe

Introduction

This topic introduces the general characteristics of the Netprobe in the Geneos architecture.

For more information on the top-level overview of Geneos, see the Geneos Product Overview.

What is a Netprobe?

A Netprobe is a lightweight monitoring agent which is deployed on every node you want to manage. As the active agent in the Geneos framework, there must be at least one Netprobe running in the environment.

Netprobes comprise the instrumentation layer of the Geneos solution, and are called probes in the Gateway Setup Editor.

Plugins

Plugins are run locally by the Netprobe to collect data. Sampled data and updates are passed from the Netprobe to the connected Gateway. The protocol used is designed to minimise network traffic. Netprobe can execute control-type functions upon receiving commands from the Gateway.

The Netprobe has a wide variety of plugins for you to choose from, depending on the platform, application, and statistics that you wish to monitor. To see the plugins supported by the Netprobe, see the list of plugins on the Geneos Home Page.

Samplers

A sampler is a specific configuration of a plugin, you can run multiple instances of a plugin with different configurations using samplers. Samplers are applied at the Managed Entities level.

Collection Agent

The Collection Agent is a Geneos component that uses dynamic plugins to do the following:

  • Discover what is available to monitor.
  • Collect metrics, logs, and metadata about the monitored applications.
  • Collect dimensional data.

For more information on Collection Agent, see Introduction to Collection Agent.

Supported platforms

For a complete list of supported platforms and other compatibilities, see the Geneos Compatibility Matrix.

Netprobe features

The Netprobe has certain key features that define how you use it within Geneos.

Netprobe setup

After a Netprobe is installed and running on a machine, the next step is to set it up to connect to a Gateway. Depending on the mode that the Netprobe is running in, as well as its relationship with a Gateway, you can set up a Netprobe by itself or from the Gateway.

For more information on the Netprobe setup settings, see Netprobe setup.

Command-line options

There are some command-line options that can be passed to the Netprobe installer for Windows platforms, or directly to the Netprobe binary.

For the full list of both installer and binary command-line options, see Netprobe Command-line Options.

Internal commands

Gateway commands are the primary method of interaction between the Gateway and connected users. Commands are invoked by users through a controlling process (such as Active Console) which prompts the Gateway to perform a given operation.

For more information on the internal commands that apply to the Netprobe, see Netprobe commands in Gateway Commands.

Security features

The following are options you can perform to keep the Netprobe secure:

Transport Layer Security

Geneos components can communicate using Transport Layer Security (TLS) as well as TCP/IP. This is configured using command line options for a listening gateway and using the xml setup file for Floating and Self-Announcing Netprobes. See Secure Communications.

Variables

Variables refer to settings on the Netprobe that relate to the system or platform it is running on.

  • On non-Windows platforms, these are set as environment variables in the shell from which the Netprobe is launched.
  • On Windows platforms, these are set in the registry.

For more information on applying Netprobe variables, see Netprobe variables.

Whitelisting

Where a whitelist is defined, the Netprobe can restrict the plugins and commands that can be run on it to a listed few.

Whitelists are defined in the Netprobe setup file.

For more information on whitelisting, see Netprobe Whitelist.

Netprobe types

Netprobes have different modes of operation, which are referred to as their type. It is useful to configure netprobes as different types to suite the application environment.

The virtual Netprobe is an exception, as it is a completely different type of Netprobe.

Normal Netprobe

In normal mode, the Netprobe remains passive, and only starts to monitor data when it receives a configuration from an incoming Gateway connection.

In this mode, every Netprobe needs to be separately specified in the Gateway setup file. In addition, the setup needs to be manually updated if the Netprobe is migrated to a different server.

Most client implementations begin with Netprobes running in normal mode.

Floating Netprobe

In floating mode, a Netprobe and Managed Entity are configured on the Gateway, but without connection details.

On starting, the Netprobe informs the Gateway of its host name and listen port. In turn, the Gateway connects to the Netprobe. This allows a Netprobe to automatically follow an application that migrates between servers.

For more information on using floating Netprobes, see Manage floating Netprobes.

Self-announcing Netprobe

With Self-Announcing Netprobes, no Netprobe or Managed Entity is configured on the Gateway. Instead, you configure the Netprobe setup file to specify both the Netprobe and Managed Entity names, along with one or more type names that correspond to types in the Gateway setup file. This configuration allows Netprobes to start up on any hosts and immediately be configured with default monitoring. In addition, the Netprobe can fetch its setup file from a remote source.

For more information on using Self-Announcing Netprobes, see Manage Self-Announcing Netprobes.

Virtual Netprobe

Virtual Netprobes do not require you to install or run a Netprobe. Instead, virtual Netprobes appear in the Gateway directory structure as regular Netprobes, but do not make a TCP connection to an external Netprobeprocess.

Virtual Netprobes are intended to be used for configuring Gateway plugins and for creating user-defined dataviews using Compute Engine.

Auto-discovery

Beginning Geneos 5.1, auto-discovery is available to Netprobes.

You can enable auto-discovery by invoking the -discovery command-line option.

Discovery executable

Auto-discovery works by running a discovery executable, which extracts JSON metadata from its environment. For example:

{
	"netprobe": {
		"discovered-properties": {
			"OS": "Linux",
			"Version": "RHEL 7.1 x64",
			"Location": "AMER",
			"DataCenter": "NY4",
			"Applications": "ION_Gateway, Pricing Engine",
			"ION_HOME": "/opt/ion",
			"Database": "MySQL",
			"MySQL_HOME": "/opt/mysql",
			"JAVA_HOME": "/usr/jre8"
		}
	}
}

You can tailor the executable to conform to your Geneos implementation. Nonetheless, a template is available in the Netprobe binary:

  • netprobe/templates/discovery.tmpl.sh for Linux and other platforms.
  • netprobe\templates\discovery.tmpl.bat for Windows.

JSON metadata

Using the JSON metadata, the executable updates the Netprobe setup file with the metadata through the use of macros.

If you specify a setup URL with the ? character, then the Netprobe appends the JSON metadata as query parameters and pulls the setup file from the URL specified.

Local Netprobe setup file

The following example shows a raw Netprobe setup file:

<?xml version="1.0" encoding="ISO-8859-1"?>
<netprobe
	compatibility="1"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:noNamespaceSchemaLocation="http://schema.itrsgroup.com/GA2011.2-110303/netprobe.xsd">
	<selfAnnounce>
				<enabled>true</enabled>
				<retryInterval>60</retryInterval>
				<requireReverseConnection>false</requireReverseConnection>
				<probeName>SAN-[[$HOSTNAME]]</probeName>
				<managedEntity>
						<name>me-san-centos6</name>
						<attributes>
								<attribute name="OS">[[$OS]]</attribute>
						</attributes>
						<types>
							<type>type</type>
						</types>
				</managedEntity>
				<gateways>
						<gateway>
								<hostname>192.168.101.52</hostname>
								<port>12912</port>
						</gateway>
				</gateways>
	</selfAnnounce>
</netprobe>

The following example shows a resolved Netprobe setup file:

<?xml version="1.0" encoding="ISO-8859-1"?>
<netprobe
	compatibility="1"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:noNamespaceSchemaLocation="http://schema.itrsgroup.com/GA2011.2-110303/netprobe.xsd">
	<selfAnnounce>
				<enabled>true</enabled>
				<retryInterval>60</retryInterval>
				<requireReverseConnection>false</requireReverseConnection>
				<probeName>SAN-ATSCENTOS63</probeName>
				<managedEntity>
						<name>me-san-centos6</name>
						<attributes>
								<attribute name="OS">Linux</attribute>
						</attributes>
						<types>
							<type>type</type>
						</types>
				</managedEntity>
				<gateways>
						<gateway>
								<hostname>192.168.101.52</hostname>
								<port>12912</port>
						</gateway>
				</gateways>
	</selfAnnounce>
</netprobe>

URL query parameters

Consider the following JSON metadata:

{
	"netprobe": {
		"discovered-properties": {
			"hostname": "ATSCENTOS64",
			"OS": "Linux"
		}
	}
}

The following example shows a URL from which the Netprobe attempts to retrieve as setup file using JSON metadata as query parameters:

http://localhost:8080?hostname=ATSCENTOS63?OS=Linux

Discovery debug

If you enable the DISCOVERY_DEBUG environment variable, then the NetprobeXML setup, both raw and resolved, is saved in the Netprobe log. For more information, see DISCOVERY_DEBUG in Netprobe variables.