Idea Details

Spectrum/UIM (nimsoft) Integration

Last activity 05-31-2019 01:47 AM
Mark De Boer's profile image
02-12-2015 03:51 AM

Hi,

We've integrated UIM 8.1 with Spectrum 9.4.1.

Events are getting through, but alert mapping is almost non-existent. Lots of UIM alerts are mapped to the same event id and get the same alert (ex 0x6330002), while they are different alerts.

 

Also lots of UIM alerts get the 0x10801 event, Unknown alert. This is almost unworkable as we'll need to manually map the events to the correct alerts or even create new ones.

 

It would be most useful if there's a decent event handling and alert mapping available in Spectrum for UIM.

 

cheers

 

Mark


Comments

02-04-2016 05:41 AM

Hi Guys ,

 

We are also facing same issue as mentioned by Mark  "We've integrated UIM 8.1 with Spectrum 9.4.1.

Events are getting through, but alert mapping is almost non-existent. Lots of UIM alerts are mapped to the same event id and get the same alert  Major (ex 0x6330002),  Critical (0x6330003)while they are different alerts.

 

Also lots of UIM alerts get the 0x10801 event, Unknown alert. This is almost unworkable as we'll need to manually map the events to the correct alerts or even create new ones.

 

It would be most useful if there's a decent event handling and alert mapping available in Spectrum for UIM.

 

Thanks

HK

08-25-2015 02:20 PM

Suppression key in UIM traps only include the probe name and OID in case of snmptd probe. This is very basic and needs more information to be more specific so that different alarms can be created in Spectrum appropriately. For instance, multiple rules for different alarms can be written on a single varbind in UIM, but when the traps are sent to Spectrum, they all come up with the same suppression key and hence just create a single alarm, when in fact, they could be different alarms.

07-24-2015 01:49 PM

I ran into similar issues, and exactly as mentioned by mark.de.boer, found the current resolution to be configuring the suppression keys.  Suppression keys seem to be automatically created for processes monitoring, but not elsewhere.  If not separate traps for separate probes, perhaps at least a sane default suppression key. 

07-13-2015 09:04 AM

Replying on my own comment, seems that spectrum is using the supression key to differentiate between the alarms.

 

So if the supression key is different, he creates a new alarm. If the key is the same, he puts the UIM alarm as an event under the previously created alarm in Spectrum.

As you can see in the example above, the supression key for some alarms is empty. This explains why these alarms are all bundled as events under one and the same alarm in Spectrum, instead of creating a new alarm.

 

Can someone confirm this?

06-30-2015 02:59 AM

Hi Kiran,

 

Most of the problems are like this:

 

Spectrum Event ID: 0x06330042","NimsoftHostServer","0x6330042","10"

"","Feb 6, 2015 9:38:57 AM CET","simacrobo1","Unknown alert received from device simacrobo1 of type NimsoftHostServer. Device Time 0+00:00:00. (Trap type 1.3.6.1.4.1.4055.1.6.3)

Trap var bind data:

OID:  1.3.6.1.2.1.1.1.0  Value:  NimBUS/SNMP gateway

OID:  1.3.6.1.4.1.4055.1.1.0  Value:  0

OID:  1.3.6.1.4.1.4055.1.2.0  Value:  1.1.1.2

OID:  1.3.6.1.4.1.4055.1.3.0  Value:  Average (6 samples) paging is now 8824 KB/sec, which is above the error threshold (2000 KB/sec)

OID:  1.3.6.1.4.1.4055.1.5.0  Value:  cdm

OID:  1.3.6.1.4.1.4055.1.8.0  Value:  SimacHub

OID:  1.3.6.1.4.1.4055.1.9.0  Value:  10.250.10.120

OID:  1.3.6.1.4.1.4055.1.10.0  Value:  1423211975

OID:  1.3.6.1.4.1.4055.1.11.0  Value:  -3600

OID:  1.3.6.1.4.1.4055.1.12.0  Value:  BH54545752-26192

OID:  1.3.6.1.4.1.4055.1.13.0  Value:  SimacRobo1

OID:  1.3.6.1.4.1.4055.1.14.0  Value:  SimacPoc","NimsoftHostServer","0x10801","10"

"","Feb 6, 2015 9:38:57 AM CET","simacrobo1","Unknown alert received from device simacrobo1 of type NimsoftHostServer. Device Time 0+00:00:00. (Trap type 1.3.6.1.4.1.4055.1.6.3)

Trap var bind data:

OID:  1.3.6.1.2.1.1.1.0  Value:  NimBUS/SNMP gateway

OID:  1.3.6.1.4.1.4055.1.1.0  Value:  0

OID:  1.3.6.1.4.1.4055.1.2.0  Value:  1.1.1.3

