Policy Alerts Overview

Kentik'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 Alerting.
- For information on alert-related notifications, see Notifications.
- For information on mitigation in response to alerts, see Mitigations.


About Alerting

Kentik's powerful alerting system analyzes your network traffic and detects anomalous patterns that may indicate adverse conditions threatening availability or performance. The system is built around alert policies that define a set of conditions. When those conditions are met the policy enters "alarm state" and generates an alert. A policy can be configured to generate notifications in response to an alert, as well as to initiate automatic mitigations, either built-in (e.g. Flowspec or RTBH) or third-party (e.g. Cloudflare, Radware, or A10).

For documentation of the UI used to manage Alerting in the portal, please refer to the following:

  • The logic of alert policies is covered at a high level in Alerts and Policies.
  • The Kentik portal pages involved in configuring and managing alerting and mitigation are listed below in Alerting Pages.

Alerts and Policies

Kentik's alerting system is implemented via alert policies. A policy is essentially a set of comparative evaluations that, when one or more comparisons result in a match (see About Matches), can trigger an alert (the policy enters ALARM state; see Alert Status), which results in an action such as a notification and/or DDoS mitigation.

Each policy defines the characteristics of your network traffic that will result in an individual alert and the response to be taken by the alerting system once an alert is triggered. The configuration of a policy covers the following areas:

  • Evaluated traffic: What traffic flow data do you want to evaluate as it is ingested into Kentik?
    The Data Sources, Policy Dimensions, Metrics, and Filters of the Policy’s Dataset tab, 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 track when the traffic exists or not.
  • 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 an 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 (see Notifications) and/or mitigation (see Mitigation Overview). As an alert enters an alarm state it will also be added to the Alerts list (see Alerts List), on the Alerting page.

Once a policy is defined and saved it will appear in the list on the Policies Page, which is where policies can be added, cloned, and edited.

Policy Types

When a policy is created — either by a Kentik user or, in the case of Policy Templates, by Kentik itself — it is assigned one of the types listed in the table below. A policy's type doesn't affect how it functions, but it does affect the locations and circumstances in which it is displayed in portal.

Assigned Type Where created Listed on Policies page Listed on DDoS Defense page
Custom Add Policy page Yes No
DDoS Add Policy page Yes Yes
Query-based Data Explorer Yes No

- The Custom and DDoS policy types may also be assigned to a Kentik-created policy template.
- The filters on the Policies page and the Policy Templates page may be used to determine which policy types are shown in the lists on those pages.


Alerting Concepts

The concepts covered in the following topics are crucial to understanding how the alerting system operates:

top  |  section

About Matches

If a policy is enabled, the flow data sent to Kentik 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 policy's thresholds (see Threshold Conditions). If a specified number of matches are found within a given period of time (see Threshold Frequency), an alarm is triggered and the system responds with the actions specified in the threshold that has been matched.

Note: Policies enable exceptionally powerful control but can be challenging to configure. The Kentik support team encourages you to contact us at support@kentik.com for assistance with alert policy configuration.

top  |  section

About Keys

At Kentik, 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 IP/CIDR, Destination Port Number, and Protocol. Each unique combination of values for those three dimensions will constitute an individual key.

In this top-x table, each row represents a key, meaning a unique combination of values for the dimensions represented by each column.

In the case of alerting, the dimensions that comprise the key definition are chosen on the Dataset tab (see Policy Dataset Settings). The top-X ranking of traffic is performed by evaluating the volume of the traffic — as measured in the primary metric across the selected devices, and filtered by the specified filters — that is represented by each individual key.

top  |  section

Additional Alerting Concepts

In addition to the concepts covered above, various additional concepts that are important to alerting are covered within the KB topics where the settings related to those concepts are made. For coverage of these additional concepts, refer to the following topics:


Alerting Pages

The pages used to configure and manage alerting and mitigation are:

  • Alerting (main menu » Alerting): Provides information about current or previous alerts in your organization; see the remaining topics in this article.
  • Policies (Alerting » Configure Alert Policies): A list of alert policies (see Alerts and Policies), from which policies can be added, duplicated, and edited. This page (see Policies Page) enables access to the Modify Policy pages and dialogs (see Policy Settings), which allow you to specify the details of an alert policy.
  • Policy Templates (Alerting » Configure Alert Policies » Policy Templates): A list of alert policy templates provided by Kentik to cover common situations of which customers might want to be notified; see Policy Templates. Templates can be duplicated and then edited to produce alerts tailored to the specifics of your situation.
  • Mitigations (Protect » Mitigations): Provides information about your organization’s current and past mitigations; see Mitigations.
  • Configure Mitigations (Settings » Configure Mitigations): A page listing the available platforms on which to run a mitigation and methods to run for each platform (see Configure Mitigations). Platforms can be built in, like Remotely Triggered Black-Hole routing (RTBH), or third-party systems like Cloudflare Magic Transit, Radware DefensePro, or A10 Thunder TPS; see Configure Mitigations.
  • Manual Mitigation (Protect » Mitigations): A dialog enabling you to apply a mitigation manually in real time without having a corresponding alert that is in alarm state; see Manual Mitigation.
  • Silent Mode (Settings » Silent Mode): A list of “patterns” that each represent a set of conditions (dimension/value pairs) that, when matched, will prevent the triggering of alerts on the matching traffic; see About Silent Mode.
  • Notifications (Settings » Notifications): A list of notification channels (see Notifications) that each represent a notification type (e.g. email) and notification targets (e.g. a set of email addresses).
© 2014- Kentik
In this article: