Consideration and Challenges while configuring the ITOM Event Management

[M Sindhu]

Hello,
Please avoid sharing information directly from ServiceNow product documentation, as I can refer to that separately. I’m more interested in the hands-on experience and practical challenges that are observed while the actual implementation.

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

We have a requirement to configure ITOM Event Management for a customer, and we are currently in the preparatory phase.

As we begin planning the implementation, I would like to understand the real world key considerations, challenges, and potential observations that we should keep in mind based on practical experience.

If you have previously worked on configuring ITOM Event Management or integrating any monitoring tools with ServiceNow, could you please share your experience.

The question is not specific to any particular monitoring tool. We are looking for general insights that can help us prepare for the implementation, regardless of the monitoring tools involved.

Any inputs based on your previous experience would be greatly appreciated and will help us identify potential challenges early in the process.

Thank you.

[Avin ANZ]

• Based on my experience while doing event management integrations with tools like Dynatrace/Logic Monitor / Datadog or any monitoring tools. A few things I would suggest are listed below:
  Understand what each monitoring tool is actually sending to ServiceNow. Get sample payloads for scenarios before building the rules.
• Do not send all events into ServiceNow from monitoring tools. It is better to filter events at the monitoring tool itself wherever possible.
• CI identification should be done . In many cases i have see that this becomes one of the key challenges because one tool may send only hostname, another may send FQDN, IP, entity ID or some other data identifier. Make sure these values can map to the CMDB CI records.
• Validate the CMDB for sample monitored devices first before onboarding everything. Keep the event mapping consistent across tools. attributes which are part of the event data like node, resource, metric, severity, description and message key should be handled in a standard way as much as possible.
• Make sure deduplication rules are properly configured as repeated events for the same issue should update the existing alert rather than creating multiple alerts. 
• I have seen cases where the alert gets created correctly but does not close because the recovery event does not match the original alert properly. so make sure this part is tested well
• Also we need to understand that a critical event in Dynatrace, LogicMonitor or Datadog ( in my case these are the monitoring tools i used) in let it be any monitoring tools this might not always mean it is a p1 or p2 incident. Make sure that when an incident creation is happening it considers the CI, business service, impact and how long the issue has been active to determine the priority.
• Conversion of alerts to incidents needs  to be validated thoroughly. If every alert creates an incident, the purpose of event management is lost and the service desk will end up with too much noise.
• Monitoring tools like Dynatrace / Datadog may already group alerts which are to related problems. If ServiceNow is also doing correlation make sure both are not trying to solve the same issue in different ways.
• I normally start with a smaller set of CIs or applications and validate the complete flow from monitoring tool. Once that is stable, then expand to the remaining scope.

These are some of the learnings which i can say. Hope this helps you and your team

[sash_machiraju]

From my experience, the biggest challenge in Event Management implementations is not ServiceNow itself, it's the quality and consistency of the events coming from the monitoring sources.

A few lessons learned:

• Define your event identity strategy early. Decide what fields will be used for de-duplication and clear correlation (message key, source, node, resource, etc.). Changing this later is painful.

• Don't onboard every event source and alert on everything. Start with actionable alerts. Most projects underestimate the amount of alert noise that monitoring tools generate.

• Validate the complete event lifecycle, not just open events. Test open, duplicate open, clear, reopen, delayed clear, and clear-without-open scenarios. Many issues are only discovered after go-live.

• CI binding is often harder than expected. Event Management works best when events consistently map to the correct CI. Poor naming standards across monitoring tools can create significant operational challenges.

• Establish ownership and governance early. Decide who owns event rules, alert tuning, source onboarding, correlation logic, and incident generation criteria.

• Create source onboarding standards. For every new monitoring source, define message key strategy, severity mapping, CI binding approach, clear event handling, and alert ownership before onboarding.

• Monitor ingestion health continuously. Compare source event counts against ServiceNow event counts and alert counts. It is common to find dropped events, parsing issues, filtering mistakes, or ingestion gaps.

• Keep correlation simple initially. Get ingestion, CI binding, and alert creation stable before introducing complex correlation and AIOps use cases.

• Be very careful with custom alerting logic and thresholds. What works well in test environments can behave very differently once production volumes increase.

• For HLA/Event Management integrations specifically, pay attention to data quality, dataset mappings, and ingestion consistency. In my experience, many alerting issues ultimately traced back to ingestion or source-data problems rather than the alert rules themselves.

Overall, the most successful implementations focus on event quality, noise reduction, CI binding, lifecycle testing, and governance before they focus on advanced correlation or automation. These areas usually determine whether Event Management becomes operationally useful or just another source of alert fatigue.