Migration to Alerts 2.0

Alert rules in your account will be migrated by Monitis to the new Alerts 2.0 alerting model.

At this phase the migration will be carried out for the following monitors:

– Application monitors:

  • Log
  • Email Round-Trip

– Server-Device monitors:

  • Bandwidth
  • Disk I/O
  • Service
  • Internal TCP

– All custom monitors

Migration of the alert rules in your account will be done in accordance with the rules described in this document. The migration rules are illustrated with examples to make them easier to understand. Please read them carefully to be prepared for the migration of alert rules in your Monitis account to Alerts 2.0.

The following rules will apply when migrating to Alerts 2.0:

  • For each alert rule a threshold of WARNING or CRITICAL severity level is created in the monitor (see Thresholds).
  • The alert rule’s condition (consisting of the metric, operator and value) will be moved to the newly created threshold of the monitor to form the performance part of it.
  • The “Alert upon X failures” parameter’s value in the alert rule will be set as is to the “Number of consecutive checks” parameter in the availability part of the monitor’s threshold.
  • The monitor will enter CRITICAL or WARNING state anytime a respective severity level threshold is violated.

1-new

  • The alert rule will be mapped to the monitor’s state (CRITICAL or WARNING). Alerting will be triggered whenever the monitor will enter the state set in the alert rule.

2-new

  • In some cases the alert rule will be mapped not to the monitor’s state but to the threshold created in the monitor (see above). You can change the alert rule’s condition from threshold-based to status-based (CRITICAL or WARNING). Once changed the condition can’t be changed back to threshold-based. Please refer to Changing Alert Rule’s Condition from Threshold-based to State-based below.

3-new

Detailed case-by-case explanations of the migration rules are provided below under Migration Rules.

 

Migration Rules

The following rules apply to migration of your existing alert rules to Alerts 2.0 in the described cases:

    1. If there is only one alert rule in the monitor.
    2. If there are two alert rules in the monitor with the same threshold but different number of repetitive failures.
    3. If there are more than two alert rules in the monitor with the same threshold but different number of repetitive failures.

  1. If alert rules in the monitor have different thresholds (different metric, operator or value).
  2. If a threshold in the alert rule is set on the “State” or “Status” metric of the monitor.

 

  1. If there is only one alert rule in the monitor.
    • The alert rule’s condition is moved to the CRITICAL level threshold created in the monitor.
    • The alert rule is mapped to the CRITICAL state of the monitor.

Example: before migration to Alerts 2.0 the user had only one alert rule on his MySQL monitor.
4-new

Upon migration to Alerts 2.0:

    • The alert rule’s condition is moved to the CRITICAL level threshold created in the monitor

5-new
The alert rule is mapped to the CRITICAL state of the monitor.6-new

2. If there are two alert rules in the monitor with the same condition but different number of repetitive failures.

  • Condition of the rule with lower number of failures is moved to the WARNING level threshold created in the monitor.
  • Condition of the rule with higher number of failures is moved to the CRITICAL level threshold created in the monitor.
  • The alert rules are mapped to the WARNING and CRITICAL states of the monitor respectively.

Example: before migration to Alerts 2.0 the user had two alert rules with the same condition but different number of failures on his MySQL monitor.

 

7-new
8-new

Upon migration to Alerts 2.0:

  • Condition of the rule with lower number of failures is moved to the WARNING level threshold created in the monitor. Condition of the rule with higher number of failures is moved to the CRITICAL level threshold created in the monitor.9-new
    10-new
  • The alert rules are mapped to the WARNING and CRITICAL states of the monitor respectively.
    11-new
    12-new

3.If there are more than two alert rules in the monitor with the same condition but different number of repetitive failures.

  • Each alert rule’s condition is moved to a CRITICAL level threshold created in the monitor.
  • The alert rules are mapped to the respective CRITICAL level thresholds created in the monitor. You can change the alert rule’s condition from threshold-based to state-based (CRITICAL or WARNING). See Changing Alert Rule’s Condition from Threshold-based to State-based.

 

Example: before migration to Alerts 2.0 the user had four alert rules with the same condition but different number of failures on his Oracle monitor.

