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.

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!

This new feature may seem small because its UI surface is constrained within lesser-used screens, but it packs a whole lot of punch under the hood. Let's dive into the details of Kentik Portal authentication – the good, bad, and challenging aspects – because there's a lot of new things to unpack today.

Single Sign-On is the modern way of managing access to a broad set of company-wide applications in a structured and more secure way, centralizing access control for all of these applications in the Identity Provider (IdP)  companies have chosen.

When login happens in Kentik using SSO, the Identity Provider presents claims to the Service Provider (in our case Kentik Portal) for each user (user attributes) in a standardized format named SAML2. Each company has a different pre-existing way to define user groups and rely on their IdP to do so.

With this SSO to RBAC attribute mapping feature, Kentik makes it easier and more flexible to leverage your current IdP configuration of user groups to enforce Kentik Portal permissions.

Let's dive in.

UserLevel vs RBAC

As Kentik Portal moves to a full RBAC permissions model, many areas are still governed by our legacy UserLevel permission model: we have three types of users, each one with a set of implicit permissions – Member, Admin, and SuperAdmin. For all areas of Kentik Portal that aren't governed by RBAC, UserLevel applies:

• Members generally have View only rights
• Admins have Update/Create/Delete rights 
• SuperAdmins are a special case: they are Admins who have the additional power to login using password authentication, even when SSO is required – there needs to be at least one per company, but the lesser the better to keep risk surface as low as possible.

As we progressively extend the surface of portal areas that are governed by RBAC, these areas will not be covered by UserLevels anymore – but in the meantime, we maintain both.

What our users have been asking for

Many customers with a large Kentik user-base have asked for RBAC permissions to be controlled centrally from their Identity Provider, which implied the following requirements:

• Kentik Admins want to control RBAC permissions directly through their SSO Identity Provider, as managing users at scale requires a centralized approach and dedicated tool outside of Kentik's User Administration page. Additionally, not all users want or need to enforce RBAC permissions via SSO – some are OK with using Kentik Portal's User Management capabilities, meaning both methods need to co-exist.
• Kentik Admins want to leverage their existing IdP configuration without modifications. Typically, the SSO team prefers to not create new groups for Kentik, but instead use existing groups. 
• Some SSO IdPs allow users to belong to multiple groups. This usually results in nested User Groups being presented to authentication by the IdP, and Kentik SSO needs to accommodate this reality.
  This is typically the case for more complex SSO Setups bridging LDAP or ActiveDirectory user groups into SSO->SAML2.
• For whatever user attribute key handed out in the SAML2 payload, Kentik Admins don't want to have to create specific values to match what Kentik's Service Provider (SP) end of SSO expects – they want to use existing ones and map them.
• Kentik Admins want to be able to forbid access to Kentik Portal for users that aren't in specific groups (instead of defaulting to Member as our current system does).

Introducing SSO Attribute Mapping

To satisfy the requirements captured in the previous section, we've updated the SSO configuration screens quite drastically to present these new functions.
If you don't see the Company Settings menu entry below, you are not a SuperAdmin and therefore cannot access the SSO settings.

As you can see, there are two sections – one for UserLevel SSO enforcement, and the other for RBAC SSO enforcement, since both will coexist for some time.

• The configuration for UserLevel enforcement configuration aspects have changed to this new model
• We've added an RBAC role-set mapping section. Rightfully you're asking, "But what's a Role set ?" – hang on, we'll get to that later ;)

In both of them, the Kentik Administrator can configure the key, which will be presented by their IdP to the Kentik Service Provider end of SSO: the authentication engine will look for the key and its value(s) in the SAML2 assertion presented by your IdP. Upon successful match of the key value, the subsequent UserLevel or Role-Sets will be assigned to the user based on this rule:

• By default, if no key is configured, Kentik Portal will use portal-local user settings for UserLevel or Role-Sets: this is the most common case where you don't want your SSO IdP to dictate user permissions
• If a key is configured, then Kentik Portal will evaluate the value in this key against the mapping table below it:
  • If the configured key isn't found or if the value for this key isn't present in the mappings, then the authentication process will turn to the default setting, as displayed below for UserLevel
    
    
• If a key is configured, and a match is found in the mapping table, then users will be assigned a UserLevel and Role-Set corresponding to the match
• If a key is configured, and multiple matches are found in the mapping table, then users will be assigned:
  • The highest UserLevel matched 
  • A set of permissions that corresponds to the union of all permissions listed in the Role-Sets that are mapped against these values

Let's look at the example below

1. Kentik Portal is expecting the key named kentik_userlevel from the IdP
2. if this key shows up with admin or guest values, the user's UserLevel attribute will be re-written on the fly to Administrator or Member
3. If no key is found, or if the user comes with a value that's different from the mapped ones (admin and guest), the default configuration will apply and the user will be denied access based on the configuration above.

