Observation Deck is our vision for a new focal point of the Kentik platform. It brings together all of our products & modules (current and future), in one place, so customers can get a complete and tailored view of their network and infrastructure. Every new customer will get a curated, default Observation Deck at the end of their initial onboarding. Observation Deck can then be configured to meet their exact needs.

Now customers with Azure Cloud infrastructures can add widgets to their Observation Deck and the Kentik Cloud landing page has been extended to show Azure views as well.

Note the addition of “Cloud Provider Filters” at the top right. This allows to visualize either a multi-cloud environment (“All”), or a specific Cloud. Traffic/flow widgets will filter data by cloud provider if selected.

Azure regions are now shown on the Weathermap.

For a multi-cloud environment, here is how this looks, including the Cloud backbone traffic.

Setting up monitoring of Cloud environments with Kentik can be difficult, especially when users run large multi-account environments. Ensuring that each account has the proper roles with the necessary permissions for Kentik to retrieve metadata and flow logs can be challenging to maintain at scale. That’s where our Cloud Config status comes in. It quickly analyses complex environments to ensure that all accounts are configured as required for Kentik to monitor Cloud networks. This capability is now available for Azure in addition to AWS.

March 2022 marks another important milestone milestone in Kentik's Hybrid Cloud observability product offering by not only releasing Azure Maps, but also  adding AWS VPC endpoint support.

Azure Map

In March we made a large leap forward in enhancing our multi-cloud observability solution. We are introducing the first version of our Kentik Map for Azure, providing a similar look and feel to the AWS map. While many concepts are the same, there are differences, for example a VPC in AWS is a VNET in Azure:

Similar to AWS, we are now showing the Azure regions including their VNETs, allowing users to click into the subnets, and display traffic and other details:

VPC Endpoint support for AWS

We now display VPC endpoints in the AWS Map as network gateways so that map users can easily view traffic to (or in some cases, from) these constructs.

February 2022 comes with a broad set of Kentik Cloud improvements. Google VPC Flow Logs now include GKE (Google Kubernetes Engine) dimensions, users can now post their own AWS metadata using a newly created ingest API (instead of allowing Kentik to retrieve it via AMI assumption), dissociate the accounts used to collect Flow Logs vs Cloud Metadata, and last but not least, the Kappa agent for Kubernetes celebrated its 1.0 version !

Google Kubernetes Engine dimensions

Kentik Data Explorer now supports Google’s extended flow logs for Google Kubernetes Engine (GKE) environments. Google extended their VPC Flow Logs to include annotations that describe network traffic inside the Google Kubernetes Engine environment – i.e, the pods, services, nodes, etc. After hearing from a customer who needed this capability inside Kentik, our engineering team added support for these new dimensions.

AWS Agentless Ingest

Kentik Cloud users can now choose how they want to send their cloud data (VPC flow logs and AWS metadata) to Kentik. This helps solve a problem for some who couldn’t allow Kentik to reach into their AWS accounts via an IAM role assumption. We have exposed a REST API to which you can manually post AWS metadata and we can provide a Kentik-hosted S3 bucket to which VPC flow logs can be written or replicated.

Improved Metadata-only onboarding/settings

It’s now easier to configure an AWS cloud export to collect only metadata from a given account/region. Now that we’ve made this simpler, anyone should be able to understand how to configure such environments.

Enhanced kappa agent for Kubernetes

Kentik has released version 1.0 of the eBPF-based kappa agent for Kubernetes network performance and telemetry. Improvements in this version include easier deployment, critical performance telemetry (% Retransmit and % Out of Order Packets), and host metadata reporting.

A lot of new additions have surfaced in February 2022 in the Kentik Map UI. Amongst others, users will find: a health digest reporting function, new layers for AWS Regions and cloud backbone, as well as improvements in the map legends.

Kentik Map Health Digest

An indicator in the toolbar gives a count of issues we’ve discovered on your network and opens a popover that provides a high-level rundown. Click the View Problems button to see a list detailing the issues, then drill down to the map to see an impacted component in the context of its surrounding infrastructure.

