This feature is a small one, but one that has been requested by a deceptively high amount of our users! A lot of screens in Kentik portal let the user scroll through a list of "Objects", and these list views are usually filterable by a variety of attributes that depend on the nature of the object: Interfaces, Devices, Sites, Synthetic Tests, Synthetic Agents... Users have asked us to make it quicker for them to select these objects using combination of labels. Read on !

About a year ago, we released an updated version of our new Role Based Access Control system that leveraged Labels in order to make management of permissions on labels a much more efficient task, where users were now able to apply permissions on collections of Objects (aka Dashboards, Saved Views, Synthetic Monitoring Agents, Synthetic Monitoring Tests, Devices, Credentials ...).
This made Labels in Kentik more valuable, useful, and central to the entire product.

One of the requests that kept coming back to us from our users was the ability for the user in these list-type screens to be able to better filter on either Intersection or Union of labels.
A simple way to look at it, a very common need that surfaced when we released the unified Traffic and NMS Device screens was, for instance: 

Show me all my Routers that both have CDN Caches connected to them AND are used to connect transit providers

A common way for our users to add this metadata to devices would be to leverage the flexibility of Labels – and our new UI allows them to narrow down the list of devices from the Device Management Screen using a logical AND expression in the filter as shown below.

Notice how the top-right of the Label input filter now contains an AND/OR selector ? 
This is how you do it: AND will Intersect all labels in the field, while OR will display the union of objects with the labels in the field.

Going back to our example, this is what it would look like in the Device Management screen:

Another pretty common ask was, for example:

Show me all the Synthetic Tests configured to be used in Production AND built to monitor Kentik Portal

...and in this case, users would also use a set of labels to describe which tests are used by the Production Team, and which tests are focused around monitoring Kentik Portal. Notice how we drink our own champagne in the screenshot below 😉

The Library module in Kentik Portal got a special treatment: remember how Kentik offers a lot of Preset Dashboards and Saved views ? (by the way, always peruse our library, a lot of the presets here have been built for our own needs, chances are every time you want to create a Dashboard or a Saved View, one of our Network Nerds over at Kentik has already produced something similar for you to use or steal inspiration from)

In this special case, the Library Label Filtering capability allows users to expand and contract two categories of labels: Kentik Presets and Your Own Company Labels, as displayed in the example below.

Hope you find this feature useful!

As you've read in previous updates, we are progressively extending our RBAC capabilities towards an increasing number of Kentik Portal functionalities. This time around, we've added RBAC to Devices.
Read on as we explain how this works!

Previously on RBAC...

1. In November 2023, we released our initial RBAC capabilities, you can read about it here: https://new.kentik.com/role-based-access-control-is-live-3R1D68. The initial release covered RBAC management, Connectivity Costs, Synthetic Monitoring Agents and Synthetic Monitoring tests.
2. In March 2024, we both overhauled the admin UI for RBAC, and Label-based RBAC, extending its capabilities to dashboards and saved views based on Labels: https://new.kentik.com/label-based-rbac-and-more-2GBruo, so users could manage content in a centralized and more straightforward way. 
3. In May 2024, we extended RBAC capabilities to our Credentials Vault: https://new.kentik.com/rbac-extends-to-credentials-vault-1Yrrwc.
4. In November 2024, we linked SSO and RBAC. We introduced Role-Sets and SSO to RBAC attribute mapping, so that user groups read from your SSO Identity Provider could dictate and enforce RBAC permissions for groups of users.
   https://new.kentik.com/sso-to-rbac-attribute-mapping-30lFi8.

As we've said before, the entire migration of our legacy UserLevel model (Member, Admin, SuperAdmin) into RBAC is going to take some time, but we're constantly adding to its coverage.

What does RBAC for Devices look like ?

In your RBAC Role creation UI, you can now see this additional area of permissions, allowing you to enable permissions throughout the portal related to Devices exporting telemetry to Kentik.

With the unification of NMS and Flow management screens released in February 2025, these Device-level permissions apply to both NMS and Flow devices, see the announcement here: https://new.kentik.com/nms-flow-unified-device-experience-makes-them-better-together-2xzqg.

When configuring RBAC permissions around devices, the View, Update, and Delete permissions can be scoped to specific labels. For instance, if a certain team should only have View access to edge and core devices, your permission set should look like this:

Effectively, this means that users assigned to this role — assuming no other assigned role grants broader access (since we union permissions across all roles) — will only be able to see devices with the edge and core labels,  which, among other things, imply:

• Any Dashboard or Saved view they will access will only include data from devices with these two labels, even if the dashboard or saved view initially contains All Devices
• When on the unified Device Management screen, these users will only see core and edge devices listed, even if there are more of them
• Users will only be able to see the interfaces in the Settings > Interfaces screen corresponding to the devices that they have permissions to view (therefore the same Interface screen will contain more interfaces for device-unrestricted users than one with restrictions)
• For any Network Explorer view that contains device breakdowns, those of a user with device restrictions will only include data from those devices (therefore the same screen will look different from that of a user with permissions to all devices)
• Any Device API call will be bound to the same permissions as that of the user whose API token is issued to make the API call: in other words, API and Portal permissions for devices are the same for a given user
• The Capacity Planning workflow will exclusively use the permissions of a given user to display capacity: if a capacity group contains interfaces from devices a user isn't allowed to see, they won't be displayed in the Capacity Group details (again the same screen will look different depending on the Device Permissions of the user)

As an exception, Connectivity Costs is unaffected by Device RBAC for now. Users will be able to see all connectivity costs, including for interfaces that belong to devices they are not permitted to view. If they click on these interfaces, then they will be blocked from accessing further details for that device.

How do UserLevels map to Device RBAC permissions?

Prior to Device RBAC rollout, device permissions where somewhat rudimentary:

• Member users could only View devices
• Admin users could View, Create, Update, Delete devices
• SuperAdmin users had the same permissions as Admins

For the sake of backwards compatibility, the Member, Admin and SuperAdmin Kentik-Managed Roles have been updated accordingly

Admin, SuperAdmin Kentik-Managed Role

Member Kentik-Managed Role

When a more fine-grain approach is needed, Kentik-Managed Roles can be removed from users and replaced with more elaborate ones. For now, Kentik-Managed Roles are intended to provide continuity between UserLevels and RBAC.

Please note:

A user with Device Create permissions can create a device with any label they want. If they only have Device View access to a restricted set of device labels, this means that not assigning a label at device creation time, or assigning one they can't View devices for, will prevent them from being able to see the device.
We will be remedying this in a short term update where any Create permission will be able to come with a default set of allowed labels, together with making labels mandatory (showing only the ones a user has access to) at Device Creation time.

What's next ?

Based on your feedback, our next RBAC extensions will be:

• "Add" type permissions to be label-compatible:
  • Configure which labels a user is allowed to attribute to a device at creation time
  • Make label assignment mandatory for users with Label-based permissions to avoid cases where users create devices they can't eventually access because of label-restricted permissions.
• MyKentik Portal RBAC: leverage labels to determine which user has create/edit/delete access to which Tenants

If there are different areas of Kentik Portal that you'd like to see rolled-up into our RBAC capabilities, please let us know !

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

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 !

As cloud network engineers work towards optimizing their cloud infrastructures for costs, performance, and security, they need to be able to quickly and easily investigate traffic across various public cloud regions and availability zones in GCP, AWS, and Azure. 

This detailed traffic path between cloud components is central to Kentik's Cloud offering; however, up until now, filtering for this traffic in Data Explorer required users to manually list all of the Zone to Zone options – which was inconvenient at best. So we fixed that. Read on.

Introducing a new type of filter clauses

The magic here lies in this new filter, now available for a certain list of hybrid cloud related Data Explorer dimensions: 

Source != (or ==) Destination

Here is how these look in Data Explorer now:

...using these two filter operators from the above screenshot now allow our users to filter traffic that either goes across zones (Does not equal the value of) or stays within a zone (Equals the value of) 

What dimensions is this available for?

While we were at it, we identified several other dimensions that could benefit from these new operators. Here's the list:

Beyond the hybrid cloud use-cases mentioned above, these new operators are also quite useful to look at inter-site traffic based on source or destination IP addresses as defined in the Site attributes.

Important note on Alerting
At the moment, these comparators are not available in our traffic-based alerting system.

Take these for a spin and let us know what you think!