This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

SDK Alert History Question

Looking at the GitHub Wiki about Alert entities (by the way, these Wiki articles explaining these entities are GREAT!  Please do more!), it says the AlertHistory entity is about alert events in the past, even if the alert is reset.  It says AlertObjects is about alerts currently triggered.  I don't see the AlertHistory table tying into the AlertConfiguration table except through the AlertObjects table... But, if the AlertObjects table only contains data about currently triggered alerts, how do I JOIN AlertHistory information to AlertConfiguration information if none of the alerts I want info on are currently triggered?

I ask because I want an AlertHistory report that tells me how many alerts have occurred for each configured alert.  Therefore, I want to be able to GROUP BY the AlertConfiguration Name column.  Sure, I can get it through AlertObjects, but like I said, if an alert isn't currently triggered I can't get it...  Yes, I know I can query the Event table for Triggered Alert events, but what if someone creates an alert and forgets to put a NetPerfMon Event Log action?  I'd rather get the raw data from the AlertHistory table itself.

  • AlertObjects entries are not cleared when the alert is reset. You can still go from AlertHistory to AlertObjects to AlertConfigurations for alerts that no longer appear in AlertActive. I'll clarify this on the wiki page.

    For example, if you have only one alert "Node is down" and only server "Crashy" that previously went down 10 times but is currently up, then you will have:

    No rows in AlertActive

    1 row in AlertObjects

    10 rows in AlertHistory with EventType=0 ("Triggered") plus some other rows with other EventType values for when it was reset or acknowledged, etc.

    The query you want should be straightforward to build.

  • Yep, I figured this out and posted replied on another post today that I mentioned this issue, just forgot to come back and update this post as well.

    Thanks tdanner.