Kentik Map Layer Selector

A new layer selector for the Kentik Map lets you choose which categories of overlays to display, including link traffic types, traffic layer types, cloud regions and backbones, traffic utilization, health, and clustering.

Kentik Map legends

The legends that identify the value ranges represented by link colors are now persistent, so it’s always easy to see what the colors mean.

Kentik Map AWS Regions and Backbones

A layer for AWS regions and backbones has been added to the Kentik Map.

As usual, our Cloud Product team turned around a ton of great enhancements to the Kentik Cloud and Map products over the month of December 2021. More than ever, Kentik goes one step closer from being the only and most complete Hybrid Cloud observability solution out there. See for yourself.

Weather Map improvements

This month saw one of the largest updates to the Weather Map yet. In this release we’ve incorporated several new features worth discussing. We added layers that allow users to view utilization and/or health data into their map, along with a nifty layer selector:

Layer Selector

Utilization layer

A major use case for Weather Map in ISPs and large backbone networks is to assist users in performing capacity planning exercises. In order to accomplish this, we needed to color the map based on interface utilization rather than total bytes. This means that our new map breaks down the interface utilization of a single interface or an aggregated bundle and buckets these interfaces into 10 groups of increasing utilization.

We also needed to add in support for interface bundling as well as support visually aggregated interfaces when more than one link connects a site cluster to another site or another cluster. To support this, we use the backend attributes that we poll from our customer’s SNMP data to determine if an interface is configured as part of a bundle or is operating as a single interface.

If a link is drawn between two site clusters, we’ll aggregate the bandwidth over both links and calculate the total utilization on the fly:

When a user clicks on this link, the system allows them to choose which link they’d like to focus on:

Weather Map sidebar improvements

We’ve also added in sidebar improvements that make selections of Sites and Links easier. Consider the following example. A user has clicked on the 3 site cluster in the Chicago region on the Kentik map:

The sidebar now opens up with a running count of the sites and links interconnecting the sites.

Expanding these elements allows to interactively browse the map:

Health Layer

We have also started to resurface health on the Weather Map. We started by adding health into the cluster popovers as such:

Of course, we also show the site health on the canvas and sidebar as well. Here we see an unhealthy ORD1 site on the canvas:

And a list of all of the sites within a view color-coded by health in the sidebar:

You will notice that we also now color links by health. We currently have two link-health states — down and degraded:

Down indicates that the router that originates or terminates a link has reported an ifOperStatus of DOWN or administratively shut down, while Degraded state means that the system is reporting errors.

Mini-map site topology

A popular request we’ve heard is to show a user’s site topology without having to load the entire site view. We now show the site topology in the sidebar itself. This is useful for getting at-a-glance understandings of how sites are constructed and is a step closer to our next iteration which allows users to see the devices that connect to other sites directly on the Weather Map canvas.

This month the cloud product team delivered a ton of improvements: tightening up our maps, making our backend systems more resilient, and improving Azure onboarding. We released an alpha version of Kentik Kube, a product designed to help networkers awash in a sea of containers find solid ground, a variety of map improvements, support for VPC endpoint interfaces and gateways, and the ability to retain VPC Flow Logs inside of S3 buckets indefinitely. And we delivered the first of two projects designed to make agentless cloud ingest a reality. We are actively seeking design partners for Kentik Kube. Please contact us if you’d like to help guide our vision for this product early on. We welcome your input! Read on for all the details.

Kentik Kube: Network visibility for Kubernetes clusters

One thing we believe at Kentik is that everything that runs over the network should be observable — from containers to clouds, and everything in between. And with that in mind, whenever we become aware of a new visibility gap making operators’ lives more difficult, we aim to bridge it.

Enter Kubernetes. In 2020, we released an agent that could be used to export network flows from Kubernetes. And this month, we’ve released Kentik Kube to visualize this data.

Kentik Kube is a new module of the Kentik Network Observability Cloud that helps cloud and infrastructure engineers gain detailed network traffic and performance visibility both inside and among their Kubernetes clusters to quickly detect and solve network problems.

