Feature Overview

We're excited to announce our new device-based alert-policy-creation workflow which provides a simpler, more powerful approach to creating intent-based alerts and notifications. Our now-deprecated "Up/Down" policies only allowed alerting on present states, "up" or "down" for example. The new system understands state changes and allows for multi-measurement comparison.

Specifically, Kentik users can now:

• Alert on entity state changes
  ex: BGP transitions from “established” to “active or “idle”
• Alert on multi-measurement threshold breaches
  ex: laser temp and fan-speed high, where int desc is “X”
• Enjoy Alert Manager Support for notifications, suppressions, silencing, acknowledgements, clearing and alert detail views

Key Workflows

Where to Start

From the Alert Policies Management page, users will notice the first change when adding new alert policies. These new "NMS" type alerts entirely replace our now-legacy "Up/Down" policy type. "Up/Down" policies that existed prior to release of this new feature still exist, and are editable. However, it is no longer possible to create alert policies of this type. Our new "NMS" alerting capabilities are better in every way.

Adding a new policy: General

The General section of the "Add NMS Alert Policy" workflow allows you to put a name and description on the policy, as well as control whether or not it's enabled.

Adding a new policy: Target & Filter Settings

The "Target & Filter Settings" section of the "Add NMS Alert Policy" workflow allows users to set their intent. This field defines what "entity" or custom measurement the user wishes to drive a notification against and grab their attention. Currently supported "entity" types are BGP Neighborships, Components, Devices, and Interfaces. The selected "Target Type" will control what "Measurements" are available to alert against.

The "Edit Devices" button will open a dialog box to determine which devices the alert policy should apply to.

Adding a new policy: Activate & Clear Settings

This new NMS alerting system will only support a single severity level per policy for now. We intend to expand this in the future. From this screen, users can also toggle acknowledgement and manual clearance requirements, set notification channels, and tune activation and clearance delay.

The part of the new system we're most excited to share is our Alert Conditions workflow! This allows users to build sentence-style conditions with advanced logic to build out complex and specific alert criteria. At least one trigger condition is required. The measurement determines what metric is available. Condition dropdowns allow for construction of readable sentences. Threshold and state conditions can be stacked. It's a massively flexible system, and this is just our first release. In the near future we intend to add support for "nested Boolean", or "compound expression" conditions.

Managing Alerts

There are essentially no changes in terms of how and where to manage this new type of alert. NMS device-centric alerts work just like traditional Kentik alerts in that they are viewed from the Alerting page, have Alert Detail sub-views, and can be suppressed, silenced, acknowledged, commented on, or cleared.

Feature Requests & Bugs

This is a new feature and we're actively seeking your feedback and ideas to make it better. Reach out through your customer success rep or directly to the Kentik NMS Product Manager (Jason Carrier, jcarrier@kentik.com) if you'd like to influence the future development of this feature.

BGP Monitor tests in Kentik Synthetic Monitoring came out including tests for the following elements:

• Reachability: % of BGP Vantage Point threshold to determine whether prefixes are visible “enough” through the public internet
• Allowed Origin: whether detected originators are part of an allowed-list (manually specified, or via RPKI) - this is commonly referred to as “Origin Hijack Monitoring”

The health of a BGP Monitor test was then the worse of these two tests, across all prefixes registered in the test, with the specificity that “Allowed Origin” could only be healthy or critical.

The “Allowed ASNs” test has now been renamed “Origin Hijack detection” to match what the industry is calling it.

Additionally, we have added “Upstream Leak Detection” - here’s the practical use for it:

In a normal situation, you only want your Upstream IP Transit Providers to announce your prefixes to the rest of the world: under no circumstance do you usually want your peers to announce your prefixes to the rest of the world as if they were your transit provider. They should keep these routes to themselves, and only use them to go from their network to yours (announcing them to their peers will break that partition).

Enters #4 step of the updated BGP Monitor test where you can now enter the ASNs of your “official” Upstream Transit Providers and we will inspect the 1st hop in the AS Path of all announcements of these prefixes (and of their more specific children).

Remember that with all BGP Announcements collected from the BGP Vantage Points, come an AS_PATH that gives the following information:

…. various ASNs …

If the is not part of your allowed list of Transit Providers for any of the prefixes (and their more specifics), the entire BGP Monitor test will be flagged as critical for “Upstream Leak”.

For further reference, the diagram below details Origin Hijack vs Upstream Leak

Early this year we launched Kentik Market Intelligence to spell out the internet interconnection ecosystem for you. It crunches large amounts of public BGP routing data, and scores and ranks all networks in any market based on the size of their customer base.

