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!

In many areas of Kentik Portal, users now have to input credentials that our systems will use for a variety of purposes: 

• HTTP Synthetic tests
  • HTTP(s)/API tests
  • PageLoad tests
  • Transaction tests
• Kentik-registered devices
  • SNMP polling community strings
  • Streaming Telemetry Credentials
  • BGP MD5

We are introducing Credentials Vault as an elegant way to manage these more centrally and securely.

Where are credentials the most used in Kentik Portal ?

Credentials HTTP Synthetic Tests

Imagine your company runs multiple tens or hundreds of Synthetic tests. Now also imagine that one of the credentials used in these tests needs rotating, which happens quite frequently. This would normally require a user to go and edit all of these tests one by one to update the credentials. This manual update process poses multiple problems:

• The obvious time sink involved to reconfigure every test
• If one of these credentials becomes compromised, users are unable to quickly swap out credentials in an efficient and quick manner, making it difficult for our users to harden their security posture and rotate credentials frequently.  

We aimed at fixing this by releasing our Credentials Vault.

Kentik-registered Devices

To enrich the Network Telemetry from your Kentik-registered devices, you provide us with SNMP polling credentials (whether v1, v2c or v3) to pull such attributes as interface descriptions and names at frequent intervals. Our users routinely have multiple hundreds of devices, and this poses the following issues:

• Copy/Pasting credentials across devices definitely increases chances of a typo
• These credentials are defined with each device registered with Kentik -> it makes changing them on large sets of devices time consuming and tedious
• Again, local definition of credentials increases the friction preventing companies from being able to efficiently and frequently rotate credentials

This is another reason we built Credentials Vault.

What is the Credentials Vault 

The Credentials Vault can be accessed in the company menu, as shown in the screenshot below:

It is a central facility allowing Kentik users to securely store their credentials.

1. Securely: 
   • All credentials are double encrypted at rest with a unique key for all Kentik tenants and a global key that only our backend systems know
   • Credentials are write-only: you can modify an existing credential, but you cannot view it
   • Management Capabilities are governed by our newly release RBAC engine
2. Centrally: 
   • Credentials defined in the Vault can be used in different parts of the portal – the initial release focuses on Synthetic tests, but we will extend it in the future quarters.
   • Modify a credential in use, and any portal component leveraging it (Synthetic Tests, and even more in the near future) leveraging this credential will immediately use the updated one. 
   • Delete a credential and all tests immediately stop functioning
3. Flexibly: Each credential is either
   • 1) a templated credential with fixed fields (this feature will be leveraged in a future release)
   • 2) a free form Key/Value store: this means you can store multiple useful fields within a single credential – a good example is for an HTTPS API Credential where you will store
     • the name of the HTTP header to put your token in
     • the username part of the header value
     • the token part of the header value

Using a Credentials Vault secret in Synthetic HTTP(s) Tests

With your credentials ready, you can now summon them in any Synthetic HTTP test, and selectively configure each field of your test with a field of your choice from this credential, as shown below:

Clicking on the Credentials Vault button will summon a credentials manager where you will be able to pick from and copy/paste into whichever field you want, see below:

As you can notice, the fields of the test where the credential key/values are summoned do not contain the actual value, but a programmatic expression of them, such as $vault("kentik_api_token.token_value"). The value for a key in a credential follows this nomenclature: $vault("<credential_unique_name>.<credential_key>") and assigns the value for credential_key to the test configuration field.

Note:
In order to make this possible, you will notice that Credential Names and Key Names within a credential follow strict rules. This is simply because these can also be summoned in a transaction test, which is the reason why we wanted them to have a javascript friendly format.

What's next ?

