Orion.AlertStatus field questions

I would advise against relying on the WorkingState or TriggerTimeOffset properties but here is the info for the curious.

Orion.AlertStatus.WorkingState is for internal use.

Orion.AlertStatus.AlertStatus.State is the internal state of the alert.  value 1 means the alert condition has been evaluated to true but there is a sustained time period.  value of 2 means that the alert has been triggered.

Orion.AlertStatus.TriggerTimeOffset is how much time till the actions get executed.

Excellent.

Can you expound a bit on what "value 1 means the alert condition has been evaluated to true but there is a sustained time period." means?

Thanks,

Scott

For alerts you can specify that the alert is only triggered if the condition exists for a certain amount of time.   Setting is on the Trigger Condition page in the alert viewer.  So the value of 1 means that the Alert trigger condition has been evaluated to true and that we need to wait the amount specified to check again to trigger it.

I have a question about the TriggerTimeOffset as well, is this in milliseconds, seconds, minutes? Also why does every node get two entries in the AlertStatus table? I'm seeing two separate entries for nodes that have an active alert in this table.

I'm trying to set up a custom SQL variable that will inform me if this alert is a new alert or if it's one that is a re-trigger due to the "AutoClearAlertIntervalInMinutes" key. I'd like to know as much as possible about this table as I believe it's the one needed to pull off something like this.

Well, I can say that having two separate alerts for a given node is most likely to do with the particular Alert Definition. Like if something is, as we call it here, flapping (going up and down, or down and back up), there could easily be an alert for each state.

You may want to double check your alert definitions.

-Scott

In this demo system I've only got the default alerts active in the system. You are correct though and it's the High packet loss monitoring and the node down alert. Based upon that revelation I'm not sure why the system isn't re-triggering the alert or firing the alert actions again when it's supposed to after the autoclear interval has expired. I'm using dummy ICMP nodes 1.1.1.1 and 2.2.2.2 to test this as they'll be down indefinitely for testing. I've posted a question of my own in regards to what I'm doing so I won't resurrect your thread again. Thanks for the information, was much appreciated!