Got it, now what are RBAC Role-Sets ?

Think of Role-Sets as operational sugar to manage user RBAC permissions more easily. In a nutshell, Role-Sets are collections of RBAC Roles. This new concept is introduced in the updated RBAC configuration screen.

The idea behind Role-Sets is that Admins usually want to be able to compose freely with RBAC Roles and Permissions – we realized it would make the Attribute Mapping very noisy if we were to ask our users to map multiple roles to a single Role key value, so we decided to offer an additional level of granularity by allowing users to group multiple RBAC roles in a Role-Set.

The new "Role-Sets" tab in this screen lets you configure these 

And the User Properties (in Company Settings > User Management) now let you assign both Roles and Role-Sets to users.

That's all folks!

As you can see, this feature packs quite a bit of punch and hopefully helps you more efficiently and cohesively manage Kentik Portal security according to moderns SSO standards !

Please let us know what you think – in parallel, we'll keep porting more and more portal areas over to RBAC out of the existing UserLevel model (another big announcement coming your way on that front, stay tuned).

Now, in the "Wait, there's more..." section, here are interesting stats around what SSO IdPs our customers are currently using – and this is the top5 ones we are testing these capabilities against.

We are thrilled to announce the general availability of Kentik Journeys, a flagship user experience of our Kentik AI family of features. You can enable this innovative tool directly through the Kentik AI configuration switch in your portal.

What is Kentik Journeys

Kentik Journeys offers a dedicated space for iterative network exploration and troubleshooting, leveraging a conversational interface powered by Kentik AI. Traditionally, network engineers have relied on network monitoring systems to browse and analyze data charts, refine queries, and repeat this process until they identify and resolve network issues. With Kentik Journeys, this process becomes more streamlined and efficient, thanks to the power of AI.

Checkout our Blog for What's New with Kentik AI to get more information about the nice features we added recently.

How to Enable Kentik AI

Kentik Journeys is part of Kentik AI feature set which can be enabled at the Organization level by users with Super Admin role in the Kentik Portal.

• For organizations which have already accessed Journeys in Preview, the Kentik AI switch is turned on by default — no changes required from your side.
• For organizations which have not enabled Journeys in Preview, the Kentik AI switch is turned off. 

Enabling Kentik AI

• Go to Journeys page on (US|EU) portal
• If Kentik AI is enabled in your organization you will be able to use it immediately
• If Kentik AI is not enabled yet:
  • If you are Member or Admin user, you will see the information to contact your Super Admin user for enabling Kentik AI
  • If you are Super Admin user, you will find the link to the Kentik AI settings page, where you can enable it. 
  • In rare case when your organization does not have Super Admin users, you will find the "Request Access" button to submit support request for enabling Kentik AI, after which our Product Support team will reach out to you with further details. 

Kentik AI settings page

• Kentik AI settings page is visible only to organization's Super Admin users (US|EU)
• The page is available through Organization settings icon on the top right side of the portal
• Simply toggle the Kentik AI switch to turn its features on and off
• See which Kentik AI features are available for your organization
• Read relevant Data Privacy and Security information related to the use of Kentik AI

We are excited to see how Kentik Journeys will transform your network exploration and troubleshooting. For any questions or assistance, please reach out to our support team.

Today, we're sharing the first step in a journey to seamlessly integrate Kentik NMS with our Flow platform. This is just the beginning of a series of iterations that will bring them together in a more cohesive and powerful way.

Read on as we show you a new and easy way to visually correlate NMS charts with Traffic data.

Metrics Explorer vs. Data Explorer

A novel take on an existing type of product, Kentik NMS' approach relies on taking advantage of what made our Flow Telemetry platform a hit: open exploration using Metrics Explorer, the little brother of our award-winning approach you know and love in Data Explorer. In other words, while Data Explorer is the business intelligence (BI) platform to your Network Traffic data, Metrics Explorer is the BI platform to your SNMP or Streaming Telemetry data.

When we launched Kentik NMS, our goal was to marry an NMS with world-class Traffic Analysis to provide our customers with the most cutting-edge and useful network observability platform available. To that end, we’ve learned a lot about how our initial users were using it and took some notes:

• Not everyone who's gained NMS Metrics Explorer expertise is comfortable with Data Explorer, especially given the latter is beyond feature-rich because of years of successive improvements
• A lot of troubleshooting workflows follow the same pattern: identify a peak or a trough on a chart, then inspect traffic to investigate what factors might be contributing to this pattern –  rinse, repeat... – very often an iterative process

Correlation, Causation, AI, and the Network Engineer

Recent days have marked the rise of ML/AI where every product (and Kentik is no exception) will show you machine learned insights about something you did not know about your network. 

