Feature Overview

NMS's device-centric alerting now includes the ability to use nested condition groups and Boolean logic when creating alert trigger conditions. 

Trigger logic using operators (ANY, ALL, or NONE) can now be combined and nested, which provides several key advantages, including:

1. More precise control over alert policies
2. Reduced alert noise
3. Better automation potential

This allows policy creators extremely granular control over determining what conditions cause an alert to fire, keeping focus on the alerts that are most meaningful to you, and minimizing noise. 

Here's what the starting alert conditions section looked like before:

And here it is now:

You'll notice you can now add "Condition Groups" and "Nested Condition Groups". These condition groups provide for Boolean logic in the alert trigger conditions - making Kentik NMS significantly more effective at managing complex network environments.

Key Workflows

Condition Groups

Condition groups are the "top level" layer. They can contain conditions and/or additional nested condition groups. Below is an example of a policy starting out with three condition groups. In this case, you can think of an implied OR operator between each of the red box condition groups. 

Nested Condition Groups

Nested condition groups exist in a hierarchy which can go four layers deep, each with their own operator, as shown here. This allows you to express complex decision-making processes clearly and efficiently.

Advanced Alert Policies

By using nested condition groups, NMS policy creators can now tune their alerts and notifications to only grab focus from network operators when doing so brings them critical network awareness.

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 our future development.

Connectivity Costs is one of our most successful workflows and it's always difficult to pick from the numerous feature requests open for it. This time around, we're adding Backbone Costs to the workflow, as it was one of the most demanded extensions. We took a bit longer than initially planned, because we had to completely modify the data model between providers and cost groups, and then migrate it. But, now it's here! Read on for the details. 

Workflow Terminology

In the entire workflow, we are going to refer to two types of costs: Edge Costs vs Backbone Costs. In our product terminology:

• Edge Costs: represent costs for interfaces facing the outside of your network – they are associated with Transit, IX, Peering, Direct Connects, etc....
• Backbone Costs: this is the new type of costs that this update workflow brings

The Edge Costs family represents costs at the edge of the network, i.e. to interconnect it to the rest of the internet. These are usually metered based on a price per consumed Mbps, with variations on the computation method and some amount of committed monthly bandwidth. Industry best practices require practitioners to evaluate these with a common measurement: Price/Mbps. This is what the initial releases of this workflow focused on.

Today, we're introducing Backbone Costs: This new family of costs represents portions of networks, most of the time points-to-points used to extend the network by renting physical infrastructure to a provider. Examples of these can be: Ethernet WDM Wavelengths, Dark Fiber Rent, Dark Fiber IRUs... Those links are rarely metered, usually have a fixed monthly rend, and practitioners do not want their costs computed as part of the Edge Cost/Mbps. Some of the reasons these links are traditionally excluded from Cost/Mbps computation are:

1. they very rarely come with a Committed Rate constraint
2. they don't depict interconnection costs, which Edge Costs do 

For the reasons above, we made the choice of treating these differently in the Connectivity Costs UX.

Changing the data-model to unlock new features

In the previous iteration of the workflow, the Connectivity Type attribute (Transit, IX, Free Peering, Paid Peering...) was an attribute of the Provider object – and it created multiple issues requiring this change.

This meant you could only have one Connectivity Type per Provider, which doesn't model reality: one may purchase both Transit and Point-to-Point backbone links from the same provider.

We wanted our users to be able to see costs for a given provider as a breakdown of "Edge Costs" and "Backbone Costs", but also at a global level, where we heard from our customers that they wanted to compute the budget for Edge Costs and Backbone Costs separately.

We went ahead and rebuilt the data-model behind the workflow, and while in Rome, we added a few Cost Group Attributes that our users had been asking for, and migrated our entire customers data set behind the scenes, as well as the computations that use it.

You'll notice that the Connectivity Type attribute is now part of the Cost Group object, and you'll also notice that we've added useful attributes such as Circuit ID (particularly useful for point-to-points) as well as Contract ID to back-reference the vendor contract in the object.

How are Backbone Cost Groups different ?

As mentioned earlier, Backbone Costs aren't pulled into monthly Cost/Mbps computations; therefore, we had to split every screen between Edge Costs and Backbone Costs, which you will notice on numerous screens:

Both the Connectivity Costs landing page and Providers pages now show a split of both – you'll notice the split on the top header strip.

