How the spectrumgtw creates a NAS alarm in Spectrum

Products

DX Unified Infrastructure Management (Nimsoft / UIM) CA Unified Infrastructure Management SaaS (Nimsoft / UIM) Unified Infrastructure Management for Mainframe

Issue/Introduction

Up to CA Spectrum 10.1.1, the SNMPgtw (SNMP Gateway) probe was used to forward the CA UIM alarms to CA Spectrum. To forward the alarms, the SNMPgtw sends traps to CA Spectrum. An incoming trap is processed to generate an event on a model, and depending on the severity of the event it can generate an alarm.

CA Spectrum receives traps from CA UIM. CA Spectrum uses originating events based on AlertMap mapping to raise different event codes based on the event conditions/severity.
The CA Spectrum EventAdmin model receives events from the Southbound Gateway and transfer the event data to EventModel or device models depending on how the integration is configured. Alarms can be created from this event data.

The EventModel is a model type that represents a unique source of event data on the system that is managed by the EventAdmin application. A given EventAdmin model can contain one or many instantiated EventModels. Each event that is received through the Southbound Gateway contains information that uniquely identifies the source of that event. The EventAdmin model receives the event, finds the unique event source, and passes the event to the target destination.

The SNMP Gateway probe and SBGW / Southbound gateway are not recommended for alarms synchronization from UIM to DX NetOps Spectrum.

Broadcom recommends using the Spectrum Gateway (spectrumgtw) probe for alarm synchronization.

DX NetOps Spectrum v10.1.2 or higher

In Broadcom DX NetOps Spectrum 10.1.2 and higher, the spectrumgtw (Spectrum Gateway) probe is used to forward the CA UIM alarms to CA Spectrum. Actually the spectrumgtw supports bi-directional integration. Alarms can be forwarded in both directions. To forward the CA UIM (NAS) alarms to CA Spectrum, the spectrumgtw generates alarm events through RESTful.

The spectrumgtw uses the alarm API in the ems probe for alarms. So, in case the OC wasp is down for whatever reason, alarms will still flow from UIM to spectrum via the EMS. CA Spectrum receives alarms from the spectrumgtw probe, an originating event 0x06330071, is used in Spectrum to raise events based on event conditions. Then the CA Spectrum EventAdmin model receives the events and transfers the event data to Event model or device models depending on how the integration is configured.

Alarms sent from UIM to DX NetOps Spectrum are routed through the DX NetOps Spectrum Gateway Probe
nisapi-wasp package is used for inventory sync from UIM to DX NetOps Spectrum

Environment

CA Spectrum 10.2.3 or higher
CA UIM 8.51 or higher

Resolution

The following resolution is for an environment that still used the Southbound gateway (pre-Spectrum 10.1.1 or earlier).

Variable 8 (IP/HostName: {S 8}) takes precedence over variable 1 (Source: {S 1}).

The Southbound Gateway will transfer the event data to:

Device model (IP/HostName: {S 8}) when it is already modeled in Spectrum database (regardless of the value of Source: {S 1})
Event model (Source: {S 1}) when the device model (IP/HostName: {S 8}) is yet NOT modeled in Spectrum database

Based on this event message: 0x63300f1 for instance

UIM's net_connect Probe

UIM Alarm generated for net_connect_response_time with the following details:

----------------------------------------------------------------

{S 0x0012b4c}

Source: {S 1}

IP/HostName: {S 8}

Level: {S 101}

Suppression Key: {S 104}

Probe Name: {S 105}

Origin: {S 106}

UIM_Alarm_ID: {S 0x13344}

Alarm Source: {S 0x13342}

ChangeOwner: {S 0x13343}

ModifiedTime: {S 0x13345}

Trouble Ticket ID: {S 0x12022}

Trouble Shooter: {S 0x11f57}

User Tag 1: {S 0x13375}

User Tag 2: {S 0x13376}

Custom 1: {S 0x13377}

Custom 2: {S 0x13378}

Custom 3: {S 0x13379}

Custom 4: {S 0x1337a}

Custom 5: {S 0x1337b}

================================================================

Spectrum Event ID: {e}

Example 1: When the device model is NOT modeled in CA Spectrum

The following relevant entries below are from spectrumgtw.log file when the alarm is forwarded to CA Spectrum:

Dec 30 2018 18:31:39,810 [twScheduler_Worker-2] DEBUG SpectrumAlarmPush - Sending Event Alarm Request

Dec 30 2018 18:31:39,813 [twScheduler_Worker-2] DEBUG Connection - POST(ing): http://<hostname_1>:80/spectrum/restful/eventalarm with payload object:

<?xml version="1.0" encoding="UTF-8"?><event-alarm-request xmlns="http://www.ca.com/spectrum/restful/schema/request">

<create-events-list throttlesize="2500">

<create-event>

<varbind id="1">Device_A_<##.###.###.###></varbind>

<varbind id="0x0012b4c">Connection to 'Device_A_<##.###.###.###>' (ping) failed (profile: Device_A_<##.###.###.###>)</varbind>

<varbind id="104">Device_A_<##.###.###.###>/ping</varbind>

<varbind id="105">net_connect</varbind>

</create-event>

</create-events-list>

</event-alarm-request>

Note that the <varbind id="8"><##.###.###.###></varbind> is NOT modeled in Spectrum, hence the <varbind id="1">Device_A_<##.###.###.###></varbind> Event Model is created where the alarm is asserted on.

Example 2: When the device model is already modeled in Spectrum

The following relevant entries below are from spectrumgtw.log file when the alarm is forwarded to CA Spectrum:

Dec 30 2018 18:41:39,914 [twScheduler_Worker-6] DEBUG SpectrumAlarmPush - Sending Event Alarm Request

Dec 30 2018 18:41:39,917 [twScheduler_Worker-6] DEBUG Connection - POST(ing): http://<hostname_1>:80/spectrum/restful/eventalarm with payload object:

<?xml version="1.0" encoding="UTF-8"?><event-alarm-request xmlns="http://www.ca.com/spectrum/restful/schema/request">

<create-events-list throttlesize="2500">

<create-event>

<varbind id="1">Device_A_<##.###.###.###></varbind>

<varbind id="0x0012b4c">Connection to 'Device_A_<##.###.###.###>' (ping) failed (profile: Device_A_<##.###.###.###>)</varbind>

<varbind id="104">Device_A_<##.###.###.###>/ping</varbind>

<varbind id="105">net_connect</varbind>

</create-event>

</create-events-list>

</event-alarm-request>

Note that the <varbind id="8"><##.###.###.###></varbind> is already modeled in Spectrum, hence regardless of the value of <varbind id="1">Device_A_<##.###.###.###></varbind>, the alarm is asserted on the device model.

Additional Information

Recommended reading/references for integration using the spectrumgtw:

DX NetOps - 23.3 Integration with UIM

DX NetOps - 23.3 Multi-tenant support

spectrumgtw Advanced Configuration - Synchronize specific alarms