Additionally, we get reminded more often than not that correlation does not equal causation, as absurdly illustrated in the meme below:

Yet, years of practitioner experience in this industry tell us that a vast majority of network troubleshooting activities always end up in trying to identify a bump or a trough on a chart by looking at other charts to identify a probable root cause.

In this process, the network engineer is always better equipped when they can leverage a UI/UX that makes it easy for them to quickly eyeball multiple charts on top of each other, with a perfectly aligned time range.

So, we took a few simple use cases and iterated to provide a UI that helps the network engineer correlate SNMP and Traffic charts together:

• "A port on a device is running hot, what could be the reason?"
• "What could be the reason behind the CPU of this router peaking?"

Often times, what we noticed was that the right tool was more about allowing users to quickly iterate through hypotheses, going from one finding to the next, quickly ruling out dead ends. With this as the target user methodology, we came up with the small but powerful capability described in the next section.

Introducing the Metrics Explorer bottom drawer

In Metrics Explorer, you may now notice a little kebab menu at the end of each row. If your query yields a Site, Device, or Interface, you will now be offered with a contextual menu which allows you to summon a traffic breakdown for that specific row:

Selecting any of these entries will summon the "Dimensions Selector", allowing the user to choose any set of up to 8 traffic dimensions to break traffic down for this Site, Device, or Interface – here's an example selecting Source IP and Destination IP for this device. As you can see:

• a bottom drawer opens up with a nested Data Explorer traffic query that's perfectly lined up with the Metrics Explorer one to facilitate visual correlation
• this drawer can either be minimized, discarded, or a new tab can be opened with this very query pre-populated by clicking "Open in Data Explorer"
• discarding the bottom drawer to replace with a new set of traffic query dimensions is also pretty straightforward, allowing for fast-paced troubleshooting iteration

Tell us what you think! What's next?

This feature tested pretty well with our field teams, but we're curious what you think of it! Let us know how we can make it better in future iterations.

We've already started thinking of other areas where we want to bring this traffic inspection bottom drawer:

• Add it to the Capacity Planning workflow so that users could directly look into the reason for why an interface is facing imminent congestion
• Bringing it into the NMS Device screen: it has an "Interfaces" tab, which would definitely benefit from the ability to inspect traffic breakdown for any interfaces here
• ... and then what about the reverse? What about being able to see the CPU traffic chart for a Traffic Breakdown that has the Device name in it?

Stay tuned for near future announcements around our plans to bridge our NMS and Flow Analytics worlds together!

We've improved readability and information density in the "Connections" widget on the "Device Details" page. The device and interface have been broken into two lines in the "Remote End" column, and we've included the "Boundary" and "Connectivity" types in a new "Classification" column, similar to how this information is shown in the Settings > Interfaces table.

Previous version:  

New version:

Note: Device names have been masked.

As one of the most-used components in Kentik Portal, we're always reluctant to change the Navigation menu and interrupt our users' habits. We're making an exception today, and bringing what we hope will be welcome changes to the Navigation menu. Read on.

Summary of Changes

As can be seen in (3) we've moved your recently viewed Dashboards and Saved Views to the bottom right side of the navigation menu, with the intent of some day removing it altogether – its functionality has been ported to the search bar, which allows you to directly access a longer list of recently viewed content (see this article).

Where these recents used to be located, you'll notice two unfolding menu entries now: "Top Talkers" and "Settings", as displayed in (1), we'll get to that.

Lastly, we noticed a significant portion of our users did not realize some navigation category headers in the central panel were clickable links to Status/Summary screens. To help make this more obvious, we've now used a standard link coloring on them, as can be seen in (2).

New Expandable Top Talkers Menu

Upon hovering on the "Top Talkers" item in (1), the central panel will update with a list of available Top Talker aggregate views. Up until now, these have been rather hidden in our UI, and the only way they could be accessed was:

1. by navigating to them in Network Explorer,
2. as a Favorite Page for the users who have already favorited them (meaning they appear right away in the Search results empty state), or
3. by clicking on a well hidden drop-down menu in the Network Explorer landing page as depicted below

With this release, we are now making them available directly from the Navigation menu. Hovering on the "Top Talkers" item in (1) will swap the navigation central panel to a list of these available Aggregate Pages – see screenshot below:

New Expandable Settings Menu

As we were designing the Top Talker's menu UX, we also looked at product usage analytics and confirmed that one of the most-used screens was the Settings screen. Knowing this screen is barely a list screen, we decided to save our users multiple clicks a day by using the same paradigm and populate the central navigation panel with all available Setting screens directly from the navigation menu – see screenshot below:

What do you think?

We hope these small changes will make your Kentik Portal experience even more efficient without disrupting your familiar navigation patterns. What do you think ?