On the Providers landing screen cost chart, you'll be able to look at cost either by provider (without Edge vs. Backbone split) or by "Edge vs Backbone" where you can now see the split evolving every month.

Additionally, the summary tables on both the Provider landing screen and on Provider details screen are now split in two: an Edge Costs table, and a Backbone Costs table.

The screenshot below shows these two tables in the case no Edge Costs are registered, for compactness.

Changes in the Provider Configuration screen

As we tested the feature with a sample set of customers, we realized the average number of Edge Cost Groups (aka transit contracts or such) could be dwarfed by the number of point-to-point links. Because of this, we had to re-think the Provider Configuration summary screen and make it more scalable. This included some changes such as increasing the density of cards displayed on that screen, adding search, and filtering screens – see for yourself below.

What does the future hold?

There's a lot more changes sprinkled throughout the workflow that aren't discussed in this article and we'd love to hear your thoughts and feedback after you've taken it for a spin, so let us know what you think.

There's more in our back pocket around costs that'll be released in the months to come, so stay tuned, because it's going to get really exciting real soon!!!

Feature Overview

Together at last! We've made major improvements to how devices are viewed and managed on the Kentik platform by unifying multiple device management, performance detail, and traffic analysis pages into a unified devices experience. We've combined our three different "Device Listing/Admin" pages and two different "Device Details" pages, bringing forward the best of each.

Happy Valentines Day, from Kentik!

Unified Device Administration

These three previously separate sections of the platform have been combined into one:

• Settings > Network Devices: where previously we managed "flow source" devices
• NMS > Devices: were previously we managed "NMS" device performance
• Network Explorer > Devices: where we showed aggregate traffic from multiple devices

Unified Device Details

We also combined and refined these two previously separate Device Details pages into one:

• NMS > Devices > (device_name): which provided performance information
• Network Explorer > Devices > (device_name): which provided for traffic analysis

Main Benefits

This is the initial step in a broad reaching project to make our NMS and Flow experiences more cohesive with a focus on the reality that there aren't "Flow devices" and "NMS devices", there are simply "devices we collect data from."

The most obvious key benefits are:

• One single, centralized, collection-protocol-agnostic place to administer all devices, providing a more seamless experience when investigating network traffic and/or device performance
• One single search capability: instead of NMS Devices and Networking Devices, universal search capability now returns only one single result, better aligning with reality
• For each device, we also now display all data in a single tabular place

Key Workflows

The changes in this new set of features center around three workflows: navigation, administration, details.

Navigation Changes

As part of this unification, we’ve re-wired multiple navigation links:

• Top Talkers > Devices → now leads to /infrastructure/devices where it used to lead to /core/quick-views/devices/
• Settings > Devices → now also leads to /infrastructure/devices
• NMS > Devices  → now leads to /infrastructure/devices
• Any Metrics Explorer or Data Explorer device link now leads to /infrastructure/devices/

These endpoints are not changing for now:

• /settings/interfaces still exists, while /infrastructure/devices//interfaces now offers an improved (more filtering, more powerful), list of interfaces narrowed down to the
• /nms/interfaces for now remains as a single, global interfaces screen for all NMS devices, while /infrastructure/devices//interfaces now offers an improved (more filtering, more powerful), list of interfaces narrowed down to the

Unified Device Administration

This screen becomes the singular place where users browse their inventory and add/remove devices from their Kentik experience. It presents the following characteristics:

• Two main tabs: “Traffic” and “Manage”

  • Traffic corresponds to our well known Network Explorer /core/quick-views/devices traffic related, top-talker screen
  • Manage corresponds to the merged and improved /nms/devices  and /settings/devices screens
• Three distinct “View Modes”, each corresponding to a column arrangement within the main Manage tab:
  • Monitor is a default column-set focused around performance monitoring
  • Admin is a default column-set focused around Kentik administration
  • Custom lets the user select and organize the specific columns they want 
• More powerful filtering and grouping options

Unified Device Details

• Overview - performance and vitality summary of the device
• Interfaces - filterable, searchable, data-rich list of all interfaces on the device 
• Connections - filterable, searchable, data-rich list of LLDP/manual topology connections
• Traffic - enriched traffic flow and "top talker" information for the device
• Hardware - vitality information from device components, such as fans and power supplies 
• BGP Neighbors - peer AS names, session states, local and remote IPs, and summary info
• Telemetry - New! This tab highlights data collection methods and if they're working or not

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.

