Feature Overview

Adding event ingestion for real-time alerts and deeper network understanding

We’re excited to announce that Kentik NMS now supports SNMP Traps and syslog ingestion, giving network teams even greater flexibility and insight when managing modern infrastructure.

With this release, Kentik NMS adds support for two of the most widely used protocols for real-time network event communication. Whether it’s a hardware failure, interface status change, or critical software log message, you can now capture, query, and alert on these events natively within Kentik.

🛰️ SNMP Trap Support

SNMP Traps are a cornerstone of traditional network monitoring, allowing SNMP-enabled devices to push events without waiting for polling intervals. With Kentik’s SNMP Trap integration, you can:

• Receive SNMP Traps in real-time
• Filter and search trap events by name and OID
• Receive policy-based alerts and notifications
• Visualize trap events alongside other telemetry for faster root cause analysis

📜 Syslog Ingestion

Syslog messages are vital for capturing detailed system-level events across a wide range of devices. Kentik NMS now ingests and parses syslog data, enabling you to:

• Collect syslog events from routers, switches, firewalls, and servers
• Filter and search syslog events by name, severity, and message content
• Create alerts and notification policies based on syslog messages
• Visualize syslog events alongside other telemetry for faster root cause analysis

Why This Matters

These new ingestion capabilities allow network operators to centralize and correlate even more telemetry within a single observability platform. Whether you're troubleshooting outages, proactively monitoring infrastructure health, or securing your environment, Kentik NMS now has the signal coverage you need.

Key Workflows

Data Explorer

Query/browse traps and syslog events in Data Explorer:

Alerting

You can also bring your query context forward from Data Explorer into NMS's alert policy workflow to alert and send notifications when specific event conditions are met.

For example, let's say we're really interested when an SNMP traps of type "ciscoConfigManEvent" shows up. From the "Add NMS Alert Policy" workflow, we start by selecting a "Policy Type" of "Event" and then an "Event Type" of "SNMP Trap".

 
We then create an alert condition that will trigger a Major alert when a trap arrives of type "ciscoConfigManEvent", and configure a notification to email the interested parties when it occurs.

It's that easy.

Operability

We've also included some admin views to assist in troubleshooting and setup of the SNMP Trap and Syslog Server capabilities on the Universal Agent.

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.

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.

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.

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.

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.

We're thrilled to share the enhancements we've added to Kentik NMS over the past six months. Your feedback and continued support have been instrumental in driving our newest product forward. Here's a summary of the key updates:

New Device Workflows

• Topology Connections: We now show “Connections” on the “Device Overview” screen and “Interface Details” drawer. LLDP connections are automatically detected. Manual connections can be added where LLDP is not in use and are marked with an “M”:

• Device Dependencies: NMS can now detect when one device is downstream from another. When the upstream device goes down and the downstream device does not respond, the upstream device is marked as down while the downstream device(s) are marked as unobservable. This makes it easy to differentiate which device is down and needs your attention vs which devices simply is not responding due to the down device. The first place you will see this is in the status of a device:

Additionally, alerts configured to trigger when a device goes into status down will not trigger for these devices, of course. This is the default and will greatly improve the signal-to-noise ratio when alerting on downed devices. If for some reason you do want to alert for these devices, you can configure the alert to trigger for devices in status down or status unobservable. 

To enable this functionality, you must specify the “Closest Network Device” for the NMS agent by navigating to Settings > Universal Agents (NMS), selecting an agent in the table, and clicking edit:

• Unobservable due to agent down: In the event that an NMS agent goes down, all devices being monitored by that agent will be marked as Unobservable. Mousing over the status label will display a notice indicating that the device is down because the agent is down, and will indicate the name of the down agent.
• ICMP-only devices: Sometimes you don’t have SNMP access to a device but still want to monitor it. NMS now supports this use case with "ICMP only" devices. Add these devices by going to "Menu > NMS > Devices" and clicking "Add Devices" in the top right. At the prompt, select "PING ONLY". Doing so provides up/down status and latency:
  
  
  
  
  
• API for Device CRUD and Query: To better serve the largest and most complex networks in the world, you can now use the Kentik API to create, read, update, and delete (CRUD) NMS devices. You can also now run Metrics Explorer type queries via API. To make it easier, Metrics Explorer can show you the API query for any query you’ve done in the UI.

New Alerting Workflows

• Acknowledge Active Alerts: Alerts can now be acknowledged even while they are active. This is a common practice to indicate to the rest of the team that someone is aware of the issue and is taking action. The name of the acknowledger will be noted an a comment can optionally be added. Users can also choose to automatically acknowledge additional occurrences of the same alert ("auto-ack"), for situations like a flapping link.

• Silence Notifications: Notifications can be "silenced" and "unsilenced" from the Alerting page with the push of the button. Alerts will still trigger and can be seen in the UI, but notification channels will not be executed. By selectively silencing notifications for alerts, network admins can better manage focus and reduce noise to their team.
  
  
  
  
• Suppress Alerts: You can now prevent an alert policy from triggering all together by using suppress alerts from the Alerting page. 

Supressed alert policies will not trigger, and so alerts will not show up on the alert list and, of course, notifications will not be executed. You can see all configured Alert Suppressions on the Alert Suppressions page in Settings. From this page, users can view, create, edit, and delete Alert Suppression Patterns.

• State Alerts: State alerts were previously limited to out-of-the-box supported entities - Devices, Interfaces, and BGP neighbors only. You can now configure state alerts for any metric, including custom metrics. Another way to think about this is that threshold alerts alert when a metric is less than or greater than a value (or baseline) whereas state alerts alert when a value is equal to a certain value, for example the number 3 which corresponds to an interface being down.

Quality Enhancements

• Status Bugs: In very specific scenarios, devices were incorrectly marked as down. While most customers were not affected by this bug, those that were had instances where many devices were reported down but were not really down.
• SNMP Polling Efficiency: Several bug fixes involving SNMP timeouts, conflicting statuses and agent stability.
• Query Performance: In an effort to reduce the amount of time it takes to load some of the more complex NMS pages, we've made query optimizations to backend improve performance. While there's still room for improvement, we think you'll already notice the difference.
• Other Bugs: We addressed numerous issues relating to usability, reliability and predictability - especially where alerting is concerned.

In addition to the software changes above, you will find a great deal more information about NMS available in the knowledge base. These articles will help you get the most out of Kentik NMS.

We are committed to continuously improving to meet your needs and exceed your expectations. We encourage you to explore these enhancements and send us your feedback!

Thank you for being a part of the Kentik community. Stay tuned for more exciting updates soon.

We are thrilled to announce our latest innovation in network observability: Kentik NMS. Designed to revolutionize how large networks are monitored, Kentik NMS combines the best of traditional NMS with the extensibility of a metric observability platform.

All customers have access to Kentik NMS now*.

Key Features:

1. Ingest Any Metric: Collect SNMP, Streaming Telemetry, and any source that can send Influx Line Protocol (including Telegraph and GNMIc), with more collection protocols coming in the future.
2. Device Monitoring: Identify devices, monitor availability, and track KPIs like CPU, memory, interface stats, and hardware components.
3. Metrics Explorer: Explore the entire OpenConfig inspired data model, formulate precise questions, pivot grouping, and control aggregation.
4. Query Assistant✨: Use natural language to Ask Any Question with the power of AI and Large Language Models. The fastest and most intuitive way to start analyzing.
5. Correlate: Compare NMS data alongside Flow, Synthetics, and other capabilities in the Kentik Platform.
6. Routing Protocol Monitoring: Monitor routing protocols like BGP and ISIS to ensure neighborships are healthy and understand how the number of prefixes sent and received has changed over time.
7. Dashboards: Build custom dashboards so you can understand the health and performance of a specific site, region, an app, or your whole network at a glance, using data from NMS, Flow, Synthetics, and the rest of the capabilities of the Kentik Platform.
8. Alerts: Configure simple state alerts or define advanced threshold alerts using the power of Metrics Explorer and baselines.
9. Extensibility: Have a special use case? With Collection Profiles you can configure collection of brand new data points from any supported collection protocol, do basic adjustments with built in transformers, or advanced adjustments using Starlark, a Python based scripting language. Display the results on dashboards and generate alerts as required.
10. Kentik Agent: Deploy one or many high-throughput agents to collect data. Agent updates are automated and seamless, just like updates to the Portal.
11. Real time monitoring: Collect data as fast as once a second, and stream it in real time to the browser. New data points go from the device being monitored to your browser in seconds.

*Customers with a Kentik Platform Essentials license get 100 Metrics Per Second (MPS), enough to monitor 3 to 10 network devices. Customers with Pro or Premier get 250 MPS, enough to monitor 8 to 25 network devices. 

This capacity lets all Kentik customers start using Kentik NMS today at no additional cost. For additional capacity, contact your Kentik account team.

A big thank you goes out to the customers who piloted Kentik NMS for the last 6 months and the 20 customers in Private Release, testing Kentik NMS for the last 3 months. These customers have provided invaluable feedback and tested NMS in production networks to get it ready for you!

Get started by navigating to Network Monitoring System in the main nav. Once you have a linux VM or Docker environment to host your collector, it takes about 5 minutes to deploy the collector, start a discovery, and begin seeing the first of your devices in Kentik NMS.

To learn more about Kentik NMS, check out our website. To dig into the technical details and learn more about using Kentik NMS, check out the Knowledge Base. If you have questions, would like to see a demo, or would like hands on help to deploy Kentik NMS in your environment, contact your Kentik account team.

TL;DR, show me the screenshots!