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:

• Apply different sets of rules/actions/alerts/etc to the same data.
• Limit the data visible to certain users.
• Manage configuration better by specialising Gateways - for example, a data-gathering Gateway with sampler configuration exporting to a rule-application Gateways.
• To duplicate data to satellite sites where connectivity is poor.

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

• the sampler
• the sampler’s managed entity
• the sampler’s probe
• all the sampler’s dataviews

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

• the managed entity
• the managed entity’s probe
• all the managed entity’s samplers
• all the dataviews on all of the managed entity’s samplers

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

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 value of cells in dataviews that belong to samplers which match the shared dataset paths.
• Any computed cell values, and any additional Gateway created dataviews, or rows, columns, and headlines on dataviews that belong to samplers which match the shared dataset paths.
• Gateway Plugins, if they match the shared dataset paths.
• Virtual Probes, if they match the shared dataset paths.
• Self-Announced Probes, if they match the shared dataset paths.
• Runtime Parameters are shared (e.g. the connection state of probes).
• Configured Parameters are shared (e.g. host and port of probes).
• Managed Entity Attributes are shared.
• If importSeverity is set, the severity and active state of components are also shared.

The following items are not shared by the exporting Gateway:

• The Severity of cells and components (unless importSeverity is set).
• The Active state of cells and components (unless importSeverity is set).
• The Logged and Logging Success status.
• The Knowledge Base information of cells and components.
• The Snooze state of cells and components (unless importSeverityWithSnooze is set).
• The User Assignment state of cell and components (unless importSeverityWithUserAssignment is set).
• The configured environments of directory components are not shared.
• Database logging defined on an exporting Gateway will not be available on the importing Gateway.
• Rules defined on an exporting Gateway will not be available on the importing 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:

• Additional computed dataviews, rows, columns, and cells cannot be added. This is because there is no place to configure them.
• If importSeverity is set, then it is not possible to execute rules on the imported data.
• Unless importSeverityWithSnooze is set, Snooze commands will execute on the local copy of the imported data, not on the exporting Gateway.
• Unless importSeverityWithUserAssignment is set, User Assignment commands will execute on the local copy of the imported data, not on the exporting Gateway.
• Commands exported by samplers on imported probes (for example, FKM Clear this Trigger) are available on imported data only if the conditions described in Commands are met.
• Most other commands, including SampleNow and RMS commands, are not available on imported data.

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:

• The importing connection can be suspended like any other, but if it is all the imported probes for the connection will be marked as suspended.
• If a probe is suspended on the exporting Gateway, it will be marked as suspended on the imported Gateway but there will be no option to unsuspend it.
• The commands to suspend and unsuspend probes are replaced with commands to suspend and unsuspend the importing connection for imported probes.

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

• Importing Gatewaysconnect to the exporting Gateway using the useSslCertificate as authentication setting
• User connects to the importing Gateway using a Single Sign On user
• The command must be a delegated command.

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;

• “Top 20 Processes” defined by the Hardware sampler
• “Clear this Trigger” defined by the FKM sampler
• “Show Expression Diagnostic” defined by the Webmon sampler

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:

• Netprobe
• Gateway
• Client

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 does not support the authentication method proposed by the importing Gateway
• data permissions is set to data none permissions (and the Gateway is configured to support this)
• the user is deleted

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:

• Region = LDN
• App = A1

Attributes specified in importing configuration:

• Region = Imported
• Source = SourceX

Resulting attributes in imported managed entity:

• Region = Imported
• App = A1
• Source = SourceX

Allowing dynamic connection to the exporting gateway Copied

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

• Snooze Data plugin
• UserAssignment Data plugin
• Severity Data plugin

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:

• Gateway host.
• Port.
• Authentication details (if any).
• One or more named data sets that the exporting Gateway exposes.

Exported Data Copied

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