Ever wonder exactly what measurements Kentik NMS collects for a specific device model before you actually add it? Planning a rollout and need to verify support for your entire network inventory? Thinking of adding a new device model to your environment and wondering if we already support it?

We're excited to announce the new NMS Device Support Explorer, a powerful tool that gives you unprecedented transparency into Kentik’s monitoring capabilities. Know precisely what data you’ll get from every device in your network.

With the NMS Device Support Explorer, you can now:

• Instantly Verify Support: Search our entire library by Vendor, Model, or even the SNMP sysOID to confirm full support for your hardware.
• See Every Measurement: Get a granular, model-specific list of every measurement we collect—from interface stats and CPU utilization to temperature, BGP peers, and more.
• Streamline Planning: Accelerate your onboarding and network expansions by planning with certainty, knowing exactly what types of data you'll have from day one.

This level of transparency into the NMS platform itself isn't just a feature; it's a reflection of our philosophy. The NMS Device Explorer is unique to Kentik and is only possible because of our state-of-the-art architecture and OpenConfig-inspired data modeling. We don't just show you your network's data—we give you unparalleled understanding of it.

[Explore device support in our Knowledge Base]

Don't see the measurements you need listed for your devices?

Submit an NMS New Metric Request from our portal.

In a previous announcement, we introduced Universal Agent as a foundational piece of software to further operationalize and unify our collection of telemetry agents under a single umbrella. With the benefits of this approach, we are hard at work porting all of our existing collection agents towards this new paradigm as Universal Agent Capabilities. 

Today, we will be talking about our OTT Service Tracking DNS tapping agent, and how as an existing OTT Service Tracking user you can migrate these DNS taps at no operational cost and start benefiting as early as today from their highly improved operability. Read on!

OTT Enrichments, how do they work?

Firstly, let's review how Kentik's OTT Service Tracking functionality works. Contrary to DPI (Deep Packet Inspection) which requires you to deploy DPI hardware at your network edge to map your subscribers' consumed applications, Kentik offers a creative, lightweight, and operationally and financially efficient method to perform the same task: users deploy a DNS Tapping Agent, in addition to exporting network flow telemetry from their devices, and our True Origin engine maps DNS query responses to traffic based on an ever-growing library of domain name patterns to directly color this flow telemetry with OTT describing attributes – OTT Service, OTT Category, OTT Provider.

Until today, the DNS tap collection was instrumented via our former host monitoring agent kprobe in a specific mode that did not export host telemetry, but only DNS query/responses. The drawbacks of this legacy approach are:

• kprobe is not observable in Kentik Portal, both from a DNS tapping activity metrics standpoint and an out-of-the box alerting standpoint
• kprobe upgrades are manual, requiring deployment for each new version
• combining host monitoring and DNS tapping in the same telemetry agent introduces a shared bug surface between two very different functions
• in cases where kprobe couldn't be installed on a DNS resolver, deploying it as a DNS tap required a complicated launch command

Taking a hard look at these constraints, we are now happy to offer a much more operable and easy-to-deploy solution via a new Universal Agent capability, so let's look at the benefits now!

So what's new ?

Trivial deployment of DNS taps, under the hood upgrades

As of today, all Universal Agents deployed offer a new capability aptly named DNS OTT Tap which replaces kprobe's legacy role of conveying DNS query/responses to our flow ingest clusters for OTT-related flow enrichments. Installing it will download the capability's core binary and enable it.

Once the capability is enabled, users will be able to configure the few parameters, and the Universal Agent host will keep the OTT DNS Tap capability in its latest version without any further operational attendance needed.

Easy promiscuous mode

You can now select a specific host interface to capture DNS queries and responses. In addition, if you’re using port mirroring, port spanning, or tunneling to send this traffic from the server-facing port to another host, you can enable Promiscuous Mode on that interface to capture it, as shown in the diagram below.

OTT DNS Tap metrics

Every Universal Agent capability comes with its own set of metrics. The OTT DNS Tap is no exception to this principle: clicking on the capability [Details] button will show two charts – one for the amount of DNS query/response funneled by the capability to Kentik's ingest clusters, and a second on the number of query/responses discarded, to monitor for any issue related to the capability's specific job.

