Alerting
Questions about alerting and problem detection in Dynatrace.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Dynatrace Managed – Route Application Problems to Application Team in ServiceNow

Sohel_Rashid
Contributor

Hi Team,

We are using a Dynatrace Managed environment integrated with ServiceNow.

Currently, when an incident is generated from Dynatrace, it is being routed only to the OS/Infrastructure team, including incidents related to application services/problems.

We would like to configure the integration/workflow so that:

  • OS/Infrastructure-related problems → routed to the OS team
  • Application/Service-related problems → routed only to the respective Application team
  • Application-related incidents should not be assigned to the OS team unnecessarily.

Could someone please guide us on the recommended approach to achieve this in ServiceNow?

Specifically, we would like to understand whether we can use Dynatrace problem/entity information, tags, management zones, or alert/event attributes to determine the assignment group in ServiceNow.

If anyone has implemented a similar setup with Dynatrace Managed + ServiceNow, please share the configuration.

Thanks in advance for your guidance.

2 REPLIES 2

You could create different Alerting Profiles for the different assignment groups and link each profile to its specific Custom integration.

You can use the principle of ownership for this:

  • Tag hosts with something like TEAM:OS-TEAM

  • Tag each Application/Service with TEAM:[respective Application Team]

  • Create an Alerting Profile for each team, e.g. TEAM:[respective Application Team], filtering only on problems tagged with that specific team.

  • Set up multiple custom integrations, with each integration linked to one Alerting Profile. (use TYPE custom and not SNOW), you can use the SNOW api as reference how you payload should look like.

  • In each integration, use the assignment_group in the JSON body corresponding to that team.

The main thing you need to make sure of is that everything is tagged correctly and that an entity doesn't end up with multiple team tags. Otherwise, you could potentially generate two ServiceNow tickets for the same problem.

You could also use Management Zones, but I personally prefer to have the tagging fully set up first and then build the Management Zones based on those tagging rules. That’s just my personal preference, though.

AntonPineiro
DynaMight Guru
DynaMight Guru

Hi,

You can have some tagging / routing strategy in Dynatrace. But I would recommend implement all routing logic in ServiceNow's side for different reasons:

  • Dynatrace cannot covers all routing use cases. Example, Disk C to team A, disk D to team B. Disks are not tagged, host is tagged.
  • You can reuse logic for another sources (Prometheus, Zabbix, Nagios, etc. etc.)
  • ServiceNow CMDB knows more about CI, if is retired, owner group, support group, etc.

Best regards

❤️ Emacs ❤️ Vim ❤️ Bash ❤️ Perl

Featured Posts