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. 

Kentik's Cloud Performance Monitor is a great way to see at a glance the performance and accessibility of different services provided by AWS.

This month, we added support for Aurora and Lambda services. Customers may use the Cloud Performance Monitor to see the amount of traffic forwarded to and from these services. In addition to the traffic volume, customers can also see AWS service performance information, such as HTTP latency and status codes, if they deploy synthetic agents with tests targeting those service endpoints. Set up synthetic tests that target Aurora and Lambda service endpoints to see performance information similar to what is shown below:

Note: The Cloud Performance Monitor page is dynamic and shows only services actively communicating with your cloud deployment. If your account doesn’t show these new services or the services pictured in the screenshot above, that’s likely due to a lack of traffic towards those services in your environment.

Google Cloud allows customers to configure sampling rates at the flow records generation point on a per-subnet basis, which can significantly reduce the cost of flow log generation.

The Kentik portal now displays the average sampling rate for each exporter and the number of subnets configured with sampling. This is not a configuration knob, but a value configured on the Google Cloud dashboard. The inclusion of this data in Kentik Cloud provides a quick way for users working multi-cloud environments to consume sampling rate information.

We are happy to announce the general availability of Azure Firewall logs as a datasource following its initial introduction in May.

Customers can consolidate flow records generation by using Azure Firewall as the primary source of flow information sent to Kentik. The ingest process is identical to the one used for NSG flow logs and requires customers to store records in their storage accounts.

Customers can filter traffic flows traveling through a particular firewall in the Data Explorer by using the “Logging Resource Category” and “Logging Resource Name” dimensions and then excluding NetworkSecurityGroupFlowEvent (NSG flow logs):

Note: Azure Firewall flow logs don’t have traffic throughput information, so users must choose flows/s as the metrics instead of bit/s. This will create a visualization similar to the graph shown above, and allow Kentik to see flows going through the firewall. With these metrics, customers can determine the relative load of the Azure Firewall and attribute flows to the firewalls.

For customers seeking traffic throughput information from Azure Firewall Logs, the Azure team has advised using “Fat Flows”. However, at the time of publishing this announcement, the Fat Flows feature is in preview and unavailable for API ingestion. Once it is fully supported in the API, Kentik will add “Fat Flows” support.

To simplify troubleshooting workflows in Google Cloud, we've added several new details to the Kentik Map for Kentik Cloud. In the Cloud Network Details sidebar, we've added support for displaying the Firewall Policies that apply to each VPC. We've also added support for displaying details about the Load Balancers deployed in each VPC.

The new Firewall Policies area complements the Firewall Rules area added in July 2023, which shows the actions taken by those rules—denied and allowed traffic—in the selected VPC. 

For troubleshooting, the VPC details sidebar is now the single destination for getting all information related to firewall actions and rules:

In addition, the Cloud Network Details sidebar now also contains detailed metadata about the load-balancers deployed in the selected VPC:

In the coming months, we're going to consistently streamline the Settings screen as you have known it.

Today, we're sharing the 1st iteration of this broader project – Organization Settings. Kentik users now have a new Organization Settings menu displayed next to User Settings at the top right of the navigation bar, making it easier and faster to manage company and organization-wide settings.

Let's start with what's new in the Organization Settings menu:

• Licenses moved from the top Navigation menu to this menu
• All of the additional links in this menu have been moved over from the Settings screen 
• You'll also notice that your Kentik Company ID (CID) is now mentioned at the top right of this menu

The User menu is right next to it and now looks like this – the entries are self-explanatory. User Name, Email, and your Kentik Portal User ID (UID) are now displayed in this menu.

Thanks to relocating many of these entries from the Settings page, the Settings page now displays a more streamlined and clean look. Additionally, we've created a dedicated section for all Alerting settings to be housed – making the page much more homogenous and easy to navigate for users. 

Let us know how you feel about these changes!