Can Threshold Alerts in NetOps be sent to Spectrum to utilize Incident auto-generation with the Service-Now integration?

[Jim Farrell]

We have setup a group in NetOps portal that included polled interfaces for % utilization.  From this we have created a new Threshold and applied it to that new group that will trigger an alarm when the value exceeds 80% utilization and then resets when it drops below that level in a given duration within a given window.  We would like to use the Spectrum Service-Now integration to auto-generate an Incident when this occurs, but we need to determine how to send this over to Spectrum for that to take place, most likely using the SBGW integration already existing between Spectrum and the NetOps Portal.   

Or is there a way to perform Service-Now integration directly from the NetOps portal into Service-Now to auto-generate the incident from the Threshold event?   Any suggestion for the most efficient approach would be appreciated.   

We did look to do the monitoring of the router interfaces threshold directly in Spectrum, but it is just more efficient using the NetOps Portal as we are already polling the router WAN interfaces, so we already have the source from NetOps Performance Center.

Thank you in advance.

[Sandeep Kumar Mazwar]

Hi Jim,

You are right, the most efficient approach would be to integrate Spectrum and NetOps Portal, which have many other benefits apart from receiving NetOps Portal alerts in Spectrum.

Once you integrate Spectrum and NetOps Portal, each device in Spectrum would have a CAPC_Item_Id (which is same as Device ID in NetOps) that will sync Spectrum model to NetOps.

Now, when threshold alert is triggered in NetOps, that will appear on the associated Spectrum model and next you can use Spectrum alarm notifier to process the alarm for auto-ticket in SNOW.

That will also help to consolidate Spectrum/NetOps Portal alarms and ticket history.

Regards,

Sandeep Mazwar

[Catalin Farcasanu]

I would suggest also, in addition to what Sandeep suggested, to use SANM that should redirect the relevant alarms to an instance of AlarmNotifier that should be configured to open/close tickets to SNOW via RestAPI. It's the cleanest way possible. In the SetScript/ClearScript you can decide what information you're sending out to SNOW. The ticketId you receive you can update it on the alarm in the TroubleTicket attribute. 

You'd have to establish also if any CI synchronization is performed between Spectrum and SNOW, in order to decide on which CI the alarms get assigned. 

The Spectrum - Portal integration will handle the rest, in relation to alarms. 

[Jim Farrell]

So, for the NetOps to Spectrum integration, is it in fact the Southbound GW, or is there another integration that needs to exist between them?   Currently we only have Spectrum as a DataSource to NetOps Portal, and we have all of our routers only discovered in NetOps to utilize the Performance Center functions for polling WAN utilization, etc.   

As well, I looked at a few of the routers that are in the NetOps Portal device inventory, and the attribute for CAPC_ID is currently "0" so I take this to mean there is no proper integration between NetOps and Spectrum on our installation at this time.  

We are currently in process of upgrading our entire platform to the latest Broadcom releases for Spectrum, NetOps, NetFlow, VNA, Performance Center, etc.   As well as updating the main Database for the NetOps side of things, per Broadcom's recommendation.   Therefore, is it best to wait to take advantage of any newer integration functions between NetOps Portal and Spectrum with this newer release, or can we perform the integration with our current release levels (22.2.5.0.36 for Spectrum,  and 22.2.5.1037 for NetOps Portal) with minimal performance impact to the NetOps Portal side of things? 

Thank you in advance for any suggestions or recommendations.

 

[Catalin Farcasanu]

The OOTB integration between PC and Spectrum relies on PC to discover and maintain a list of devices that are discovered in both Spectrum and PM. This creates a 1 to 1 relation between devices/interfaces in Spectrum and those in PM (the population of Attribute CAPC_Item_id). The main benefit from this would be the contextual menu in OneClick console that allows direct selection for a device/interface in Spectrum to PM and on the PM side, the Alarms tab population on each device identified in PM, with the corresponding Spectrum alarms displayed directly in PM.

This OOTB integration assumes some configuration on both PM and Spectrum, in relation with the IP Domains that are managed in PM. There are also some restrictions that are mentioned in the documentation.

For Thresholding, indeed there are several ways of doing it:

• one relying on traps that Spectrum receives from PM (which you well observed as being a SBGW integration) - this will work even if the Spectrum is not configured to be integrated with PM or if the devices/interfaces are not entirely synched. 
• one relying Spectrum polling for events from PC polling via Rest-API integration.- this will only work if the PC-Spectrum integration is configured and devices are properly discovered and identified in both systems, restrictions considered. 

Having done them both, I can tell you that the second options is far a better one that the first one, with more benefits on the unified visualization on the PM side. 

If you wish to evade altogether the Spectrum-PM integration, in PM there's the option to trigger a Notification that will trigger a custom script. The script can be configured similarly to an AlarmNotifier instance to perform some sort of operations on the SNOW server. This will evade the Fault Management tool (Spectrum) and I think will create additional work on the NOC when trying to see if a specific Alarm in PM is treated as an incident in SNOW. 

I would use the OOTB integration between Spectrum and PM and rely on SANM filtering to decide what alarms create/close tickets in SNOW. I would also update Trouble Ticket ID(0x12022) on each alarm to match the SNOW IncidentID, with a link over in it that would jump to specified incident in SNOW. This way you see in the Fault Management tool (SPECTRUM) all you need to see about the current status of an alarm that is affecting the infrastructure and its corresponding created TroubleTickets (event if the condition comes from PM). This can be later followed in the SRM Reporting also.