Some features are hidden jewels that are hard to spot: they don't come with a shiny UI that make them stand out, but they pack some heavy punch and you wouldn't know unless someone reveals their true power to you.
This is one of those features. More often than not, assessing the benefits (aka the amount of traffic that can be peeled off to the IX) in joining a certain exchange requires so much discouraging work that these decisions end up being made on a gut feel, almost as an act of faith.

Enter the Data Explorer PeeringDB filter dimensions!

The theory

Let's say we want to evaluate how much of our actual traffic could be peered off at a specific Internet Exchange. What do we do as a Network Engineer without access to Kentik ?

1. Collect source ASN or destination AS flow data inbound and outbound, then dump it in a spreadsheet
2. For each ASN in that breakdown, list all Internet Exchanges that they are present either via leveraging the PeeringDB public API, or manually by reviewing all ASNs' PeeringDB record – some ASNs are at tens if not hundreds of exchanges...At the same time, note what their peering policy is.
3. Run that ASN list through a sieve to only keep those at the Internet Exchange you are interested in, and that have a peering policy you can comply with.
4. Sum all the resulting traffic.

Having done this routinely in my career, I can safely say that:

Either you have coding skills and you can code your way out of it... or you don't and this will take multiple hours. This outlines the issue of inefficient peering decisions: analytical decisions are gated by an inordinate difficulty in collecting and correlating simple data sets together, and the common result is that hunches and arcane culture end up replacing the science.

So how does it work ?

Here's how we wanted this to work: add filters to Data Explorer, so that users can make these types of queries – let's think SQL for a second:

Show me my top Destination ASNs where said ASNs are registered in this specific IX, with an open policy

When the query is run, Kentik's Data Engine issues a two steps query: 

1. Pulls the list of top destination ASNs, 
2. Pulls the list of ASNs at this specific IX and filter it by the list returned in the first step. 

Remember, Kentik is mirroring the PeeringDB database daily, so this information is always fresh.

and Voila !

Cool story bro, now just show me a real life example kthx.

Let's try this with a concrete example: Kentik is present at Linx NoVA. I want to know how much inbound traffic we can peel off from our Transit upstreams at this exchange. We've got a few peering sessions there, but I have a hunch I can reclaim quite a bit of bandwidth through this exercise – let's see if I'm right.

I'm going to look at these dimensions, no surprise here

But when building my filter, I'm going to use this new PeeringDB section here, where I can now set whatever IX I want my source top ASNs to be part of:

Notice how you can leverage this same dimension with a "SOURCE or DESTINATION ASN is member of this IX"

You'll notice that this filter item sources its values directly from PeeringDB, so I'll enter "LINX NoVA" for "Source ASN is Member of IX" – note that I'm filtering on Source Network Boundary = External because I just want to see the traffic coming into my network.

My intuition gets confirmed: if I look at the resulting SanKey diagram, it appears that only a small part of traffic towards LINX NoVA member ASNs I receive traffic from is actually coming through my IX port at LINX NoVA, see for yourself.
According to this query, I could peel ~384Mbps from inbound Transit traffic to this exchange by establishing the right sessions with these ASNs on the right side of diagram I'm currently receiving traffic from.

Now If I really want to get a realistic estimate, I need to ensure that I'm only considering traffic from ASNs with an Open Peering Policy - no problem: PeeringDB also has that information, so let's just add it to the filter

And so the Transit part of the previous SanKey gets revised with a bit less traffic because the query engine is now discarding source ASNs without an Open Policy:

As always, there's more!

There are more use cases that this well-hidden gem empowers our users to do:

• Reclaim Transit traffic and convert it to IX peering traffic, and more importantly maximize the use of your IX ports
• Identify PNIs to secure with IX peering as a fallback, or additional peering locations you can meet your existing peers at for more resilience 
• More than anything: evaluate which IX to deploy to next based on how much assured traffic you can peer off and estimate the port capacity you will need.

All of these are focused around IXes, but the same applies to this other filter dimension set: "<Source | Destination | both> ASN member is available at <specific datacenter facility>" – which helps you answer the same use case, but from a data center standpoint for PNIs.

This is a pivotal step towards an even better outcome: what if every day, Kentik ran a report on all of your top Source or Destination ASNs and made informed, analytical suggestions about which of them you should go next?

Watch this space, because this is where we are headed.

If you remember back in May 2023, we released our initial version of a PeeringDB integration - more details here: https://new.kentik.com/we-now-integrate-peeringdb-data-akabK

The theory

PeeringDB contains a directory of most of the registered Internet Exchanges (IXes), as show in an extract below.
 For each one of them, their data contains the IP Ranges, v4 and v6.

 For each interface that we poll on your devices using SNMP or Streaming Telemetry, we get information such as the IP Addresses configured. Using the aforementioned IX IP Range data, we are then theoretically able to match any interface to an Internet Exchange from Peering DB based on its IP Address.

