How can we help?

Alerting 2.0 Beta User Guide

Follow

Auvik has been listening to your feedback and we thank you for your interest in the Beta. We look forward to your continued feedback as we move from the Beta to the general release later this year.

Alerts are a big part of your day to stay on top of changes to your network. Auvik has invested in a new alerting engine to address several fundamental concerns and to provide a more scalable and dynamic solution that can more easily adapt to new types of alerts.

By utilizing more powerful conditional logic and controlling the timing of how long conditions need to be true before triggering an alert, our goal is to facilitate richer alerts, reduce alert noise and simplify the ongoing management of alerts. With the addition of device tags, users can easily re-use groups of devices while creating new alerts.

Important Beta Details

The Beta release is a preview of the upcoming new Auvik alerting functionality. As such, it isn’t quite 100% of what the general release will be like. See the Alerting v2 Planned Releases article for more details of how the new Auvik alerting experience will evolve over time.

Any alerts created with the new alerting experience workflows during the Beta are not guaranteed to be available after the Beta has ended. Technical requirements may change during the Beta which may require us to reset data or make other changes which will render the Beta alerts no longer compatible.

Since the existing notification channels will serve both legacy and new Beta alerts, please be advised that if you use the same notification channel for similar alerts between the legacy and Beta alerts, you will receive duplicate notifications. For comparison testing purposes, we recommend setting up additional notification channels that are directed towards your testing users, so that your business operations are insulated against potential duplicate notifications.

Scope of the Beta

The new Auvik alerting experience will be rolled out as a side-by-side experience with all of your legacy alerting configuration. We’ll gradually add more and more new alerting functionality in new releases after the Beta which will give you time to evaluate the new alerts and migrate legacy alerts to the new system. When the new alerting solution has replaced and exceeded the business value of the legacy alerts, the legacy system will be retired.

Legacy Alerting

You will continue to have access to your existing legacy alert definitions and will also continue to receive your usual alerts and notifications through email, Slack, ConnectWise Manage, or any other integrations you currently have configured. Additionally, the Auvik API will continue to operate as usual.

Global Site-Level Scope

The Beta is restricted to creating and managing alerts at the global site-level. The global site-level is the billing account with Auvik, most often an MSP.

What this means is that new alerts can only be created while you’re viewing the global site-level. If you’re currently looking at or a specific site in the account hierarchy, the create new alert controls will not be visible. This also means that any alerts that are created will be applied to all sites in the account, and during the Beta you will not be able to disable or override the alert for a specific site. These additional management features will be available for the general release, allowing users to specify exactly which sites alerts should apply to and be able to tweak settings for specific sites.

Alert Trigger Conditions

Not all alert trigger conditions will be available at the start of the Beta, but more will be added between the Beta and general release which will provide net-new alerts plus parity with what you can alert on in legacy alerts. We’ll continue to add more new types of alerts after the general release as well.

Two of the Beta alert trigger conditions are related to Cloud Ping Packet Loss which are new and are not available in legacy alerting while the remaining are present in legacy alerting.

