SOI Alarm/Event Enrichment with CA CMDB

[ricmi12]

Hi guys, I am a little lost, we have SOI receiving alarms from Spectrum and UIM connectors and what we want to do is enrich these alarms we receive with some CA CMDB fields, how could I do this?

Thanks

[Michael Boehm]

Hi Miguel,

 

what exactly do you want to enrich?

Is this information related to the CI that an Alert is attached to - e,g, static information that can be added on CI level?  Or is it something that has to be checked on arrival of an Alert?

Did you implement the CMDB Connector to get information about the CIs from the CMDB?

 

In general when you want to enrich an Alert with "external" information, you have to define an Event Policy with the enrich option, specifiy the DB connection and search criteria, and map the fields.

Michael

[ricmi12]

Hi Michael,

 

What I want to do is enrich the alarm received from spectrum with some fields like, Location, City, Contact Name etc..

Actually it worked  good using java enrichment in a CMDB template with the select query as a specific case (specific device name), but I cant find a way to  make the select query work  in a dynamic way I mean with a variable, I cant find the link between spectrum source hostname and CMDB name of the CI, I figured it out that could work with federated asset id which is the same that Spectrum Element ID but it didn't work, I'm attaching a screen with the select query options I used.

 

Thank you in advance

 

Regards

[Michael Boehm]

Hi Miguel,

 

the challenge you are facing is:

The Alarm only has the information to be attached to a specific CI, which is identified by the Spectrum Model_Handle.  The Alarm does not have any further information about this CI, thus you do not have a direct link to a name of this CI.
You would have to first lookup the name of this CI in the SOI DB, and then pick up the details such as Location, City, Contact, etc.

 

When using the CMDB Connector, the information you are looking for can be added to CIs generated by this connector.

These CIs will be correlated to the CIs coming via the Spectrum Connector.

Then you have to define a query which is going to the SOI DB and finding this information based on the Spectrum Model_Handle (which is a nested query).

To run this query for every incoming Alert creates a lot of overhead on the system (Performance impact).

 

What is the reason to have this information directly attached to the Alert?

The information is static to the underlying CI, and thus it does not have to be recreated for every Alert.

Is it not sufficient to click on an Alert and then see the CI information in the Component Detail pane of the console?

In this case you automatically see all the information about the CI that was reconciled from all underlying Connectors (e.g. also the CMDB information).

The only customization you would need in this case is to fill the required fields when the CI is created via the CMDB Connector (connector policy update).

 

Regards,

Michael

[ricmi12]

Hi Michael I got your Idea,sounds good,  it could work but I have a question, you said that if we want to see additional CI attributes its enough to click the alarm and see component detail pane, and I suppose we should see into USM Notebook, but how client personalized attributes like: company serial number, company area, device owner etc.. could be reflected in this area? it suppose that if we load this info into the SDM CMDB will be synchronized with SOI? should we do something additional ?

Thank you in advance

Kind Regards

[Michael Boehm]

Hi Miguel,

the answer to your question depends on the place where you store this additional information.

There are several fields in the CMDB which are taken over automatically by the CMDB Connector.

If some of the information is in fields that are not assigned by default but which are read during the DB load, you can adopt the Connector Policy to assign these fields to any of the related SOI attributes
And if this information is in fields which are not read by the connector, you can still adopt the Connector policy with an SQL enrichment (similar to the one you tried in the Event Policy) and assign the values to SOI attributes.

The advantage would be that this would only be executed once at startup of the connector, because the information is static to the CIs - it would avoid having to query for the info for every Alert again.

 

Regards

Michael

[ricmi12]

Thanks Michael, Yes actually we filled some fields in CMDB that are reflected automatically into the USM Properties and as you say there are some fields that are read during the DB load and we want it to be displayed in the usm properties panel, when you say "you can adopt the Connector Policy to assign these fields to any of the related SOI attributes" what do you mean, ? how can I do this? sorry about silly question

Thank you in advance

 

Kind regards

[Michael Boehm]

Hi Miguel,

there are never silly questions, only stupid answers.

 

To figure out which properties the Connector code is reading, you can set the Connector Framework into debug mode (we can talk internally about the exact steps if you are not familiar with that).

Following this step you get RAW files in the debug subdirectory, which show you all the attributes for the CIs that the Connector code is reading from the CMDB.
In the Connector policy you can then check if all of these attributes are assigned to SOI properties.  Sometimes there are more attributes read than assigned to SOI properties.

In this case you can add code in the Connector policy to assign the missing attributes to SOI properties, such as the "UserAttributeX" fields, or any other field that is suitable for the information.

 

If the Connector code is not reading the properties, then the only way would be to add code to the Connector policy to enrich the information, using a similar way as you did with your initial SQL Query: you have to search in the CMDB for the information and then process the result in the Connector policy.

 

Updating Connector policy requires special skills.  Let me know if you need help in performing these tasks.

If you have a system we can work on, we can schedule a WebEx to do that together.

 

For faster communication about specific details, please use email or IM.

 

Regards,

Michael

[ricmi12]

Thank you very much Michael, let me look at this and if there is some doubts I will let you know

[Anon Anon]

hi Miguel,  has this been addressed to your satisfaction now?  just checking in on this -