With this new release, we've added a significant feature set: Kentik Market Intelligence Insights. 

KMI Insights? Tell me more...

Insights are the relevant news items around the networks and markets you care about. When crunching the billions of BGP dump entries multiple times a day, our platform now identifies interesting insights that get contextualized in the KMI UI, coloring them with the networks involved and the market they are observed in.

Sample insights can be: added within for instance, or any network adding new providers, as well as rank changes and changes in routing announcements between two networks.

Each insight comes with a certain amount of mandatory attributes: 

• A Customer Network: as identified in the Provider/Customer ASN relation we crunch with every run
• A Provider Network: as identified in the Provider/Customer ASN relation we crunch with every run
• A Market: the market this insight applies to
• Insights type:  as explained before, our engine classifies insights based on their nature (see list in the screenshot above)
• Magnitude: an arbitrary 1-5 value that helps order these insights from most important to least important, which is most often correlated with the change in prefix score, either plus or minus, between two networks

All these attributes have two purposes: helping the Kentik Market Intelligence UI display them in context (see further down this announcement), and allowing users to slide and dice these insights and tailor them to any subset they'd like to keep track of.

Contextualized insights

A new "Top insights" panel now appears on the right side of the landing page, it can be collapsed/expanded using the top right [insights] toggle.

The landing page will display unfiltered insights, ordered by magnitude, and this list of insights will by default follow the market filter used on the landing ranking screen.

This side panel can be configured to include or exclude specific types of insights, or to extend the period covered by the insights.

When navigating to any Network Details screen, the insights right-side panel will be displayed on the "Overview" tab for this network, and filtered to focus on the investigated network.

Track Networks and Markets that matter to you !

A while back, we introduced Observation Deck, which is a place for every user to compose their landing page with the areas of network visibility that specifically matter to them, based on widgets from specific workflows and areas of the product.

Kentik Market Intelligence now has its first widget and it's powerful!

In the future, we will add more KMI-related widgets to the Observation Deck so that you can embed widgets showing rankings and visualizations from KMI.

We hope you'll enjoy this update as much as we do. Please send us your feedback on it, we'd love to hear what you think!

In previous releases we provided the option to include network layer data in web tests by enabling ping and trace route in HTTP(S) and Page Load tests. This allowed us to quickly correlate application and network metrics to identify the root cause of an application's performance or availability issues.

Expanding on our cross layer visibility we can now include BGP data in web tests as well. Allowing us to further improve the time it takes to identify the root cause of issues as originating in either the application, network or routing domain.

Where previously you would need to create a separate BGP Monitor test you can now examine the same BGP data in an adjacent tab on the results page itself. No need to jump between test views!

When included, BGP data will be visible as an additional tab in the test results page.

Putting it altogether, we can now analyze all layers of information relevant to a target application's health on the same screen, including

Application metrics and Network Ping metrics in the Results tab.

Network Trace metrics in the Path View tab.

To add BGP data to an HTTP(S) or Page Load test turn the switch to "Enable bgp monitoring" (disabled by default) and enter the necessary details as you would for a regular BGP Monitor test including health options for Allowed ASN(s), RPKI status and Reachability (Advanced Options). 

Refer to the KB for more details on configuring BGP Monitor tests.

Building on our existing BGP monitoring capabilities – Event Tracking, Hijack Detection, Route Leak Detection and RPKI Status Check – we majorly enhanced our BGP monitoring feature set (under Synthetics) with new visualizations that track BGP Reachability and the BGP AS Path.

See the related blog posts, Introducing BGP Monitoring from Kentik and Why You Need to Monitor BGP, or watch the video (webinar) Why you should monitor BGP and where to start for useful overview information.

To get started: click Menu > Synthetics > BGP RouteViewer (we automatically pull in your AS and Prefix info for you) and click the blue  "Start Monitoring" button. 

Or go to Synthetics > Test Control Center > Add Test > BGP Monitor to create your own test

Reachability tracking

We help you track changes in the reachability of your prefixes from hundreds of vantage points all over the internet and will alert you when any of them become unreachable. You need to be sure that traffic from your ASes can make its way to your customers and the service providers you depend on.

AS path change tracking

Frequent changes in the path that BGP route announcements take between ASes can be a sign of instability. Monitoring for these changes and getting alerted as soon as they occur is a key part of ensuring service reliability.

AS path visualization

Fast troubleshooting of issues requires being able to visualize data to find trouble spots quickly. We give you a 10,000-foot view of changes in BGP routes over time — an indispensable tool!

March 2022 comes with a flurry of new Synthetic Monitoring feature updates. Amongst others:

• A new top-level location for the BGP route viewer page
• Multiple enhancements to the synthetics Performance Dashboard

BGP Route Viewer Page

Similar to the State of the Internet page, we have moved the BGP Route Viewer tab into a separate top-level page. We recently introduced BGP performance monitoring as part of the Kentik Network Observability Cloud, and want to give this feature more visibility as many customers requested it. If you’d like to learn more about this feature and its use cases read the blog post, Introducing BGP monitoring from Kentik.

Performance Dashboard enhancements

We continue to enhance the Performance Dashboard moving it more towards being a true dashboard. The updated widgets include: The incident log (width), the Test Status Summary pane (styling and location), the Recently Added Tests (styling and location), and Agents and Credits (styling and location).

KMI is a new service provider workflow that uses the global routing table to classify the peering and transit relationships between ASes and to identify the providers, peers, and customers for any AS in any geography. KMI estimates the volume of IP space transited by ASes in different geographies and produces rankings based on that volume, thereby enabling users to compare ASes in various markets.

This new workflow is available to all Kentik users with Premier Edition or with the service provider add-on available for the Kentik Pro Edition. This new workflow does not require any configuration and is immediately usable, as it relies on public routing data from a large number of BGP vantage points all around the world.

As routing data gets crunched on a daily basis, it can now be consumed via a simple interface allowing our users to decrypt how networks are connected to each other, what any network’s customer base looks like or what their providers and peers are.

KMI uses the global routing table to classify the peering and transit relationships between ASes and to identify the providers, peers, and customers for any AS in any geography.

Additionally, KMI scores and ranks any network against the size of their customer base in any subdivision of markets, as well as per customer base type such as retail, wholesale or backbone. KMI can now serve as a public, neutral and objective benchmark to score and rank all networks.

Here are a few pointers to get you started with KMI:

• Product page: Kentik Market Intelligence
• Blog post: Launching a labor of love, Kentik Market Intelligence
• Press release: Kentik Market Intelligence launches to benchmark the internet
• Knowledge Base article: Details about how the neutral, objective scoring and ranking algorithm works

This December, a few top demands make it to the synthetics product area, amongst others: 

• App Agents get the traceroute and ping data back-ported from the legacy Private Agents
• BGP Monitor tests are made easier to navigate by allowing you to switch between the prefixes being monitored
• All existing Notification Channels are now available to synthetic tests

Ping and trace in page load tests

You are now able to run ping and traceroute on the App Agents. As a first step in the rollout, we have enabled UI changes to be able to run this as part of the Page Load test (the only test that uses the App Agents today).

BGP Monitor aggregated prefixes and prefix selector filter

Based on feedback from certain customers we realized that the BGP test results were noisy and it was hard to get a high level view of the number of changes and prefixes involved before digging into the details. We have made three changes to address this:

• We are aggregating the result set by prefix and grouping them into collapsed groups.
• The header for each group indicates the total number of BGP events grouped by type (Announcements, Withdrawals and Unexpected Origin events).
• A prefix selector on the top right allows users to easily filter down to a specific prefix and doing so only shows events for that specific prefix over the selected time range.

Support for all notification channel types in Synthetics

When we added support for alerts and notifications in Synthetics about a year ago, we supported Slack, email and JSON/webhook. We did the work necessary to support and template all the other notification types and have exposed them in the UI.

RPKI validation in BGP Monitor

We’ve added optional RPKI validation to the BGP Monitor test. When enabled (also the default) we will query the RPKI database and report the RPKI status in the result set.

New App Agents

We released a new set of agents that will enable tests at the application layer. These are what we’re calling “App Agents” and they are capable of running a full headless Chrome browser instance. These agents will enable us to offer our customers tests like Page Load tests and Transaction tests. When used in conjunction with our rich network layer functionality, these new agents and test types will allow network engineering and network operations teams to quickly determine if the issue is at the network layer or at the application layer.

Full Browser Page Load Test

We activated the Page Load Test type that performs a full browser page load using the new App agents.

• The new test type can be set up by clicking “Page Load” under “Web Tests”
• Agent selection uses the new App agents but this is seamless to the end user.
  • Once in the test setup, clicking the “edit agents” button will only display the App agents in the list (that is currently a subset of all locations but growing to include all currently supported locations).
• The test set up is similar to the HTTP or API test except:
  • It performs a full browser page load (while the HTTP test stops after the page contents are retrieved using a GET)
  • Only includes GET option (since it is a page load). Does not include ping and trace alongside the page load (we have plans to support that in the future).
