Status service reference

This topic contains reference information for the Agile Service Manager status service.

IBM Netcool Operations Insight integration

Matching Netcool/OMNIbus events to resources (on-prem and OCP)
Resources are matched to events based on their matchTokens property.
You can use a (comma-separated) list of Netcool/OMNIbus ObjectServer alerts.status field names to identify top-level resources.
If you do not supply a list, this defaults to "Node, NodeAlias".
If you do supply a list, all fields listed need to be from the alerts.status table.
For on-prem, set the environment variable NETCOOL_EVENT_NODE_FIELDS in the $ASM_HOME/etc/nasm-status.yml file.
For OCP, edit the status.nodeFields values. You can perform the following configuration via the operator:
spec:
 helmValuesASM:
  status.nodeFields: CustomField,Node,NodeAlias
Where the nodeFields are the fields of the ObjectServer's alerts.status table. If an added field is not one of the fields already listed in the Topology Gateway's ConfigMap 'field_filter.map', you must add it manually, and then restart the gateway.
Access scope:

The scoping functions allows for preferential matching of alerts. If similar resources and alerts in your environment exist in multiple different scopes, you can tag them with scope-specific information to allow a unique match to be made.

Such a scenario can occur (for example) under the following conditions:
  • The same applications are running in test, staging and production environments.
  • The same deployments are running in multiple namespaces in a single Kubernetes cluster.
  • The same components are running in cloned Openstack projects.
  • The same private IPs exist in multiple routing domains.
If an alert matches duplicate resources, a (case-insensitive) match of the alert scope against the resource scope is attempted.
Resource scope
Resources have an accessScopeTokens list property containing the following information:
  • The provider of the resource, as defined by the observer job
  • Optional additional scope supplied in the observer job’s Access Scope CSV string parameter
  • Scope explicitly added by some observers, such as the Kubernetes observer’s data_center and namespace_ job parameters
Alert scope
The alert fields to use for scope are configurable.
If adding any non-default alerts.status fields to the configuration, the gateway’s field_filter.map must be updated to pass that field through to the status service, and the gateway must be restarted.
  • The default fields of the alert used to look up resource matchTokens are resource.sourceId and resource.name.
  • You can use the NETCOOL_EVENT_SCOPE_FIELDS variable (Helm value is helmValuesAsm.status.scopeFields) deuplicate resources when there are multiple matches on matchTokens.
  • The values of these fields are compared with the resource property accessScopeTokens, with preferential matching based on case-insensitive comparison.

Additional information

For more information on the merge service and the creation of matchTokens, see the following topic: Defining rules

For more information on configuring the XML gateway, see the following section in the Netcool/OMNIbus documentation: https://www.ibm.com/support/knowledgecenter/en/SSSHTQ/omnibus/gateways/xmlintegration/wip/concept/xmlgw_intro.html

For additional gateway configuration information, see the following IBM developerWorks discussion: https://developer.ibm.com/answers/questions/256154/how-is-the-xml-message-bus-probe-and-gateway-confi.html

State and status derived from Netcool/OMNIbus

The status of resources is derived from individual fields of the event.
Table 1. General event state rules
Agile Service Manager State Netcool/OMNIbus event mapping
open Active event with Severity > 0
closed Deleted event
clear Closed event with Severity = 0
Table 2. Use of Netcool/OMNIbus alerts.status event fields by Agile Service Manager
alerts.status fields Use by Agile Service Manager
Agent Provider name for events generated from Agile Service Manager
AlertGroup Type of Agile Service Manager event
AsmStatusId Identifies the unique ID of the topology service status node. Used as a performance improvement to bypass resource lookup.
Class 45111 for Agile Service Manager events (should be mapped in alerts.conversions)
Customer TenantId for events generated from Agile Service Manager
EventId Status [type] for events generated from Agile Service Manager
Identifier Determines the type of status, populating the status field
LastOccurrence Used for the observedTime of open events
LastOccurrenceUSec Used for sub-second event clearing by the updated generic_clear automation, available in $ASM_HOME/integrations/omnibus/updated-generic-clear.sql
LocalPriObj Resource lookup
LocalRootObj Resource lookup
Manager Observer name for events generated from Agile Service Manager
Node Resource lookup
NodeAlias Resource lookup
ServerName Used to generate the unique eventId
ServerSerial Used to generate the unique eventId
Severity Severity 0 events represent a clear state
StateChange Used for the observedTime of clear events
Summary Used for the status description, shown in the UI
Type

Only Type 1 (Problem), Type 13 (Information) and Type 20 (ITMProblem) events are processed.

All others are ignored.
Table 3. Netcool/OMNIbus event data mapped onto Topology Service status
Topology Service status field Netcool/OMNIbus source
description alerts.status Summary
eventId <ServerName>/<ServerSerial>
eventManager "netcool"
observedTime

closed - time event received by observer

clear - alerts.status StateChange

open - alerts.status ObservedTime
severity alerts.status Severity
state

closed - deleted events

clear - Severity 0 events

open - none of the above
status alerts.status Identifier