This website uses Cookies. Click Accept to agree to our website's cookie use as described in our Privacy Policy. Click Preferences to customize your cookie settings.
10 Sep 201801:55 PM - last edited on 28 Apr 202108:40 AM by MaciejNeumann
When a Dynatrace monitor detects a situation above a set threshold (i.e. CPU utilization high), it will generate an alert and create a ticket in ticketing tool, Here's an example of a ticket created as part of testing. Note the word "OPEN" under the details, noting that an alert has been triggered. When a Dynatrace monitor detects that the threshold value is no longer being exceeded (i.e. CPU utilization had now dropped back down to acceptable levels after a job completes), the "alert" will be "cleared" on the Dynatrace console to show that the issue is resolved. Ideally, the existing SCCD ticket will be updated to indicate that the issue is resolved. That's often handled by other systems creating a worklog entry for the existing ticket. However, what's happening with Dynatrace right now is that a completely new ticket is being created, with the word RESOLVED in the details. This means for each issue, two tickets are being created. One when the "alert" is opened in Dynatrace and one when the alert is resolved in Dynatrace.
am I correct in assuming you are using the Custom Webhook Integration feature? The second request sent by Dynatrace is exactly what you are describing as "clearing" the problem. Dynatrace identified the problem to be over and sends another request with State=Resolved. You won't have to close these tickets manually.
If you just get another ticket when the State=Resolved request comes in, it seems that the second request isn't mapped to your ticket created by the first request. You could use the {PID} placeholder as an identifier to accomplish this.
If your ticketing system doesn't support such behavior, you'll need to write a small middleware to map these two requests to your ticket.
Currently we are using above script, it already has PID in it. It still generates separate ticket for RESOLVED event.Please help me with modified script
I'm not familar with SCCD but you'll have to use this PID to map the request to an existing ticket, if available. This will have to be done inside the tool. Dynatrace is only able to send these static requests on Problem occurrence and resolution.
If the tool doesn't support this you'll have to write a middleware as said in James' post and mine above.
Your ticketing tool would need to be what handles this - it has no way of knowing that the PID is an identifier for problems or what other information says when it is an update to an already opened problem. This needs to be configured on the ticketing tool side if it is supported by your tool. Otherwise you'd need to find an alternative such as the middleware Franz described.