As the industry has adopted Kubernetes as a de facto standard for workload scheduling, teams that support these environments are discovering that their network and Kubernetes monitoring tools can’t help them answer critical questions because they:

• Are unaware of traffic patterns within Kubernetes or do not create traffic logs for these environments
• Do not take into account the network models implemented by Kubernetes
• Do not fuse Kubernetes metadata into traffic data.

We built Kentik Kube to provide this visibility for these teams. Our solution supports cloud-managed Kubernetes clusters (AKS, EKS, and GKS) and on-prem, self-managed clusters using the most widely used cloud implemented network models.

Kentik Kube helps by supporting the following use cases:

Network performance: Discover which services and pods are experiencing network delays so you can troubleshoot and fix problems faster. Identify service misconfigurations without capturing packets. Configure alert policies to proactively find high latency impacting nodes, pods, workloads or services.

Top talkers: Identify clients/requesters consuming your Kubernetes services so you can track down problematic connections. Discover oversubscribed microservices so you can adjust scaling, configure node affinity, etc. Know exactly who was talking to which pod, and when.

Policy validation: Ensure that your network reality matches your design. See which pods, namespaces and services are speaking with each other to ensure that your configured policy is working as expected.

Total infrastructure visualization: Know which pods are deployed on which nodes — even historically. See which pods and services are communicating with non-Kubernetes infrastructure or the internet. View your network from container to cloud.

AWS Flow Logs in-bucket file retention

Kentik has always allowed our AWS customers to retain their flow logs in their buckets. However, we ran into problems with customers who wanted to keep their flow logs around for long periods of time. We’ve made some significant changes and are happy to report that customers can now keep their flows around as long as they like — without any adverse effects on their Kentik subscriptions.

VPC endpoint support and ENI gateways

This month we’ve begun our journey towards full support of VPC endpoints in Kentik Cloud. Our first volley of product improvements includes giving customers the ability to group and filter flows based on these gateway IDs in the Data Explorer.

We support both Gateway-style VPC Endpoints as well as Interface VPC endpoints (AWS PrivateLink). However, despite their similar names, these are very different things under the hood. VPC Endpoint Gateways act as gateways to Amazon services, keeping this traffic inside your VPC and off the public internet. Using these endpoints can save money by keeping VPC network egress costs down — making identifying when traffic isn’t using these gateways a key use case. These gateways aren’t exposed as elastic network interfaces and thus can be difficult to track traffic using other network solutions. Kentik is the only solution on the market that gives you this capability.

AWS PrivateLink allows AWS and their customers to configure their services for consumption without forcing traffic to flow over the public internet. Over 128 different AWS services are available behind these so-called “interface endpoints” while just a small few are available behind VPC endpoint gateways. Interface Endpoints serve to reduce cost and can serve a security function in that sensitive information can be shared between AWS customers privately. These endpoints are exposed in a more standard fashion inside of VPCs using Elastic Network Interfaces as the gateways. The major difference in how this impacts Kentik users is that these interfaces are grouped in the Interface Type dimensions and specific interfaces are identified in the ENI ID dimension while the Gateway-style endpoints are grouped into the Gateway Type dimensions and the specifics are found under Gateway ID dimension.

S3 bucket ingest

We took a major step forward this month in our promise to offer agentless ingest to AWS customers. Instead of having Kentik reach into customer buckets to retrieve flow logs, we can now support customers who wish to write their flow logs directly into an S3 bucket that Kentik manages and maintains. This allows customers to write flow logs more flexibly (via direct VPC write, lambda copies, S3 actions, etc.) and also allows customers to avoid giving Kentik permissions into their S3 buckets. Next up on our agentless agenda is to provide a method for companies to post their metadata to a similar endpoint for enrichment and mapping visualizations. Stay tuned!

Map improvements

Following our September release of the Weather Map, we’ve continued to iterate on our Kentik Maps product. This month we’ve added a bunch of important fixes and improvements.

We’ve improved handling overlapping lines in AWS. Previous versions of Kentik Map would allow lines connecting close together objects to overlap. We’ve added some logic to detect this condition and give these objects a bit of breathing room, making it easier to visually determine the path connecting the objects and select them with your mouse.