All available Beta alert trigger conditions include:

  • Cloud Ping Packet Loss

    • Last Ping Successful

    • Cloud Ping Packet Loss (%)

  • Network Element Offline

    • Device Online Status (Offline/Online)

  • High CPU Utilization

    • CPU Utilization (%)

  • Packet Discards

    • Interface Packet Discard Count (#)

  • Packet Errors

    • Interface Packet Error Count (#)

Pre-Configured Alerts

There are no pre-configured alerts using the new Beta functionality, but the legacy versions remain. Once all of the initial alert trigger conditions are available with new alerting, we’ll add several net-new pre-configured alerts in addition to replacing any valuable legacy pre-configured alerts.

Alerting Noise

The Beta includes several alert noise reduction mechanisms, including alert delays, boolean operators for more refined alerts, and being able to alert on any or all interfaces in a single alert. We are still working on the logic for reducing downstream alerting noise, and this will be available post-Beta.

Legacy vs New Alerting Summary

Feature

Legacy

New Alerting Beta

Scope of Alerts

Define, override, or remove alerts at global site-level, multi-sites, or sites.

Alerts at global site-level only applied to all multi-sites and sites within account. Will be more flexible post-Beta.

Managing & Creating Alerts

Navigate to “Manage Alerts > Alerts”.

Navigate to “Manage Alerts > New Alerts”.

Devices and Interfaces

Alerts were executed against individual devices and interfaces which results in the need to specify each interface and receive separate notifications for each.

Interfaces are now included in a device and an alert can specify a condition on any or all interfaces in one device which results in only one notification.

Condition Builder

Alert definition conditions could only be built with an AND boolean operator. This required users to create two alerts if they wanted to monitor two things but only cared if one of them happened.

Alert definition conditions can now be built with ANDs and ORs, and it’s more intuitive to chain multiple conditions together.

Alert Delay

Alerts were triggered immediately when an alert definition’s condition is true. This results in noisy alerts when conditions flap or quickly self-heal.

Any alert can have an alert delay setting which requires the alert definition’s condition to stay true for a specified amount of time before an alert is triggered and notifications are sent.

Custom OID Alerts

Users can build alerts using custom OIDs defined in SNMP Poller Settings.

Custom OID alerts are not supported in the Beta, but this capability will be added post-Beta.

Notification Channels

Navigate to “Manage Alerts > Notification Channels”. Can continue to use as normal for legacy alerts.

Can leverage any existing or create new notification channels from “Manage Alerts > Notification Channels” to use with legacy or new Beta alerts.

Maintenance Windows

Navigate to “Manage Alerts > Maintenance Windows”. Can continue to use as normal for legacy alerts.

Can leverage any existing or create new maintenance windows from “Manage Alerts > Maintenance Windows” to use with legacy or new Beta alerts.

Managing & Creating Tags

N/A

Navigate to “Manage Tags” to build custom tags of devices you work with often to re-use in any new Beta alerts.

Permissions

Role permissions for the new alerting experience leverage the existing permissions. If you already have permissions for any aspects of the legacy alerting, you’ll automatically have those same permissions to the new alerting as well. Additionally, there is a new role permission for managing Tags (see Managing & Creating Tags for more details of tags in general).

Existing role permissions

A role consists of multiple combinations of a feature and a level of access (Access and Edit, View, No Access). These are the existing alerting features a user needs access to. They are located under Alerts section in the edit role permissions editor.

  • Manage Alerts

    • Represents the legacy and new manage alert capabilities, including being able to create/edit/view and manage alert definitions.

  • Triggered Alerts

    • Represents the legacy and new triggered alerts capabilities, including being able to view & dismiss triggered alerts.

  • Maintenance Windows

    • Represents the legacy maintenance window capabilities, including being able to create/edit/view maintenance windows. The Beta features no changes to the maintenance windows functionality and they will continue to function for legacy alerts and also be applied to new alerts.

  • Notification Channels

    • Represents the legacy notification channel capabilities, including being able to create/edit/view notification channels. The Beta features no changes to the notification channels functionality and they will continue to function for both legacy alerts and also be applied to new alerts.

New role permissions

A new role feature property to control user access to be able to create, edit, and delete tags. This permission is located under the Admin section in the edit role permissions editor.

  • Manage Tags

    • Represents the new tag management capabilities, including being able to create/edit/view and manage tag definitions.

Managing & Creating Tags

Tags are a way to group together frequently used devices based on any number of properties. These produce dynamic lists of devices which will adapt to changes in your network when hardware is added or removed. Tagged devices can then be easily reused across any number of alerts instead of building the list of devices each time.

Managing Tags

A new navigation option named Manage Tags will be available for Beta users with the correct permissions (see Side-By-Side Rollout > Permissions for more details) which can be used to manage and create tags. This page will display a list of the tags that currently exist. Similar to managing alerts, you can select tags to edit or delete them.

alertbeta1.png

Creating Tags

Users can create a new tag by clicking the Add Tag button from the Manage Tags page. Tags are built in a similar fashion to alerts by specifying the conditions that meet the outcome you’re looking for.

Do you need to treat a certain make or model differently than others? You can create one tag to exclude that make/model and another for only that make/model. Are there specific groups of hostnames, device IDs, or serial numbers that you frequently refer to? Then create a tag which captures those specific devices.

A new tag requires a tag name. This is the name you’ll refer to in an alert to use it.

Tags currently only apply to devices.

Use the condition builder to specify the parameters of the tag by utilizing AND/OR boolean statements and various properties of devices.

  • Use + Add Rule to add a new rule to a boolean group. A rule is a device condition you want either to be true or false. For example, “device vendor is not equal to Cisco” is a rule. All rules within a boolean AND/OR group are subjected to that boolean logic. E.g. two rules under a “All conditions must be true (AND)” group specify that both rules must result true for a device to be included in the tag.

  • Use + Add Group to create a new boolean group. You can chain together multiple boolean clauses each containing different rules. This allows you to create rich boolean statements like (A AND (B OR C) AND NOT D).

For example, you want to be able to easily refer to all of my switches except for Cisco branded switches. After providing a name, we just need to create two rules under an AND group to specify we’re looking for any device whose Device Vendor is not Cisco and whose Device Make is a Switch.

alertsbeta2.png

Using Tags

For the Beta, tags can only be used while creating/editing alert definitions.

A dropdown in the alert definition builder allows you to select a tag to use. The devices defined by that tag will be used while executing the alert (see Managing & Creating Alerts for more details).

Managing & Creating Alerts

Created alert definitions are listed in a table where you can see their important properties at a glance, and also manage them by disabling/enabling, and deleting definitions.

New Alerts Management

Since we’re performing a side-by-side rollout with the legacy alerting capabilities, Beta users will see the existing Manage Alerts > Alerts and a new Manage Alerts > New Alerts. Users can manage legacy alerts as they always have, while the new page allows users to create new Beta alert definitions and to manage them in a similar fashion.

Similar to legacy alerts, 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, or enable/disable the selected alert definition.

Disabled alert definitions will remain in your list, but will no longer generate alerts and notifications. If you delete an alert definition it will be permanently removed. User actions to create, edit, and delete alerts are captured in the Audit Log.

alertbeta3.png

All Alerts

Triggered alerts, whether from legacy alert definitions or new alert definitions, will continue to appear in the existing All Alerts page. A new column in this table will appear during the side-by-side rollout to tell users if a specific alert came from a legacy or new alert definition. This will be handy for users to compare alerting results between the legacy and new systems while they are migrating their usage of alerts.

A Note on Devices & Interfaces

For alerting purposes, devices now include interfaces, components and anything else associated with the physical device. This allows users to create rich alert definitions with any data available to the device, including interfaces.

In legacy alerts, if you had 10 interfaces you wanted to keep an eye on, you had to explicitly include the 10 interfaces and you’d receive up to 10 alerts if any or all of the interfaces met the alert conditions. With Auvik’s new alerts, users can now just ask the device if any or all of its interfaces meet a certain condition in one alert with a single notification outlining any or all of the interfaces.

Creating an Alert

To create a new custom alert, click on the Add Alert button from the Manage Alerts > New Alerts page. Unlike legacy alerts, there is no need to select the type of alert (e.g. collector, device, service); instead, the choices you make while building the alert will dynamically add and remove additional options.

Alert Definition Metadata

New alert definitions start with an Alert Name and Alert Description.

  • Alert Name: Provide a short, but descriptive name.

  • Alert Description: This description is used to help identify and provide more context about what this alert definition is about. This will be referenced within the Auvik portal and can provide context while editing the alert in the future. An additional field named “Trigger Message” will allow a dynamic message which you’ll see as part of notifications for triggered alerts.

Scope of Alert

A dropdown named Apply Conditions to allows users to select the scope of this alert definition. The list of options will increase post-Beta to include services.

  • Collectors

    • Create conditions to alert on your Auvik collectors.

  • Devices

    • Create conditions to alert on desired devices.

  • Interfaces on a device

    • Create conditions to alert on any or all interfaces on desired devices.

  • Cloud ping check

    • Create a cloud ping check condition. This will become one of many service-based type alerts post-Beta.

Device Selection

For Devices and Interface on a device type of alert definitions, users need to define the applicable devices.

  • All Devices

    • The alert will be applied to all devices within the current account context.

  • Devices with this tag

    • User can select a tag that has already been created which represents a defined group of devices based on the properties of that tag.

  • Devices that match these conditions

    • User can specify the specific conditions which specify a list of devices to use with this alert. This is similar to the user experience of building a tag (see Managing & Creating Tags > Creating Tags).

Severity

Similar to legacy alerts, there are four severity options --Informational, Warning, Critical and Emergency. Clicking the Add button beside the desired severity will add a new section to the workflow and allow you to continue.

Trigger Conditions

Use the condition builder to specify the parameters of the alert by utilizing AND/OR boolean statements and various properties of devices.

  • Use + Add Rule to add a new rule to a boolean group. A rule is a device condition you want either to be true or false. For example, “…” is a rule. All rules within a boolean AND/OR group are subjected to that boolean logic. E.g. two rules under a “All conditions must be true (AND)” group specify that both rules must result true for this alert to be successful.

  • Use + Add Group to create a new boolean group. You can chain together multiple boolean clauses each containing different rules. This allows you to create rich boolean statements like (A AND (B OR C) AND NOT D).

Alert Delay

In addition to an alert definition’s trigger condition, users can use an Alert Delay to specify how long the condition needs to remain true before the alert should actually trigger.

Alerts which immediately trigger with no delay can cause noise when a condition momentarily flaps or a one-off occurrence self-heals before a user even sees an alert.

Users can simply pick a time in minutes that their alert condition should remain true before any notifications are sent. When something first matches the alert’s trigger condition, a timer will begin to make sure that condition holds true for the specified time before creating an alert. If the specified condition no longer matches before the timer reaches the desired alert delay value, then no alert and notifications are created. When this happens, the timer resets and we start over.

For example, let’s say you have some interfaces you want to keep an eye on for packet discards. You know some of a device’s interfaces sometimes have a heavy load and packet discards can sometimes spike, but you don’t consider it a problem until at least one interface on the device has spiked over 100,000 and stays that way for at least 5 minutes. When creating your packet discard alert with a condition threshold of >= 100,000, you’d simply specify an 5 minute alert delay value.

alertbeta4.png

Trigger Message

The trigger message is the summary of the alert you’ll see in notifications and can use variables of the device to create dynamic messages to give you the information you need quickly.

Notifications

Select the notification channels which apply to your alert definition. Similar to legacy alerts, you can select zero, one or more notification channels in the same alert definition. Regardless of any notification channels you select, be aware that an alert will always be displayed in the All Alerts page of the Auvik portal.

Users can continue to leverage their existing Notification Channels they are already using or create additional channels specifically for Beta testing. Please be advised that if you use the same notification channel for similar alerts between the legacy and Beta alerts, you will receive duplicate notifications. For comparison testing purposes, we recommend setting up additional notification channels that are directed towards your testing users, so that your business operations are insulated against potential duplicate notifications.

For example, if you have an existing Auvik Collector Disconnected legacy alert using an email notification channel and you create a Beta alert that has the same condition and uses the same email notification channel, you will receive a notification for both legacy and new Beta alert.

Clear Condition

The clear condition determines when a triggered alert is no longer an issue and the alert can be dismissed. Similar to legacy alerts there are three options:

  • Default – Inverse of Trigger Condition

    • By default, the inverse condition is used to clear the alert.

  • No Clear Condition – Clear by Dismissing

    • This requires a user to explicitly clear the alert from the Auvik portal.

  • Custom Clear Condition

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request