As can be seen on both screenshots, both metrics are instantly available in Metrics Explorer for further reporting, so that administrators of the DNS Tap fleet can quickly troubleshoot. Here's an example of a single Metrics Explorer query showing the number of query/responses per seconds that an entire fleet of DNS Taps is performing:

At last, we've improved the [Configuration] screen of our Service Provider > OTT Service Tracking workflow to now include all deployed OTT DNS Taps with their agent status health. 

What does the migration path to the OTT DNS Tap Universal Agent Capability look like?

The process to switch from a standalone kprobe setup to Universal Agent's OTT DNS Tap capability couldn't be safer and simpler. It consists of the below steps:

1. On each DNS server where kprobe is currently running on, deploy Universal Agent. (Knowledge Base Article)
   The process is trivial: enter the command line on the server's shell and follow the instructions until Kentik Portal offers you to register the newly detected agent.
2. Once Universal Agent is installed successfully on the DNS server, install the OTT DNS Tap capability. (see Knowledge Base entry here)
3. Configure the OTT DNS Tap capability to your liking – default settings should cover most of the installs.
4. At this point both kprobe and the OTT DNS Tap will be sending the same data to Kentik's DNS ingest cluster, and it does not affect the OTT enrichment data at all.
5. Verify that the OTT DNS Tap capability is receiving DNS Query/Responses from the capability's drawer in the Universal Agent UI. (see screenshot in the OTT DNS Tap metrics paragraph in this post)
6. 🎓 Congratulations, you are done: you can now safely uninstall kprobe and proceed to the next DNS server.

The simplicity of the migration path relies in the fact that both kprobe and the new Universal Agent capability can coexist without causing any OTT Flow enrichment issues.
👌 So, go ahead and migrate your kprobe instances right away and benefit from the improved observability of our Universal Agent as soon as today!

Note: if any doubt whether the kprobe instance running on a DNS server is used as a Legacy DNS Tap or to generate host flow telemetry, the following command on the host will help disambiguate - if it yields any result, then there's a kprobe running on this instance needing to be replaced with a Universal Agent OTT DNS Tap capability:  ps auxw | grep kprobe | grep dns

What comes next ?

In one of our next releases, we'll be adding out-of-the-box alerting for both Universal Agents and capabilities, sending you notifications whenever your fleet of telemetry agents is encountering issues.

In addition, we have a really neat slate of improvements that we are also going to bring to life in the near future, amongst others: new agents such as Flow Proxy (fka kproxy) will be ported over under Universal Agents, as well as some large scale deployment options, and also an initial set of HA (High Availability) options – so watch this space!

We're thrilled to announce a significant upgrade to the Knowledge Base (KB), designed to help you find information about Kentik’s powerful Network Intelligence features more efficiently than ever before. While you'll still access the KB at https://kb.kentik.com, we've made substantial enhancements to deliver a truly new and improved experience.

What's New and Improved?

So. Many. Things.

Search

We wanted an easier path to Kentik product knowledge, so we added these search enhancements:

• Search the entire KB at once: Platform, Portal, and in the near future, API documentation
• Search with natural language questions

Streamlined Access to Information

Navigating the KB is now easier than ever:

• The redesigned “Explore Articles” sidebar simplifies your learning and troubleshooting journeys. 
• The “In This Article” table of contents now has an improved layout and automatically highlights where you are in the article.
• Next/Previous Article buttons, Feedback, and Related Articles at the bottom of every article
• Recently Modified, Recently Created, and Most Viewed article lists on the home page

A Modern, Intuitive Experience

It might have been overdue, but we think you’re gonna love these:

• Refreshed look and feel
• More variety of visual elements like callouts, accordions, tabs, and videos
• Ability to copy code blocks with a single click
• Choice of Dark/Light/Auto themes

We are committed to continuously improving your experience with Kentik, and this Knowledge Base evolution is a key part of that commitment. Dive in and explore the enhanced capabilities  at https://kb.kentik.com and let us know how it goes!

