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.

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.

Upon popular request, we've added a new agent to the Kentik platform – Kentik BGP proxy (kbgp) – which enables BGP enrichment of flow data to internal network devices without requiring global IP connectivity. Before kbgp, customers could only establish BGP sessions with devices with an assigned public IP address. Via kbgp, BGP enrichment can now extend to flow data generated from all internal areas of your network, further enhancing network troubleshooting for on-prem and campus environments. Read on for details!

Kentik BGP proxy (kbgp) is a Kentik agent that can proxy BGP peering sessions between customer devices inside the customer’s network and Kentik over the Internet. The kbgp is deployed inside the customer’s private network. The customer devices are able to establish BGP peering with the kbgp, which will multiplex and relay BGP packets in real time to Kentik. The result would be the same as if the devices are peering directly with Kentik.

The functionality is achieved similarly to the functionality that is performed by kproxy, which collects flows locally inside the customer’s network and securely exports them to Kentik inside an HTTPS tunnel.

Without kbgp, customer devices can only establish BGP sessions with Kentik over the Internet, which requires that the customer device has a public IP address assigned. With the use of kbgp, multiple registered devices can have BGP peering with a single kbgp. The BGP session packets are carried over a secure gRPC session to Kentik, where the BGP session is logically established and the data is transferred. kbgp does not store any BGP state or BGP routes, making this agent lightweight and requiring very few resources.

The image below shows the logical diagram of kbgp usage inside a customer’s network

The key benefits of deploying kbgp in a Kentik-monitored network include:

• Kentik will be able to add BGP context to the flow data from internal network devices that don't have global IP connectivity
• The BGP data is secured and encrypted during the transfer from the customer's network to Kentik

At the moment, kbgp does not appear under the Kentik Agents section in the Settings menu, but we are actively working on a way to display the agent within the UI. For more information about the kbgp installation, configuration, and troubleshooting, please check out our kbgp KB article and let us know your feedback in the comments.