We are already working on the next areas of Kentik Portal where Credentials Vault is going to be made available.
One of them is a secret project we are currently working on (be patient, it's coming very soon!), and the other obvious one is Kentik-registered devices, which we are hoping to release within the first quarter of this year.

Next on the list, we are evaluating requests to add Synchronization with Secret Vaults as a Service providers such as AWS or Hashi Corp's Vault – more to come on that in the future.

Lastly, we will eventually turn to Kentik Integrations such as Notification Channels, so that credentials from the Vault can be used in their configurations.

Kentik Library is the central place in the Kentik portal where our users store and organize their Saved Views and Dashboards, but also where users can find Kentik preset visualizations for a broad set of use cases. Today we release a completely new UX for the Library module, read on.

Categories folders are replaced by Labels

One of the major changes that you will notice is that categories folders have been replaced with labels - this change results from careful consideration of quite a few factors:

• With recurring requests from users to nest folders, we soon realized that the frontend code behind it was not going to scale well, with the drag and drop across nested folders providing a rather clunky experience.
• The search filter did not play well with folders, as folders would keep being displayed without content if they did not contain any view matching the search
• We noticed in our product analytics that our userbase did not create as many folders as we initially expected
• Users did not have an elegant way to move Dashboards/Saved Views in bulk from one category to another, therefore making administration and organization of these suboptimal.

In parallel, a few things have happened since our last Library Module update:

• Our Product and Design teams had started extending labels to other areas of Kentik Portal: Devices, Synthetic Agents, Synthetic Tests... to the extent that we had built a label management screen in the settings section, and we noticed users were keen on creating labels.
• After releasing the initial version of Role-Based Access Control, some of our users started asking us to extend RBAC capabilities to Dashboards, Saved Views, and Synthetic Monitoring tests in a scalable fashion: having to set rights to these objects on a content-by-content basis would in this case be very tedious and required a method do assign permissions to groups of such items.
  Allowing users to assign common permissions to content based on its label(s) would be an ideal solution to the aforementioned problem.
• Additionally, scaling the Library Categories UI with labels offered all of the benefits of nested folders, without any of the disadvantages.

What can I do with Labels?

In the Library, users are now able to assign multiple labels to their dashboards and saved views.
Additionally, Kentik Presets come with their own, uneditable labels, and they are always represented with an orange label, prefixes with the Kentik logo.

Additionally, the same label(s) can be applied in bulk to a list of selected Dashboards or Saved Views, making management much more convenient for our users with a lot of content (some of our users have multiple hundreds of Dashboards or Saved Views).

With this release, your former category folders have been ported over to labels and assigned to any content they previously contained.

Anatomy of your new Library

1. A top horizontal strip
   Displaying your Favorites and Most Recent views (we'll soon release more features with these favorites, stay tuned !)
   
   
2. A filterable table of all your available content
   Note that your views and Kentik Presets are now together within the same table, with the ability to filter any of them via the Filter Panel.
   
   
3. The search input field
   Allowing you not only to allow text search (on views title and description), but also surfacing the filters from the 4. Filter Panel for quick removal
   
   
4. A full-fledged filter panel
   This search panel now allows our users to search for Dashboards much more efficiently based on: favorite status, whether a subscription exists, labels, their sharing status, the owner as well as which type these are (Dashboards vs Saved Views, and even more precisely the visualization type for a Saved View).
   
   

Next steps

We truly think this new library makes the management and administration tasks for your content much more efficient at a large scale but would love to hear your thoughts about it.
 
In the future, we will add additional metadata to the views available in the Library, such as whether the view is trending within the company, whether the preset view is trending amongst Kentik users, or when the view was last accessed (to facilitate cleanups of older content by admins).

Another thing we're working on that we wanted to tease is how we are planning on letting users navigate saved views directly from Data Explorer, without having to jump back and forth between the Library and Data Explorer - but more to come on that soon ;)

We would also love to hear what future features you'd like to see developed in the Library, do let us know via our dedicated Feature Request portal or your Customer Success team.

One of Data Explorer's most advanced and clever features allows users to generate a set of time series, each based on a different set of filters: Filter-Based Dimensions.
Up until now, the Actions > Show API Call menu option would produce a query that wouldn't return the resulting time series but only the total metric value.
We have now backported this feature into our Query API for you to use.

What is a filter-based dimension?

Regular data explorer dimensions will only let you "break down" metrics by dimensions (think of it as a "Group By" on dimensions in the SQL world). Filter-based Dimensions were added to Data Explorer so users could consider slices of traffic that may overlap (and therefore where a "Group By" will not do the job), but that you'd still want to compare to each other within the same chart. With Filter-Based Dimensions, users can define as many time series as they want to be displayed, each one with its own independent filter, regardless to any potential overlap of the traffic slices for each filter.

A good example use for these is displaying subscriber traffic coming from different farms of servers without using a Custom Dimension to discriminate traffic from each farm - let's dive into an example.

• traffic from Farm-1 
  • comes inbound from devices with the compute label
  • on these two routers, it leverages interfaces with a description string containing farm-1
• traffic from Farm-2
  • comes inbound from Router-2
  • is sourced within the 1.2.3.0/24 CIDR

You can define two Filter-based Dimensions to identify traffic from these farms by creating two filters, one for each series which will be displayed in the chart

How can I get the API Call for a Data Explorer Filter-based Dimension query?

All you need to do is create your Data Explorer Filter-based Dimension query and proceed to Actions > Show API Call and a cURL query will be generated for you to use displaying the literal query to use in your code.

If we go back to our initial example, you'll notice that your Filter-based Dimensions are now fully described in the generated API call. 

"filterDimensions": {
          "connector": "All",
          "filterGroups": [
            {
              "name": "Farm 1",
              "named": true,
              "connector": "All",
              "not": false,
              "autoAdded": "",
              "filters": [
                {
                  "filterField": "i_device_label",
                  "metric": "",
                  "aggregate": "",
                  "operator": "=",
                  "filterValue": "21"
                },
                {
                  "filterField": "i_input_snmp_alias",
                  "metric": "",
                  "aggregate": "",
                  "operator": "ILIKE",
                  "filterValue": "farm-1"
                }
              ],
              "saved_filters": [],
              "filterGroups": []
            },
            {
              "name": "Farm 2",
              "named": true,
              "connector": "All",
              "not": false,
              "autoAdded": "",
              "filters": [
                {
                  "filterField": "i_device_name",
                  "metric": "",
                  "aggregate": "",
                  "operator": "ILIKE",
                  "filterValue": "Router-2"
                },
                {
                  "filterField": "inet_src_addr",
                  "metric": "",
                  "aggregate": "",
                  "operator": "ILIKE",
                  "filterValue": "1.2.3.0/24"
                }
              ],
              "saved_filters": [],
              "filterGroups": []
            }

We have improved our options for synthetic network testing by supporting different protocols for basic network tests (Ping tests). In addition to ICMP, we have expanded the options to test TCP and UDP connectivity between Synthetics private agents or between agents and any target.

As a part of this feature, we have added the ability to start the TCP or UDP listener on our Synthetics private agents which acts as an “echo service”:

• Specify one or more TCP ports to listen and respond to TCP connections
• Specify one UDP port to listen and respond to UDP packets as an echo service

Please note that UDP protocol is susceptible to spoofing attacks, therefore running this service is recommended only within private networks and with the appropriate access control to the open UDP ports by using network access lists or firewall rules.

Additionally, the network connectivity test configuration is extended with the following testing methods/protocols:

• TCP: Based on the TCP Syn packet sent to a configurable port and expecting the TCP Syn+Ack packet response from the target IP.
• UDP-ICMP: Based on the UDP packet sent to a configurable port and expecting ICMP Port unreachable received from the target IP.
• UDP-ECHO: Based on the UDP packet sent to a configurable port and expecting the UDP packet response from the target IP.

Today we are proud to announce that the highly anticipated RBAC (Role-Based Access Control) is going live. In a few words, RBAC will eventually replace our implicit User Level (Member, Admin, SuperAdmin) permission system and offer a much more granular approach to user permissions. Read on to get the details and the shape of things to come in that department.

If you are a Kentik Administrator in your company who will be tasked with managing user permissions, please take the time to read this KB article which outlines the changes from the Legacy User Level-based system, the new RBAC capabilities, and the gotchas from the migration.

What is RBAC?

Role-Based Access Control is a set of User Permission capabilities that allow Kentik Portal Admins to adopt a granular approach to what actions each user can perform in the Portal.
While RBAC will eventually fully replace our User Level model, both will coexist for a while as we port Portal capabilities from one model to the other (which will take a few quarters).
An additional framework, named Permission Overrides is also in place for a limited number of Portal modules: Connectivity Costs and Synthetic Monitoring. It allowed users to set fine-grain permissions for these aforementioned modules only: this capability has been phased out with this RBAC release and replaced by native RBAC permissions.

How does RBAC work?

Users can access RBAC settings in the company settings menu, as depicted below:

Within this settings screen, RBAC administrators will be allowed to create Roles.
Each Role contains a configurable list of permissions, such as "View Connectivity Costs", and "Edit Synthetic Tests"... and a user can be assigned as many roles as desired. When a user has multiple roles assigned to them, the resulting permissions will be the union of all permissions described in all the assigned roles.

The following screenshot illustrates a role named "Administrators", which contains permissions.

The following screenshot is that of a User Settings (from the User Management screen) displaying which roles and resulting permissions are assigned to a given user. Notice that this user has two roles: "Members" and "Connectivity Costs Viewer"

RBAC uses an "implicit deny" model
It's important to notice that this RBAC permission model is based on "Implicit Deny", which means that there are no "Prevent user from doing this..." type of configuration: a user can only perform an RBAC-regulated action if they have the related permission in any of the roles they have been assigned.

What does the initial release of RBAC encompass? 

The initial goal for this first release is to get rid of the legacy Permission Overrides model, which we are therefore sunsetting. The initial set of Portal areas covered by RBAC are listed below:

• RBAC Management:
  View permission by user, Create Roles, View Roles for the Company, Create Roles, Update Roles, Delete Roles, Assign User to Roles, Remove Users from Roles
• Connectivity Costs:
  View the Connectivity Costs workflow, Configure Providers and Costs
• Synthetic Monitoring Agents:
  Create Agents (Register), View Agents, Update Agents, Delete Agents
• Synthetic Monitoring Tests:
  Create Tests, View Test results, Update Tests configuration, Delete Tests

Introducing Kentik-Managed Roles

For convenience, we have also added the notion of Kentik-Managed Roles: these are roles that are exclusively editable by Kentik. The idea behind these is to provide a simple alternative to cover all existing permissions in one role leveraging Reasonable Defaults.
Whenever a new area of the Kentik Portal is folded into the RBAC engine, reasonable defaults for this area of functionality will be updated to these Kentik-Managed Roles - making it somewhat seamless to our users who are currently satisfied with the User Level model.

There are currently 3 such roles, and they mimic the current Member, Admin, SuperAdmin User Levels. For new users, one of these 3 roles will be by default assigned upon user creation based on the Legacy User Level.

Important Note
By default, the Connectivity Costs workflow is entirely disabled for users with the Member Kentik-Managed Role - as a lot of you have mentioned our permissions around it were too loose. New users created with a 'Member' User Level will require an additional custom Role to access the workflow. Since existing users without permission overrides already had access to the Connectivity Costs workflow, we've added a "Connectivity Costs Viewer" role to their profile so they can keep access to the workflow.

What's next in RBAC world ? 

Our initial RBAC release establishes the foundation of the RBAC permission engine. In the coming quarters we'll build on this foundation by expanding the RBAC model into new areas:

• We are working to extend Labels to multiple areas of the portal beyond Devices, Synthetics Agents, and Synthetics tests (see Test Control Center), and we want to extend RBAC permissioning to apply to content grouped together by users using labels.
• In Q4, we will extend label-based RBAC permissions to Synthetics agents and tests, and will shortly follow with Dashboards and Saved Views, allowing the permissions for content created by users to be managed both centrally and granularly.
• Our soon-to-be-released Credentials Vault will be upgraded shortly with the ability to manage secrets based on labels.

More than anything, we would love to hear your thoughts on which area of Kentik Portal you would like us to work on implementing next, so please do let us know!

The Connectivity Cost Edge workflow has gotten its initial Read API released: a proportion of our existing users were waiting on this API to better integrate Kentik with their own internal systems and I'm happy to report it is now live.
They can now, via the API, pull the summary monthly data for any month, from all and any of the providers they have configured.

See the API tester here:
https://portal.kentik.com/v4/core/api-tester/cost-v202308/swagger if you are a US SaaS customer, or here https://portal.kentik.eu/v4/core/api-tester/cost-v202308/swagger if you are an EU SaaS customer.

A lot of you have been asking for a feature allowing you to embed a Dashboard URL containing the value of the Guided Mode Parameter in your external systems.
This is now possible, read on!

Dashboards always come with this URL format: https://portal.kentik.<com|eu>/v4/library/dashboards/<dashboard_id>
Let's say your Guided Mode dashboard pivots around a Destination Interface Provider dimension.

In this example, you can access this dashboard with the parameter pre-filled with the value my_provider using this URL:
https://portal.kentik.<com|eu>/v4/library/dashboards/<dashboard_id>/guided?provider=my_provider

Finding the parameter name to use in the URL after the guided?<parameter>=<value> portion may be a little tricky: parameters in Guided Mode do not 1:1 correspond to the SRC|DST|SRC_or_DST dimensions you are used to in Data Explorer, because Guided Mode considers families of Dimensions, and discard the directionality. Here are a few examples:

• Using SRC, DST (or both) ASN as a parameter will result in using as_number as a parameter name
• Using SRC, DST (or both) AS_PATH as a parameter will result in using bgp_aspath as a parameter name
• Using SRC, DST (or both) Provider as a parameter will result in using provider as a parameter name

The extensive list of URL parameters is available below for your consumption:

- application
- as_group
- as_name
- as_number
- aws_acc_id
- aws_priv_dns
- aws_pub_dns
- aws_region
- aws_subnet_id
- aws_vm_id
- aws_vm_name
- aws_vm_type
- aws_vpc_id
- aws_zone
- az_inst_id
- az_inst_name
- az_region
- az_rsrc_grp
- az_sub_id
- az_sub_name
- az_vnet
- bgp_aspath
- bgp_community  
- bot_net
- cdn
- city
- cloud_provider
- cloud_service
- connectivity_type
- country
- device
- device_label
- dns_query
- eth_mac
- gce_proj_id
- gce_region
- gce_vm_name
- gce_vpn_snn
- gce_zone
- interface_capacity
- interface_desc
- interface_group
- interface_id
- interface_name
- ip
- market
- network_boundary
- port
- provider
- region
- service_name
- service_provider
- service_type
- site
- site_market
- tag
- threat_list
- traffic_org
- vlan
- vrf

Our customers have requested a feature to mute the alarms and notifications for Synthetic tests during their maintenance windows or other activities on their network. Alert Suppression is now available under the Alerting and Notifications section inside the Test Settings.

Users can specify the start and end time of their silence/maintenance window and will not be alerted during the selected period.