13-new
14-new
15-new
16-new

Upon migration to Alerts 2.0:

  • Each alert rule’s condition is moved to a CRITICAL level threshold created in the monitor.
    17-new
    18-new

19-new
20-new

  • The alert rules are mapped to the respective CRITICAL level thresholds created in the monitor. You can change the alert rule’s condition from threshold-based to state-based (CRITICAL or WARNING). See Changing Alert Rule’s Condition from Threshold-based to State-based.

21-new
22-new
23-new
24-new

4.If alert rules in the monitor have different conditions (different metric, operator or value).

  • Each alert rule’s condition is moved to a CRITICAL level threshold created in the monitor.
  • The alert rules are mapped to the respective CRITICAL level thresholds created in the monitor. You can change the alert rule’s condition from threshold-based to state-based (CRITICAL or WARNING). See Changing Alert Rule’s Condition from Threshold-based to State-based.

Example: before migration to Alerts 2.0 the user had two alert rules with different conditions on his Oracle monitor.

25-new
26-new

Upon migration to Alerts 2.0:

    • Each alert rule’s condition is moved to a CRITICAL level threshold created in the monitor.

27-new
28-new
The alert rules are mapped to the respective CRITICAL level thresholds created in the monitor. You can change the alert rule’s condition from threshold-based to state-based (CRITICAL or WARNING). See Changing Alert Rule’s Condition from Threshold-based to State-based.

29-new

30-new

 

5.If a threshold in the alert rule is set on the “State” or “Status” metric of the monitor.

Note: In Alerts 2.0 “State” and “Status” metrics will be removed from the below listed monitors and included – as standard availability part – into monitor’s thresholds (CRITICAL or WARNING):

  • Internal TCP
  • ERT
  • Condition of the alert rule set on “State” or “Status” metric is moved to the CRITICAL level threshold created in the monitor. As the alert rule’s condition cannot be kept as is when moving it to monitor’s threshold because of removal of “State” and “Status” metrics from the monitors (as per the above note), the CRITICAL level threshold will contain only the availability part (“If for X consecutive checks check failed”). The performance part of the threshold will show not set (metric values blank).
  • Depending on the rules 1-4 above, the new alert rule is mapped to either:
    • The monitor’s state (CRITICAL or WARNING).
    • The CRITICAL level threshold created in the monitor.

Example: before migration to Alerts 2.0 the user had only one alert rule set on his Oracle monitor, and it was configured on the “Status” metric

31-new

Upon migration to Alerts 2.0:

    • Condition of the alert rule set on the “Status” metric is moved to the CRITICAL level threshold created in the monitor. As the alert rule’s condition cannot be kept as is when moving it to monitor’s threshold because of removal of the “State” metric from the monitors (as per the above note), the CRITICAL level threshold will contain only the availability part (“If for X consecutive checks check failed”). The performance part of the threshold will show not set (metric values blank).

32-new

  • The alert rule is mapped to the CRITICAL state of the monitor.

33-newExample: before migration to Alerts 2.0 the user had two alert rules on his Node.JS monitor, one of them configured on the “State” metric.

34-new
35-new

Upon migration to Alerts 2.0:

  • Each alert rule’s condition is moved to a CRITICAL level threshold created in the monitor. The CRITICAL level threshold for the alert rule configured on the “State” metric will contain only the availability part (“If for X consecutive checks check failed”), and the performance part of it will show not set (metric values blank).
  • 36-new
    37-new

    • As the two alert rules use different metrics, as per the rule 4 above the alert rules are mapped to the respective CRITICAL thresholds created in the monitor. You can change the alert rule’s condition from threshold-based to state-based (CRITICAL or WARNING). See Changing Alert Rule’s Condition from Threshold-based to State-based.

38-new
39-new

Changing Alert Rule’s Condition from Threshold-based to State-based

If a migrated alert rule is mapped to the monitor’s threshold, you can change it to the monitor’s state by switching the radio button to “Monitor’s condition changed to:” and selecting the state: CRITICAL or WARNING.

You will be alerted then whenever the monitor enters the selected state.

40-newImportant: once changed to state-based the alert rule cannot be changed back to threshold-based.