We're excited to announce a major enhancement to Kentik's Traffic Costs feature, giving you even deeper insights into where and how your network spend is occurring. Two months ago we released Traffic Costs, an industry-first automated workflow enabling customers to instantly calculate how much various slices of network traffic were contributing to connectivity costs. https://new.kentik.com/unveiling-hidden-network-costs-introducing-traffic-costs-1yRCxi

And now with this exciting enhancement, you can analyze traffic costs across multiple new, powerful dimensions. The original Source/Destination ASN, AS Group, and AS Path as well as the Customer Port traffic slices are still available, and now you can analyze network spend based on:

• CDN Provider: Understand costs by content delivery network to manage efficiency and performance, and negotiate better rates.
• OTT Service, Provider, and Category: Get granular visibility into costs by Over-the-Top (OTT) traffic, including specific services and content categories.
• Geographic Areas:  Break down costs by country, region, and city to identify cost drivers by location.
• IP/CIDR Blocks:  Attribute costs directly to specific IP addresses or CIDR ranges for precise accounting and planning.

You’ll see all the new dimensions listed under Create a New Estimate on the Traffic Costs page.

For example, in this screenshot we can easily calculate and see how much it’s costing my network to receive traffic from Netflix every month and deliver to my subscribers. 

And in this example, we’re looking at how much it’s costing my network to send traffic to Akamai each month. 

These new traffic slices provide the actionable intelligence you need to optimize network spend across the business, improve traffic engineering, and strengthen cost accountability.  Log in to the Kentik portal to explore the new capabilities today!

Coming Wednesday (July 16, 2025):

We are excited to announce powerful new enhancements to our NMS product, bringing more security and flexibility to your SNMP data collection. You now have access to stronger encryption for SNMPv3, better polling setting defaults and advanced controls to fine-tune polling behavior for every device in your network.

Enhanced SNMPv3 Security

Security is paramount, which is why we’ve added support for the following, more secure SNMPv3 protocols:

• Authentication Protocols: SHA-512 & SHA-128
• Privacy (Encryption) Protocol: AES-256

SHA (Secure Hash Algorithm) and AES (Advanced Encryption Standard) are both cryptographic algorithms, but they serve different purposes. SHA is a hashing algorithm used for creating a unique fingerprint of data, while AES is an encryption algorithm used to scramble data so it can only be read with a key.

This allows you to secure your network management traffic with the latest standards.

Important: Please note that these new security protocols are available for NMS data collection performed by the Universal Agent (UA). They do not apply to KProxy-based flow enrichment.

A Look Ahead: Our Unified Agent Strategy

The Universal Agent (UA) is the future of data collection at Kentik. Our long-term plan is to consolidate all SNMP and Streaming Telemetry collection into the Universal Agent, which will handle both NMS metric collection and flow enrichment. Features such as our topology maps, capacity planning, cost analysis, and traffic engineering are currently powered by our KProxy agent only, but will be served by Universal Agent’s NMS capability in the future. By focusing our development on the UA, we can deliver enhancements like these new security protocols more quickly and efficiently. It will also importantly resolve issues with double-polling currently caused by separate agents for flow enrichment and NMS collection. 

Granular Control Over Polling

Now available when configuring NMS Monitoring Templates, Polling Options gives you gives you the flexibility to fine-tune polling behavior, balancing performance and speed of telemetry to your specific needs:

• Max OIDs per Request: Adjust the number of OIDs (Object Identifiers) the agent requests at one time. This applies to SNMP v2c and v3 only.
• Request Retries: Set how many times the agent will retry a failed request.
• Timeout: Define how long the agent will wait for a response before timing out.
• Parallel Requests: Control the number of simultaneous polling requests (workers) for a single device.

Sensible New Defaults

Based on extensive real-world testing, we’ve also updated the default polling configuration for both existing and newly added devices. Our new approach favors pulling more data in a single request while reducing the number of parallel requests. This has proven to be a more efficient method for the vast majority of network hardware.

Why We Made This Change

Every network is unique, and some devices can be more sensitive to polling than others. While our default settings are designed to work brilliantly for most hardware, these new controls give you the power to ease the polling impact on devices with limited resources or unique configurations. It’s all about providing a powerful, flexible monitoring solution that adapts to your environment.

