If you want to send alerts to a ticketing system, the secret is to It's possible to utilize SolarWinds HCO or Orion modules, as intermediary. Configure DPA to send the relevant traps to HCO and use the alerting engine there to create the ticket.
The trick is to have 2 rules in the log functionality (one for trigger and the other to reset), and call those in a single alert in HCO. Lets look at the examples here.
In this example I've enabled an alert for "Total Blocking Wait Time", set every time minutes in DPA. The main thing is to set the Notification Policy to "Notify when level changes".
In HCO you can check the "Logs" dashboard and filter for "log type" of "traps". Here is an example of the relevant trap for an alert trigger. A reset event will look almost identical, except the cnfAlertName will be "NORMAL". In this example I've highlighted the 2 varbinds that will be used to create the log filters.
So the next thing to do is create 2 rules to handle both the trigger and reset logs. You can follow the steps here to create the rules . I like to include the keywords "trigger" or "reset" in the rule name, as it's useful later. In my example I went with "DPA Alert Trigger - Total Blocking Wait Time"
But the main settings to include are under the conditions to add in the necessary logic for the varbinds above.
And then under actions ensure the option for alert integration includes the option to "Send a Log Rule Fired event to Orion Alerting" is set.
I then repeated these steps for a rule called "DPA Reset Trigger - Total Blocking Wait Time", with almost the same logic, except with the severity set to normal.
Then we move on to the final stages, configuring "alerts".The alerts have several parts, including logic for triggering and resetting, as well as different actions that can be performed on trigger and reset.
In our use case we will use the alert created when we created the first alert as our base. More info for alert configuration is available here Under "settings"-"manage alerts" I'm going to select and edit the alert that was created when we created our log rule. In this case we can see the logic for the "trigger condition" is a "Log Analyzer Alert Message Event" where the "processing rule " equals the name of our first trigger rule (don't worry, this will be populated).
But on the "reset condition" is where we make a big change
In this case I'm going to select "Create a special reset condition for this alert" and copy the condition from the trigger
Next I'm going to select the "reset" rule from the drop down list
From there it's just normal alert trigger and reset actions, which include the integrations with the ticketing systems. Info on configuring those is available here. Up to 10 varbinds from the trap can be used in the alerts, info on those variables is available here