Integrating Dynatrace with ServiceNow Event Management

[DB1]

Hi

We are integrating Dynatrace with ServiceNow Event Management and need guidance on the recommended mapping strategy.

We receive two types of events:

1. Davis Problems 
2. Custom Events / Anomaly Detector alerts 

What is Dynatrace's recommended approach for:

• Differentiating these event types within ServiceNow?

• Map directly from Severity Dynatrace to Severity ServiceNow? 

• Routing incidents to different assignment groups?
• Avoiding duplicate incidents when a Davis Problem and a Custom Alert are generated for the same root cause?

Is there any standard procedures to mapping to ServieNow?

Thank you

[DB1]

is there any suggestion on the following approaches? Do you think of the following approaches would work and would significantly simplify the integration whilst reducing the number of Dynatrace alerting profiles?

 Route by Dynatrace Event Type

Dynatrace Event Type        ServiceNow Assignment Group

-------------------------------------------------------
 OPEN Problem              Operational Team

OPEN Custom                Relevant Application Support Team

Route by Alerting Profile

For SEV1 and SEV2:

IF Alert Source = SGO-Dynatrace

AND Alerting Profile = Ops_operationalTeams_Critical

THEN Assignment Group = Operational Team

For SEV3 and SEV4

IF Alert Source = SGO-Dynatrace

AND Alerting Profile = Ops_ServiceTeams_Standard

THEN Assignment Group = Application Owner

This approach would allow us to standardise the configuration and maintain only two Dynatrace alerting profiles:

• Ops_OperationalTeams_Critical (SEV1/SEV2)
• Ops_ServiceTeams_Standard (SEV3/SEV4)

This reduces ongoing administration effort and avoids the need to create and maintain multiple alerting profiles for individual services.

[DB1]

is there anyone has better solution mapping directly severity from Dynatrace to Servicenow? 

[michiel_otten]

I would keep the integration fairly simple. Since ServiceNow Event Management is event-based, I would send Dynatrace events into ServiceNow and let ServiceNow handle the processing afterwards, such as deduplication, CI binding, alert creation, assignment and incident creation.

I would not use Dynatrace Alerting Profiles to determine resolver groups or to replicate ServiceNow assignment logic. Doing so would quickly result in a large number of Alerting Profiles for individual applications or support teams, which becomes difficult to maintain and scale.

I would mainly use Alerting Profiles to determine which events or problems are relevant enough to be forwarded, and after what duration, in order to prevent over-alerting. For example, an availability issue might be forwarded immediately, while a slowdown or resource issue may only be forwarded after it has persisted for a certain amount of time.

For the actual severity, I would use the severity of the Dynatrace event as the starting point. Dynatrace now has a standardized event.severity model from 1 to 5: Critical, Major, Minor, Warning and Informational. A Problem inherits the highest severity of the events correlated into that Problem.

This is especially interesting for custom anomaly detectors, because you can explicitly set an event.severity on those events. This allows you to classify custom alerts consistently instead of relying only on their event type or category.

I would also avoid directly mapping Dynatrace severity to an assignment group. Severity tells you how serious the issue is, but not necessarily who is responsible for resolving it. The assignment group should ideally be determined based on the affected or root-cause CI, ownership information and CMDB relationships in ServiceNow.

So in short: use Alerting Profiles primarily to control what gets forwarded and when, in order to reduce noise. Use event.severity to consistently describe the technical severity of the event, including custom anomaly events. Then let ServiceNow Event Management handle CI binding, Event Management correlation/deduplication, ownership, assignment and incident creation.

This also prevents ending up with a large number of Alerting Profiles for every application or support team.

[DB1]

Is it possible to set or customize the severity for the built-in Kubernetes alerts in Dynatrace, or are the severities fixed by the default anomaly detection configuration?

[nick-p-montana]

I think I have a helpful answer to your original question but first I would like to ask you about this reply. Are your kubernetes related alerts particularly noisy? Are you trying to use their severity classifications to adjust the logic for when to trigger an incident email notification in servicenow?