Alerting

Quiet vrs Exclude hours

Alerting quiet vrs exclude hours
Quiet hours, in short it works the same way old Exclude used to work and upon end of the quiet interval alerting will look back for the repeat duration.

Exclude hours

Defines a time window during which performance thresholds are not evaluated.
Metric values collected during this period are ignored for alert evaluation. They do not contribute to threshold duration, alert generation, or any alert state.
This option is useful when predictable workload is expected, such as backup jobs, maintenance windows, batch processing, or scheduled system activities that should not affect alerting.

Example
A database backup runs every night between 01:00 and 03:00 and causes storage latency to exceed the configured threshold.
By configuring a Monitoring Exclusion for this period, XorMon ignores these measurements entirely. Threshold duration does not accumulate, and no alert is generated based on the excluded interval.

Quiet hours

Defines a time window during which alert notifications are not sent.
Unlike Exclude hours, threshold evaluation continues normally. Metric values are processed, threshold duration continues to accumulate, and alert state is maintained.
If an alert condition is active when the suppression period ends, XorMon sends the alert according to the configured Repeat policy.
This option is useful when administrators want to avoid receiving notifications during certain hours, while still preserving complete monitoring history and alert evaluation.

Example
Notifications are suppressed between 22:00 and 06:00.
A CPU utilization threshold is exceeded at 23:30 and remains above the threshold until 08:00.
XorMon continues monitoring throughout the night but does not send any notifications during the suppression window.
After 06:00, if the threshold is still exceeded, an alert is sent and includes the full alert context, including the time during which the notification was suppressed.

Follow this to read about Anomaly alerting.
SAN Ports event alerting is capable to work in 3 modes:
  • Default ➡ It raises an alert when any SAN port goes to the "red" status.
  • Offline ➡ It raises an alert when any SAN port changes from the "green" state to the Offline/Down state.
  • Any change ➡ It raises an alert when any SAN port changes from the "green" state to the other color state.

SAN port alerting

Prediction alerting

Use alerts based on predicted resource utilization to strengthen proactive monitoring capabilities.

Configuration

  • Settings ➡ Alerting ➡ Prediction tab ➡ New Alert Group
  • Select metrics for which you want to be notified of their predicted behavior
  • Days to Threshold: Alert if prediction reaches threshold within specified number of days
  • Model: Prediciton model, 'Auto' selects reactive prediction model, otherwise you can use specific trend predictions
  • Similar to performance alerting, predictive alerting can send information about events via email or other configured integrations

Alert setup:
Predictive alerting 1

Alert message example
Predictive alerting 2
Follow this to read about Ping alerting.
You can create alerts based on performance data metrics for all configured devices.
Any metric that is collected by the tool can be selected for alerting.
Configure it via the UI ➡ Settings ➡ Alerting ➡ Performance
Define email groups under "Email" tab at first.

How to create a new alert

Storage-based alert: select "Storage" ➡ New Alert Group
Alerting cfg 1

Put a name, select a class, subsystem (volume) and volumes here via regex ('.*' means all volumes on all storage devices) ➡ Add
Alerting cfg 2

Select a metric (Latency)
Alerting cfg 3

Put threshold and email targed groups defined in advance ➡ Save
Alerting cfg 4

Then via a "+" sign in the alert line on the right you can add more metrics to be alerted for the same alert group.

Video

  • Alerting
  • Filter items by parent device

Examples

Email alerts have included graphs by default, you can set your own time range of that graph in the Alerting Options tab

Storage email alert
Alerting example 1

Alerting example 1 attachement


Server email alert
Alerting example 2

Alerting example 2 attachement


It raises an alert when any critical HW or SW error is detected for any devices.
Basically, the alert is sent when any device goes to the "red" status in the global health status dashboard.
Once a device goes back to "green", clear alert is sent.
You can configure via the UI ➡ Settings ➡ Alerting ➡ HW Events
Define email groups under "Email" tab at first.

Alerting event