OID:  1.3.6.1.4.1.4055.1.3.0  Value:  Average (3 samples) total cpu is now 100.00%, which is above the error threshold (90%)

OID:  1.3.6.1.4.1.4055.1.5.0  Value:  cdm

OID:  1.3.6.1.4.1.4055.1.8.0  Value:  SimacHub

OID:  1.3.6.1.4.1.4055.1.9.0  Value:  10.250.10.120

OID:  1.3.6.1.4.1.4055.1.10.0  Value:  1423211975

OID:  1.3.6.1.4.1.4055.1.11.0  Value:  -3600

OID:  1.3.6.1.4.1.4055.1.12.0  Value:  BH54545752-26189

OID:  1.3.6.1.4.1.4055.1.13.0  Value:  SimacRobo1

OID:  1.3.6.1.4.1.4055.1.14.0  Value:  SimacPoc","NimsoftHostServer","0x10801","10"

"Major","Feb 6, 2015 9:38:57 AM CET","simacrobo1","Fri 06 Feb, 2015 - 09:38:57 - NIMSOFT SNMP GATEWAY

 

Major CPU Alarm generated with the following details:

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

Average (3 samples) total cpu is now 100.00%, which is above the error threshold (90%)

Source: SimacRobo1

IP/HostName: 10.250.10.120

Level: Clear

Suppression Key:

Subsystem: NMS.Alarm.Host.CPU

Probe ID: cdm

Origin: SimacHub

Arrival Time (s): 1423211975

NIM-ID: BH54545752-26189

Domain: SimacPoc

 

 

 

As you can see, two alerts from UIM, one CPU and one disk threshold are mapped to one spectrum alert  ie Major CPU alarm. And this happens quite frequently. I had cases where SQL alerts were mapped to Spectrum Exchange alerts. So these alerts are lost because the operators will never see them.

 

I don't have the lab anymore we're in progress of building a new one. You can also check the original case 00021297: UIM Event handling in Spectrum.

 

Above extract of the spectrum events was with the old lab. We were using Spectrum 9.4.1 and UIM 8.1

 

kind regards

 

Mark

06-27-2015 12:35 PM

Hello Folks,

 

Thanks Kiran, Nagesh and Greg for the information.  I can see that using alarm severity as the simplest way to create an "integration" between CA UIM and CA Spectrum, but this is the worst possible integration when trying to manage correlation between multiple alarms and multiple probes.  I agree with Mark, Chris and Stuart that this approach is lacking at best.  In my experience, I think the ideal way to create an integration between Spectrum and UIM is at the probe level, with each probe having its own set of cause codes associated with each probe alarm types.  This would go a long way toward having the ability to correlate between cause codes and allow for a much tighter integration.  I understand that is is A LOT of work and if you happen to be a Spectrum and SNMP expert with a CA Spectrum developer id that you can create this type of integration, but ideally this would be something that CA would do and not leave it to the customer.

 

Thanks for your consideration.

 

Glenn E Burns

06-26-2015 08:54 PM

Hi Mark,


We went through another round of review on this along with the UIM technical team. We could not find a scenario where there would be an "Unknown Alert" per se.

Can I please request you send a screenshot of the "unknown alert" situation? That would help us move forward with the assessment..

 

Regards,

Kiran Diwakar

04-03-2015 02:12 AM

Hello Team,

 

Great feedback (and critique ) - as always, appreciate the vocal responses.

 

While Greg and Nagesh articulated some the things very well, let me try to give some different perspective as well - something more candid on how we took this path,


