Event Management : Restrict Incident creation for Child CI

[pradeepgupta]

Hi All,

We are using Event Management to create Incident based on Alert.

My Requirement :

1.Event will be created in service-now by say third party ABC.(Event will have ci(node),resouce, source, type).

2.Based on the Event Alert will be created.

3.Based on Alert filter Incident will be created.

4.If two/more event comes with the same ci(node),resouce & type then Alert to create however Incident should not be created and update the same incident.

5.If Incident is created for parent ci(node) than if new alert comes for his child ci(node) so it should not create new incident and update existing parents incident.

I successfully achieved till point no. 4, any one can help me on point no. 5?

[pradeepgupta]

Any one have worked on Event Management ?

[pradeepgupta]

Any idea about Event Management Harish Murikinati

We have one Monitoring tool (ABC) which is integrated with Service-now. When any event occurs(CPU High utilization) Monitoring tools captures that and through integration it creates event in Service-now. Once event created in SN it creates Alert and based on filtered alert incident is being created in service-now.

As of now if event comes for parent and child ci two different incidents created, The requirement is to create only one as if parent is down all the ci which are dependent on parent will also be down.

Please help me to achieve this.

[Ak Islam]

Hi Pradeep,

I have the same scenario as you have. can you please help me ?

Thanks

Ak

[Tony Branton]

Hi,

If you have two or more events with the same source, node, type and resource fields then Event Management will de-duplicate these (or consolidate them) into a single alert.   Once an alert has been created, additional events containing data that matches the message_key in the alert (automatically created by Event Management using source+node+type+resource) will update the alert.   If you wanted to force events to be consolidated to an alert, you can use an Event Rule to set the message_key field, possibly based on data captured in the events.

If the alert caused an incident to be created then no additional incidents will be create - the incident remains associated with the alert being updated by an event.   If the Event Management evt_mgmt.alert_reopens_incident property controlling Incident behaviour is set to Reopen Incident, then an alert that was closed and is re-opened will reopen the incident - no new incidents are created.

I understand that in item 4 is talking about relating multiple alerts to a single incident, however I'd recommend first consolidating multiple events that should be related to a one alert.

If the problem you're trying to solve involves ensuring only a single incident is created for multiple related alerts, then one solution is to configure an Alert Rule that will only create an incident for a specific alert and not for the other related alerts.   For example, in the Fuji release of Event Management if an alert is created for an event from one monitoring tool and a second alert is created by an event from a different monitoring tool, and the node, resource and type in the second alert matches the first, the second alert will be automatically related to the first alert.   What you can do in this case is to configure an Alert Rule that only creates an incident for the first alert as it may represent the root cause.   You can then drill down from the incident to the alert and then view a list of the related alerts.

Suppressing incidents for alerts for CI that have parent CI's already with an incident requires business logic that effectively says does the CI the alert is affecting have parent(s)?   You can't do this using the standard condition builder in an alert rule, which means configuring the logic in a JavaScript-based business rule.   You'd be better adopting service maps with impact relationships and the impact calculation capabilities in the Geneva release of Event Management rather than attempting to develop complex a business rule that could potentially mask a causal alert.