Managing Alerts using Alerts v2

You can now add default alerts to v2 alerting. The initial set includes:

• Auvik Collector Disconnected
• Auvik Collector Discovery
• Firmware Change on Network Element
• High Broadcast Traffic
• High CPU Utilization
• High Interface Utilization
• High Memory Utilization
• High Packet Discard(s)
• High Packet Error(s)
• High Storage Utilization
• Infrastructure Device Offline
• Network Element Offline
• Recent VMware Snapshot Not Taken
• Software Version Change on Network Element
• VMware Hypervisor CPU Module is Bad or Degraded
• VMware Hypervisor Hard Drive is Bad or Degraded
• VMware Hypervisor Power Supply is Bad or Degraded
• VMware Hypervisor RAM Module is Bad or Degraded
• VMware Snapshot Limit Exceeded
• VMware Snapshot Repository Size Exceeded

See List of Preconfigured Alerts and Default Settings for each in Auvik Alerts v2 for the full list and detailed descriptions of each.

To add the default alerts, from your Auvik instance:

1. Click on Manage Alerts
   
2. Click on Alerts V2
3. Mouse over the gear() icon and click Add Default Alerts
   
4. Click Add Default Alerts on the pop up that appears
   

After a few second a message will appear confirming that the new default alerts have been added and you will see a list of Alerts appear in your Manage Alerts > Alerts 2.0 section.

Note: If you don't see Add Default Alerts as an option:

• Make sure you’re on the Alerts 2.0 Table tab (not Legacy alerts).
• Confirm your role/permissions allow alert management at this site.
• Clear any table filters and refresh the page.

If the option still isn’t visible, contact support and include a screenshot of the Manage Alerts page.

Existing alert definitions can be sorted and filtered to find the right one. Select one or more alert definitions to perform a number of actions on them.

Alerts v2 Management

Users will see both the existing Manage Alerts > Alerts and a new Manage Alerts > Alerts V2 in the lefthand navigation. Users can manage legacy alerts as they always have, while the new page allows users to create new alert definitions and to manage them in a similar fashion.

Similar to legacy alerts, users can navigate to any point in their account hierarchy to view, create and manage the alert definitions relevant to that site. Users can sort the table’s columns and filter the list using various properties using the Search Alerts text box.

By selecting a checkbox beside an alert definition’s name, users can either view, edit, delete, enable/disable or clone the selected alert definition.

All Alerts View

Triggered alerts, whether from legacy alert definitions or new alert definitions, will continue to appear in the existing All Alerts page. Click on the row to view the Alert Details, or select a checkbox to perform any actions. V2 alerts cannot be dismissed manually but that will be addressed shortly.

Note: The Pause action button does not apply to v2 alerts (Check out Alert Delay for more details on how we’ve replaced the Auto Pause functionality).

A new field named Source in the Alert Details view will specify if this alert was created from a Legacy or V2 alert definition.

We recommend naming your alert definitions accordingly, so you can easily identify new Alerting v2 alerts from your legacy alerts (e.g. 2.0_Infrastructure Device Offline). If it’s ever unclear where a specific alert came from, just refer to this Source field in the alert details view.

Alert Definition Auditing

User actions to create, enable/disable and delete alerts are captured in the Audit Log. Additionally, edits of individual fields in the alert definition will appear in the Audit Log as well.

Alert Resolution Timing

After a device recovers, there can be a short delay before the alert transitions to a resolved state. This is expected behavior because Auvik confirms a stable recovery through its health-check cycle before marking the alert as resolved.

What you might observe:

Alerts v2: The alert resolves correctly once stability is confirmed, but the resolved event rows themselves can remain visible until you dismiss them.

During the confirmation period, it may appear that the alert is still active even though the device is back online. Once the health checks pass, the alert updates to Resolved.

Tips:

• Allow a brief window for the health-check cycle to complete before expecting the alert to clear.
• Refresh the page and dismiss resolved event rows to keep your view tidy.
• If tickets are tied to alerts, expect that ticket updates or closures may follow the alert’s resolved state with a short delay.

Managing Alerts in Multiple Sites and Creating Variants

Navigate to any site within your account hierarchy to view the alert definitions that have been applied to that site. Whether the alert definition was created at the site you’re viewing or at a parent site and then applied to the current site, it will be displayed here.

After tenant consolidation: verify Alerts v2 alert definitions

After sites or organizations are consolidated into a destination tenant or parent organization, review Alerts v2 alert definitions before relying on them for production notifications.

Alert definitions may be disabled, limited to an unexpected set of sites, or replaced by site-specific variants during organizational changes. Alerts v2 does not rely on simple parent-to-child inheritance for all alert behavior. Each alert definition has an applied site scope that should be reviewed directly.

Review Alerts v2 alert definitions

A user must have the required permissions to manage alert definitions. If you cannot edit or enable an alert, contact the Auvik administrator for the destination tenant.

1. Sign in to the destination tenant.
2. Navigate to Manage Alerts > Alerts v2.
3. Review the alert definitions that should be active after the consolidation.
4. Confirm that each intended alert definition is enabled.
5. Review the sites or organizations to which each alert definition is applied.
6. Confirm that the alert conditions, notification channels, severity, and timing settings are still appropriate.
7. Enable the alert definition or update its applied site scope if required.
8. Use the audit log, where available, to review recent alert-definition changes.

