Introduction to Rules and Alarms (4301442)

The Home Page is not correlating with the Alarms being fired.

This article discusses the basics of Metrics, Rules, Alarms and the correlation to the Home Page.

Clarity on those concepts and flow may answer many questions in the field.

Rules

The data gathered in each of the Metrics and its data segments is constantly being checked by the Rules.
A Rule is defined per each metric, and the Rule checks the metric data in order to alert the user, if required.
The alert is in the form of Alarm and mail notification (if configured).
In order for the Rule to "know" if an Alarm should be triggered, the Rule uses either thresholds or Boolean condition.

The types of Rules are:

• Rules that are checking strict thresholds numbers
• Rules that are checking Baseline thresholds (Foglight for Oracle only)
• Rules that are checking Boolean conditions (like yes/no, enabled/disabled)

Alarms

• Baseline deviations — invoked for several of the metrics for which a baseline is configured
• Thresholds — displays alarms about metrics or workloads, whose configured threshold has been exceeded

If the Rule processes the Metric data and find out that the thresholds point to exception (for example, CPU usage is over 80, and 80 is the threshold which beyond an Alarm should be fired), an Alarm will be triggered.

According to each Rule definition (thresholds, Baseline thresholds, Boolean), an Alarm will be fired.

Rule with thresholds/Baseline thresholds can trigger an Alarm with the below severities:

Indicator	Color	Severity	Description
	Yellow	Warning	The metric (or workload resource) has exceeded the configured threshold or deviated from the baseline.
	Orange	Critical	The metric (or workload resource) has significantly exceeded a threshold or deviated greatly from the baseline.
	Red	Fatal	A severe connectivity issue was encountered, thereby triggering a fatal alarm. Such an issue can occur in one or more of the components that take place in the monitoring process; for example, if Oracle database is not responding, the listener is down, or the number of connections reached the number of sessions defined in the init.ora file.The Home Page for *Foglight for Oracle is composed from multiple components, and some of the components are colored relaying on the Baseline thresholds (the same yellow, orange and red as with the regular thresholds). The Baseline based components in the Home Page (for example, all the Wait Event components) will be colored in green if the Baseline learning curve has not been stabilized. It takes minimum of 24 hours for the Baseline learning curve to be adjusted to the environment.

While some of the components in the Home Page are colored based on Baseline thresholds, the Alarms flow stays the same:
Metric data > Rule > Alarm (if there is a reason to fire the alarm). So there are two different paths here:

• The colors of the Home Page Baseline based components
• The colors of the Alarms for the same components that are driven from the regular path of a Rule thresholds that are checked against the metric data.

A typical scenario here would be a green Wait components in the Home Page, while an Alarms is fired with different color for the same component.

Those are Multiple Severity Alarms.

• Rule which is based on Baseline thresholds will fire according the Baseline thresholds.
  Baseline thresholds have their own learning curve and inner algorithm and cannot be modified.

Baseline Alarms are concidered as Multiple Severity Alarms.

• Besides the Multiple Severity alarms, there are the Simple Rule alarms.
  thos alarms have only one severity defined, and the color will be one as well (yellow, in most alarms).

Alarm Acknowledgement and Status

Alarms are acknowledged automatically when the severity status is changed (for example from yellow to red, or from orange to yellow). Once an alarm is fired, it won't fire again. The reason for not firing the same alarm again is related to the Rule checking the Metric data.  The Rules are checking the data segments of the metric every 30 seconds, and assuming the issue persists - it will fire (theoretically) an alarm every 30 seconds. In order to avoid the huge overhead, the Rule checks both the metric data and if an alarm was already fired (assuming there is a need for an alarm, of course). If there is a need for an alarm on the one hand, and an alarm on the same subject/metric was previously fired then the current alarm stays put and no new alarm is triggered.

A typical scenario here would be an Alarm with certain figures that stays put even after 1 hour.

The Home Page

Foglight for SQL Server Home Page answers on the Monitored Instance Real Time figures (Current data segment of the Metrics).

Foglight for Oracle Home Page shows the Average of the selected time period (default is one hour) figures (Period data segment of the Metrics).

The difference between the Home Pages is because of history legacy to Sosse that is maintained for Foglight for SQL Server.

Correlation to the Home Page and Alarms severity in Foglight for Oracle

The Home Page for *Foglight for Oracle is composed from multiple components, and some of the components are colored relaying on the Baseline thresholds (the same yellow, orange and red as with the regular thresholds).
The Baseline based components in the Home Page (for example, all the Wait Event components) will be colored in green if the Baseline learning curve has not been stabilized.
it takes minimum of 24 hours for the Baseline learning curve to be adjusted to the environment.

While some of the components in the Home Page are colored based on Baseline thresholds, the Alarms flow stays the same:
Metric data > Rule > Alarm (if there is a reason to fire the alarm).
So there are two different paths here:

• The colors of the Home Page Baseline based components
• The colors of the Alarms for the same components that are driven from the regular path of a Rule thresholds that are checked against the metric data.

A typical scenario here would be a green Wait components in the Home Page, while an Alarms is fired with different color for the same component.