Escalation Rule Example

consider a healthy zixi source that suddenly encounters intermittent packet loss over the course of several minutes, which eventually recovers notifications for packet loss, resulting in cc errors, are controlled by the “source – analysis – tr101 p1 transport” rule of the event profile, which is configured as follows the escalation window is set to 10 minutes and an escalation count of 4 events according to the rule, notification emails should be sent for both error and ok states the resulting behavior of the monitoring system is as follows scenario one zen master checks the source the source is actively streaming, and packets are delivered for each confirmation during the rolling escalation widow, the response is good a network error causes the source to lose packets the following state check informs zen master of cc errors due to packet loss as this is the first non positive event during the window, zen master places the source into a warning state the source has recovered, at the next check the response indicates the source is good zen master returns the source into a good state further packet loss occurs, and the following checks return a non positive result of a source exhibiting cc errors zen master has returned the source to a warning state note that the cumulative event total is now 2, and that concurrent non positive results are considered a single ongoing event monitoring of the source continues, returning several more cc error results between to concurrent sets of good responses the event count has reached 3, when the following check returns another non positive result the event count within the window is now 4, meeting the escalation requirement zen master now escalates the state of the source to an error due to the notification settings, an alert email is sent to users with notification privileges on the source the next and subsequent confirmations return positive results, but the source state has already met the error criteria within the window and remains in error once the error criteria is met, further responses indicating cc errors within the window will cause the error state on the source to persist the source recovers, and subsequent checks return positive state after a full de escalation window of good responses zen master returns the source to a good status due to the notification settings, an alert email is sent to all users with notification privileges on the source scenario two in scenario 2, the healthy source encounters sustained interruption before recovery the healthy source begins to return non positive responses indicating cc errors, and zen master places the source in a warning state the cumulative event count is 1 packet loss in ongoing for almost the full duration of the escalation window, and the confirmations continue to return non positive responses indicating cc errors the event count remains 1 and the warning states persists upon another non positive response, if the full duration of the escalation window is reached, zen master escalates the state of the source to an error note that in this scenario the event count did not exceed one, but continual non positive events for the duration of the window result in an error state due to the notification settings, an email alert is generated to all users with notification privileges on the source the source recovers, and subsequent confirmations return a good state after a full de escalation window of good responses (i e , 10 minutes and 4 event counts), zen master finally returns the source to an ok state zen master generates an alert email to all users with notification privileges on the source