Gateway Sharing

Introduction Copied

Gatewaysharing can be used to share monitoring data from one Gateway to another. This is achieved by having one Gateway exporting a named subset of its monitoring data and another Gateway importing by requesting that subset by name.

This feature can be used to:

Simple Example Copied

Exporting Copied

Below is an example of an exported data set. It has name (in this case “CPU Sampler”) which is to be used by the importing Gateway. It also has a set of paths that are used to define the objects to be exported. In this case we are exporting all the samplers on the Gateway that have a PluginName of CPU.

Go to Navigation > Exported data in the Gateway Setup Editor.

Importing Copied

Below is an example of an imported connection. This defines the connection to an exporting Gateway. The configuration provides:

  1. The location of the exporting Gateway (host and port)
  2. A list of named data sets to import

Imported Data Sets Copied

Data sets are defined by one or more XPaths. These Xpaths can point to any number of probes, managed entities, or samplers in the exporting Gateway. Xpaths pointing to dataviews or individual cells are not supported. X paths that reference run-time values (for example severity or connection state) are not supported.

The matching components are shared by the exporting Gateway along with all their ancestors and descendants.

If an Xpath points to a specific sampler then the following are shared

If an Xpath points to a specific managed entity then the following are shared

The path expressions used to define the data sets exported by a Gateway cannot include any runtime information in their filters. Any path containing such filters will be ignored and an error similar to the one below will be generated.

Cannot use non-identifying predicate: [predicate]. Path will be ignored

More information about identifying predicates and non-identifying predicates can be found in XPaths - User Guide especially in the section on Predicates.

Conflict Resolution Copied

It is possible for the names of imported components to conflict with components already in the importing Gateway. The reason for this conflict is that Gateways require that all probes and all managed entities have unique names.

Conflicts are always deemed to apply to entire probes, even if only one of multiple managed entities caused the conflict. Netprobes and all their exported children are either imported in their entirety or not at all.

In the event of a conflict between a shared probe and a probe configured in the setup file of the importing Gateway, the setup file will always win and the shared probe will not be imported. This is true even when a conflict is introduced by a setup change, although a setup validation warning will be issued when saving the setup.

In the event of a conflict between shared probes imported on different connections, it is undefined which probe will win.

Note

If multiple connections are made to
the same Gateway and they import the same probe, this will be considered a conflict (unless the optional prefix setting is used to remove the conflict).

In the event of a conflict between a shared probe and a self-announced probe, it is undefined which probe will win.

An optional prefix can be applied to the names of all imported probes and managed entities to help resolve conflicts.

When a conflict is resolved, either by configuration changes on the importing or exporting Gateway, the probe will be imported once more.

What is shared Copied

By default, only raw data values are shared, the philosophy being that the importing Gateway will be able to treat the imported probes as if they were normal netprobes, applying its own rules, handle its own logging, actions, alerts, snoozing, active state, user-assignment, etc.

The following items are shared by the exporting Gateway:

The following items are not shared by the exporting Gateway:

Limitations of Shared Data Copied

For the most part, shared data can be treated exactly as if it were from a normal Netprobe.

However, there are some important limitations:

Hot-Standby Copied

The importing Gateway, when configured as a Hot Standby pair, will behave the same as any other Gateway configured in Hot Standby pair. When the primary importing Gateway goes down, the secondary will take over and re-establish the connection with the exporting Gateways, so the import will work seamlessly in a Hot Standby configuration.

The configuration for importing Gateways (as shown earlier in this section) allows an importing connection to be configured with a primary and secondary Gateway.

In order to import from an exporting Gateway in Hot Standby mode, the user can specify the secondary Gatewayconnection details (host and port). If the port is not specified, it defaults to the default Gateway listen port (7039) for both primary and secondary exporting Gateway. The importing Gateway will always import data from the currently active Gateway in the Hot Standby pair. Every time a failover happens, a new connection will be established with the exporting Gateway which takes over.

Data Quality Copied

Because imported probes share the same connection they behave differently with regards to data-quality in the following ways:

Commands Copied

Exporting Gateways can export commands as well as data to the importing Gateway. When the user executes an imported command on the importing Gateway, the importing Gateway delegates the execution of the command to the exporting Gateway. The exporting Gateway executes the command and returns the results to the importing Gateway, which in turn returns the results to the user via the Active Console or Web Server.

Hence these commands are referred to as “delegated commands”. In order for an exporting Gateway to accept a command from an importing Gateway, three things need to be true

Service Connection Copied

