cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Need to create a ticket when cpu usage is 90

sarathkumar_ram
Newcomer

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 SCCD. 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 SCCD ticket. However, what's happening with Dynatrace right now is that a completely new SCCD 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. That adds quite a bit of extra work for the support teams trying to work the tickets and for everyone else who's trying to track tickets.


1 REPLY 1

JamesKitson
Dynatrace Leader
Dynatrace Leader

Is this AppMon (the forum it's in) or Dynatrace (RESOLVED is a phrase that shows up in Dynatrace problem notifications). I'll answer under the assumption it's Dynatrace and can move it to the appropriate forum once you confirm.

Regardless, I've run into this issue as well and as of right now there is no solution in the product to get the behavior you're looking for. For custom integrations you can only configure the endpoint and payload but there's no way to either restrict it so that it only fires at the start or to have it send a different request to update created tickets (this would require Dynatrace knowing and storing some identifier for the original ticket and then dynamically changing the call it makes for updates like the problem resolution). Right now it just sends out the call you configure for any status changes hence the multiple tickets.

Apart from writing your own software to sit in the middle what the most common resolution is is that some ticketing or notification software can be configured to look for things like text indicating it's an update to an existing ticket rather than a brand new one. For instance looking for "RESOLVED" in the subject and you can include the problem ID as well to know which problem it is updating. I haven't set this up but I know others have, and it is partly dependent on how configurable your SCCD software is.

James