|Note: Use policy-based alerting for all new alerts. SQL-based alerting remains available only to customers with existing SQL-based alerts (see SQL-based Alerts).
Kentik Detect’s policy-based Alerting system is covered in the following topics:
- For information on settings for alert policies, see Alert Policies.
- For information on active or historical alerts, see Alert Dashboards.
- For information on alert-related notifications, see Alert Notifications.
- For information on mitigation for alerts, see Alert Mitigation.
A policy-based alert is essentially a set of comparative evaluations that, when one or more comparisons result in a match (see About Matches), can trigger an alarm (the alert enters ALARM state; see Alert States), which results in an action such as a notification and/or DDoS mitigation. Alerting is implemented via alert policies, which each define the characteristics of an individual alert in the following areas:
- Evaluated traffic: What traffic flow data do you want to evaluate as it is ingested into Kentik Detect?
The Devices, Query, and Filters pane of the Alert Policy sidebar, as well as general policy settings related to top-X depth and minimum volume, are used to define the scope of the traffic that will be evaluated. You can also set the time interval between evaluations.
- Comparison mode: What’s the comparate to which the current traffic will be compared?
Current traffic can be compared to a static value, a historical baseline, and/or an existence condition (i.e. specified traffic does or does not exist).
- Thresholds: What sorts of differences between the current traffic and the comparate will trigger an alarm?
Each alert can include up to five thresholds, each with its own comparison mode and settings that determine the conditions that will trigger an alarm, the timing for entering and leaving alarm state, and the actions to take in response.
- Actions: What actions will occur in response to an alarm?
Each threshold includes settings for its own independent set of actions, which boil down to various options for notification and/or mitigation. As an alert enters alarm state it will also be added to the Active Alerts list (see Active Alerts), which lives on the Active page. When an alert leaves alarm state it is shifted to the list on the History page instead (see Alert History).
Once an alert policy is defined and saved it will appear in the list on the Alert Policies Page, which is where policies can be added, duplicated, and edited.
If an alert policy is enabled, the flow data sent to Kentik Detect from your network devices (routers, hosts, etc.) is evaluated at the specified evaluation frequency for a match between the characteristics of the evaluated traffic and the characteristics defined in any of the alert’s thresholds (see Threshold Conditions). If a specified number of matches are found within a given period of time (see Activate When Settings), an alarm is triggered and the system responds with the actions specified in the threshold that has been matched.
Note: Alert policies enable exceptionally powerful control but can be challenging to configure. The Kentik support team encourages you to contact us at firstname.lastname@example.org for assistance with alert policy configuration.
A key is an identifier that represents a unique combination of values for a given set of dimensions. Suppose, for example, that the dimensions are Destination Interface, Destination BGP AS_Path, and Full Device. The definition of the key (“key definition”) will be “Dest Interface, Dest BGP AS_Path, Device.” And each unique combination of values for those three dimensions (e.g. “209:64901:8367”) will constitute an individual key.
In the case of alerting, the dimensions that comprise the key definition are chosen on the Dataset tab of the Alert Policy Dialogs (Add Alert Policy or Edit Alert Policy). The top-X ranking of traffic is performed by evaluating the volume, as measured in the primary metric, of the traffic — across the selected devices and filtered by the specified filters — that is represented by each individual key.
The Alerting section of Kentik Detect is accessed from the Alerting menu on the main Kentik Detect navbar (Alerts » Alerting). The pages in the Alerting section are organized spatially into two main parts:
- Work area: The main part of the window, where information is displayed and settings are set.
- Sidebar: An area at left that contains a list of links to the individual pages that make up the Alerting section of Kentik Detect (see Alerting Pages).
Note: If your organization has any currently configured SQL alerts then a SQL Alerts link will be displayed at the bottom of the sidebar. Clicking the link shows additional sidebar menu items that enable access to the SQL alert areas of the portal.
Policy-based alerts are defined and managed on the following pages of the Alerting section:
- Active: A filterable list of alerts that are currently in alarm state; see Active Alerts.
- History: A filterable list of alerts that have triggered alarms but are no longer in alarm state; see Alert History.
- Debug: A list showing values of keys (combinations of one or more dimension) from the most-recent evaluation of a chosen alert and the corresponding baseline (if any) for that alert; see Alert Debug.
- Policies: A list of alert policies (see About Alerts and Policies), from which policies can be added, duplicated, and edited. This page (see Alert Policies Page) enables access to the Alert Policy Dialogs, which contain the UI for specifying the details of an alert policy.
- Library: A list of preset alerts provided by Kentik to cover common situations about which customers might want to be notified; see Alert Library. Presets can be duplicated and then edited to produce alerts that are tailored to the specifics of your situation.
- Silent Mode: A list of Alerts that are in learning mode, which means that no alarms will trigger because information for baseline values is still being collected; see Alert Silent Mode.
- Channels: A list of channels (see Channels Page UI) that each represent a notification mode (e.g. email) and notification targets (e.g. a set of email addresses); see About Notification Channels.
- Platforms: A page listing the available platforms on which to run a mitigation (see Platforms Page UI). Platforms can be built in, like Remotely Triggered Black-Hole routing (RTBH), or third party systems like Radware DefensePro or A10 Thunder TPS.
- Methods: A page listing the available methods (mitigation configurations) to be run on a mitigation platform; see Methods Page UI.
- Manual Mitigation: A page enabling you to apply a mitigation manually in real time without having a corresponding alert that is in alarm state; see Manual Mitigation.