As part of our constant efforts to secure Kentik Portal, we are updating our SSO capabilities to more recent and secure server-side code. 
Evolving SAML2 standards now require Identity Provider users to configure their Identity Provider’s Public Signing key (x.509) for each Service Provider SAML2 app they govern. 

⚠️ This security upgrade of our SSO/SAML 2.0 Backend requires us to make IdP Public Signing Keys (x.509 certificates) mandatory for our SSO Users.
On March 31st, Kentik accounts without this configuration will be able to SSO into Kentik Portal: "SSO Enabled" Accounts will still be able to login via user/password, while "SSO Required" accounts will not be able to access Kentik Portal at all (save for their SuperAdmin users).

All accounts with SSO configured and an IDP Signing key configured will be migrated transparently between now and March 31st.

Read on for the instructions if you are using SSO with Kentik.

How do I know if my company needs to update my SSO configuration ?

The first thing you need to know is that SSO Configuration in Kentik Portal can only be modified by users with a SuperAdmin user-level - traditionally, the first user to open a Kentik account for your company will be the SuperAdmin and the only one able to create other SuperAdmins moving forward. 

SuperAdmins is the only class of users who can login with User/Password credentials even when SSO is "Required": the reason for this special privilege is that at least one person in the company (ideally not too many) need to be able to disable SSO in case of a major Identity Provider failure that would prevent your users to login to Kentik.

If you are a SuperAdmin, the SSO config screen will be located at 

• https://portal.kentik.com/v4/settings/authentication/sso-settings if your account is on our US SaaS Cluster
• https://portal.kentik.eu/v4/settings/authentication/sso-settings if your account is on our EU SaaS Cluster

Or you can just look for the SSO Settings tab in the screen "Authentication & SSO"

On this screen, you'll now if your company uses SSO if this field is either set to Enabled or Required. "Enabled" means your users can login both via SSO or User/Password, if "Required" they can log only via SSO.

Next on the same screen, just look for the field depicted below:
if it is empty, this means you do not have the signing key for your Identity Provider configured and will need to configure it before March 31st, 2025.

If that is the case, your SuperAdmin users should have already been presented with a prompt to perform this change when logging into Kentik Portal.

Where can I find this IdP Public Signing Key ?

First you need to find a co-worker who has access to your Identity Provider's Admin interface. Typical Identity Providers are: Okta, Microsoft Entra ID (formerly ADFS), OneLogin, Ping Identity, Duo Security, Google Suite...

In this Identity Provider, you will have one configuration per App registered for SAML2 authentication - find your Kentik Portal application configuration.

From this point, the easiest is for you to find a way to download what is often referred to as "Identity Provider Metadata Configuration File".
If you open this xml file with a text editor, you will find your Identity Provider's x.509 signing key between these tags:

Just copy paste its content in Kentik Portal's SSO "IDP Public Signing Key (X.509 cert)" field and save your SSO configuration.

IMPORTANT NOTE:
Depending on your text editor, the Copy/Paste action may insert unwanted characters that will make the configured key malformed and make authentication fail.
This lifesaving online tool will strip this Cert string from all it's undesirable characters before you can safely paste it in your Kentik Portal SSO Configuration.

Additional notes

You may wonder: "Do I really need to do this ? What am I getting out of this ?"

• If your company accesses Kentik via SSO and you don't have an IdP Signing key, this change is mandatory.
• Remember that your local SuperAdmin will always have access to Kentik Portal with a user/password type of credentials, and will be able to disable SSO if your users are locked out
• The new backend code we are replacing the current SSO Engine with follows the most recent industry security practices, therefore making your Kentik Account more secure
• Our previous SSO login workflow did not carry the URL context forward: if you came in unauthenticated with a full URL from Kentik Portal, the SSO engine would log you in and send you to the homepage configured in your user profile: with this new code, we're carrying the inbound URL throughout the login process and landing you on the desired inbound URL. (which is specially useful when a coworker hands over a Data Explorer query hash and you haven't logged in yet).

If you require help with this configuration, our dedicated support team will help you at 🛟 support@kentik.com
If by March 31st you are locked out of Kentik Portal and your friendly SuperAdmin co-worker is not available to help, our Support Team can also help you too.

