Idea Details

Integration CAPM - Spectrum: Add more variables in threshold events

Last activity 03-02-2018 10:34 AM
Christopher Ellefsen's profile image
03-03-2017 02:26 AM

We are a long term eHealth/Spectrum customer and is now in the process of moving to CAPM. What I have noticed is that the info being forwarded from CAPM towards Spectrum for events/alarms is lacking some variables compared to the eHealth-Spectrum integration. In particular Element Alias. 

 

We are currently forwarding alarms from both eHealth and CAPM towards Spectrum. For the example below we see an alarm on an interface to much errors.

 

From eHealth  we see these variables in the alarm details in Spectrum

 

Element Name - Switch-FastEthernet0/9

Element Alias - Switch-This-Has-Been-Modified-for-human-readable-purposes

 

From CAPM  we see only the ItemName variable in the alarm details in Spectrum that describes the item/element details. 

ItemName:FastEthernet0/9

 

We modify InterfaceNameAlias in CAPM PC in the same manner as we have done with eHealth. For the CAPM alarm in Spectrum the NOC has to do further digging into CAPM (follow the URL listed in Alarm Details in the alarm and log into CAPM) to get more information. As opposed to the eHealth alarm where the NOC has more "human readable information" available directly in the Alarm Details in Spectrum, and do not need to log into eHealth to decide further action. So CAPM adds an extra step for the NOC for all performance alarms. 

 

CAPM has the following variables for describing an Item (interface in this case):

- Interface Name

- Interface Name Alias

Description

- Ifalias

 

For Devices (Routers/Switches/Servers etc) CAPM has these variables:

- Name

- NameAlias

 

I would suggest to to enrich the CAPM-Spectrum integration with more information being passed from CAPM to Spectrum. The best would be to be able to have the opportunity in CAPM to choose  which variables to pass to Spectrum. Or as a minimum add the variables mentioned above to the integration so that they are visible in Spectrum (at least InterfaceNameAlias and NameAlias fields). 


Comments

03-02-2018 10:34 AM

I just came up against something along these lines.  My issue isn't with the data that's being passed, but with the event codes that are being used.  It appears that there are only three alarm types in Spectrum for events from PM (0x5c40010, 0x5c40011 and 0x5c40012 for minor, major and critical thresholds respectively).  Out of the box, there's no way to differentiate which particular profile or metric was involved with the threshold exception generated in PM.

 

I understand I can create custom events in Spectrum to parse the incoming alarms and such, and I do that for some things, but that isn't a solution that's terribly scalable or easy.  Ideally I'd love to have the option to specify a custom event code to be used for Spectrum synchronization on the Threshold Profile creation screen.  Once the profile has been created, PM would then create that event code in Spectrum at the next sync and we could then specify that code in the SANM Policy filter.  

07-21-2017 12:58 PM

This was so lacking we had to drop our plans for integration and go back to strait traps.

07-13-2017 11:23 AM

Thanks for the idea, Chris.  This is in line with our NetOps strategy to bring CAPM and Spectrum closer together to form a single network operations solution.  Do others have additional suggestions for info that should be passed in CAPM events that are forwarded to Spectrum?