We’ve improved visualizing site-to-site VPN connections. Prior versions of Kentik Map for AWS kept the customer gateways in the middle of the screen. We moved customer gateways into the “On Prem” box where they rightfully belonged. This helps clean up the interconnection section of the map considerably. We have more work coming here this quarter to make the map experience even easier to use for companies with lots of interconnections.

The months of August and September 2021 are synonymous of a large feature dump in the Cloud section ! While there's too much in it for a comprehensive summary, read the full details below to get your monthly fix of Cloud features.

Security Group & Network ACL Visibility in Kentik Map

Further burnishing our credentials as the cloud network engineers’ tool of choice for troubleshooting connectivity issues in AWS, we’ve just added a new sidebar feature to the Kentik Map, Security Groups & Network ACLs.

This sidebar enhancement enables network engineers to find traffic that is currently being dropped by AWS security groups or network ACLs applied to the selected VPC or subnet. The component analyzes the selected VPC or subnet for denied traffic into or out of the network environment and then crawls through the company’s AWS metadata to allow users to determine exactly what traffic has been dropped. The component also helps users understand which security group or network ACL policies caused the traffic to be dropped.

The system works by running a query of the flow logs to or from the selected VPC or subnet to find any traffic that had been marked by AWS as REJECTED. It then analyzes the direction of the traffic to provide an at-a-glance view of these traffic flows, as well as a convenient method for searching through the traffic to find a particular source or destination.

If a user wants to find more information about why particular traffic was dropped, they only need to click on the row to open an analysis window:

The system highlights rows that contributed to the specific traffic being dropped, making it easy to determine what policy needs to be updated and even which rule could be modified in order to rectify a misconfiguration.

Users can also view these access control policies directly from within the map — a very cumbersome task using only the AWS console and/or CLI. Kentik Cloud users now need only click on View Security Groups or View Network ACLs buttons in the sidebar and the system will open up a dialog showing exactly which policies are applied to the selected object and allow the user to browse the rules associated with each policy.

Support for New AWS Dimensions

Several months ago, AWS introduced support for the following dimensions in AWS flow logs:

• Source/Destination Packet Address: Network traffic is often encapsulated — think of NAT gateways and GRE. AWS surfaced this dimension to help users determine the original source or destination of traffic and gain a deeper understanding of how traffic flows through a cloud environment.
• Source/Destination AWS Service: Traces traffic to or from AWS services, even if the traffic is tunneled. This new dimension maps the traffic based on the packet address.
• Traffic Path: This dimension shows the path that egress traffic takes towards its destination.
• Flow Direction: Marks the direction of traffic from source to destination as ingress or egress.

ENI Tagging and Dimensions

Flows are generated from network interfaces that attach infrastructure to the network. In AWS parlance, these interfaces are called ENIs (elastic network interfaces). Mapping flows based on ENIs provides an opportunity to add new dimensions to group and filter by ENI type, as well as group or filter traffic by source and destination ENI. These new dimensions allow our users to construct super-precise flow queries that don’t double count traffic to or from instances, through gateway and load balancers as well as special infrastructure like Lambdas. This is an important advantage for Kentik Cloud users.

Cloud-Native Views for Kentik Map

We also created a more welcoming experience in the Kentik Map for cloud-native/cloud-only customers. Our previous version of the map assumed that users always had an on-prem network (or would soon be adding one). The result was that the cloud infrastructure was tucked away in the Cloud Block, while the large on-prem block remained a bare focal point on the map.

No longer! Now, when single cloud users without an on-prem network register their clouds in Kentik, the map will open up either directly in their cloud’s most appropriate view — and multi-cloud users without an on-prem network will be presented with a new multi-cloud view in the center of the map. If and when users decide to add on-prem network devices to Kentik, their experience will go back to what we are used to today (an on-prem centric view of the Kentik map).

Improvements in Sidebar Traffic Queries

