Without the Import and Export verbs, you won't be able to do this through the API. Depending on what kind of edits you are trying to make, you might get away with editing the data in the database directly. If you want to go that route, keep in mind:
* This is not a supported operation
* Back up your database first
* Make your database changes with at least the alerting service stopped
* When you start the alerting service after, look at the alerting service log (C:\ProgramData\SolarWinds\Logs\Orion\Alerting.Service.V2.log) and SWISv3 log (C:\ProgramData\SolarWinds\InformationService\v3.0\Orion.InformationService.log) for any errors
tdanner...Thanks for the prompt response! Using MS SQL Profiler, the SELECT statement below was discovered to be used to query the alert configurations/definitions.
SELECT T4.*, T5.*, T1.*, T2.*, T3.* FROM
dbo.Actions AS T1
INNER JOIN dbo.ActionsAssignments AS T3 ON T3.ActionID = T1.ActionID
LEFT JOIN dbo.ActionsProperties AS T2 ON T2.ActionID = T1.ActionID
LEFT JOIN AlertConfigurations AS T4 ON T3.ParentID = T4.AlertID
LEFT JOIN AlertDefinitions AS T5 ON T4.AlertRefID = T5.AlertDefID
The data results from this query indicates that the SQL queries in the TriggerQuery and ResetQuery columns of the AlertDefinitions table are used to evaluate the alert triggers, but no records exist in the AlertDefinitions table for new alerts created using the Solarwinds web browser UI (and several existing alerts). In addition based on the data, the Trigger and Reset columns of the AlertConfigurations table may contain the evaluation equations for the alert triggers. The data in these columns appear to be in XML format with a XML element named "Configuration". The "Configuration" XML element's format seems to define the trigger, but its format seems to deviate from the XML concept of being human readable. In other words with no documentation on the details for alert configuration/definitions, it would be a time consuming process with prone to error to figure out the proper fields used for an alert configuration/definition.
Would you be able to offer any details/documentation that would make it possible to “get away with editing the data in the database directly”?
The AlertDefinitions table relates to the "Advanced Alerts" system. This is the system that was replaced by the "alerting v2" system that has the web-based editor. In 11.5 you could use either system.
I agree that those XML blobs are not human friendly. The are produced by serializing the model objects using DataContractSerializer. There is no documentation for this format.
What kind of mass edit are you trying to make?
Like tdanner mentioned, you are going to be pretty much on your won when it comes to parsing that trigger and reset XML. I've seen the request come up often and nobody has been able to put forth an easy to use solution. I've done mass edits before to the trigger and query XML, but it was a relatively simple set of substitutions where I took the existing info, made the change via the UI once to understand what impacts it would have, then built a SQL update to push out a similar set of changes to all the related alerts. Took a long time to get it right but it was still faster in that case than editing 100 alerts by hand.
I think that mesverrum explained the type of edits (i.e. alert creation/duplication) that I am trying to accomplish. It sounds a bit time consuming, complicated, and prone to error.
A related topic at the url below is feature request for “conditional trigger actions” for alerts that would eliminate the need to create numerous “similar” alerts. For my organization’s use case, this requested feature would be used to execute different sets of alert actions based on the value of a custom node property. The custom node property value would indicate the importance of the node (critical, high, medium, low). For example, a critical priority node would send a SNMP Trap message to create a ServiceNow incident (and other actions) while a low priority node would just log the alert. To implement this functionality, it will require 4X the alerts without “conditional trigger actions” or some similar feature of Alert Manager.
While off topic of this thread, would you be able to offer an alternative feature of the Solarwinds Alert Manager that would negate the need to create 4X alerts to implement the functionality described in the above text?
Another alternative…does Solarwinds offer a more advanced alerting solution that can implement more complex conditions (like the one described above) than Alert Manager? I saw the post(s) about Alert Central being End of Life as of January 2017, and customers pointed to OpsGenie. A third party cloud service is not an option for us.
Ok, the use case is clear now. Unfortunately I don't know of any better way to accomplish this than duplicating the alerts. With the discontinuation of Alert Central, SolarWinds does not have another solution for you.
There is one possible path that I don't see mentioned here.
In the sql days I was pulling the trigger & reset conditions out and parsing/processing them with my own code. I did look at doing the same thing when the alert definition world changed to XML but I suspect there is some of the developers personality in the XML structure. Without trying to emulate that personality, the swql path would be the best option.