What does it look like in the product ?

We've added a somewhat magic rule, which we have decided to call a Kentik-managed Rule in our Interface Classification UI. This rule is a bit special compared to the other ones in the stack:

• It cannot be edited by users
• It can only be enabled/disabled by users
• It sits on top of the rules stack, which means that it will always be evaluated first to bypass any user defined rule (because for each interface, the algorithm exits on first match)
• This rule checks the IP Addresses, and looks the IP address up in all the IP Ranges from all the IXes in PeeringDB, if a match is found
  • it sets the interface to Connectivity Type = IX
  • it sets the interface to Network Boundary = External
  • it sets the Interface Provider to the name of the IX from PeeringDB
  • it establishes the mapping between this IX and the PeeringDB Exchange in the PeeringDB integration configuration so you don't have to

Here's an example of what Interface Classification Test UI for this rule will look like in case of matches

Existing Customers vs New Customers

Obviously a lot of you may already have their interfaces well classified, and most likely you used dynamic regex matching on their descriptions to get your IX classifications going.
As we didn't want to disrupt your existing setup, we have adopted what we think are reasonable defaults to roll the feature out:

• Existing customers will have the PeeringDB rule disabled by default
  -> up to them to enable it if they would like
• New customers will always have the PeeringDB rule enabled by default

But wait, there's more...

As an additional freebie, we've modified the Interface Provider field for any custom rule that sets an interface as IX: you can now choose to keep your own provider naming, or can select the actual PeeringDB name for the internet exchange - in this case the field will offer a typeahead that directly looks up values from the PeeringDB exchange names, as showcased below.

There are still a lot of features that we plan on implementing relying on the PeeringDB dataset, so watch this space, and don't hesitate to give us feedback !

Going back and forth between Data Explorer and our Library to cycle through Saved Views when doing your rounds has always been somewhat of a tax on user productivity.
We recently decided to tackle this workflow and streamline it: we have tested out this new feature with a few of our customers before launch and are now proud to present the Saved Views Drawer feature in Data Explorer.

An expert eye may already have noticed that a new button has sneaked into the Data Explorer actions bar: 

Clicking on it will unveil a new drawer in Data Explorer, allowing our users to directly browse, search and find a Saved View to load in Data Explorer, without having to go back to the Library module.

You can now entirely navigate the list of Saved Views with both mouse or keyboard, it is ordered in 3 sections (horizontal arrow keys):

• Favorites: any Saved View you have favorited either from the Library or on the View itself with the star icon next to its title
• Recent: we're also making Recent Views persistent, so you can see the TopN last displayed Saved Views
• Browser: any view in your Library that you have access to: this will be the default tab if you don't have any Favorite or Recent

Remember, the entire functionality is entirely keyboard friendly, as reminded at the bottom of this new drawer

Lastly, plenty of filtering options allow you to find the right Saved View you are looking for in a sea of user generated views:

...these filters can be cleared at any moment via the UI displayed below

We weren't entirely satisfied with our last revamp of the Library UI so we gave it a few more iterations to make it more legible, we hope we like these new tweaks.

Top Recent/Favorites Strip

In the initial iteration of the overhaul, we noticed that the top strip would sometimes get in the way for users with little vertical real estate (i.e. low vertical resolution). It would consume a large part of vertical real estate and a large part of the content of the library would be pushed below the fold so we went ahead and fixed that:

The top Strip is now toggle-able, and your last setting will be remembered by your browser as it is stored in your local session. Beyond that, there's now a keyboard shortcut to show/hide that Favorites/recent top-strip: [shift]+[f]

Views grouping

Users can now group the views in the data-table based on a few attributes: ungrouped, Owner (who created the view), Sharing (Shared, Private, or Kentik Preset), View Type (Dashboard or Saved View)

...these groupings will appear in the list table as group header rows with counts - as depicted below when grouping on "Sharing"

New labels visual format

Finally, the previous display of labels in the list using full-color labels made it very noisy, so we rethought the way we're displaying labels - a picture being worth a thousand words:

vs the previous format

• The title of the view was made bigger
• the labels made more subtle while still showing their colors (avoiding color overload)
• the labels are now sitting next to the title (a visual treatment we stole from GitHub's clean UX)
• the labels for presets also have had their format changed to this to better match the new visual format 
  

New Label selector filter UI

We changed the Label Selector to be more efficient, and in line with the new visual format both in the filter panel, but also in the bulk interface above the list of views.
Note how labels are now sorted by 1) your company's label (alphabetically) 2) Kentik Presets labels (alphabetically) one after the other and not together anymore like they used to be.

Why all these changes on labels ?

One of the reasons we're updating the visual aesthetics of labels is that as you may have noticed, labels will take a more and more central role throughout Kentik Portal, especially when it comes to RBAC (Role Based Access Control) - and to achieve that, we want a label UX throughout Kentik Portal as smooth and legible as can be.