Did you know that sites don’t need to be directly connected to each other in order to show traffic lines in the Kentik Map? Several quarters ago, we introduced a feature called “Draw Links Using…” which enabled users to select an option to draw links based on BGP Ultimate Exit as well as Site IP addresses configured in the site architecture dialog. This enables “island” networks (networks without a backbone) or SD-WAN networks to configure their sites and easily run traffic queries between sites.

These lines are drawn by queries using new dimensions called Source/Dest Site by IP and Site Type by IP. Because we’d heard that some new business was based on this, we’ve responded by adding these dimensions into the sidebar for convenient analysis in the map.

Another quick but important usability improvement was to create a new sidebar section titled “Details.” This prevents map objects (subnets, VPCs, gateways) with lots of metadata from making the sidebar unusable.

Azure Updates

A major improvement we’ve added for Azure is the ability for companies that centralize the collection of NSG flow logs into a single storage account to create “metadata-only” exports for resource groups within the same region. To make this work, simply disable the slider called “Enable Flow Logs for this Export” on any resource groups that don’t have their own storage account associated.

We’ve also implemented some improvements to our Azure services based on customer feedback as well as added infrastructure resiliency and backend code improvements. Stay tuned for more improvements this and next quarter as we continue to round out our cloud offerings.

New Cloud Tour in Demo Mode

We’ve added a sixth tour to Kentik’s Demo Mode, which walks users through a troubleshooting scenario involving connectivity problems between AWS resources and an on-premise database. The new tour highlights the difficulty of conducting this kind of troubleshooting in complex cloud environments with existing tools, and makes very clear Kentik’s strength in helping solve these issues.

New Weather Map

This month we are excited to announce beta availability for our new Weather Map — a new core feature of Kentik Maps.

Our new Weather Map shows network engineers how their network looks so that network architectures and the current traffic patterns can be understood at a glance. This feature was one of the most requested enhancements to Kentik Maps since we went live, and we’ve only begun to scratch the surface in terms of what we plan to do here.

Today, the Weather Map is simple. It renders a company’s sites over a geo-political map, using the customer’s configured site addresses to translate to latitude and longitude coordinates. We also cluster groups of sites within the same region to declutter the map; as users zoom towards these clusters, the cluster breaks open, revealing the sites positions on the map below. Between sites (and clusters) of sites, we’ll draw links using the connected interfaces so customers can view their backbone network utilization and click on links for easy traffic analysis.

We’ve got an amazing roadmap of features coming out for Kentik maps this quarter, so stay tuned for future updates to Weather Map, AWS map and site maps in Q4.

Historical Queries

Another great new feature enhancement is our ability to rewind the clock and show users how their AWS network (and associated traffic) looked in the past, using historical metadata.

When we launched the Kentik Map for AWS, we began with a metadata service that only stored metadata describing the current state of the user’s network. However, if a user adjusted the time window to find specific flows, we assumed that the AWS architecture was the same during the specified query window as it was when the query was actually run. We knew this would eventually require historical support, which took time to design and implement.

However, that day is here! Users can change the to/from dates in the Kentik Map and we will update the map to show the user what the environment looked like during that time. If we took multiple “snapshots” of metadata during the specified time, we will show the most current we have for the time window.

This means that if traffic used to flow through a gateway that was subsequently deleted, we’ll show that gateway on the map. If traffic entered a subnet that only existed for a day or an hour — we’ll draw that subnet on the map.

Clickable Lines in the Kentik Map for AWS

We’ve added the ability to click on a line within AWS and get instantaneous traffic details for the line! In prior versions of the Map for AWS, users could only click on Map elements such as Subnets, Gateways, etc. Understanding and analyzing traffic between elements was left as an exercise for the user to construct queries using the Data Explorer. Now users can click on lines between subnets (“Show Connections”), lines between gateways, and lines to and from internet ASNs.

NAT Gateways and Transit Gateways

We also improved upon the way that the Kentik Map rendered traffic to and from gateway objects. Previous versions of the Kentik Map couldn’t determine the amount of traffic entering a subnet from a gateway. Now that we’ve switched our flow enrichment over to using network interfaces rather than only IP addresses, we can indeed show traffic from this infrastructure entering your customer’s environments.