We're Here to Help!

Not sure what settings are right for your devices? Our Product Support team is ready to assist you in optimizing your new polling configurations. Please don't hesitate to reach out for guidance.

Laying the foundation for class-specific Device Details

Kentik NMS is getting smarter about how we meet the observability needs of the kinds of devices you're monitoring.

Until now, all Device Details pages looked the same—whether you were viewing a router, switch, firewall, or even a server or UPS. This one-size-fits-all approach helped us get the feature out the door, but we know it’s not how network operators think or work.

Why this matters

When troubleshooting or planning, operators expect different insights from different devices:

• Routers: You care about routing tables, interface health, BGP sessions.
• Switches: You want to see port status, VLAN memberships, trunk links.
• Firewalls: You’re hunting for ACLs, session counts, and threat logs.

That’s why we’re introducing device “classes”—clear, functional groupings like Router, Switch, Firewall, Server, and more. These classifications will allow Kentik NMS to tailor what data we highlight on each Device Details page, surfacing the most relevant insights first.

What’s new today

This release introduces:

✅ New class icons for fast visual identification
✅ Device classifications across all NMS and Flow-enriched devices
✅ Vendor logos added to the Vendor column in the Devices table

These changes enhance both the navigation experience and the visual consistency across the product.

Class icons uniquely represent the 12 devices classes we found more prevalently on our platform: Router, Switch, Firewall, Load Balancer, SD-WAN Gateway, Wireless Controller, Access Point, Server, UPS, PDU, Optical Transport, and Storage Array. In the future, we'll be adding the ability for admins to change the assigned device class, and create their own custom classes!

Classifications have been added most conspicuously to the Devices and Device Details pages, making identifying a device's base functionality much easier. Classification happens automatically based on the SysObjectID-derived make and model, and some AI magic. Previously, a device's icon was driven by a mixture of the Flow device type or device vendor. As not to lose the value, the vendor icon has been added to the vendor column.

🔜 Coming soon: Rich, class-specific views that show the right metrics, tables, and visualizations based on what kind of device you're looking at.

Why it’s better

• Less clutter: Device icons are now consistently based on a single characteristic - function class.
• ‍Instant recognition: Icons + vendor logos = less scanning, faster decisions.
• More context: Classes unlock tailored data views for each device type.

This is just the first step in a bigger journey to make Kentik NMS a truly intelligent network observability platform. Let us know what you think—and what you want to see next!

In this post, we'll be covering a feature that was delivered a while back but had the gem of a long-term project hidden in it – and now is the time to talk about it. I'm talking about our (now not so) recently released Kentik NMS product – let's get back to this in a short moment.

Over the years, Kentik has built a number of Agent binaries – each one to carry out a specific function as a Telemetry Agent for its own type of telemetry.

• kproxy lets you proxy flows from inside of your network to our public flow ingest cluster
• kprobe is used as a DNS tap to provide the magic mapping between DNS and Flow records to unlock OTT observability
• kbgp is a local BGP hub, which prolongs your BGP sessions towards our BGP ingest enrichment cluster
• ksynth is the Synthetic Monitoring agent you run (privately) or we run (publicly), which performs Synthetic Tests

You'll notice the one missing here is our SNMP poller: you now see it as what we call a "Capability" of the Universal Agent we released when we unveiled Kentik NMS.

In a nutshell, you install Universal Agent, enable the NMS capability on it and you're off to the races. Hang in there, this is what this post is all about!

Operability challenges of Telemetry Agents

Managing large fleets of telemetry agents always comes with operational complexities – let's lay out a few observations we've made over the years in that field. In everything that follows, "operability" is a key term.

Observable agents

As your Telemetry comes to rely on these agents, they quickly become a critical part of your infrastructure, and therefore now require to be observable – some examples here:

• If a Flow Proxy (currently named kproxy) becomes faulty, users need to be alerted. If they don't, they will assume the trough in their traffic charts is due to a network outage and waste valuable time troubleshooting the situation.
• The team in charge of running your telemetry systems is often a different team than the one building and running the network – while they may not be daily Kentik users, they need to monitor them in a scalable way and reduce the amount of integration work needed to operationalize them. 
• Agents running on a host (virtual or physical) can go wrong for multiple reasons: maybe the host itself is not doing well (i.e. it's not the Agent's fault), maybe the function the Agent performs is not doing well, but the host is doing just fine. In other words, users want self-serviceability when it comes to determining why agents are not doing their job.

Frictionless upgrade path

When running large infrastructure, the last thing engineers want to do is have to upgrade a large fleet of Agents: "if it ain't broke, don't fix it" is usually the governing principle. Operational realities require the upgrade path to be the most frictionless possible:

• Bug fixes can require upgrading a large fleet of agents – the task of upgrading a large fleet of agents therefore needs to be as frictionless as possible to maintain constant state of operation.
• Availability of new features requiring Telemetry Agent upgrades tend to be delayed in favor of the aforementioned conservative approach.
• Security updates to large Telemetry Agent fleets can get delayed because of upgrades deployment complexity – these are always critical, should always be seamless enough to not incur delays.

Agent proliferation vs. One-size fits all

With the rise of observability, agent proliferation in your infrastructure has been skyrocketing. Each new agent comes with its own upgrade track, bugs, security context... in other words, the operational complexity of one's telemetry setup increases exponentially with the number of agents required to operate one's infrastructure. All telemetry agents share common goals, requirements, and functions: they need to be deployed, monitored, and updated.

The first way that comes to mind to deliver these common functions is to collapse all agents into a single swiss army knife agent: the operational ease of this solution is appealing, but comes with a few significant drawbacks:

• All functions carried by the agent require eventual updates, and having many functions served by a single agent usually results in increasing the frequency at which these need to be updated – depending on the number of functions collapsed together, this often results in a significant increase of update pace, therefore operational tax.
• Each function performed by the agent comes with its own bugs and security weaknesses – collapsing multiple agents in one often result in increasing the bug and security risk per agent.

For the reasons above, the ideal setup is one where we can reap the benefits of both a single agent, while keeping multiple ones at the same time. Let's discuss our new approach to agentry in the next section!

Introducing Universal Agent

What is Universal Agent ?

"One Ring Agent to rule them all, One Ring Agent to find them, One Ring Agent to bring them all, and in the darkness Kentik Platform bind them"

With the aforementioned challenges in mind, our engineering team produced a modular design centered around a new deployable binary, named Universal Agent.

Universal Agent acts as a host governor module (literary pun intended), tasked with offering a common foundation to "capabilities" running under it: it acts as the sole controller towards our SaaS platform, handles the download and enablement of other agents (now named "capabilities"), handles under-the-hood update cadences for both itself and its governed capabilities, and collects/ships not only host-level metrics, but also specific metrics for each capabilities to the Kentik SaaS platform.

What benefits does Universal Agent offer ?

Operational peace of mind
Universal Agent is now the central piece of Kentik's Telemetry Agent strategy. Its setup process is trivial and its enrollment entirely driven by the Kentik Portal UI our users all know and love.

Furthermore, Universal Agent updates are transparently and gracefully managed "under the hood", and the same goes for any Capability run by the agent – little if no operator intervention is now needed to keep an Agent and its Capabilities up to date.

Central management & monitoring
The Settings > Universal Agents now becomes the central place where you will in turn manage your complete Kentik telemetry agent ecosystem. This interface lets you identify any agent or capability deployed on your network and its current running state.

Agent Observability
Each deployed Universal Agent reports host-level metrics, accessible directly from the Settings > Universal Agent screen

As a bonus, all agent host-level metrics are also available in Metrics Explorer under the /kentik/agent measurement tree without any extra work needed. Universal Agents have now become observable, with their vitals now available for dashboarding like any other NMS device.

One single binary to access all of our telemetry collection capabilities
Once it is deployed, Universal Agent gives instant access to all the telemetry functions we've ported over as "capabilities". These get installed and enabled upon simple click. While NMS was the initial capability we shipped Universal Agent with, our entire ecosystem of telemetry agents will follow over time and be integrated as a Capability.