This update may not seem like a groundbreaking one, but as a user who uses Data Explorer 24/7, this one has been on my bucket list for a long time, and I'm unreasonably excited about it.

Read on!

Have you ever selected a large number of dimensions in Data Explorer, and been surprised to see the chart's Hover Tooltip cover the entire chart?

It used to drive me crazy... and while this wasn't mentioned by our users as an annoyance often, I'm pretty sure many people accepted it as an immutable reality that was never gonna change.

The screenshot below used to make me curse 🤬 even more than when I had to read text written with the Comic Sans font - and anyone who knows me enough knows how angry I get at the bare mention of this typeface...
Believe it or not, but there's an actual chart behind this tooltip on the screen grab below!!!

... and the main reason was that our charting library required so many technical contortions to get the tooltip to freely overflow out of the embedded chart that we could never find the necessary amount engineering cycles to fix it.

You will now be glad to hear that we have fixed this, and also provided a first round of layout efforts to make said Tooltip more legible. As you can see, the tooltip can now travel outside of the chart embed and take as much real estate as it needs from both the data table below, and the query panel as well, always leaving the currently-hovered part of the chart visible.

Laugh at me all you want, but every now and then, you get to fix one of your own nightmares and it feels very good - today is one of those days. :)

The story of how this came up is also a glorious one: during our weekly Product Design office hours, one of the designers teamed up live with one of our engineers and decided they were going to fix this LIVE during the meeting. Granted, it eventually took more than this live coding session in front of everyone, but it was a marvel of collaboration and ownership to watch, so tip of the hat to these two employees reading this article who'll know who they are, I'm pretty sure a lot of our users will be delighted!

Hope you enjoy the new tooltip as much as I do.

This update focuses on this very specific set of Cloud related dimensions that our Network Flow users have been asking improvements on when it comes to Data Explorer:

Keep reading if you use these enrichments in Kentik for your Networking Device flow telemetry.

What the problem was

