Flow Policy Settings

The settings for Flow policy types in Kentik's alerting system are detailed here.

Notes:

• For more information about policy-based alerting, first read Alerting, Alert Policy Templates, Alerting Page, Notifications, and Mitigations.

• Alert policy configuration can be complex. Please reach out for help by contacting Kentik support (see Customer Care).

Flow Policy Settings Tabs

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

• General Settings: Define the overall policy properties.

• Dataset Settings: Narrow the subset of traffic evaluated for all thresholds.

• Activate & Clear: Manage alert triggering criteria, event frequencies, manual acknowledgments, and notification routing.

• Baseline: Configure the historical data buckets and aggregation methods used to establish normal traffic patterns for comparison.

• Dashboards & Labels (Optional Settings): Format organizational tags and bind specific destination dashboards to a policy's alerts.

General Settings

The General tab of a Flow policy settings page (add, edit, clone) includes:

• Name: The unique name for the alert policy.

• Description: An optional summary of what the policy monitors and its intended use case.

• Enable Policy: A switch to activate or deactivate the policy. A policy must be turned On to evaluate traffic and generate alerts.

• Flow Policy Types: Selectable cards to monitor flow-based traffic patterns:

  • Protect: Monitors traffic patterns indicating potential attacks (e.g., SYN floods, amplified reflections).

  • Traffic: Monitors NetFlow/VPC FlowLog traffic patterns, focusing on flow rate thresholds and fluctuations.

• NMS Policy Types: Selectable cards to monitor system, device, and network management states:

  • Agent: Tracks agent health metrics such as resource usage and status.

  • Agent Capability: Tracks capability health and enablement status.

  • BGP Neighbor: Monitors BGP peering session states and metrics (e.g., session state changes, advertised prefixes).

  • Component: Tracks device component states and hardware metrics (e.g., CPU, power supply).

  • Device: Monitors system-level device states and metrics (e.g., up/down status, overall CPU/memory).

  • Event: Filters SNMP traps or syslog messages using custom regex filters.

  • Interface: Tracks interface states and counter metrics (e.g., operational status, traffic spikes).

  • Classic Threshold: Utilizes rolling window aggregations and classic baselines for average-over-time thresholds.

  • Custom: Allows for any NMS measurement, including cloud and custom metrics from third-party integrations.

Dataset Settings

The Dataset tab of the Flow policy settings page narrows the subset of traffic evaluated for the alert’s thresholds, as follows:

• Data Sources: Displays the devices and cloud resources currently selected for evaluation (e.g., All devices).

  • Click Edit Devices to open a dialog to update the data sources covered by this policy.

