Alert Policies

Management of the alert policies used by Kentik's alerting system is covered in the following topics:

• Policies Page
• Adding a Policy
• Policy Settings
• General Policy Settings
• Policy Dataset Settings
• Policy Threshold Settings
• Policy Baseline Settings

Notes:
- For general information about policy-based alerting, see Policy Alerts Overview.
- For information on policy templates, see Policy Templates.
- For information on active or historical alerts, see Alerting.
- For information on alert-related notifications, see Notifications.
- For information on mitigation for alerts, see Mitigations.

Alert policies are managed from the Policies page, which is covered in the following topics:

• About the Policies Page
• Policies Page UI
• Policies List
• Policy Filters
• Policy Details Drawer
• Policy Debug Dialog

Note: For information on configuring a policy, see Policy Settings.

The Policies page is used to manage alert policies for Kentik’s alerting system (see Alerts and Policies). This page displays the Policies List, which is a table listing the alert policies that are currently available to your organization. Policies can be added, enabled/disabled, cloned, deleted, and edited using this list.

The Policies page can be accessed in one of the following ways:

• Settings page: Click Alert Policies in the Alerting category.
• Alerting page: Click the Manage Policies button at the upper right.

Note: While admin-level users can see and use all of the controls listed throughout this article, member-level users can only:
- See and filter the policies displayed in the Policies list.
- Open a policy’s Policy Details Drawer.
- Enable or disable policies.

The Policies page is made up of the following UI elements:

• Policy Templates: A button (at the right of the SubNav) that opens the Policy Templates page, where you can manage templates, including adding a policy from a template (see Add Policy from Template).
• Policies statistics: Just below the page title, these fields indicate the number of policies created and enabled in your organization and give the maximum allowable number for each.
• Add Policy: A button (upper right) with two parts:
  - Add Policy: Go to the Add Policy page (see Policy Settings), where you can configure and save a new policy.
  - Open menu (down arrow at right): Open a drop-down from which you can choose Add Policy from Template, which opens an Add Policy from Template dialog that enables you to create a policy from a policy template.
• Filters (funnel icon): A button that toggles the Filters pane between expanded and collapsed.
• Search field: A field that you can use to narrow the policies shown in the Policies List. If text is entered, the list will show only policies that match the text in the ID, Name, or Description column. The field will also display any filters already applied with the Filters pane.
• Filters pane: A set of Policy Filters that you can use to narrow the alert policies shown in the Policies List.
• Policies list: A table listing the policies in your organization and giving information about each (see Policies List).
• Policy Details drawer: Click on any policy in the Policies list to open a drawer from the right of the page that contains a summary of that policy’s settings (see Policy Details Drawer).

The Policies list is a table that shows all of the alert policies that are currently available in your organization. The table includes the following columns of information and actions for each policy:

• Select All (in heading row): A checkbox for toggling the selection state of all policies in the list:
  - If either no checkboxes in the list itself are checked or only some are checked then clicking this checkbox will select all policies.
  - If all checkboxes in the list are checked, clicking this checkbox will deselect all policies.
• Selected: A checkbox in the leftmost column that enables you to select the policy. When a policy is selected, the Selected Policy Controls appear above the Policies list.
• Status: The status of the policy, either Disabled (gray) or Enabled (green).
• Type: The type of the policy (DDoS, Query-based, or Custom; see Policy Types).
• ID: The system-generated unique ID assigned when the policy was created.
• Name: The user-specified name of the policy. The policy’s user-specified description, if entered, is presented below the name.
• Data Sources: The network entities whose traffic is covered by the policy, which are specified on the Dataset tab in Policy Settings.
• Metrics: The units (e.g. bits/s, packets/s, flows/s, etc.) by which this alert measures incoming flow data (see Data Funneling). The primary metric is listed first, followed by secondary metrics (if any).
• Dimensions: The dimensions defined in the policy, which combine to make a key definition that will determine how traffic is subdivided for evaluation (see About Keys). Dimensions, which are based on fields in the KDE main table, are described in Dimensions Reference.
• Used by Tenant: The My Kentik Portal tenants using this policy (“None” if not used by a tenant).
• Actions: A vertical ellipses that pops up the Policy Action Menu.

When one or more policies are selected, a series of controls appears above the Policies list:

• Add/Edit Labels: A link to the settings page for Labels, where you can create, edit, or remove the labels that are available to apply to the selected policies.
• Clear Labels: Clear the labels that are applied to all currently selected policies.
• Apply Labels: A drop-down list of labels from which you can choose one or more labels to apply to all currently selected policies. Click labels in the list to select or de-select. Click outside of the drop-down to close it.
• Enable: Enables the selected policies if they are currently disabled.
• Disable: Disables the selected policies if they are currently enabled.
• Delete: Brings up a Delete Policies dialog in which you can confirm (or cancel) removal of the selected policies from your organization’s collection of alert policies.
• Add Notification Channels: Opens the Add Notification Channels dialog, where you assign one or more existing or new notification channels to the selected policies.
• Policies selected: The number of policies currently selected is displayed to the right of the controls.

Notes: If you’ve selected both enabled and disabled policies, both the Enable and Disable buttons will appear:
- Enable will enable any disabled policies and keep any enabled policies as enabled.
- Disable will disable any enabled policies and keep any disabled policies as disabled.

The Add Notification Channels dialog allows you to assign one or more notification channels to the selected policies. The dialog has the following UI elements:

• Close: Click the X in the upper right corner to close the dialog. No notifications channels will be added to the policies.
• Notification Channels: A field that shows lozenges for each of the notification channels currently assigned to this policy. A lozenge to the left of each channel name indicates the channel's type.
  - To remove a channel from this policy, click the X in the channel’s lozenge.
  - To add a channel, click in the field to drop down a filterable list of channels in your organization. Click on a channel to add it to the field.
  Note: The drop-down list does not include channels that are already assigned to this policy. It does include disabled channels (see Enable or Disable Notification), but they can't be selected.
• Add New Channel: Opens the Add Notification Channel dialog (see Notification Settings) where you can create a new notification channel for your organization and automatically add it to the currently selected policies.
• Test Notification Channels: Send a test notification to the recipients in all currently assigned channels. Present only when the Notification Channels field is populated.
• Cancel: Exit the dialog without changing the notification channels assigned to the selected policies.
• Continue: Save the current notification channel assignments and exit the dialog.

The Action menu for each policy can be accessed via the vertical ellipsis in the following locations:

• At the right of each policy's row in the Policies List;
• At the right of the title in the Policy Details Drawer.

The menu includes the following options:

• Edit Policy: Go to the Edit Policy page where you can edit the Policy Settings.
• Enable/Disable Policy: Enable a disabled policy or disable an enabled policy.
• Clone Policy: Go to the Clone Policy page, where the settings of a new policy will be populated with the values of the policy that you cloned (see Clone a Policy).
• Delete: Open a confirming dialog that allows you to delete the policy from your organization’s collection of alert policies.
• Debug: Opens the Policy Debug Dialog which displays tables containing the top keys for current traffic and top keys for baseline data.

The policies displayed in the Policies list can be filtered using the controls in the Filters pane on the left. For filter categories with a set of checkboxes (e.g. Type):

• If any boxes are checked, only policies that match those boxes will be included.
• If no boxes are checked, there will be no matching on that category.

The pane includes the following elements:

• Close: Click the < in the upper right corner to close the Filters pane. Click the Filters button (funnel icon) above to show it again.
• Clear all (appears only when you’ve specified one or more filters): Click to clear all current filters.
• Type: The types of policies to include in the list (DDoS, Query-based, or Custom; see Policy Types).
• Status: The policy statuses to include in the list (Enabled and/or Disabled).
• Policy ID: A field with which you can filter the list to one specific policy by entering a full policy ID (no partial matching).

The Policy Details drawer is a read-only display of policy settings, including details that may not be displayed directly in the Policies list. Click anywhere on the row of a policy to open its details drawer.

The drawer contains the following elements:

• ID number: The system-generated unique ID assigned when the policy was created.
• Name: The user-specified name of the policy.
• Actions: A button (vertical ellipses icon) that pops up the Action menu (see Policy Action Menu).
• Status: A lozenge indicating the policy’s status, either enabled (green) or disabled (gray).
• Description: A description of the policy if any was provided by the policy’s creator.
• Policy Dashboard: The dashboard that is set as the destination of the Open Dashboard button for any alert listed in the Alerting list. See Policy Dashboard under General Policy Settings. A lozenge labeled Preset will be present if the dashboard is a Kentik-provided preset.
• Dataset: An expandable/collapsible pane containing a summary of the current settings of the Dataset tab of the policy (see Policy Dataset Settings).
• Thresholds: An expandable/collapsible pane containing a summary of the current settings of the Thresholds tab of the policy (see Policy Threshold Settings). The number in brackets indicates the number of thresholds in use for the policy.
• Baseline: An expandable/collapsible pane containing a summary of the current settings of the Baseline tab of the policy (see Policy Baseline Settings).

The Debug dialog provides context that can be used to better understand why a threshold (see About Alert Thresholds) in a given alert policy triggered an alarm. The Debug list (table) presents information about a given policy from two main perspectives:

• Current Traffic: The table shows information related to the top-X keys (see About Keys) for the policy in current traffic, where:
  - Current traffic is the set of flow records (and associated traffic data) included in the most recently completed aggregate. The duration of each aggregate is determined by the policy’s Evaluation Frequency setting (see the Building Your Dataset pane of the Dataset tab of the Policy Settings Pages).
  - X is defined by the Maximum Number of Keys setting in the same pane (the actual number of keys may be less depending on the Minimum Traffic Threshold setting).
• Baseline Data: The table shows information related to the top-X keys in the baseline data of the same policy (see About Historical Baselines).

Note: The Debug dialog is only available for enabled policies.

The Debug dialog is made up of the following UI elements:

• Close: Click the X in the upper right corner to close the Debug dialog.
• Top Keys: From the drop-down, choose which of the following is displayed in the Debug list:
  - Current Traffic: Information about the top-X keys in the alert policy’s current traffic.
• - Baseline Data: Information about the top-X keys in the alert policy’s baseline traffic.
• Debug list: A table that displays information related to top-X keys (current or baseline) in the selected policy. Each view has its own unique sets of columns. See Debug Current Columns and Debug Baseline Columns.

Note: When insufficient traffic is available for debugging, a message will display in place of the Debug list:
- Current traffic: “No matches found” may mean that there is no traffic at all, or there is no traffic for the policy to evaluate for matches.
- Baseline data: “No baseline data available” may mean that there is no traffic or that the baseline is still building.

The Current Traffic view of the Debug list includes the following columns:

• Position (#): The ordinal position of the key in the top-X current keys for this policy.
• Keys: The policy’s key as defined in the policy’s Dimensions setting (Data Funneling pane of the Dataset tab of the Add Alert Policy or Edit Alert Policy dialog).
• Entries: The total number of flows with this key in the current traffic data aggregate.
• Primary Metric: The value of the policy’s Primary Metric as specified in the Data Funneling pane, which determines the position of the key in the top-X.
• Metric 2: The value of the policy’s first Secondary Metric (if any) as specified in the Data Funneling pane.
• Metric 3: The value of the policy’s second Secondary Metric (if any) as specified in the Data Funneling pane.
• First seen: The timestamp of the start time of the current traffic data aggregate.
  Note: The timestamp may be UTC or local depending on the Time Zone selected in your User Profile (see User-specific Defaults).

The Baseline Data view of the Debug list includes the following columns for each row:

• Position (#): The ordinal position of the key in the top-X baseline keys for this policy.
• Keys: The policy’s key as defined in the policy’s Dimensions setting (Data Funneling pane of the Dataset tab of the Add Alert Policy or Edit Alert Policy dialog).
• Count: The total number of flows with this key in the baseline data.
• Value: A percentile value for the policy’s Primary Metric as specified in the Data Funneling pane, which determines the position of the key in the top-X. The percentile that is used (98th, 95th, 25th, etc.) is set in the Building the Baseline pane of the Baseline tab (Rollup aggregation).
• Min Value: The lowest one-hour rollup aggregation value occurring for the primary metric over the “baseline window” set in the Building the Baseline pane.
• P50 Value: The 50th percentile value of the policy’s Primary Metric over the “baseline window.”
• Max Value: The highest one-hour rollup aggregation value occurring for the primary metric over the “baseline window.”
• Chosen Time: The timestamp of the first flow record in the baseline data that matches the key.

The addition of a policy to your organization’s collection of alert policies is covered in the following topics:

• Policy Creation Methods
• Add a Query-based Policy
• Clone a Policy
• Use a Policy Template

Note: To add a policy, your user level must be admin or higher.

You can add an alert policy with any of the following methods:

• Create a policy from scratch via the Add Policy button, which takes you to a blank Add Policy page (see Policy Settings Pages).
• Create a policy from Data Explorer using the Create Alert Policy action (see Add a Query-based Policy).
• Duplicate an existing policy using the Clone Policy button in the Action menu at the right of each row in the Policies list (see Clone a Policy).
• Add a policy based on a policy template (see Use a Policy Template).

The settings that you’ll make when adding a policy are covered in Policy Settings. When you’ve finished specifying the settings, click Save. The new policy will be listed in the Policies list.

Note: The first time you access a policy settings page you’ll see a dialog offering a tour of the page.

A query-based policy is a time-limited policy built from contextual Data Explorer queries. You can create a policy directly from Data Explorer using all of the criteria (dimensions, metrics, filters) you’re using to view your data.

To create a query-based policy:

1. In Data Explorer, create a query with the necessary data sources, dimensions, metrics, and filters.
2. On the SubNav, click the Actions button to display a drop-down menu.
3. Select Create Alert Policy. The criteria used in the query (dimensions, metrics, etc.) automatically populates a new policy on the Add Query-Based Policy page.
4. On the General tab, provide a name for the policy.
5. On the Thresholds tab, click Edit Conditions and add at least one condition (see Threshold Conditions).
6. Check the indicators in the Policy Summary Pane to see if you have any missing fields or errors in the policy.
7. Click Save. You will be taken back to the Data Explorer page from which you created the policy. The policy will now appear in the Policies list on the Policies page.

Notes:
- On the General tab (see General Policy Settings), if you set the Policy Expires time to Never or you disable Policy Status, the type of the policy changes from Query-based to Custom.
- If you choose to edit a Query-based policy after it appears in the Policies list, its expiration is removed and the policy type changes to Custom.

Cloning allows you to duplicate a policy so that it can be modified without altering the original. To clone a policy:

1. In the Policies list on the Policies page, find the policy that you’d like to clone.
2. From the Actions menu at the right of the policy’s row, choose Clone Policy, which takes you to the Clone Policy page, where the settings of a new policy will be populated with the values of the policy that you cloned.
3. Change the name of the new policy so that it’s distinct from the original policy you cloned.
4. Change any other settings on the tabs of the Clone Policy page to tailor them to your requirements for the new policy.

Note: Once a new policy has been created by cloning it will be added to the Policies list.

Templates are preconfigured policies provided by Kentik as the starting point for creating a policy for your organization. Kentik provides templates for many common alerting needs. Templates are not intended to be used as-is without being customized to your network and traffic situation.

There are two routes to adding a policy from a template:

• Policies page: On the Policies page, click the drop-down portion of the Add Policy button and choose Add Policy from Template to open the Add Policy from Template dialog. Choose a template from the drop-down, then click Continue.
• Policy Templates page: On the Policies page, click the Policy Templates button to go to the Policy Templates page, then click the Clone icon at the right of a row in Templates list.

Both of the above methods lead you to an Add Policy page whose settings (see Policy Settings) are already filled in with the default settings of the template. Tailor the settings to your specific needs and save the new policy.

The Add Policy from Template dialog includes the following settings and controls:

• Cancel buttons: To cancel the action and close the dialog, click the X in the upper right corner or the Cancel button at lower left.
• Drop-down menu: Display the menu to see a list of existing templates that you can use as the basis for your new policy.
• Go to Policy Templates: A link that takes you to the Policy Templates page (see Policy Templates).
• Template description: A description of the template and what it is designed to detect.
• Continue: A button that takes you to the Add Policy page, whose tabs will be populated with the settings of the template you selected from the drop-down menu. You can tailor the new policy to the specific needs of your organization by adjusting these settings.
  Note: The Continue button will be greyed out until you select a policy template from the drop-down menu.

The pages and dialogs used to specify policy settings are covered in the following topics:

• Policy Settings Pages
• Policy Settings Page UI
• Policy Settings Tabs

Alert policy settings are accessed on the following policy settings pages; the specific page used depends on the situation (add, edit, clone, etc.):

• Add Policy page: Used to specify the settings of a new custom policy. Accessed from the following locations:
  - From the Policies page via the Add Policy button at upper right.
  - From the Add Policy from Template dialog, accessed as described in Use a Policy Template.
• Edit Policy page: Used to edit an existing policy. Accessed from the Policies page via Edit Policy on the Policy Action Menu.
• Clone Policy page: Used to clone an existing policy (see Clone a Policy). Accessed from the Policies page via Clone Policy on the Policy Action Menu.
• Add Query-Based Policy page: Used to create a policy from a query in Data Explorer. Accessed from Data Explorer via Create Alert Policy on the Actions menu (in the SubNav at the top of the page). The settings (dimensions, metrics, etc.) in Data Explorer's Query sidebar will be used to populate the settings of the policy (see Add a Query-based Policy).

The policy settings pages share the same layout and the following common UI elements:

• Help (? icon): Click to open this KB article in a new tab.
• Cancel: A button in the upper right corner that reverts all settings to their values at the time the page was opened and returns you to the Policies page.
• Save: A button that saves changes to policy settings and returns you to the Policies page. The button is active only when the settings on all tabs are complete and error-free (see the indicators in the Policy Summary Pane).
• Settings tabs: The tabs on which the policy settings are made (see Policy Settings Tabs).
• Summary pane: The Policy Summary Pane includes an expandable/collapsible card for each tab that indicates its status and gives a high-level overview of its settings.

The Summary pane is situated at the right of the policy settings page and features a set of expandable/collapsible cards, one for each settings tab. Each card includes the following elements:

• Summary indicator: An indication of the status of the settings on the corresponding tab, which may be one of the following:
  - Complete (green circle with checkmark): All required settings on the tab are complete and valid.
  - Incomplete (empty circle): One or more settings on the tab aren't specified.
  - Error (red octagon with X): One or more settings on the tab need to be corrected.
  Note: Policies whose settings are incomplete or contain errors can't be saved.
• Heading: The name of the tab whose settings are summarized in the card.
• Count (Thresholds only): The number of active thresholds in the policy.
• Expand/Collapse: An up/down arrow; click to toggle the card between expanded and collapsed.
• Summary: A read-only summary of the settings on the corresponding tab, with indicators for any errors that need to be corrected.

The following tabs are included on all types of policy settings pages (add, edit, or clone):

• General: Used to define the overall properties of the policy; see General Policy Settings.
• Dataset: Used to narrow the subset of traffic that is evaluated for all thresholds in this alert; see Policy Dataset Settings.
• Thresholds: Used to specify up to five collections of conditions that trigger the alert to enter alarm state (see Alert Status); see Policy Threshold Settings.
• Baseline: Used to configure the baselines against which current traffic is compared to determine if there is a deviation from the norm; see Policy Baseline Settings.

The General Settings tab of each policy settings page (add, edit, or clone policies) is used to define the overall properties of the policy. This tab includes the following configuration options:

• Name: The name of the policy. Maximum of 50 characters; must include at least one letter.
• Description (optional): A description of the policy; used to summarize what the policy looks at and indicate what it is used for.
• Policy Status: A switch enabling you to enable or disable the policy. The default is enabled.
• Labels: A selector from which you can apply one or more Labels to the policy:
  - Click in the field to choose one of your organization’s existing labels from a drop-down list, which can be filtered by label name.
  - Click the Add Label link to open the New Label Dialog, where you can add a new label.
  - When labels are assigned they are displayed as lozenges in the field.
• Policy Type (DDoS or Custom policies only): A drop-down that sets the type of the policy to DDoS or Custom. Query-based policies can only be created from Data Explorer (see Add a Query-based Policy).
• Policy Expires (Query-based policies only): Sets the length of time after which the policy will be disabled. Options include: Never, 15 days, 30 days, 60 days, or 90 days. The default is 90 days.
  Notes:
  - If you turn off the policy status switch, the expiration switches to Never.
  - If the Policy Expires time is set to Never, the type of the policy changes from Query-based to Custom.
• Silent Mode: A switch that turns Silent Mode on or off for this policy. If on (typically used while establishing a baseline for new policies), the policy won't enter alarm state (and trigger notifications and/or mitigations) until a specified date.
  Notes:
  - Silent mode is enabled by default for query-based policies.
  - Silent mode can be enabled on a pattern basis on the Silent Mode Page.
• Silent Mode End Date: If Silent Mode is switched on, this field specifies the date on which the alert will exit silent mode. The default is seven days.
• Policy Dashboard: A selector from which you can choose a dashboard that will be the destination of the Open Dashboard button for this alert on the Alerting page (see Alert-specific Actions). Click in the field to choose one of your organization’s existing Dashboards from a drop-down list, which can be filtered by dashboard name.

The Dataset tab is used to narrow the subset of traffic that is evaluated for the thresholds in this alert. The tab is divided into two panes whose settings are described below:

• Data Funneling
• Building Your Dataset

Note: A policy's metrics can't be changed while the policy is in use by any of your tenants, which will be indicated in the following locations:
- Tenants will be listed by name in the Used by Tenant column of the Policies List.
- On the Edit Policy page, a banner at the top of the Dataset tab tells you how many tenants are using the policy and provides links to the Tenant Policy Settings for each such tenant.

The settings in the Data Funneling pane define which network traffic will be evaluated by this policy:

• Data Sources: Displays the policy's current data sources and provides access to the dialog for selecting data sources:
  - Data Sources list: A list of the devices and cloud resources that the traffic evaluated by this policy is going through, to, or from.
  - Edit Data Sources: A button that opens the Data Sources Dialog so you can change the data sources covered by this policy.
• Policy Dimensions: Controls listing the dimensions used to evaluate the traffic and enabling access to the dialog for selecting dimensions (see Policy Dimensions).
• Metrics: Controls listing the metrics currently selected for the policy and enabling access to the Metrics dialog for managing primary and secondary metrics (see Policy Metrics).
• Filters: Controls for the filters that are set to screen the traffic that is evaluated for the alert:
  - Filters list: A list of filters currently applied to this policy (see About Filters).
  - Edit Filters: A button that opens the Filtering Options dialog (see Filtering Options Dialog).

Note: A mitigation can be assigned to a policy (see Threshold Mitigations) only if the dimensions assigned with the Policy Dimensions setting above include source or destination IP/CIDR.

The Policy Dimensions section (required) of the Dataset tab shows the dimensions used to evaluate the traffic and enables access to the dialog for managing the policy’s dimensions:

• Dimension list: A list of the dimensions (see About Dimensions) that combine to define a key.
• v4 CIDR & v6 CIDR: These two fields allow users to set custom IPv4 and IPv6 prefixes when any CIDR metrics dimensions are applied to the policy. These fields appear for the following dimensions: Destination IP/CIDR, Source IP/CIDR, Source Next Hop IP/CIDR, and Destination Next Hop IP/CIDR.
• Edit Dimensions: A button that opens a Dimensions dialog (see Dimension Selectors) to edit the dimensions of the key. The key definition determines how traffic is subdivided for evaluation (see About Keys). You cannot have more than eight dimensions.
  Example: If the primary metric is packets/second, and the group-by dimensions are set to Source:AS Number and Destination:AS Number, then the top-X evaluation will involve looking at all unique combinations of source ASN and destination ASN to determine which combinations have the highest traffic volume as measured in pps.

The Metrics section of the Dataset tab shows the metrics currently selected for the policy, and enables access to the Metrics dialog for managing primary and secondary metrics:

• Primary: A lozenge indicating the metric selected as the primary unit (e.g. bits/s, packets/s, flows/s, etc.) by which ingested flow data will be evaluated to determine top-X. For a list of available metrics, see General Metrics and Host Traffic Metrics.
  Example: If the primary metric is bits/second then the top-X evaluation will rank keys by bps.
• Secondary: A lozenge indicating the metric used to specify multiple additional static comparators (see Policy Threshold Settings) that are based on a metric other than the primary metric. Each added comparator represents an additional condition that must be met in order to trigger an alarm. The Secondary Metrics selector supports simultaneous selection of two secondary metrics.
• Edit Metrics: A button that opens the Metrics dialog (see About the Metrics Dialog) where you can edit the primary and secondary metrics for the policy.
  Note: The maximum number of metrics per policy is three: one primary and two secondary.

The settings in the Building Your Dataset pane specify how the network traffic defined in the Data Funneling pane will be evaluated. By default, the pane is hidden. To show the pane, click Advanced Settings at the bottom of the tab.

The pane always includes the following controls:

• Evaluation Frequency: The interval at which newly ingested traffic data is grouped by dimensions and the traffic data represented by the resulting keys is evaluated. Options include 60 seconds (default), 2 minutes, and 5 minutes.
• Maximum Keys Per Evaluation: The number of keys (unique combinations of dimension values; see About Keys) to evaluate for a match with the conditions specified in the alert's thresholds. Maximum valid value is 300.
• Minimum Traffic Threshold: The minimum value, as measured by the primary metric, that a key must have to be included in the top-X ranking and evaluated for a threshold match.
  - Specified value: Specify the minimum value (measurement units are determined by the primary metric).
  - Auto-calculate: If checked (default), the value is auto-calculated using a formula based on the settings of the comparators in the policy’s thresholds (see Threshold Conditions) and the Minimum Traffic Threshold field is greyed out.

If the Dimensions list in Data Funneling includes more than one dimension, the Building Your Dataset pane will also include the following Dimension Grouping controls (see About Dimension Grouping):

• Group Dimensions: A switch to enable grouping by some dimensions before the final top-X evaluation.
• Dimensions to Group By (shown only if Group Dimensions is enabled): The number of dimensions, starting at the top of the Dimensions list, that will be included in the key definition used for grouping.
• Maximum Keys per Group (shown only if Group Dimensions is enabled): The number of keys from each group that will be included in the overall top-X for the alert. The maximum valid value is the lesser of 300 or the value of the Maximum Keys per Evaluation setting.

Dimension grouping introduces an additional layer of control into how the alerting system tracks the top-X keys for current traffic. Dimension grouping can help keep keys from a high-volume area of the infrastructure from dominating the top-X keys, so that the alerting system can pick up on significant changes in other areas as well.

With dimension grouping disabled, the key definition (set of dimensions) specified in the Dimensions field (see Data Funneling) is used as a single unit, resulting in keys that are each a unique combination of dimension values. These keys are then ranked by traffic volume to arrive at Top-X.

With dimension grouping on, traffic is instead evaluated in stages as follows:

• The dimensions specified in the Data Funneling section are split into two sets, one of which can be thought of as the “grouping set.”
  - The first dimension in the grouping set is the first dimension in the Policy Dimensions field.
  - The last dimension in the grouping set is the dimension whose position in the Dimensions field corresponds to the number specified with the Dimensions to Group By control.
  - The remaining dimensions are in the non-grouping set.
  - Example: Dimensions are Source ASN, Full Device, Destination Country, and Destination ASN. If Dimensions to Group By is set to 2, the grouping set is Source ASN and Full Device.
• Traffic is initially evaluated as if the key definition is only the grouping set. The resulting groups will each represent the traffic having a unique combination of the dimensions in the grouping set (e.g. Source ASN and Full Device).
• The traffic in each of these groups is then evaluated as if the key definition is only the non-grouping set. The resulting keys within each group will each represent the traffic having a unique combination of the dimensions in the non-grouping set (e.g. Destination Country and Destination ASN).
• The top N keys will be taken from each group and merged into a single pool, with N determined by the Maximum Keys per Group control.
• The keys in this pool are ranked by volume, resulting in the overall top-X keys for the alert, with X being defined by the Maximum Keys Per Evaluation control.

The settings of the Alert Thresholds tab are covered in the following topics:

• About Alert Thresholds
• General Threshold Settings
• Threshold Conditions
• Threshold Configuration
• Threshold Frequency
• Threshold Actions
• Threshold Notifications
• Threshold Mitigations

A threshold is a collection of settings that define a set of conditions that must be matched in order for an alert policy to be activated, at which point the policy generates an alert for each key for which conditions have been matched. Each policy includes at least one threshold by default but may include up to five (Critical, Severe, Major, Warning, Minor).

The Thresholds tab includes the following general settings:

• Diagram: A visualization of the query built out of the policy as it is currently configured. Only visible if the policy is enabled.
  - Refresh: Click to refresh the visualization’s traffic data.
  - View in Data Explorer: Click to open the query in Data Explorer (opens in a new tab).
• Severity selector: Choose which threshold you are configuring: Critical, Severe, Major, Warning, or Minor.
• Threshold Status: Determines whether or not the threshold is currently enabled (evaluating traffic data, generating alarms, etc.). A threshold that is not currently needed can be disabled and retained for future use.
• Threshold Description: A field in which to enter a description of the traffic conditions the threshold is intended to monitor.

The settings shown in the Conditions section determine what constitutes a match (see About Matches) for the threshold. These settings are configured in the Edit Threshold Conditions dialog. The dialog is accessed via the Edit Conditions button in the Conditions section.

Note: The settings in the Edit Threshold Conditions dialog for a given threshold are independent of the same dialog's settings for other thresholds.

The Edit Threshold Conditions dialog includes the following general fields and controls:

• Close buttons: To close the dialog, click the X in the upper right corner or the Cancel button at lower right. All elements will be restored to their values at the time the dialog was opened.
• Conditions tiles: A set of tiles that each define a condition (see Conditions Tile Types).
• Apply button: Click to apply the conditions to the policy. This will close the dialog and return you to the policy settings page.

A conditions tile is a set of controls used to specify one condition for the threshold. By default, the Edit Threshold Conditions dialog includes the following standard types of conditions tiles:

• Metrics Condition: Tile(s) that display any selected metrics condition(s). Can be static and/or baseline condition(s). Click Show Chart to display a visualization of the metric’s data for the last three days. See Metrics Condition.
  Note: The default primary metric for a newly created policy is Packets/s. You can change this on the Dataset tab (see Policy Dataset Settings).
• Top Keys Condition: A tile that displays the top keys condition (if enabled). See Top Keys Condition.
• Interface Capacity Condition: A tile that displays the interface capacity condition (if enabled). See Interface Capacity Condition.
• Ratio-Based Condition: A tile that displays the ratio-based condition (if enabled). See Ratio-Based Condition.

Notes:
- In addition to the above tiles, if a secondary metric is specified in the policy's Dataset tab, the Edit Threshold Conditions dialog will also include a tile for the secondary metric.
- If no settings are made in a given tile in the dialog then no condition of that type will be displayed in the Conditions section on the tab for the corresponding threshold on the policy's settings page.

A conditions tile is a set of controls used to specify one condition for the threshold. Each such tile in the Edit Threshold Conditions dialog includes the following controls, which appear in full when you click the tile's Add Condition button:

• Add Condition: A button that expands the tile for a condition, enabling you to specify the condition's settings.
• Condition statement: Indicates the condition being applied and a summary of the settings entered for that condition. Condition statements vary depending on the type of condition (see topics below)
• Show Chart (present only for metrics and ratio-based conditions): A button that opens a chart showing the last three days of data (as defined by the policy’s data sources, filters, and dimensions) for the specified metric(s), with the static/baseline metric being displayed in orange.
• View in Data Explorer (present only for metrics): A link (icon to the left of the Add Condition button) that takes you to Data Explorer, where the Query pane will be populated to match the settings of this policy's Dataset tab. When the Show Chart button has been clicked the same link will also appear as part of the UI of the chart.
• Refresh (present only when a chart is open): A button that refreshes the data in the visualization.
• Remove (trash icon): A button that removes the condition from the threshold.

By default, the tile for a metrics condition (primary or secondary) includes a static condition in which current traffic is compared with a fixed number specified by the user. A metrics condition may optionally include a further requirement based on a comparison of current traffic with a historical baseline. The overall metrics condition defined by the tile's settings is stated to the right of the tile's heading and will be met when the evaluated traffic meets both the static condition and the baseline condition (if any).

The static condition is met when the current metric value exceeds the condition value specified with the following controls:

• Condition value: A field in which to enter a number.
• Condition units: A drop-down from which you can select the units in which the condition value is expressed.

The baseline condition is met when the current metric value exceeds the baseline metric value to the extent specified with the following controls:

• Comparison value: A field in which to enter a number.
• Comparison type: A drop-down from which you can choose the type of comparison:
  - % of baseline: The condition is met when the current metric value as a percent of the baseline metric value exceeds the specified comparison value.
  - Units over baseline: The condition is met when the current metric value exceeds the baseline metric value by at least by the number of units (e.g. bit/s or packets/s) specified with the comparison value.

Notes:
- The default metric is packets/s. If you choose a different metric on the Dataset tab (see Data Funneling), the UI of the metrics condition tile will reflect your selected metric.
- Baseline conditions are available only for a policy's primary metric. If a baseline condition is set for a given threshold, a top keys condition cannot be set for that threshold.

If the policy includes a top keys condition, it will look for a change in the composition of the top-X keys (a key entering or leaving the top keys). The following controls determine how the top keys are evaluated:

• Comparison Direction: Determines which set of top-X keys (current or historical) is the primary set and which is used for comparison (see Comparison Direction).
• Top Keys: The number of keys to evaluate.
  Note: If the field is left blank, the number of keys to track is set to the value of the Maximum Number of Keys field in Building Your Dataset (default = 25).

Note: If a top keys condition is set for a given threshold, a baseline condition cannot be set for that threshold.

The Interface Capacity tile of the Edit Threshold Conditions dialog enables you to alert based on a comparison of the current utilization of an interface whose traffic is included in the policy's dataset with the capacity of that interface. The tile's Add Condition button is active when the following is true:

• The policy's dimensions include Source Interface and/or Destination Interface.
• The policy's metrics include bits/s (see Data Funneling).
• No baseline condition is set in the Metrics Condition tile.

The condition is defined with the two-part Utilization control:

• Comparison value: A field in which to enter a number.
• Comparison method: A drop-down from which you can choose the method used to compare utilization with capacity:
  - Mbits/s: The condition is met when the current utilization of the interface (traffic volume), expressed in bits/s, exceeds the interface's capacity by at least the comparison value.
  - %: The condition is met when the current utilization of the interface, expressed as a percent of the interface's capacity, exceeds the specified comparison value.

The Ratio-Based Condition tile of the Edit Threshold Conditions dialog enables you to set a policy condition based on a part-to-part ratio between any two metrics specified on the Dataset tab (see Data Funneling).

The following controls, which designate one metric as "Left" and the other as "Right," are used to define the condition:

• Bidirectional: A switch that controls how the two parts of the ratio will be evaluated:
  - When the switch is off, the condition will be met if the ratio of the left metric to the right metric exceeds the ratio defined by their respective metric values. For example if the left value is 10 and the right value is 1 then the condition is met when the ratio of the left metric to the right metric exceeds 10:1.
  - When the switch is on, the condition will be met when the ratio of either metric to the other metric exceeds the ratio defined by their respective metric values, e.g. if the ratio of left to right exceeds 10:1 or the ratio of right to left exceeds 10:1.
• Metrics: Two control sets, one for the left metric and the other for the right. Each set has two parts:
  - Metric value: A field in which you enter the numeric value of one metric's part of the ratio.
  - Metric: A drop-down from which you choose the metric for one part of the ratio.
• Swap Metrics (left/right arrow icon): A button that moves the settings of the left metric controls to the right metric controls, and vice versa.
• Margin (shown only when Bidirectional is on): Active only when the metrics value fields are both set to 1, this field adds a fractional value to both parts of the ratio. For example, if the margin is set to 0.2 then the left:right ratio and the right:left ratio each become 1.2:1.
• Show Chart: See Show Chart in Conditions Tile Common UI.

Note: The tile's Add Condition button is active only when the policy's dataset includes at least two metrics.

The settings displayed in this pane of the Thresholds tab vary depending on the settings of the Edit Threshold Conditions dialog:

• Comparison Direction (shown only when a baseline condition or top keys condition is set for the primary metric): Determines which set of top-X keys (current or historical) is the primary set and which is used for comparison (see Comparison Direction).
  Note: If the Comparison Direction is set to Historical Baseline to Current Traffic, the If no baseline exists setting is automatically set to Activate an Alert.
• If no baseline exists: A drop-down that sets what to do if a key in the primary top-X is not present in the comparison top-X (see No Existing Baseline).
• Default Value (shown only when a baseline condition is set for the primary metric): The value, displayed below the If no baseline exists drop-down, used for comparison when If no baseline exists is set to “Use a Default Value”, or if we can’t determine the Lowest or Highest Value from Top Keys (maybe there are no baseline values yet) — then the Default Value is used in those cases.
• Top Keys: If specified, the following fields override (for this threshold only) the dataset's Maximum Keys Per Evaluation setting (see Building Your Dataset), which is stated in parentheses to the right of each field:
  - Top current keys: The number of keys to evaluate from current traffic.
  - Top baseline keys: The number of keys to evaluate from baseline traffic.

The Thresholds tab includes a Comparison Direction setting in two places:

• In the Top Keys Condition tile of the Edit Threshold Conditions dialog;
• In the Threshold Configuration pane of the tab.

The following table explains the effect of this setting:

The If no baseline exists setting is shown only when a baseline condition is set for the primary metric. The setting is a drop-down that sets what to do if a key in the primary top-X is not present in the comparison top-X:

• Use Lowest Value from Top Keys (default): Compare the value of the key in the primary top-X set to the value of the last (lowest) key in the comparison set.
• Use a Default Value: Compare this key’s current value to the static value in the comparison value field.
• Do Not Alert: Classify as not a match on this key.
• Activate an Alert: Classify as a match on this key.
• Use Highest Value from Top Keys: Compare the value of the key in the primary top-X set to the value of the highest key in the comparison set.

Note: If the Comparison Direction is set to Historical Baseline to Current Traffic, this setting is automatically set to Activate an Alert and cannot be changed.

Kentik's alerting system defines a "match" as an individual instance of the network traffic evaluated by this alert policy matching the conditions defined for this threshold. The Threshold Frequency settings specify how many matches must occur within a given duration of time in order to trigger an alert:

• Times: The count of matches that must occur within the specified duration.
  Note: If the number is set to 1, the time settings are irrelevant; an alert will be generated immediately upon the first match.
• Duration value: The number of time units in the duration.
• Duration units: The time unit of the duration, either minutes or hours.
• Reset period: The number of match-free minutes after which the count of matches is reset to 0.

The settings in this section determine how the alerting system responds to an alert generated by this threshold. These settings include:

• Acknowledgment Required: If this switch is enabled, an alert that is no longer in an alarm state will not be fully cleared until it is acknowledged manually from the Alerts List on the Alerting page.
• Notifications: A drop-down from which you can choose notification channels that will be notified in the event of an alert for this threshold (see Threshold Notifications).
• Mitigations: A drop-down from which you can choose mitigations that will be triggered in the event of an alert for this threshold (see Threshold Mitigations).

When an alert is triggered or otherwise changes state, notifications may be sent in various forms to designated parties at various destinations. The Notification Channels field is used to specify the notification(s) sent when an alarm is triggered. The notifications controls include:

• Notification Channels: A field that shows lozenges for each of the notification channels you’ve selected to add to this threshold:
  - To add a channel, click in the field to drop down a filterable list of channels in your organization and click a notification channel. Repeat as needed.
  - To remove a channel from this policy, click the X in the channel’s lozenge.
• Add New Channel: Opens the Add Notification Channel dialog (Add or Edit Notification), where you can configure a new notification channel in your organization (see Notification Settings) and automatically add it to the policy.
• Test Notification Channels: Send a test notification to the recipients in all of the selected notification channels.
  Note: Test Notification Channels is visible only when there are channels in the Notifications Channels field.

Note: For more information about notification channels, see Notifications.

The Mitigations section enables you to set one or more mitigations (see About Mitigation) that will be triggered in response to an alert on this threshold.

In its initial state, the Mitigations section includes the following controls:

• Mitigation selector: A drop-down list from which you can select a mitigation.
• Add Mitigation: A button that assigns the currently selected mitigation to this threshold.

Once a mitigation is assigned to the threshold, a configuration tile for the mitigation is displayed above the initial controls (which may still be used to add another mitigation). The tile includes the controls covered in Mitigation Settings.

Note: The mitigations assigned to a policy (automated mitigations) will escalate and de-escalate automatically as changing conditions match different thresholds in that policy.

The mitigations tile for an individual mitigation that has been assigned to the threshold includes the following controls:

• Remove: A red X at upper right. Click to remove the mitigation from the threshold.
• Apply Mitigation: A drop-down that specifies when the mitigation will be applied:
  - Immediately, when alert starts: Initiate the mitigation immediately when the threshold activates an alert.
  - After user confirmation: Initiate mitigation action only after a user clicks the Approve and start the mitigation option in the actions at the right side of a given alarm's row in the Alerts List on the Alerting page.
  - After user confirmation or timeout expires: Wait for a user to acknowledge or cancel the mitigation from the Alerting page. If the specified time period expires with no user action, then initiate the mitigation automatically.
  - Application Timer (shown only when Apply Mitigation is set to “After user confirmation or timeout expires”): The duration (in minutes) of the timer.
• Clear Mitigation: A drop-down that specifies when the mitigation will stop:
  - Immediately, when alert ends: Stop mitigation immediately when the alert exits alarm state.
  - After user confirmation: Continue mitigation (even after the alert ends) until it is canceled by a user.
  - After user confirmation or timeout expires: Continue mitigation (even after the alert ends) until it is manually cancelled by a user or the specified time expires.
  - Application Timer (shown only when Clear Mitigation is set to “After user confirmation or timeout expires”): The duration (in minutes) of the timer.

If desired, you can add one or more additional mitigations to the same threshold. Multiple mitigations are assigned as follows:

1. Use the controls covered in Add Mitigation to Threshold to add another mitigation.
2. Use the controls covered in Mitigation Settings to specify when the new mitigation will be applied and cleared.

The ability to apply multiple mitigations to a threshold enables you to simultaneously trigger all of the mitigation methods/platforms (e.g. appliances at multiple sites) with which you’d like to respond to a given set of conditions, and to do so in a way that is much more scalable than by cloning a given policy for each of your appliances.

Support for multiple mitigations per threshold also enables the response for a given alarm to include a mix of mitigation types (e.g. RTBH, A10, and Radware). The following scenario, for example, outlines a multi-location DDoS response involving multiple mitigation types:

1. De-preference or stop-announcing a BGP route on Location #1 by injecting a route whose community has been predefined as a flag for these actions.
2. Announce a broader routing table entry, less specific than /24 (thus forcing acceptance by Internet peers), for Location #2.
3. Trigger a third-party mitigation method (e.g. A10 or Radware) on Location #2 to announce more specific prefixes for internal re-direction to a scrubbing center.

Mitigations whose platform is Flowspec will include a Traffic Matching card at the right of the standard Mitigation Settings tile. The dimensions listed in the card have either been populated with specific values or are inferred from values elsewhere in the policy. To see which Flowspec components (see Flowspec Component Types) are involved for this mitigation, click the View Method Details button, which opens the Mitigation Method Details dialog.

The settings of the Historical Baseline tab are covered in the following topics:

• About Historical Baselines
• Baseline Presets
• Building the Baseline
• Using the Baseline
• Weekend Baselining

Baselining enables the alerting system to trigger an alert based on a comparison of current traffic, more specifically the current value of a key (see About Keys), against a baseline value. Derived from historical traffic patterns, the baseline represents what's "normal" for that key. If the current value varies from the norm in a way that matches a condition specified in one of an alert policy's defined thresholds, then that threshold will trigger an alert.

The baselining process begins with a historical data set that has the following characteristics:

• It covers traffic that is "funneled" the same way as the current traffic to which it will be compared, which is defined on the Dataset tab (see Policy Dataset Settings).
• It covers a specified time range covering multiple hours or days (the "baseline window").
• It's drawn from time series data points that each represent the traffic volume of a top-X key for one time-slice, which is a duration (1, 2, or 5 min) determined by the Dataset tab's Evaluation Frequency setting.

We arrive at a baseline value for each key in two main stages:

• Building the baseline: We smooth out spikes or drops in normal traffic by normalizing/averaging the data points for each top-X key over the baseline window (based on the options in Building the Baseline). The result is a series of "buckets" that each cover a duration of one hour and include one value for each of the top-X keys.
• Using the baseline: We choose certain buckets (based on the options in Using the Baseline) and normalize/average the key values in those buckets into a final historical value for each key. This value is what's used for comparisons in the conditions of each threshold.

When a comparison of the current value with the final baseline value results in a match with the baseline condition defined for a given threshold then that threshold may — depending on its Threshold Frequency settings — trigger an alert.

Note: The settings for historical baselines in a given policy apply to all of the thresholds in that policy that include one or more baseline conditions.

Kentik offers three presets that serve as a starting point for configuring baselining for a given policy. Once you choose a preset you can tailor settings to your specific needs with the controls that are revealed by clicking Advanced Options (see Building the Baseline and Using the Baseline). When you change any of the settings the baseline will automatically be reclassified as Custom.

The following presets are available:

• Default: Produces a general-purpose baseline for most alerting applications.
• Precision: Produces the most accurate baseline for highly detailed applications.
• Express: Rapidly produces a baseline that's less accurate but nonetheless useful for general applications.

All of the above presets share the following approach:

• In Building the Baseline:
  - Rollup aggregation: Set to 98^th percentile.
• In Using the Baseline:
  - Bucket width: Each key's value for a given hour is based only the key's value in that hour's bucket.
  - Final aggregation: Set to 95^th percentile.
  - Use separate patterns for weekdays and weekends: Disabled by default.

The table below shows how the presets differ.

The controls of the Building the Baseline pane (accessed via Advanced Options on the Baseline tab) enable you to specify the historical data that will be included in an initial (“rollup”) aggregation pass. The controls are structured as three settings that together answer the question "How should we build the buckets that will be available for your baseline?":

• Window: Go back [duration] from [end point]. These settings determine the time range of the baseline window (e.g. "go back one week from one day ago"):
  - Duration: The length of the time range. Options include 1, 2, 3, or 4 (default) weeks.
  - End point: A drop-down that sets the end point of the time range for evaluation of historical data. The window will go back in time from this end point for the specified duration. Traffic data newer than the end point is excluded to prevent current spikes or anomalies from skewing baseline values. Options include 1 hour, 1 day (default), and 1 week ago.
• Bucket depth: Use the top [##] of keys in every hour of the window. By default, this number is set to match the Maximum Keys per Evaluation setting on the Dataset tab (see Building Your Dataset).
• Rollup aggregation: For each one-hour bucket, derive each key's value based on the [minimum/maximumn/percentile] of the time series datapoints for that hour. Options include Minimum, Maximum, or Percentile: 98th (default), 95th, 50th, 25th, or 5th.

Note: The baseline window described above is "rolling," meaning that older traffic data continually ages out and newer traffic data is continually added.

The controls of the Using the Baseline pane (accessed via Advanced Options on the Baseline tab) enable you to define how the buckets defined in Building the Baseline are used to derive final comparison values. The controls are structured as four settings that together answer the question "Which buckets should we take key values from, and how should we derive a comparison value for each key?":

• Completeness: Don't use this baseline until it has at least [##] [time unit] of data. This minimum duration helps ensure that the baseline reflects sufficient information to establish what the "normal" value is for each key. Time unit options are hours or days.
  - Number field: Enter a number representing time units.
  - Time unit: Click the drop-down to select days (default) or hours.
• Compare to: For each key, take baseline values from the buckets for [every/the current] hour of [every/the current] day of the week. Use these drop-down to determine which buckets are included in the final aggregation:
  - All buckets in the window: every hour of every day.
  - Buckets from the current hour of every day (default).
  - Buckets from the current hour of the current day.
  Note: The availability of these options depends on the Window settings in Building the Baseline.
• Bucket width: For each key, derive the value representing each "compare to" hour from [just that hour/surrounding hours].
  - If bucket width is "just that hour" then the value of each key for that hour is taken only from the bucket for that hour.
  - If bucket width is "surrounding hours" then an additional line appears, enabling the key values for a given hour to be derived from a number of hours on either side (see Baseline Bucket Width).
• Final aggregation: Derive the final comparison value for each key from the [minimum/maximumn/percentile] of the key's values for the "compare to" hours. This drop-down specifies how the values for a given key in the chosen buckets will become a single comparison value for that key. Options include maximum, minimum, and percentile: 99th, 98th, 95th (default), 90th, 80th, 50th, 25th, 10th, or 5th.
  Note: Policies watching for activity in excess of baseline typically use Maximum, 98th, or 95th percentile aggregation. Policies watching for activity below baseline typically use 25th percentile aggregation.

The buckets resulting from Building the Baseline each cover one hour in the overall baseline window, with one value per key per bucket. The Bucket width setting in Using the Baseline enables you to replace those single-hour values for each key with values that are derived from up to four hours on either side of the bucket's nominal hour. This additional aggregation step is specified in the following line, which appears when Bucket width is specified as "surrounding hours": Aggregate [#] hours before and after using [minimum/maximumn/percentile].

The number of hours that can be aggregated into a single bucket value ranges from 1 to 4. The method of deriving the bucket value from multiple hours may be minimum, maximum, or a percentile: 5th, 10th, 25th, 50th, 75th, or 90th.

The final section of the Advanced Options section on the Baseline tab is the Use separate patterns for weekdays and weekends checkbox. When this box is checked, the baselines for weekends (UTC Saturday and Sunday) will be calculated independently from the baselines for weekdays (UTC Monday through Friday), thereby taking into account variations in traffic patterns caused by day of week.

The following procedures cover basic operations related to managing alert policies in the portal:

• Add a Policy
• Edit a Policy
• Disable or Enable a Policy
• Remove a Policy
• Debug a Policy

Note: See also Add a Query-based Policy, Clone a Policy, and Use a Policy Template.

As discussed in Policy Creation Methods, Kentik provides several different approaches to creating an alert policy. The following is a basic outline for adding a policy using the Add Policy page:

1. Choose Settings from the portal's main menu.
2. On the Settings page, click Alert Policies (under Alerting).
3. On the resulting Policies page, click the Add Policy button at the upper right.
4. On the General tab of the Add Policy page, specify the settings covered in General Policy Settings.
5. On the Dataset tab, specify the settings covered in Policy Dataset Settings.
6. On the Thresholds tab, specify the settings covered in Policy Threshold Settings.
7. On the Baseline tab, specify the settings covered in Policy Baseline Settings.
8. Click the Save button at the upper right to save the policy and return to the Policies page, where the new policy will now be included in the Policies List.

To edit an existing policy:

1. Choose Settings from the portal's main menu.
2. On the Settings page, click Alert Policies (under Alerting).
3. In the Policies List on the Policies page, find the row of the policy whose settings you'd like to change.
4. Click the Action icon (vertical ellipses) at the right of the row and choose Edit Policy from the popup.
5. On the resulting Edit Policy page, click on the tab containing the setting that you'd like to change (see Policy Settings Tabs), then find the setting and change it.
6. Click the Save button at the upper right to save your changes and return to the Policies page.

To disable a policy or re-enable a policy that was previously disabled:

1. Choose Settings from the portal's main menu.
2. On the Settings page, click Alert Policies (under Alerting).
3. In the Policies List on the Policies page, find the row of the policy you'd like to disable or enable.
4. Click the Action icon (vertical ellipses) at the right of the row:
   - To disable an enabled policy, choose Disable from the popup. The policy will no longer monitor its dataset, generate alerts, or trigger mitigations.
   - To enable a disabled policy, choose Enable from the popup. The policy will resume normal policy-related functions.

To remove a policy from your organization's collection of policies:

1. Choose Settings from the portal's main menu.
2. On the Settings page, click Alert Policies (under Alerting).
3. In the Policies List on the Policies page, find the row of the policy you'd like to remove.
4. Click the Action icon (vertical ellipses) at the right of the row and choose Remove from the popup.
5. In the resulting confirmation dialog, click Remove. The policy will be permanently removed from your organization's collection of policies.

To debug a policy, that policy must currently be enabled. To debug an enabled policy:

1. Choose Settings from the portal's main menu.
2. On the Settings page, click Alert Policies (under Alerting).
3. In the Policies List on the Policies page, find the row of the policy you'd like to debug.
4. Click the Action icon (vertical ellipses) at the right of the row and choose Debug from the popup. The Debug dialog appears.
   Note: You can also select Debug from the Action menu in a policy’s Policy Details Drawer.
5. Depending on what you are trying to debug, use the drop-down button to select whether the Debug list shows Current Traffic or Baseline Data.

Note: When insufficient traffic is available for debugging, a message will display in place of the Debug list (see Policy Debug Dialog UI).