In order for the exporting Gateway to allow command delegation, a secure connection needs to be established between the exporting and importing Gateway. The exporting Gateway requires the user to authenticate themselves using an SSL certificate. This ensures that passwords are not being stored in the importing Gateway setup and that the connection is a secure connection.

If the importing Gateway uses another form of connection, then delegated commands will be rejected by the exporting Gateway. These commands will not be presented to the user if they are running a GA4.5.0 or newer Active Console or Web Server.

SSO Users Copied

In order for the exporting gateway to allow command delegation, the user must authenticate themselves using SSO. If the user connects to the importing Gateway using system login or password login, then no imported commands will be shown in Active Console or Web Dashboard.

Delegatable Commands Copied

There are multiple types of commands in the Gateway, below is a list of the commands that can be delegated.

Rule Commands Copied

This set of commands includes the Show Rule command. This set of commands is only delegated if the importing Gateway has imported severity data. If the severity data is not imported, then this set of commands will be run locally.

Snooze Commands Copied

This is the set of commands that allow a user to snooze a cell, as well as the Unsnooze command and the Snooze Info command. Snooze commands are only delegated if the importing Gateway has imported snooze data. If the snooze data is not imported, then this set of commands will be run locally.

The following is an example of what will happen if the snooze command is not delegated:

If a CPU sampler has a rule that turns the cell red at 90% on the exporting Gateway and a different rule that turns the cell red at 70% on the importing Gateway (which is not importing severity or snooze information). A value of over 90% would result in the cell on the exporting Gateway turning red and the cell on the importing Gateway turning red. Snoozing the cell on the importing Gateway will not snooze the cell on the exporting Gateway. Likewise, snoozing the cell on the exporting Gateway will not snooze the cell on the importing Gateway.

User Assignment Commands Copied

This is the set of commands that allow a user to assign a cell to a user, as well as the Unassign command and the User Assignment Info command. User Assignment commands are only delegated if the importing Gateway has imported user assignment data. If user assignment data is not imported, these commands will be run locally.

Probe Commands Copied

This is a set of commands defined on probes and managed entities that are executed on the Netprobe. This set includes the View Netprobe log command.

Sampler Commands Copied

This is the set of commands that are defined by the probe samplers. Examples of these commands are;

These commands are automatically exported along with the data.

This set of commands does not include commands that are defined by Gateway samplers.

This set of commands does include the commands that are generated from the probes environment. An example of generated commands are the commands that the JMX sampler builds to allow access to the mbean management operations.

Netprobe User Commands Copied

There are 3 run locations for User commands:

Only the user commands that run on the Netprobe are exported. These like “Sampler Commands” are automatically exported along with the data.

Gateway and Client user commands can be shared by sharing include files. In the case of Gateway user commands, the scripts run will need to be available on the importing Gateway server, as the commands will be run on the importing Gateway. They will not be delegated to the exporting Gateway.

Further restrictions for Snooze and User Assignment on Probe and Managed Entity targets Copied

A snooze or user assignment command that alters state will not be executed by the exporting Gateway and will instead return an error. If this were to be executed then the effect on such a snooze or user assignment could have implications outside of the exported dataset.

Authentication Copied

By default an importing Gateway will use a non-authenticated connection to import data from an exporting Gateway. This will suffice as long as the exporting Gateway does not enforce authentication. However, even if the exporting Gateway does not enforce authentication, it will not allow command delegation on a non-authenticated connection.

To import data from a Gateway that does enforce authentication, on the importing Gateway the import data configuration must specify authentication details in the form of a username and password which will be used to connect to the exporting Gateway. It is recommended that an SSL certificate is used to authenticate the user. It is possible to use a user name and password but this disables the exporting of any commands.

The user login credentials used by the importing Gateway are done by populating the optional authentication section in the Advanced tab of the imported data connection which intends to export from that particular export Gateway.

User Set-up Copied

On the exporting side, this username must be set up as a user in the authentication section. The user must be allowed to connect and receive Gateway directory data. The example below shows the user setup. A summary view has been shown as the user name and description are configured in the basic tab, while the ssl settings are configured in the advanced tab.

For example:

Restrictions Copied

System and PAO authentication is not supported as the importing Gateway has no mechanism for such. Effectively to provide secure authentication the user would need to have a password specified.

In all other respects, a user configuration that facilitates a connection from a direct downstream component such as Active Console 2 to view data should allow an importing Gateway to connect and import data. There is no way to mark a user as only usable for Gateway Sharing purposes.

Storing Passwords Copied

On the importing side, the password can be stored in the Gateway setup file as plain text or encrypted using either Geneos legacy encryption (std) or AES 256-bit.

Authentication Failure Copied

In the case of authentication failure a “login failure” message will be written to the log of both importing and exporting Gateways. The importing Gateway will not be able to import the specified data sets from particular exporting Gateway.

When this occurs the connection status of the connection will be set to rejected in the Gateway Imported data plugin (if configured).

If the user credentials used by an importing Gateway are changed (password, password type) on the exporting Gateway, the Gateway will drop all importing connections that use those credentials. This will be reported in the exporting and importing Gateway logs. The importing Gateway will re-establish the connection if its connection details are still valid, otherwise the user will have to amend the details in the importing Gateway in order to reconnect.

The exporting Gateway will also drop the connection to an importing Gateway if one of the following changes occurs to the user used by the importing Gateway:

The exporting Gateway will also drop the connection to an importing Gateway if the authentication -> authenticateUsers flag has changed from enabled to disabled state. This would cause any earlier rejected connections to drop, so that the importing Gateway can reconnect.

Restricted Access Copied

Each dataset can be restricted to a set of users who can view them. When a connection is made a check is made to see if access is restricted. If it is then the user is checked against the set of allowed users. If the user does not have access to all of the required datasets then the connection is dropped.

The connection will also be dropped if the set-up changes such that the connected user no longer has access to any one of the requested datasets.

Sampler Visibility Settings and Dataview Additions Copied

Dataview Additions Copied

It is possible to add rows, columns and headlines to a dataviews. These additions are performed on the exporting Gateway. The cells created and the values they contain will be visible on both the importing and the exporting Gateway.

Sampler Visibility Settings Copied

It is possible to set visibility settings on a sampler. The following sections describe how those settings interact with GatewaySharing.

Is Visible Copied

If the “Is Visible” setting is set to false then sampler data is not published to any clients. Thus it will be present in the exporting Gateway but will not be present in the importing Gateway.

Publish Copied

If the “Publish” setting is set to false then sampler data is not published to the exporting Gateway. Thus it will not be present in the exporting or the importing Gateway.

Hide Columns & Hide Rows Copied

These settings hide the rows and columns before the data is published by the data provider. Thus neither the exporting Gateway nor the importing Gateway will see the hidden columns and rows.

Import state information Copied

Import severity Copied

If importSeverity is set to true on a connection, the Gateway will import the severity and active state of shared data from the exporting Gateway, and will disable local rule evaluation on shared data from the exporting Gateway so that the imported severity and active state cannot be overridden. Import-severity cells may still be referenced by rules targeting other cells.

The ShowRules command will be delegated to the exporting Gateway. See Gateway Sharing > Commands.

Import severity with snooze Copied

If importSeverityWithSnooze is set to true on a connection, the Gateway imports the snoozed state of shared data from the exporting Gateway. Snooze commands that are run on imported data items are delegated to the exporting Gateway.

Import severity with user assignment Copied

If importSeverityWithUserAssignment is set to true on a connection, the Gateway imports the userAssigned state of shared data from the exporting Gateway. User assignment commands that are run on imported data items are delegated to the exporting Gateway.

Attributes Copied

It’s possible to configure an importing Gateway to apply specific attribute values to the managed entities that it imports. These can be specified on a per-connection basis such that the respective attribute values are applied to managed entities imported through each connection.

In the case where an imported managed entity has any of these attributes specified originally, then the original values would be overridden by the values specified in the importing configuration.

E.g.:

Original attributes in imported managed entity:

Attributes specified in importing configuration:

Resulting attributes in imported managed entity:

Allowing dynamic connection to the exporting gateway Copied

The ActiveConsole supports a “Connect to Source Gateway” command for the following Gateway plugins:

This command allows a user to connect to the exporting Gateway without having its connection parmeters configured in their Active Console. By default, the details needed to make this dynamic connection are provided by the exporting Gateway, as run-time parameters of the sampler.

In some cases, the hostname and port provided by default, which are determined by the configuration of the exporting Gateway, are not useable by the Active Console. For example, the hostname might use an alias not known to the Active Console. To allow dynamic connections in these cases, use the configuration settings for importedData > connection > dynamicConnection.

Configuration Copied

Imported Data Copied

This section details of all connections to the exporting Gateways.

A Connection entry is defined per exporting Gateway. Each entry details:

Setting Option Description Mandatory Default
Name Name given to the importing connection with the exporting Gateway. Yes
Primary Gateway host and port for the primary exporting Gateway (in case the exporting Gateway is configured in Hot Standby mode) or the standalone exporting Gateway that this connection connects to. Yes
Hostname Host name for a primary (or standalone) exporting Gateway to establish connection with. Yes
Port