The Hybrid Cloud observability feature set in Kentik Portal makes a big leap forward these June and July months, with a special focus on Amazon Web Services features, read on !

AWS Entity Explorer

A quiet but mighty addition to our product, the AWS Entity Explorer puts important network metadata at our user’s fingertips. You might not know it, but the details that dictate how cloud networks behave are buried behind APIs or inside cloud interfaces — which were built for automated consumption — and certainly not for solving problems for network engineers. With this new feature, engineers can answer questions like “What VPC is this internet gateway associated with?”

Features include:

• Instantly find any network element using our quick search utility. Search on owner IDs, entity IDs, tags, and names.
• Jump from gateways to attached VPCs to quickly navigate around complex metadata.
• Our new “Open in Map” feature allows users to quickly locate and understand how infrastructure is placed within their environment.
• Open cloud networks elements in Quick Views and Data Explorer.

Support for Peered Transit Gateway Traffic Queries

The Transit Gateway in AWS continues to stymie network engineers trying to get a handle on how their traffic is routed within their AWS cloud network. Our original implementation of TGW support only looked at traffic that had originated on a directly-attached VPC. However, Transit Gateways can be peered with each other — meaning that a single Transit Gateway can actually be forwarding traffic to or from an adjacent Transit Gateway. Being that we are awesome, and because we are the only network observability company with a solution to monitor traffic through Transit Gateways, we solved this problem by writing an algorithm that discovers peered Transit Gateways — so you can always see the correct amount of traffic flowing to or though your TGWs.

AWS “Show Path” Feature

A truly kick-ass, differentiating feature for Kentik Cloud. Understanding how traffic flows from one VPC to another over a cloud network is truly a painful experience — one that has network engineers switching back and forth between their command lines and the AWS console for minutes before arriving at a simple answer. The AWS Show Path feature eliminates this pain and replaces it with an intuitive, complete and beautiful way to see paths between sources and destinations in the cloud.

Show Path works across peering connections, transit gateways, over direct-connects and site-to-site VPNs and also works locally, within a VPC. The feature elegantly handles default and covering routes by suggesting specific routes from adjacent devices ensuring that the path drawn is as complete as possible.

AWS Configuration Status

One thing that has become clear over the last few months is that we need to continue to strengthen our ability to quickly and easily onboard AWS flow logs and metadata. However, with the multitude of architectures we support and data + flow logs coming in from tens or sometimes hundreds of different sources per customer, we never had a way to concisely convey the health of a customer’s Kentik implementation… until today.

The AWS Configuration Status page aims to make this easier by helping users get an at-a-glance overview of how complete (or incomplete) a customer’s AWS/Kentik configuration is. For each region that a customer has configured an export for, we extract the account ID, and display a high-level overview of the API and Flow status. Clicking on a row allows customers to get more details such as a listing of exactly which APIs our system requires and a success state for each. Warning messages are detailed and complete on the mouseover. Below the APIs, we enumerate the flow logs configured for each entity within a given account/region and flag any accounts that don’t appear to have flow logs configured such that Kentik could ingest them.

Search Feature for Kentik Map + Performance Monitor

Building a map for large customers with hundreds or thousands of accounts is definitely possible, but doesn’t always result in the most useful of visualizations. That’s why we added a search and filtering feature to both the Kentik Map and the Performance Monitor. This feature allows users to quickly find ‘needle in the haystack’ entities like VPCs, subnets, and gateways. Our search intelligently recognizes the format of each search string entered and builds a complex search query that can be saved for quick reuse.

Support for External ID

At the request of one of our customers, we’ve added support for External IDs in the API and S3 calls that we initiate to AWS. External ID helps protect our customers from “Confused Deputy” attacks that could allow our service to be abused by malicious 3rd parties to attack our customers. (We don’t believe that the access we request could ever be used in such a way, but better safe than sorry!) As this feature has become more front-and-center in AWS’ role configuration dialogs, we are glad to support this enhancement. The feature now injects a unique string per customer with each request that we send to AWS. This string is set to be the Kentik customer CID.