• Policy Dimensions: Lists the traffic evaluation dimensions used to define a key (e.g., Destination IP/CIDR.

  • v4 CIDR & v6 CIDR: Set custom IPv4 and IPv6 prefix lengths when CIDR dimensions are applied to the policy (e.g., 32 and 128).

  • Click Edit Dimensions to choose how traffic is subdivided for evaluation (up to 8 dimensions).

• Metrics: Shows the policy’s currently selected metrics used to trigger the alert.

  • Primary: The primary unit (e.g., Packets/s) by which traffic will be evaluated to determine the top-X ranking (see General Metrics and Host Traffic Metrics).

  • Secondary: A lozenge for the secondary metric (up to 2), used to specify multiple additional static comparators (see Policy Dataset Settings). Each added comparator is a condition for triggering an alarm. Use the Secondary Metrics selector to choose up to 2 secondary metrics.

  • Click Edit Metrics to modify primary and secondary metrics (see About the Metrics Dialog).

  Note: Each policy can have a maximum of three metrics: one primary and two secondary.

• Filters: Displays any currently applied filtering criteria (see About Filters).

  • Click Edit Filters to apply or edit custom criteria that narrow the scope of evaluated traffic (see Filters Dialog).

Advanced Settings

Click the expander arrow to reveal the Advanced Settings pane with additional configuration options for tailoring your dataset evaluation:

• Building Your Dataset: A summary explaining that the dataset begins with all traffic matching the policy's dimension keys, ranks them by the primary metric, and evaluates the top-X keys.

  Note: When you select multiple dimensions, the Dimension Grouping controls also become active in this section.

• Evaluation Frequency: The time interval represented by a single data point in the dataset (60 Seconds, 2 Minutes, or 5 Minutes).

• Maximum Keys Per Evaluation: The maximum number of keys in the overall pool, combined from all groups if dimension grouping is enabled (default: 25).

Dimension Grouping

If you’ve included more than one dimension, the Advanced Settings pane also includes the following Dimension Grouping controls:

• Dimension Grouping (switch): Select Enabled to group traffic by dimensions before the final top-X evaluation.

• Grouping Summary: A dynamically generated plain-text summary explaining exactly how the system will evaluate your configured groups and keys.

• Dimensions to Group By: Specify the number of dimensions, starting from the top of your selected Policy Dimensions list, to form the basis for grouping.

• Maximum Keys per Group: Use the selector to choose the number of keys from each group to include in the overall top-X pool. Value cannot exceed 300.

  Note: This value cannot exceed the limit set in Maximum Keys Per Evaluation.

Activate & Clear Settings

An alert policy's Activate & Clear settings define the exact set of conditions that must match for the policy to enter an alarm state. Upon activation, the policy generates an alert for each key where the conditions are met. These settings manage alert triggering criteria, event frequencies, manual acknowledgments, mitigations, and notification routing.

Global Options

• Suppress Alerts: A toggle switch that engages Alert Suppressions for this policy. When turned On, the policy will not enter an alarm state, trigger notifications, or initiate mitigations until a specified end date (ideal for establishing new policy baselines or staging).

  Notes:

  • Alert suppressions are enabled by default for query-based policies.

  • Alert suppressions can be enabled on a pattern basis on the Alert Suppressions & Silences Page.

  • Suppress Alerts End Date: If Suppress Alerts is switched on, specify the date on which the alert suppressions will end. The default is seven days.

Severity Tiers

Each policy includes at least one active threshold but can evaluate up to five severity tiers simultaneously. Select from the horizontal tabs (Minor, Warning, Major, Severe, Critical) to configure properties per level:

• Enable Toggle: Turns the selected severity threshold On or Off. Disabled thresholds can be retained for future use without evaluating traffic.

• Description: A free-form text box to document the unique intent or monitored conditions of the specific severity level.

Conditions

The Conditions pane is where you define the technical rules that constitute a match. If multiple conditions are selected, all of them must evaluate to true simultaneously to trigger the alert. At least one condition is required:

• Static Condition: Evaluates current metric data directly against a fixed numeric threshold value (e.g., if traffic is at least 100 packets). Click Show Chart to display a visualization of recent data.

• Baseline Condition: Evaluates current metrics against a rolling historical baseline (e.g., if traffic is at least 20% above the baseline).

  Note: Requires a Static Condition to be active.

• Top Keys Condition: Evaluates changes in the composition of the top-X keys (e.g., when a key joins or leaves the top keys in current traffic).

• Interface Capacity Condition: Triggers alerts based on an interface’s current utilization relative to its total capacity.

  Note: Requires the Bits/s metric and an Interface dimension.

• Ratio-Based Condition: Evaluates the ratio between two different metrics.

  Note: Requires at least 2 metrics to be selected on the Dataset tab.

Frequency

The Frequency pane is where you control the temporal parameters required to confirm a genuine alert state and prevent "flapping":

• Trigger Threshold: Requires the above conditions to be met at least X times within a rolling window of Y [Minutes/Hours].

• Reset Period: The duration (in minutes) of continuous activity-free metrics required to completely reset the condition counters back to zero.

Acknowledgement Required

• On/Off Toggle: When enabled (On), incoming alerts initially enter an "Ack Required" state, requiring manual confirmation from an operator via the active alert workflows before they can be cleared or resolved.

Mitigations

Note: This section is only visible when a Flow-based policy’s dimensions include source or destination IP/CIDR.

• Mitigation Selector: Choose one or more automated mitigations to activate when this threshold is triggered to protect network availability from undesirable traffic. (Automated mitigations will escalate and de-escalate automatically as changing conditions match different thresholds).

Notifications

• Notification Channels: A multi-select field to assign where alerts are routed when triggered (e.g., Slack, PagerDuty, Email).

• Add New Channel: Click to open the Add Notification Channel page to build and bind a brand new notification destination directly from the policy workflow.

• Test Notification Channels: Click the button to initiate a test notification to the selected channels.

Fallback Settings

Note: This section dynamically appears only when your conditions compare current values to baseline values).

• When Baseline Values Are Missing: A dropdown that determines how to handle a missing comparison value if a key in the primary top-X is missing from the historical baseline set. Options include:

  • Use Lowest Value from Top Keys (Default)

  • Use Highest Value from Top Keys

  • Use a Default Value

  • Do Not Alert

  • Activate an Alert

• Fallback Value: Specify the static numeric fallback value to use for the metric if no baseline top key values exist (e.g., if baselining has not yet finished accumulating data).

