Kentik’s product and engineering teams continue to deliver the new capabilities and features that matter the most to our customers, driven by the valuable feedback that we collect. Here is a summary of new features as well more detailed descriptions and relevant screen captures.
We released a new set of agents that will enable tests at the application layer. These are what we’re calling “App Agents” and they are capable of running a full headless Chrome browser instance. These agents will enable us to offer our customers tests like Page Load tests and Transaction tests. When used in conjunction with our rich network layer functionality, these new agents and test types will allow network engineering and network operations teams to quickly determine if the issue is at the network layer or at the application layer.
We activated the Page Load Test type that performs a full browser page load using the new App agents.
BGP Route viewer is the first of a series of capabilities planned to help proactively monitor BGP-related conditions that can impact performance. In response to customer requests and feedback, we have developed a comprehensive roadmap for BGP monitoring, and we believe our solution will have significant performance advantages over alternative solutions.
The first part of Kentik’s solution is BGP Route Viewer. BGP Router Viewer appears as a tab along with the existing SaaS and Cloud Performance tabs. For customers who have entered prefixes in their Network Classification settings, we will automatically load BGP update data for those prefixes in this tab. For customers who have not entered any prefixes in their Network Classification settings, we will show an interface that allows you to do so and give you the option to save the entered prefixes to the Network Classifications page.
With the new Page Load tests, results can be plotted in a time series along with HTTP stages and the timing for each stage. This new view helps network teams isolate network layer issues from HTTP layer issues.
The (traceroute driven) path experience has been one of the most valued features of Synthetics and while it works well, we felt like we could go back and revisit the design holistically after having added a bunch of small and big features iteratively since it first launched (back in November). The updates we made can be summarized in two main buckets:
Here is a list of the main changes:
In response to customer feedback, we have added a new type of visualization option under Synthetics in the dashboards (library) portion of the product. One of the key use cases is customers who set up DNS servers by zones and want to see a global view of the performance of their whole DNS infrastructure.
We deployed nine new global agents throughout LATAM, improving our coverage in the region and increasing count from four agents to thirteen.
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:
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.
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.
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.
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.
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.
We added a service tracking workflow extension: OTT Service Capacity.
While working on adding this new functionality to the OTT workflow, information density has significantly increased, making the existing workflow harder to read. We have taken this opportunity to streamline it and reorganize content in it to make it clearer for users.
These screenshots illustrate the newly streamlined UX of the OTT workflow. We are now showing OTT traffic ranking in each category, where we initially only showed links to the different OTTs.
The engine classification rate which used to be a pie chart has also been reworked into a horizontal gauge to give more room to the actual usable data.
We have also reworked the OTT Service Details pages, not only to include OTT capacity, but also to better segment information in it:
This extension of the OTT Service Tracking workflow was designed to meet the following requirements:
We are now by default scanning the capacity for the top 100 OTT services for each customer and presenting the results in the Capacity tab of the landing page for the OTT workflow. Each treemap displayed on this page is a representation of traffic delivered by each interface (all devices included) and its utilization status.
The OTT service details page now also includes a tab for Capacity, providing an in-depth look at all devices and interfaces. The treemap shows all interfaces, and the list underneath is the list of devices involved. Each device entry listed below the treemap displays the contribution of its interfaces to the current OTT service and can be expanded to get details.
When expanding any device from the list, the user will see the details for each interface on the device involved in the delivery of this OTT Service.
Any interface within a device can also be expanded to display metric details around performance and the number of impacted users, taking into account the thresholds set for capacity in the workflow configuration.