Port for a primary (or standalone) exporting Gateway to establish connection with.

No 7039
Secondary

Gateway host and port for a secondary exporting Gateway, in case the exporting Gateway is configured in Hot Standby mode.

When connecting to an exporting Gateway configured in Stand Alone mode, this setting should not be configured. In case of Hot Standby mode, when either primary or secondary exporting Gateway goes down, the connection is re-established with the other exporting Gateway when it takes over.

No
Hostname

Host name for a secondary exporting Gateway to establish connection with.

No
Port

Port for a secondary exporting Gateway to establish connection with.

No 7039
Secure Setting this flag indicates that the Gateway should connect to the exporting Gateway using secure protocol. If the flag is set then the port selected should be the secure port of the exporting Gateway. See Secure Communications for more details.
Data Sets

Named subsets of monitoring data to import, as configured on the exporting Gateway. If more than one dataset is specified the union of all datasets will be imported.

Yes
Authentication

Username and password that is needed to establish an authenticated connection to the exporting Gateway. This is necessary where the exporting Gateway enforces authentication. If connecting to an exporting Gateway that does not enforce authentication then this can be left unset.

No
Username

Username to be used for an authentication connection.

Password

Password to be used for an authentication connection. This can be stored as plain text or encrypted using either Geneos legacy encryption (std) or AES 256-bit.

See Secure Passwords.

UseSSLCertificate

Setting this option indicates that the Gateway's SSL Certificate will be used to authenticate the connection.

Prefix

An optional name that can be prefixed to the imported probes and managed entities names, to resolve any name conflict with existing probes/managed entities or those imported from other exporting Gateway connection. If this name is mis-specified then an error will be raised by the Gateway and the connection will be ignored.

No
Attributes Attributes to be applied to all managed entities imported through this connection. See Attributes. No No attributes specified
Import

State information that can be imported from the sharing Gateway.

No
Import Severity

Import the severity and active state of cells and components from the sharing Gateway. Enabling this will disable local rule evaluation on the imported data. The ShowRules command will be delegated to the sharing Gateway.

No Not imported
Import Severity with Snooze

Import the snoozed state of cells and components from the sharing Gateway. Snooze commands that are run on imported data items will be delegated to the sharing Gateway.

No false
Import Severity with User Assignment

Import the userAssigned state of cells and components from the sharing Gateway. User assignment commands that are run on imported data items will be delegated to the sharing Gateway.

No false
Dynamic Connection Controls the parameters supplied for Active Console to use when executing the "Connect to Source Gateway" command. No Use exported parameters
Use Exported Parameters

Default option, supplies the hostname and port published by the exporting Gateway.

Use Importing Connection Supplies the same connection parameters to Active Console as are configured for this importing connection.
Override Supplies explicit parameters for Active Console to use when connecting to the exporting Gateway.
Override > Primary > Hostname Host name used by Active Console when connecting to the primary (or standalone) exporting Gateway. Yes
Override > Primary > Port Port used by Active Console when connecting to the primary (or standalone) exporting Gateway. No 7039
Override > Secondary

Caution: Only use these settings if the exporting Gateway is configured in Hot Standby mode.

No
Override > Secondary > Hostname

Host name used by Active Console when connecting to the secondary exporting Gateway.

Caution: Only use these settings if the exporting Gateway is configured in Hot Standby mode.

No
Override > Secondary > Port

Port used by Active Console when connecting to the secondary exporting Gateway.

Caution: Only use these settings if the exporting Gateway is configured in Hot Standby mode.

No 7039

Exported Data Copied

This section is all the named subsets of monitoring data that the exporting Gateway exposes.

Setting Description Mandatory
dataSet

Named subset of monitoring data that the exporting Gateway exposes. Each data set can have multiple paths.

No
dataSet > name

Name of the data set that the exporting Gateway is exposing. This name will be used by the importing Gateway to request shared data.

Yes
dataSet > paths

List of paths to data that the Gateway will expose. The Gateway will export any sampler, Gateway Plugin, Virtual Probe or Self-Announcing Netprobethat matches one of the specified paths.

Yes
dataSet > restrictedAccessexportedData > dataSet > restrictedAccess

List of user names that are allowed to access the dataset.

Each dataset can be restricted to a set of users who can view them. When a connection is made a check is made to see if access is restricted. If it is then the user is checked against the set of allowed users. If the user does not have access to all of the required datasets then the connection is dropped.

The connection is also dropped if the setup changes such that the connected user no longer has access to any one of the requested datasets.

["Geneos"] ["Geneos > Gateway"] ["User Guide"]

Was this topic helpful?