ServiceNow action configuration for alerts originating from trap source like DPA

Does no one have this issue but me? If I want to create an incident in SNOW from DPA I can have 1 active incident per configured alarm at a time. So if I have an AG status has changed alarm for 100 Db instances only one instance can have an incident in SNOW at a time. The same goes for any other trap source so anything coming out of Log viewer\analyzer. I cant be the only one.

I think we need clarity.  DPA creates trap --> SolarWinds Orion Platform --> ingests with Log Analyzer --> you want an alert to be triggered based on the message (and maybe filtered by the source?) --> you want a create incident action to SNOW for this

Do I have that correct?

I think we need clarity.  DPA creates trap --> SolarWinds Orion Platform --> ingests with Log Analyzer --> you want an alert to be triggered based on the message (and maybe filtered by the source?) --> you want a create incident action to SNOW for this

Do I have that correct?

Yes. The issue is that Event Viewer/Analyzer cannot discriminate between an alarm from the same source and title. Alarms from DPA will all have the same source and the alarm title will be the same for all traps originating from DPA with the same issue. When integrating these alarms into SNOW you end up with a mess of incidents that have been reopened and updated multiple times for multiple different traps instead of one incident for every trap. The same happens for any other single source trap sender. 

I'm not familiar with sending traps some DPA myself but am with DPA alerting. Could the DPA trap send additional data in the trap that could then be ingested in Orion, and perhaps relayed to ServiceNow as a result?

Just scratching the surface here but reviewing the documentation it does appear that the following fields are sent in the trap by default? Does that line up with what you see on your end?

Due to the nature of sending these traps to Orion from DPA, it would be expected that the source would be the same as it's all coming from the DPA server.

So the real question is... do those 4 fields sent in the trap content hold any merit / use and can you reference them in some consistent way to help distinguish the alerts. There are variables to access specific data in traps/syslog in Log Analyzer / Viewer, link below.

• Four string objects bound to each trap: database name, alert name, alert level, and response instructions

https://documentation.solarwinds.com/en/success_center/orionplatform/content/core-log-analyzer-variables-syslog-trap.htm

https://documentation.solarwinds.com/en/success_center/dpa/content/dpa-snmp-alerts.htm 

I think it's more the way Log Viewer/Analyzer handles traps. If all the traps come in under the same filter, each time it matches it makes an "event" against the node and the alert triggers off the event. So when you have a bunch of different traps come in, it will reopen the same SNOW incident because they match the filter+node rather than create a unique SNOW incident each time the alert triggers. This is also why when you get a bunch of traps come in at once, instead of making unique alerts you only get the single alert.

I vaguely recall someone found a way around it but it involved some custom scripting and injecting alerts directly into the database. I can't remember who though.

Good point shuth I didn't think about that and assumed the source as the network source lol. Yeah this sounds like a limitation with Log Analyzer that wasn't there with the legacy trap/syslog functionality I didn't think.

If I find anything on that I'll relay it