SCOM does not process alert data. It simply reads the data from the database and then SCOM uses its own built in logic to do whatever you tell it to do. The two systems are independent.
Thanks for confirming! Guess it's curtains for the management pack. I'll submit a separate feature request for the connector code to include an option for scraping correlated alerts configured in Orion. We want to make Orion our enterprise platform, and I'm trying to develop a way to do this without writing code that locks me into maintaining it.
Orion customers, any of you successfully sending correlated (suppressed) Orion alerts to OpsMgr as a monitor versus alert rule? It's real easy to send alerts to OpsMgr via the event log. Since Orion sends up and down alerts with the same severity and event ID it's looking trickier to develop a monitor that can handle this:
OpsMgr event log monitor goes unhealthy when Informational event 3003 received with DOWN in description. Goes healthy when same event received (severity and id are fixed) with UP in description. Piece of cake except when there are multiple nodes/interfaces down.
Servers A and B go down, you get two node down alerts in OpsMgr.
Server A comes back up, OpsMgr event log monitor reads event with UP in description. Which alert is closed?
If Orion alert vars were written to the event log as parameters, problem solved. Unfortunately testing showed this doesn't happen. Am I overlooking something?
Appreciate any feedback, and thank you all in advance!
Never mind folks, I failed to consider using a trigger to run an external .vbs/.ps1 script or C# console app to manipulate the data as needed to create and close OpsMgr alerts.