SNOW integration

[leif_ericksen]

Hi, folks let's say I have a *live.dynatrace.com environment with a tenant called GreatOutDoors This tenant has 3 synthetic monitors, and 1 needs problems assigned to the ServiceNow queue while the others are supported elsewhere.

Should I create a new Management Zone and Alerting profile for the one synthetic and configure it to send tickets to ServiceNow?  Oddly, it seems that there are issues with the SNOW backend as SNOW is taking the environment name ML_OUTDOORS_PROD and adding that to the short description. Then when I review the ticket in SNOW the initial entry indicates SNOW could not identify my CI. Unfortunately, I do not have access to the SNOW backend and must rely on another team.

Is there a best practice to ensure SNOW is able to identify my CI or is there a way for me to send the desired resolver group as part of my payload? Sending the desired RG seems best as we can change it as needed by how we send the ticket so SNOW rather than rely on backend code and table lookups.

[Sujit]

@leif_ericksen Best to use payload where you can add one identifier which can be used as CI (snow side) and send this payload to SNOW.  In payload you can add all required tags or entity which you wanted to see in your incident like longDescription, tags, application etc..

Thanks

Sujit 

[jairam_ramaswam · Accepted solution]

@leif_ericksen I think to just send certain synthetic events to ServiceNow, would be good to have an Alerting profile created and have a tag on that specific synthetic monitor. You can use this as filter to just include the specific synthetic event to be sent to ServiceNow and restrict others. Management zone would be another way to do it, whichever you prefer.

We dont integrate Synthetic monitor data into ServiceNow with our CMDB integration so these CIs wont be available. If the end goal is to assign it to a specific resolver group, then couple of ways to do it. First, adding this group as tag in Dynatrace and then parsing this tag in ServiceNow to assign the resolver group. Secondly you can have Assignment lookup rules in ServiceNow for all problems originating from Synthetic Events to be assigned to specific resolver group.

If you need more information, please open a Support ticket with DT or you can let your ServiceNow team know about the above ways

[leif_ericksen]

This is great, so it seems that this is going to come down to adding tags and building a specific payload to send the SNOW. Then I need to work with the SNOW team to read what is sent over from DT and build custom code to react to those tags.  Does anybody have a sample of how the data looks when it leaves DT? Oddly I can look at the first entry in SNOW, but I believe it has been altered before being posted as the short description there does not match what DT is supposed to be sending. I will ask my SNOW team for the same information but I was thinking the community would be faster. Again it is rough not haveing access to both sides of the information stream.

Thanks for the reply, it is helping me get focused and understand the environment better.

[renatarc]

Hello

From my experience, the data push from DT to ServiceNow is the payload of the Problems API v2 (get detail).

https://www.dynatrace.com/support/help/dynatrace-api/environment-api/problems-v2/problems/get-proble...

In ServiceNow, the data is transformed and input into the import set table (x_dynat_ruxit_problems).

https://www.dynatrace.com/support/help/setup-and-configuration/integrations/problem-notifications/se...

The short description of the incident on ServiceNow should correspond to the value that you setup  on "Description", in you "Problem Notification" in DT.

Best regards