Moving forward in 2024, expect other areas of Kentik Portal with labels involved to receive the same visual update to match their style with this new one.

Up until now, Description text for both Saved Views and Dashboards haven't been first class citizens when users navigate to either of them and want to know what a view they haven't created themselves is all about.
We just made it incrementally better, read on.

Where we come from

Displaying Description text for Saved Views and Dashboards used to require a little bit of user gymnastics, especially for Dashboards where the only ways to visualize this description would be

• look at the description summary in the Library screen (which may be truncated if too long)
• have edit privileges on the dashboard and proceed to Action > Edit > Dashboard properties

For Saved Views, descriptions were only displayed in a rather space constrained Edit field in the query panel - again, not entirely ideal.

We've noticed that some users are Content Creators (to use a common term these days), and they create the best dashboards for everyone in the company to use - and some other users are Consumers, meaning they rarely build out Saved Views and Dashboards, but consume them heavily for their operational tasks.
More often than not, the subtlety of the view crafted by the Content Creator can escape the Consumer User (instructions on how to use, limitations of the view, how to interpret the data...) - this is what we want to improve with this micro-feature.

Where we're going

Upon loading either a Dashboard or a saved view, you will now notice a speech bubble icon next to it:

Beyond this, we bound this action to a new shortcut, [shift]+[d]so that shortcut-savvy users can access it without needing any extra click - the modal can also be discarded with the [esc] key.

Remember, all the shortcuts that are active on any screen can be displayed by using another shortcut: [shift]+[?]

What the future holds

We are already considering rich, markdown-style panels for our future Dashboard revamp (roadmap milestone still tbd) - what do you think?

As some of our customers had noticed, entering a Site address as a one liner instead of multiple fields for city, region and country came with some occasional misfires.
We've fixed this in our UI, so that you can always override these issues manually when they happen.

What was the problem?

We chose for our users to enter their Site locations via one-liner addresses. Upon saving a site, the provided one-liner address is issued to the Google Maps API and we interpret the results to store the following attributes for the site:

• City
• Region
• Country
• Lat/Long 

Address formats vary from one country to another, and so does the data structure for an address returned by Google Map's API. Based on this returned data structure, we attribute City, Region and Country based on our deciphering of this data structure, which changes for every country, meaning that sometimes we get it wrong, here's an example

...where the resulting address in the Site object is as follows

...unfortunately, the city here should be Barueri, because Tamboré is the name of the neighborhood.

The solution

While this issue is a rare occurrence, it hits some geographies much more than others, with the cognitive load borne by our customers in these locations: a Data Explorer query returning a City they have never heard of...
This is why we are now allowing our users to override these values manually by selecting a City, Region and Country of their choice if they so desire - in continuation of the previous example:

We are excited to announce the preview of Kentik Journeys AI.

Kentik Journeys takes the concept of natural language query a step further by providing an AI-assisted conversational user experience purpose-built for the process of troubleshooting and network analysis.

When troubleshooting, engineers typically ask a question, analyze the answer, then ask a new, and hopefully better-informed question. Sometimes this process is simple. Often it is not. This process is repeated until the user comes up with the root cause and then applies a fix leading to a resolution.

Journeys provide a dedicated space to perform this iterative process, saving questions and answers as the user performs their troubleshooting journey. These journeys can be shared across all Kentik users of a company to encourage communication and knowledge sharing.

The real power of Journeys is its network context. Meaning it understands your network - the devices involved, your cloud regions, on-premises sites, etc. Anyone can converse with Journeys about their specific network, within a user experience that is purpose built for the journey of troubleshooting, hence making it much faster and more efficient.

Journeys respect your Security and Privacy. Under the hood we use a Large Language Model (LLM) service from the leader in GenAI. Customer data is never used for training any models and no customer data (like flows or metrics) are ever exposed to the LLM. Some set of partial metadata (site and provider names) are supplied to the LLM prompts. On top of this, our service provider privacy policy clearly defines that no data supplied to their models will be ever used for training of AI models.

How to get access to Journeys

We would like to highlight that our Journeys capability is currently in "Preview" mode, as our goal is to incrementally enhance the user experience. We plan to do it by carefully considering your feedback and suggestions, improving accuracy, expanding the range of supported questions, and integrating additional Kentik features. 

Due to this, we are taking a phased approach to granting access, ensuring a fulfilling experience and providing appropriate support for every customer. Access to Journeys will initially require a request, and we will progressively make it available to all of our users. We appreciate your patience during this process and promise to keep you updated on when access will be available for your company.

If you are interested to participate in the preview, please request access for your company on the Journeys AI page.

How to use Journeys

When you first enter into the Journeys AI page, a short tutorial will be started that demonstrates how to use it. Please follow the instructions to get familiar with the user interface and read the instructions on how to make good queries.

We hope you give it a try and let us know what you think.

Here are some example screenshots of Journeys.

CPU usage

Traffic analysis

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.