Observability for each Agent Capability
Each enabled Capability comes with its own set of metrics, designed to describe its function. These metrics also get shipped for free to our NMS subsystem and displayed at Agent > Capability level in the Universal Agent Management UI. Again, as these metrics are being stored in our Metrics subsystem, they can be accessed via Metrics Explorer, but also alerted upon.

What's next ?

With this foundation built, we have already started producing new Capabilities leveraging this new model:

• Our newly released Syslog Server is one of these new capabilities
• As part of the same release, we also released a Trap Receiver capability

We've already started porting over our existing Agents to this new "Capability" model – watch this space for more announcements in that field real soon!

Lastly, we will be leveraging our brand new NMS Alerting platform in the very near future to provide automated alerts on Agents and Capabilities Health.

Good news! We’re extending our existing VRF (Virtual Routing and Forwarding instances) support to include Nokia routers – so if you're using Nokia’s SAP/SDP interfaces, you’ll now get deeper visibility into your VRF traffic, just like you already do with other vendor gear in the Kentik portal. 

A couple of months ago, we announced expanded support for Nokia SAP/SDP – and this latest update builds on that momentum, further extending Kentik’s visibility and insights for Nokia-based networks.

A critical technology of modern networks, VRFs allow multiple, independent routing domains to co-exist within a single router or switch, each with its own set of interfaces, routing protocols, and forwarding policies. This segmentation enhances network security and performance  – especially in multi-tenant and -customer environments – helping isolate traffic, avoid conflicts, and support more efficient routing.

Nokia uses vendor-specific MIBs with their TiMOS OS, which has historically made full visibility a bit tricky. With this update, Kentik now pulls in enhanced flow data for Nokia VRFs, including support for BGP, IPv6, and Ultimate Exit path tracking. That means you can now see where your traffic is actually egressing – even across complex Nokia VRF deployments. 

If you're already using VRFs on Nokia, there's nothing extra to configure – just start using the standard VRF dimensions in Kentik and you’re good to go.

As always, reach out if you have questions or want help digging into your VRF data!

We are excited to release a new Kentik AI feature called “Cause Analysis," part of our core Traffic Analysis portfolio. Designed to help network engineers more quickly understand the underlying network traffic contributing to network anomalies, this new interactive feature in Data Explorer uses data mining, AI, and Kentik's industry-leading context enrichment to instantly identify the most relevant and contributing factors (dimensions) of network traffic within a given time frame. It reduces the amount of time it takes to investigate sudden traffic changes, like spikes, increases and drops in relatively short time frames.

Our goal is to make it easier and faster for our users to quickly understand the most important characteristics of the traffic contributing to a change, like application, IP addresses or prefixes, ASNs or public cloud services. This analysis is done automatically upon user request without needing to select any flow dimensions in the Kentik Data Explorer and without expert level knowledge in traffic analysis. The results can easily guide a user to understand the cause of traffic changes and anomalies and to take appropriate further actions.

This feature is available for companies that have enabled Kentik AI.

Cause Analysis in Data Explorer

Cause Analysis in Data Explorer supports three user workflows:

Traffic analysis - to find the most contributing traffic dimensions in a single time selection window

In this workflow, a user is able to select a single time window on the graph and to invoke Cause Analysis. Currently the time window is limited to 2 hours.

The results of the analysis will be shown below the chart in an additional tab named “Cause Analysis” which will emphasize the most contributing factors on the traffic during the selected time window. A Kentik AI summary of the results is provided at the top of the panel. The lower part of the panel shows numerical results presented in a hierarchical table, which are produced by Kentik’s data mining algorithms.

The values of traffic rate and the percentages in this table are estimates and not the completely exact values. The intention of this feature is to efficiently emphasize the most contributing dimensions to help answer the question "what happened?".

The analysis considers selected traffic metric, e.g. Bits/sec, Packets/sec or Flows/sec.

Traffic comparison analysis - to find changes in traffic patterns between two selected time windows

