Introduction to Netprobe

Introduction Copied

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

What is a Netprobe? Copied

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 Copied

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 Plugins and integrations page.

Samplers Copied

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 Copied

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 Copied

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

Netprobe features Copied

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

Netprobe setup Copied

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 Copied

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 Copied

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 Copied

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

Transport Layer Security Copied

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 Copied

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 Copied

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 Copied

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 Copied

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 Copied

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 Copied

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 Copied

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 Copied

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

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

Discovery executable Copied

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 Copied

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 Copied

The following example shows a raw Netprobe setup file:

<?xml version="1.0" encoding="ISO-8859-1"?>
<netprobe
 compatibility= 
 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= 
 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 Copied

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 Copied

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