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

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.

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.

Today, we're excited to announce an exciting update to Kentik's Alerting threshold condition capabilities. We've improved our threshold conditions to make them easier to configure and more powerful than ever. For those unfamiliar, kentik's threshold conditions allow users to set thresholds including baselines, to alert them when key performance metrics exceed or fall below-specified values. We have made it easier to configure these thresholds when using baselines, by providing a simple "Above or Below" drop-down, versus in the past, to configure a policy to trigger at 20% below the baseline, we had to set the rule to 125% above the baseline, as this is what the API was expecting. This was confusing and hard to understand for the user.

You know can simply select a % above or below the baseline. This should provide a much easier-to-understand experience for users creating alert policies with baselines.

Kentik has released a new Alerts reporting feature that lets you choose the type of Alerts (including DDoS) that you are interested in, along with the retention period (up to 90 days) and then either export this data or choose to schedule and subscribe to this report. 

This is version 1 of reporting for Alerts. This feature was suggested by our customers and provides initial reporting functionality around alerts. We plan to enhance this in future releases with more types of data, visualizations and analytics.

Example: I want to create a report of all my DDoS alerts (attacks) grouped by policies for the last 30 days.

Start by using the filter to apply the alert types, the retention period, summarization, grouping, etc. This is the main configuration of the report. Whatever you see here in the view is how the report will be created and viewed.

Then under the "Actions" drop-down in the upper right corner of the portal UI, you can choose to export this data directly or choose to set up a subscription to create a new report, say Monthly, and deliver it by email.

Fill out all of the desired subscription information and click "Subscribe"

We are happy to announce a new Health Map by Site Alerts Widget that can be configured and viewed from within the Kentik Observation Deck Dashboard. This is the first of many new widgets planned to be developed to give the Enterprise a tailored view of your networks and Infrastructure  

This new widget supports customers needing a type of NOC (Network Operations Center) view and status (Health) of their current locations based on Kentik Alerts. The User can then react quickly and take action on their most critical alerts.

Clicking on a site either in the map or the table will drill down into that specific location and display all the current alerts based on the filter settings. 

To see a brief setup video click on the link below and follow the guide in the video.

Customers can now apply a single notification channel to one or more alert policies.

From the Alert Policies page, select the policies that you would like to use, and click on the "Add Notifications" button:

Then select your existing or create a new notification channel and select "Continue"

The selected policies will now use the selected Notification Channel 

You can now schedule Silent Mode for alerts with a start and stop time for a policy or a pattern creation. This new feature will allow customers to silence alerts during maintenance windows automatically, for example.

Users can now:

• Export their Alert data in .csv format
• Configure whether to put all available columns in their export or only those that they have configured to show in the admin table (integration is seamless)
• Configure whether to export only the amount of data that they have currently loaded in the ui OR to export a fixed number of rows (up to the first 2000 rows)

Screenshots