In this workflow, a user is able to select two time windows on the graph and to invoke Cause Analysis, which will then show the most contributing factors to the traffic increase. This helps users quickly answer the question "what changed?" The system will first compare the two selected windows based on average traffic volume. Based on the results, it will further compare the window with lower average traffic to the window with higher average traffic, emphasizing which type of traffic significantly contributed to the increase. With this approach, it is irrelevant which time window will be selected first.

The results of the analysis will be shown below the chart in the tab called “Cause Analysis”. Kentik AI’s summary of the results is provided at the top of the panel. The lower part of the panel shows numerical results presented in a hierarchical table, which are produced by Kentik’s data mining algorithms.

Automatic detection and analysis of traffic changes

In this workflow, the system will automatically analyze time series results in Data Explorer and look for significant changes in the traffic that might be interesting to the customer. Those significant changes can be spikes, drops or sudden increases and decreases in traffic. On these changes, Kentik AI will perform analysis of the traffic difference before and after the change, trying to pinpoint which traffic contributed to the increase or decrease.

The workflow starts when a user clicks the button “Analyze” at the top of the time series chart or at the bottom of the query panel.

• The system will try to detect the most significant 5 changes (configurable)
• These changes will be marked in the chart
• The “Cause Analysis” panel below the chart will list the changes with the relevant details: type of the change, average traffic metric of the change and time of the change point.
• An AI summary of the change will be provided in the summary section
• Each change can be further visually expanded to show numerical results presented in the hierarchical table, which are results of Kentik’s data mining algorithms.

Cause Analysis in Kentik Insights

With this first release, Cause Analysis is also being integrated into the Device Traffic Increase Insight. The Insight is enriched with valuable information of the most contributing factors to the device traffic increase.

The system will automatically determine when the traffic increase started and perform analysis of traffic differences between traffic before increase and during detected increase. The results are presented below the time-series chart with a Kentik AI summary of the results and the relevant details. This information can help users determine what is a likely cause of such traffic increase on the particular device.

As always, we welcome your feedback as you start to use this new feature. Please reach out with any questions, concerns or feedback.

In many areas of the Kentik Portal, users can bundle-select multiple objects to apply common configuration to them. This is a common requirement as soon as your infrastructure reaches a size where you want to manage Cattle over Pets. 

A lot of functionality in Kentik Portal can be performed in batches:

• Bulk actions on Devices (labeling, plan assignment, archive/deletion, Site assignment, NMS Monitoring Template assignment...)
• Bulk actions on Interfaces (Assign Connectivity Type, Network Boundary, Provider/Customer, IX the interface is assigned to...)
• Bulk actions on Sites (Assigning Site Market, Site Type, corresponding PeeringDB Facility...)
• Bulk actions on Synthetic Agents and Synthetic tests (Labeling...)
• and many more areas in Kentik Portal

As we continue to strive to improve the ease of use and operability of our product for users with large herds of infrastructure, we've rolled out a completely new Bulk Edit UX in a limited scope of Kentik Portal to test the better UX with our users. Read on.

A pilot for the Device Screens

As of today, this new Bulk Edit UX is visible in two areas of the product:

• the Device Management screen /v4/infrastructure/devices
• the Device Details > Interfaces tab /v4/infrastructure/devices//interfaces

This new UX wiill appear at the bottom of the devices list as soon as you select two or more devices, for example:

...and will let you modify a certain number of the attributes for this device – more actions will be added to this bulk edit menu as we start hearing feedback from our users.

• Note how the left side of this also allows you to de-select these devices you've selected
• Whenever possible, the individual attribute change will display a search field to immediately find what to set the attribute to
• In the case of labels, where multiple selected devices may not have the same labels, a blue check will be displayed when all selected devices have this label on, whereas a [-] sign will show when only some of the devices have this label on, see below:
  

here all the selected devices have the "Arista" label

Whereas here only some selected devices have the Arista label on

This UX will also display in the Device Details page, as soon as more than one interface is selected:

What comes next

Depending on your feedback with this new UI, we will improve it as we go, but more importantly extend it to all other screens that currently contain bulk edit options in the legacy way we've done it. 

One of the key benefits of leveraging web components in our front-end stack is the ability to drastically reduce the time needed to port this new design over to other parts of the product!