Baseline Settings

Baselining triggers alerts based on comparing current traffic values to a baseline. Derived from historical traffic patterns, the baseline represents "normal" values for a key. If the current value deviates from the norm and matches an alert policy threshold condition, the threshold triggers an alert.

Baselining starts with a historical data set:

• Covers traffic funneled similarly to the current traffic (see Policy Dataset Settings).

• Covers a specified time range (baseline window).

• Includes time series data points representing traffic volume for a top-X key over a duration (1, 2, or 5 min) determined by the Dataset tab's Evaluation Frequency setting.

Two main stages build the baseline:

• Building the baseline: Smoothing spikes or drops in normal traffic by normalizing/averaging data points for each top-X key over the baseline window (options in Building the Baseline). The result is "buckets" each with a duration of one hour and with values for each of the top-X keys.

• Using the baseline: Choosing and normalizing/averaging key values in selected buckets into a final historical value for each key (options in Using the Baseline). The final baseline value is then used in comparisons in the conditions of each threshold.

A match between the current value and the final baseline value triggers an alert, depending on the threshold’s Frequency settings.

Note: Historical baseline settings in a policy apply to all thresholds with baseline conditions.

Baseline Presets

Select one of the cards at the top of the Baseline tab to instantly apply a baseline configuration:

• DEFAULT: Builds a purpose baseline collecting 25 keys an hour, going back 4 weeks. Recommended for most general baseline uses.

• PRECISION: Builds a baseline collecting 300 keys an hour, going back 4 weeks. Recommended for the most accurate sample of network behavior.

• EXPRESS: Builds a baseline collecting 25 keys an hour, going back 1 week. Recommended for creating a quick baseline for general alerting.

• CUSTOM: Builds a baseline with flow data specifications of your choosing. Automatically selected if you manually alter any of the preset values below.

About Your Baseline

The ‘About your baseline’ section is a dynamically generated text block that confirms what data is being measured. It displays the primary metric (e.g., Packets/s) and the time interval for datapoints (e.g., 60 Seconds) based on your selections in the Dataset tab.

Building the Baseline

This pane (under Advanced Options on the Baseline tab) helps you determine how the historical data buckets are built:

• Window: Determines the number of buckets by going back a specified duration (e.g., 4 weeks) from a specific endpoint (e.g, 1 day ago):

• Bucket Depth: The number of top-X keys collected in every hour of the window. Defaults to the Maximum Keys per Evaluation setting (see Advanced Settings).

• Rollup Aggregation: The mathematical method (e.g, 98th Percentile, Maximum, Minimum) used to derive each key’s value for the one-hour bucket.

Note: The baseline window is "rolling," meaning older traffic data ages out and newer data is added continuously.

Using the Baseline

The Using the Baseline pane determines how comparison values are derived from your buckets:

• Compare to: Determines which buckets are used to establish the baseline (e.g., the current hour of every day of the week).

• Bucket width: Derives the value for each "compare to" hour from just that hour or by aggregating surrounding hours.

  Note: If aggregating surrounding hours, you can choose to aggregate 1 to 4 hours before and after the nominal hour, using minimum, maximum, or a specific percentile (5th, 10th, 25th, 50th, 75th, or 90th).

• Final aggregation: The mathematical method (e.g., 95th Percentile) used to combine the key’s values into the final comparison value.

• Use separate patterns for weekdays and weekends: A checkbox that calculates baselines for UTC weekends independently from UTC weekdays to account for varying traffic patterns.

  Tip: Policies watching for excess activity usually use Maximum, 98th, or 95th percentile aggregation. Policies watching for below-baseline activity typically use 25th percentile aggregation.

Dashboards & Labels Settings

The Dashboards & Labels tab (located under Optional Settings) allows you to organize your policy and associate it with relevant visualization tools within the Kentik platform.

Labels

Apply labels, i.e. organizational tags, to group, sort, and filter your alert policies across the controller view.

• Apply labels to this policy...: Click the dropdown menu to open the label selector. You can type to filter the list or check the boxes next to existing labels to assign them.

• Select All / Clear: Quick-action links to instantly select all available labels or remove all current checkboxes.

• Add Label: A link that opens the Label Controls in a new browser tab to let you create a brand new label from scratch.

Dashboard

Associate a specific dashboard to be linked directly from alerts generated by this policy.

• Dashboard Selector: Click to choose an existing Dashboard from the dropdown, filtering by dashboard name as necessary. This sets the destination for the Open Dashboard button when an operator investigates this specific alert on the Alerting page (see Alert-Specific Actions).