If you are a current user of these dimensions (and it would be surprising if your Network didn't receive or send traffic to or from any of the Public Cloud Providers out there), you probably already know that the values displayed in these dimensions correspond to a text string containing:

• the Cloud Region
• the Region Availability Zone index
• sometimes an indication of which function/component of the Public Cloud Provider this flow record is associated with

This matching is based on reading the Netflow(Sflow, IPFIX) Source or Destination IP and matching it to public data-feeds from the leading cloud providers which contain a Region/Zone/Function to IP Ranges mappings.
One example of value that these dimensions can yield would be:

In this case we're looking at traffic coming from two Public Cloud Providers (AWS and Azure) into your network, with AWS traffic from eu-west-2 and eu-central-1 and Azure Traffic coming from westus-2

If you have multiple entries here, you may want to only look at traffic from AWS EU-West (all zones included), or just from AWS EU (all regions and zones included), which was previously impossible because the only filter operand on these dimensions was Equals.

The improvement we came up with

The filter operands available for these dimensions now include two different match types: Contains and Matches Regex which instantly grants our users a whole lot more flexibility.
If they now desire to filter for AWS traffic from all Zones in EU-West, they can now filter this way

... and obtain a query result such as the one below

Now combining it with the power of our Data Explorer Filter Based Dimensions - if they so desire they can construct their own dimensions based on filters

To obtain the below useful chart, that was previously not achievable

Feature Overview

Monitoring Templates are appropriate, customizable, data collection defaults - by Kentik. They can be applied to a set of entities (devices & interfaces) with a set of rules (filtering). With this new capability, Kentik Administrators can:

• Easily configure, apply and change monitoring targets and intervals across multiple devices at scale
• Prevent the polling of "admin down" interfaces, which will never be operational
• Stop polling virtual/stub interfaces that aren't "real"
• Manage Metric-per-Second ("MPS") licensing consumption (applies particularly to Streaming Telemetry)
• Control the fidelity of the data available to build graphs and other visualizations (1 minute polling vs 5 minute polling, for example)
• Influence the load created on devices by SNMP/ST data collection activities

Only Kentik administrators are able to access Monitoring Templates. 

Key Workflows

There are two ways to access Monitoring Templates in Kentik NMS. The first is by navigating to "NMS > Devices", and then using the "Manage" dropdown to select "Monitoring Templates".

The second way is when applying a template to an individual device by navigating to the "Edit Device > SNMP" tab, where there are navigational elements to also create a new template or access the Monitoring Templates settings page.

Note: Each device can only have one monitoring template assigned at a time.

Settings Page:

From the Monitoring Templates settings page, Kentik administrators can:

• View the list of preset and custom monitoring templates
• See how many and which devices are using which template
• Add, view, copy, edit or delete existing templates

Note: Devices that existed prior to October 2024 will not have a template applied, and will function as though they have the "Everything" preset, but will not show up on this settings page. New devices will automatically have the "Everything" template applied.

The Template Itself:

Templates start with a name, description and interface selection. Interfaces can be selected statically or dynamically. Only selected interfaces will be monitored.

Note: Monitoring Templates also supports Settings > Interface Classification configuration for dynamic interface selection.

Advanced Measurement Selection:

The Advanced Measurement Selection workflow allows administrators to granularly choose which metrics will be collected from devices with the template applied.

Although Monitoring Templates are an "SNMP" tab setting on the device presently, we've also included (for now) some Streaming Telemetry settings. If the "Specify streaming telemetry intervals" option is enabled, a new "Streaming telemetry interval" column will be available on the template.

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.

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.

As you may or may not know, the CDN Analytics module in our Premier platform edition leverages a powerful and constantly evolving engine to detect all CDN IPs around the world and assign them to CDNs it knows about. The number of CDNs our engine is able to detect, as well as the precision with which it can identify their IPs inside or outside of your networks, keeps improving over time as it learns.

Two new CDNs covered by our CDN detection engine!

This time around, our engine has learned of two new CDNs: EdgeNext and Netskrt. EdgeNext is a commercial CDN with a strong focus and footprint in Asia. Netskrt is a software/appliance-based CDN that specializes in last-mile caching for broadband ISPs, often referred to as a "Cache Embedding CDN" - they are one of these new-gen CDN Providers in providing technology for last mile caching but also match-making Content Providers with Broadband Providers (Qwilt is another one of them)

As you can see in the CDN Analytics workflow UI, this takes our engine from an impressive 60 CDNs detected to 62!

The special treatment Embedded CDNs get in our workflow

Embedded CDNs are identified as such by our engine, which attempts to auto-detect IP ranges of such embedded caches on your network based on Interface Classification (Connectivity Type, and Provider attributes of your interfaces).

If your Interface Classification is configured thoroughly and sets interfaces to Connectivity Type = Embedded Cache with an Interface Provider = "netskrt" then our CDN engine will pick them up and automatically classify the IP Range they're on as CDN IPs, associated in this case to the Netskrt CDN Name.

If your embedded caches are on network devices that aren't exporting flow and SNMP data to Kentik, we also give you the opportunity to manually enter them and help make this engine smarter, via CDN Analytics > Configuration > Additional Embedded Caches.

Beyond these capabilities, one of the key aspects of embedding CDNs is how much offload they yield, i.e. how much upstream bandwidth they help you save – in other words, how efficient are they. For every new embedded CDN we add, we also add CDN Analytics landing page widgets to display this offload percentage.

This iteration is no exception – we've added both Qwilt and Netskrt widgets to your landing page. To enable/disable these widgets, go to CDN Analytics > Configuration > Landing Page and see for yourself which ones you want activated.

If, like Pokemon, you gotta catch 'em all, your CDN Analytics workflow landing page can look a little like this:

Take this feature for us spin and let us know if you like it !

We've introduced the Alerting Overview to help you manage your network health. We recognized that customers needed a clear way to spot patterns, assess risks, and share progress with stakeholders using their alerting data. By providing an interactive view of how the shape of alert volume change over time, you can pinpoint recurring issues, address them quickly, and avoid future disruptions. The new page is designed to provide an executive-level source of truth for the overall shape of historical alert data, making it easier to identify and prioritize problems from a macro view. This means you can adapt faster, keep stakeholders better informed, and maintain higher service quality. The new dashboard highlights:

• Alerts by Type (NMS, Traffic, Protect, and Cloud)
• Most Triggered Policies
• Monthly Alert Trends by Severity
• Alerts by Site

You can also filter the report by quarter and source alert type.

And easily export reports to PDF for convenient sharing.

To access the new Alerting Overview, go to the Alerting page and click the Alerting Overview button.