Alert Conditions & Correlation
NetCrunch alerts trigger proactive actions, not just notifications. They detect missing events and complex conditions while correlating events across nodes to enable tailored responses and automated remediation.
Conditional Alerts
NetCrunch allows you to define additional conditions for each defined alert, regardless if it is a node status, an event log alert, or the SNMP trap. These conditions allow you to trigger an action, even if an event has not been triggered. For example, if there is no log entry confirming an operation (i.e., backup). Also, NetCrunch can receive heartbeat events and notify if one is missing. Other conditions allow you to suppress alert execution for some time (as the alert won't be triggered, the actions set to run on alert close won't be executed).
Available conditions
- On Event Condition
- This is a regular event just triggered by an event condition.
- The event happened at least after (a given time)
- The alert will be triggered only if the event happens after a given time after the previous event of the same type.
- The event happened more than (x times in the last y minutes)
- The alert will be triggered if the event happens more than x times within the given time period.
- Only if the time between
- Restrict events to the given time range. Instead of disabling monitoring, you can disable specific events by setting a time range for them. The time range mask can be set for all weekdays.
- Only if time not between
- Restrict events to a given time range by exclusion.
- The event did not happen in the time between
- Trigger alert only if the event did not happen in the expected time range. For example, you are watching for confirmation of the backup or any other periodic task. It might happen that instead of getting an error, we got nothing.
- The event did not happen after a given time.
- Trigger the alert if the specified event is not detected (received). This condition helps monitor heartbeat kind events. This is one of the simplest alerting schemes implemented by many hardware devices. So we are expecting to receive events every given time period which suppress triggering the alert.
- Event pending for more than (a given time)
- The alert is suppressed for a given period of time to wait for it might be cleared. It is particularly useful in cases when the external event source is oversensitive.
Basic Correlation
NetCrunch triggered alerts are automatically correlated. It means that when the condition causing an event is no longer present, a closing event is triggered, and the alert is closed. This helps manage the pending alert list and execute an action (notification, closing ticket action) on alert close.
Correlating External Events
It is fairly simple when the external source (i.e., trap, syslog message) triggers an event confirming that the alerting condition is no longer present. In such a case, you can add closing correlation events to the given alert.
You can also decide to close the alert automatically after some time, or you can use the alert condition to define a closing alert.
Example
The device sends an alarm message every minute. If there is no error for 2 minutes, we can assume the alert is closed.
Advanced Correlation
Settings Alerting & Notifications Monitoring Packs and Policies Global
You can find the Correlations Monitoring Pack in the global section of defined monitoring packs. It allows defining alerts triggered when alerts from multiple nodes happen within the same time range (window) or when all alerts in the group are pending (all have to be correlated).
These correlated alerts can be for any events previously defined on any node in the Atlas.