• The results are presented in a similar fashion to the HTTP or API test, with the following differences:
  • Table columns include new “DOM Processing Time” and “Navigation & App Cache” that are specifically relevant to the time taken for the browser to load and display the contents of the page respectively

BGP Route Viewer

BGP Route viewer is the first of a series of capabilities planned to help proactively monitor BGP-related conditions that can impact performance. In response to customer requests and feedback, we have developed a comprehensive roadmap for BGP monitoring, and we believe our solution will have significant performance advantages over alternative solutions.

The first part of Kentik’s solution is BGP Route Viewer. BGP Router Viewer appears as a tab along with the existing SaaS and Cloud Performance tabs. For customers who have entered prefixes in their Network Classification settings, we will automatically load BGP update data for those prefixes in this tab. For customers who have not entered any prefixes in their Network Classification settings, we will show an interface that allows you to do so and give you the option to save the entered prefixes to the Network Classifications page.

HTTP Stage Timing and Charts

With the new Page Load tests, results can be plotted in a time series along with HTTP stages and the timing for each stage. This new view helps network teams isolate network layer issues from HTTP layer issues.

Major Path UX Overhaul

The (traceroute driven) path experience has been one of the most valued features of Synthetics and while it works well, we felt like we could go back and revisit the design holistically after having added a bunch of small and big features iteratively since it first launched (back in November). The updates we made can be summarized in two main buckets:

1. Improve the overall usability of the product/feature by:
   • Reducing the number of clicks to do things (like setting the thresholds and other config knobs)
   • Reducing the quantity of information presented on default load (intelligently collapsing things to reduce information overload)
   • Reducing the amount of whitespace used so it is more compact and requires less or no scrolling
   • Preventing the path from exceeding the bounds of the page
   • Avoiding the side pane (which required knowing that one should click and would cover a third of the path when open)
   • Remove the ping-driven health timeline, as this data does not necessarily correlate with latency seen on the path and can lead to confusion.
2. Support collapse/group by sites. This has been requested by a few customers, particularly ones that run tests within their own network and find the ASN option of less use (everything collapsed into their ASN). Having the ability to group by sites lets these customers know if a path change caused traffic to go through a different site instead of the expected/desired one.

Here is a list of the main changes:

• 
• Health timeline is removed from path tab. It was ping-results driven and could confuse users when it showed issues, but no issues were present in the path. (The path is trace-probe driven, which may not show the same issues for short-lived spikes.)
• 
• All group/collapse functions (ASN, left/right) have been rolled into one main “Group by” selector and the option to group by “Sites” has been added.
• Copy for geodistance-based latency comparison has been improved and helper text/icon added.
• Option to “Reset” everything back to default quickly has been added.
• 
• The ASN legend has been moved below the path UI and is displayed in a line, moving the path higher up in the page and reducing the amount of whitespace.
  
• The main path trace visualization has received the most significant overhaul and results in a much less overwhelming and much more fluid experience than before. Highlights include:
  • 
  • Extra effort has been put into avoiding overlapping traces that cross other traces and make the overall UI very busy and confusing.
  • You can hover over any node (without needing to click) and it will show you all the information available.
    
  • Similar to the node hover, hovering over an agent (source) or target will show you all the information cleanly organized in sections, and will give you a link to view the raw traceroute output. There is also an option to quickly collapse nodes for this or other agents with just one click, right there.
  • 
  • Previously we would only show latency for (red) links that exceeded the threshold and packet loss for (red) nodes that exceeded that threshold. Now this information is shown for all nodes and links. In cases where the metrics exceed the threshold, a red font is used to highlight. Further, previously high packet loss nodes were identified with a full red circle, which was confusing if there was an ASN with a similar color. Now this is made clearer with a red border.
    
  • 

Density Grid Groups Dashboard

In response to customer feedback, we have added a new type of visualization option under Synthetics in the dashboards (library) portion of the product. One of the key use cases is customers who set up DNS servers by zones and want to see a global view of the performance of their whole DNS infrastructure.

• Select “Add” a “Synthetics Test View” dashboard element and then pick the new “Density Grid Group” allows you to multi-select any tests configured in the system that are of type “DNS Grid” or “Network Grid.”
• Select a few tests and save the widget to display agents in the first column and then test results aggregated by target in the columns to the right of that.
• For each cell in the results, each square represents that specific agent hitting one DNS server to resolve the specific target.
• A holistic view lets the user quickly pinpoint any issues from a large number of DNS servers distributed across the world.
  

9 New LATAM Global Agents

We deployed nine new global agents throughout LATAM, improving our coverage in the region and increasing count from four agents to thirteen.