So 6-8 months back we had few sessions from John Smith (our GM) and Kathy, myself helping on that session. There we had discussed about our focus on UIM (fka Nimsoft) and that we would not invest in SPIM/VAIM as much (they would continue to be supported fully, just not enhanced significantly. There were a lot of concerns on the future of Systems Management through Spectrum, in lieu of this thought (on the community as well as 1:1 discussions with customers).

So the approach we took was to move around the priorities and fund the Spectrum-UIM integration for Servers and VMWare. We got this done in 2 quarters with the key goal of having RCA and FI, along with alarm suppression done, so that this is usable (atleast to a reasonable number of customers). Just to let you know, we do have many customers using this successfully in production. Having said that, we do expect that some of the more advanced users will find some gaps in the solution. We will iteratively improve the solution based on the feedback from customers. Rest assured, our internal sales and presales teams have me personally on the hook for this for some time as well - so we are on our toes for this.We are planning some improvements, I will make a post on that separately once we have some specifics lined up with effort estimates and timelines.

 

Just one thing - we might need more time for some things that the others. For example alarm severity vs. type for mapping. Unfortunately, UIM/Nimsoft does not give us that as types, they dont have that today. We are working with them to make that happen. Other things around simplification and things that we can handle within Spectrum, we will definitely prioritize. Hope this helps and please continue to call out your ideas/suggestions/critique. We listen!

 

Regards,

Kiran Diwakar

03-12-2015 12:50 PM

Related to the UIM to Spectrum integration, the Nimsoft MIB does not define the custom_1 - 5 fields and the snmpgtw does not list those as trap variables to send to Spectrum. The custom fields are commonly used for alarm enrichment and we need to have the ability to pass this information onto Spectrum.  Realize that based on the way that custom_1 - 5 are set we do a repost of all messages to a special message subject that the snmpgtw subscribes to for Spectrum integration.

03-12-2015 02:57 AM

Just as a side note because I've already logged a case about this (and they said to post an idea)

 

SNMP gateway probe is configured exactly as you described.

 

The latest reply in my case was exactly what you posted here as well. It's all good that certain traps are mapped as minor and critical alarms, but when for example both SQL and exchange traps are mapped to the same critical alert in Spectrum, you know it's not really practical. Let's be honest here, the SCOM connector for Microsoft has currently better event/alert mapping in Spectrum. At least when a SCOM exchange alert appears in Spectrum, I don't have to open the alert and click 'more' to see SQL events in there as well.

 

This is not to attack you guys, I'm sure you're doing your best to make the integration work. And maybe we as end users need more hands on experience as well.

 

cheers

 

Mark

03-11-2015 03:06 PM

I agree...   It is kind of ridiculous to have to ask for the integrations between your own products to come out working correctly.  If you spend the resources to create a brand new snmp gateway for one of the products in your suite of tools, it should, by default, work with the base snmp event handler of that suite of tools without having to stand on our heads to make it work!  You know all the events in UIM because you created them... is it really such a stretch to have that same intelligence included and mapped in Spectrum?

 

Or, were there other factors in the design discussions that made this approach make more sense which you can share with us?  I'm not totally opposed to changing how my implementation works if someone shows me a better way to do this.

 

I think it would still make sense to have this just work out of the box...

03-11-2015 01:34 PM

Sounds like getting the Spectrum profile added to the snmpgtw probe is part of what is being asked. Thanks for this info!

03-11-2015 01:07 PM

As a side note, a default Spectrum profile is going to be added to the snmpgtw probe and should hopefully be available in the next release of the probe.

03-11-2015 11:50 AM

This is not a bug. Spectrum is working within the constraints of both products. Nimsoft's snmpgtw probe generates traps based off of severities it does

  not map each individual alarm to a unique identifier.

 

If there are 0x10801 events being received please check the configuration of the snmpgtw probe and check that it is properly configured.

 

 

The 'Base Object Identifier (OID)' should be 1.3.6.1.4.1.4055.1 (make sure it does not have an extra .1 at the end).

 

Spectrum has Alert Mapping setup for 6 2-7, so the 'Trap Mapping' needs to be configured as shown above in order to be processed in Spectrum.

 

For example Nimsoft will send  1.3.6.1.4.1.4055.1.6.2 traps for all Minor Alarms,  1.3.6.1.4.1.4055.1.6.4 for all Critical Alarms, and 1.3.6.1.4.1.4055.1.6.7

  for All Cleared Alarms and thus why you will see a limited number of Event ID's in Spectrum.

 

Example of a Minor Alarm from Nimsoft

 

Mar 11, 2015 11:38:45 EDT 4375  host-z130 10.10.20.13 0x6330041 NimsoftHost Average (5 samples) memory usage is now 32%, which is above the warning threshold (20%) No Spectro1 (0x100000) Directly Managed

 

-Greg

03-11-2015 10:00 AM

This is pathetic. Do customers really have to ask you guys for every little thing that you should already be building into the product? Without proper alert mapping, the integration is pretty much useless. I would consider this a bug and not an idea.

03-11-2015 09:34 AM

Thanks for posting the idea for CA Spectrum. Your feedback is valuable to us.

 

The design we had for UIM Integration was based on the severity and not types of events. Also, the idea to avoid informational events was a conscious one since that would impact the load on processing within the integration.

 

So far we see only six votes on this idea. We would wait for more votes on this to consider further as this is moving away from the base design of the integration.

 

Thanks,

Nagesh

02-12-2015 10:33 AM

This sounds a lot like the way SystemEDGE events were handled by Spectrum originally.  There was a doc with a bunch of steps you had to do to map all the alerts yourself.  These are key integrations between the most heavily utilized products.  It would be great if CA could ship these products in such a way that these integrations just worked out of the box.

 

What would really be nice:  During the installations and upgrades, add a few more questions in the installers that ask which products you have and which ones will be integrated together.  Based on those inputs, the products get installed and configured with the proper integrations in place.  Most folks know all of this before they get to the installation phases of their projects.  Having these basic integrations just work out of the box would considerably accelerate our ROI.