Disabled alert definitions remain visible in the alert list but do not generate alerts or notifications.

Review legacy alerts for duplicate coverage

Alerts v2 and legacy alerts can operate at the same time. If both systems monitor the same condition and use the same notification channel, duplicate notifications may be generated.

After confirming that the Alerts v2 definition is enabled and correctly scoped:

1. Review the related legacy alert definitions.
2. Identify legacy alerts that monitor the same devices, services, or conditions.
3. Disable the legacy alerts that are no longer required.
4. Confirm that the remaining notification channels are still appropriate.

Do not disable a legacy alert until the replacement Alerts v2 definition has been reviewed and tested.

Audit a sample of sites

When many sites are affected, validate a representative sample before reviewing every site.

For each selected site:

• Confirm that the expected Alerts v2 definitions are visible.
• Confirm that the site is included in the alert definition’s applied-site scope.
• Confirm that the alert is enabled.
• Review the notification channels associated with the alert.
• Check whether a site-specific variant is replacing the intended organization-level or global alert.
• Confirm that similar legacy alerts are not still active.

Alerts v2 supports applying one alert definition to one, many, or all sites. A child site can also have a variant with different behavior, so site scope and alert variants should be reviewed rather than assuming that all settings are inherited automatically.

Validate alert delivery

Use a non-disruptive validation method whenever possible:

• Use Send Test Alert to verify notification-channel delivery.
• Review a recent alert generated by a known monitored condition.
• If a condition must be simulated, use a non-production site or an approved maintenance window.
• Confirm that the expected alert source is Alerts v2 and that the notification is delivered only once.
• Restore any temporary test changes after validation.

Alert definitions don’t strictly follow a hierarchy in terms of sites inheriting other site’s alert definitions. Instead, an alert definition can be applied to any or all sites that is desired, even if it means skipping levels in the account hierarchy.

An alert definition can only be edited from the site of which it was created (mentioned in the aforementioned Permission Access Level column). When an alert definition is edited, the changes are applied to all sites that it is applied to.

Note: When any aspect of an alert definition is edited it is completely reset in terms of active alerts, Alert Delay timers and any other in-progress states. Due to aspects of the alert definition changing, like the trigger condition, Alert Delay timing elements, and clear conditions, any change to the alert definition will invalidate it.

For example:

• If an alert definition for a specific site is 4 minutes into an Alert Delay timer (see Creating Alerts) set for 5 minutes and you change the alert definition by changing the Alert Delay timer value, the alert definition is invalided so the timer and other aspects are reset.
• If an alert has been triggered and is active, but you then change the trigger condition, clear condition, notification channels, or any other aspect of the alert definition, it is invalidated and the active alert will be closed.

Creating Variants for Specific Sites

Sometimes there will already be an alert definition applied at a parent site, but you decide a child site should have a slightly different version or even that the child site should have another similar alert that runs in parallel to the original.

It’s easy to create variants of existing alert definitions by selecting the alert definition in the Manage Alerts > Alerts V2 table and clicking the Clone action button.

Start by navigating to the site where you want the different alert definition behaviour to start. For example, if you have an alert definition created at the global site level which is applied to all sites, but you want a multi-site and it’s children to have a different version of the alert, then navigate to that multi-site.

Select the alert definition of interest by clicking the checkbox to the left of it. Now click the Clone button to open an alert definition edit screen with the fields pre-populated based on the selected alert definition.

Now make any changes to the parameters of the alert definition (Check out Creating Alerts for more details), including setting which child sites this variant alert definition should be applied to. Any or all of the child sites can be selected --they don’t all have to be subjected to this new variant alert defined at the parent site.

Before saving this variant alert, if you’re immediately ready for this alert definition to be active, be sure to enable the alert definition using the toggle at the top of the page. If you’d rather make other adjustments to this or other alert definitions first, then leave the toggle off and you can always make the alert definition active later by using the Enable action button on the alert definition table (Manage Alerts > Alerts 2.0) or by editing the alert definition again.

Examples

Say we have a few organizations set up in our global level site and each of those companies have several children sites. Let’s say we want to alert if memory utilization is >= 80%. We could set up a new alert definition at the global level site (Check out Creating Alerts) and apply it to all organizations and sites, then:

Create a Variant to run in Parallel

Quickly create a variant alert definition for CPU utilization by cloning the memory utilization alert at the global level site. An easy change of the trigger condition, while keeping all other settings, will get this new alert definition up and running fast. Both the memory and CPU utilization alerts would run in parallel for all sites under the global level site.

Create a Variant to Replace One or More Sites

Change the sensitivity of the memory utilization alert definition for a specific organization and it’s children while keeping other organizations and their sites the original value (>=80%).

Navigate to the organization we want to create the variant alert for, select the memory utilization alert definition and click the Clone action button. Change the trigger condition to >=60% and apply the alert to all the children sites belonging to this organization.

Finally, return to the global level site and edit the original memory utilization alert definition to now exclude the organization and its children from the original alert. Now the original memory utilization alert definition will run at >=80% for all organizations and site except for the one we created the variant alert for >=60%.

Check out Alerting v2 Activities - Creating Your First Alerts article for more examples.

Related articles

• Using Alerts v2
• How do I add, edit, or delete alerts?
• Understanding Alert Notification Channel Inheritance
• How to Use the Send Test Alert Function Alert Definitions