Configuring the probe and gateway for a hybrid system

Edit online

The topology analytics probe and gateway containers are installed together with the other components. Once configured, resource information generated from IBM® Tivoli® Netcool®/OMNIbus events is displayed.

Before you begin

Probe and gateway configuration overview:

You stop the probe and gateway, and restart topology analytics, after each step:

You apply the $ASM_HOME/integrations/omnibus/*.sql files to the ObjectServer(s).
You configure your ObjectServer(s) in the $ASM_HOME/intergations/omnibus/omni.dat file (do not add the gateway to this file)
Optionally, you add ObjectServer usernames and passwords.
Optionally, you add an ObjectServer certificate for TLS.

This topic describes these probe and gateway configuration steps in more detail.

The topology analytics integration with an existing Netcool/OMNIbus system requires updates to the schema and automation (triggers) of that system. A sample configuration is provided, which a Netcool/OMNIbus administrator can reference to update their system.

The topology analytics integration also requires connectivity information about the Netcool/OMNIbus system, which the Netcool/OMNIbus administrator should provide.

Important: To configure the probe and gateway services, the topology analytics and Netcool/OMNIbus administrators should work together.

Remember: You configure the deployed probe and gateway services after installing the core topology analytics containers (including the probe and gateway containers), but before starting the topology analytics services.

About this task

The probe service receives status from topology analytics, and generates corresponding events in the Netcool/OMNIbus Event Viewer. These events are then fed back to topology analytics by the gateway service, which updates the topology analytics status by the status service with the eventId.

Procedure

Configure target ObjectServer schema and triggers

Perform the following updates to the target Netcool/OMNIbus ObjectServers.

Remember: Work with the Netcool/OMNIbus administrator to apply these changes.
1. Set the sub-second clearance mechanism.
  
  Sub-second clearance mechanism
  
  This mechanism allows the correct clearance of event updates that occur in the same second.
  
  A new field is added to the alerts.status schema, which works in conjunction with the core Netcool/OMNIbus field @LastOccurrence; @LastOccurrenceUSec.
  
  This mechanism is set via the topology analytics probe rules file and referred to in an updated generic clear trigger.
2. Define the topology analytics status events clearance.
  
  Specific clearance
  
  A new Netcool/OMNIbus SQL trigger handles the specific clearance of topology analytics status events.
Examples of these updates are provided with topology analytics and are located in the $ASM_HOME/integrations/omnibus directory.

asm-alert-fields.sql

Defines two new fields:

LastOccurrenceUSec

Allows sub-second clearing

AsmStatusId

Stores the topology service status ID

Without these fields, the probe and gateway services cannot connect.

asm-trigger.sql

Clears up events generated by topology analytics when resources are deleted.

These events will not be cleared if this trigger has not been applied.

updated-generic-clear.sql

Updates generic_clear automation to allow sub-second clearing.

Warning: The sample updates supplied with topology analytics should not be applied to an existing Netcool/OMNIbus deployment without a review by the Netcool/OMNIbusadministrator, as they overwrite core Netcool/OMNIbus functions, which may have been customized in an existing Netcool/OMNIbus system. In this case the Netcool/OMNIbus administrator may need to develop custom updates for this integration.
Hybrid scenario: If topology analytics is deployed on Red Hat® OpenShift® Container Platform and connecting to an existing Netcool/OMNIbus or IBM Netcool Operations Insight® system, you can obtain the sample SQL files via the following steps:
1. Log into the Red Hat OpenShift system.
2. Extract the asm-trigger.sql file:
  oc get configmap asm-noi-gateway-config -o jsonpath="{.data.asm-trigger\.sql}" > asm-trigger.sql
3. Extract the 'updated-generic-clear.sql file:
  oc get configmap asm-noi-gateway-config -o jsonpath="{.data.updated-generic-clear\.sql }" > updated-generic-clear.sql
4. Recreate asm-alert-fields.sql:
  echo -e "alter table alerts.status add column AsmStatusId varchar(64);\nalter table alerts.status add column LastOccurrenceUSec int;\ngo\n" > asm-alert-fields.sql

Enable or disable automatic ObjectServer schema changes

Note: The probe and gateway services can make modifications to the ObjectServer schema. Automatic schema modifications only work for simple Netcool/OMNIbus architectures, where the probe and gateway connect to the same pair in a single layer system. For more complex architectures, automatic modifications should be disabled.

Gateway: The gateway can automatically add the new AsmStatusId and LastOccurrenceUSec fields to the Netcool/OMNIbus alert.status table. These fields are required by the gateway.; For aggregation layer ObjectServers only, the gateway also adds a trigger to clear out events when resources are deleted in Agile Service Manager.
Probe: For collection layer ObjectServers only (that is, only if the probe connects to the collection layer because alternate sets of ObjectServer pairs have been defined), the probe adds the AsmStatusId and LastOccurrenceUSec fields.; For collection layer ObjectServers, the trigger is not applicable.

In order for Agile Service Manager to modify the Netcool/OMNIbus schema and create triggers, the Netcool/OMNIbus root password must be provided in a secret called <NOI Release Name>-omni-secret. If this violates Netcool/OMNIbus administrator policies, disable the automatic schema modification and ask the Netcool/OMNIbus administrator to make these changes manually.

To disable the automatic schema changes, set the deployPhase option in the application.yml file to none for both aggregation and collection layer ObjectServer pairs.

Example

global:
  hybrid:
    disabled: false
    objectserver:
      primary: 
         hostname: agg-pri.asm-bobbajo-svt.xyz.com
         port: 4101
      backup:  
         hostname: agg-bak.asm-bobbajo-svt.xyz.com
         port: 4201
      config:
        deployPhase: none
        ssl:
          virtualPairName: AGG_V
noi:
  objectserver:
    primary:
        hostname: coll-pri.asm-bobbajo-svt.xyz.com
        port: 4301
    backup:
        hostname: coll-bak.asm-bobbajo-svt.xyz.com
        port: 4401
    config:
      deployPhase: none
      ssl:
        virtualPairName: COL_V_1

Remember: Automatic schema changes are only suitable if Netcool/OMNIbus is deployed on a simple, single-layered architecture.