kentik Product Updates logo
Back to Homepage Subscribe to Updates

Product Updates

Latest features, improvements, and product updates on Kentik's Network Observability platform.

Labels

  • All Posts
  • Improvement
  • Hybrid Cloud
  • Core
  • Service Provider
  • UI/UX
  • Synthetics
  • Insights & Alerting
  • DDoS
  • New feature
  • BGP Monitoring
  • MyKentik Portal
  • Agents & Binaries
  • Kentik Map
  • API
  • BETA
  • Flow
  • SNMP
  • NMS
  • AI

Jump to Month

  • April 2025
  • March 2025
  • February 2025
  • January 2025
  • December 2024
  • November 2024
  • October 2024
  • August 2024
  • July 2024
  • June 2024
  • May 2024
  • April 2024
  • March 2024
  • February 2024
  • January 2024
  • December 2023
  • November 2023
  • October 2023
  • September 2023
  • August 2023
  • July 2023
  • June 2023
  • May 2023
  • April 2023
  • March 2023
  • February 2023
  • January 2023
  • December 2022
  • November 2022
  • October 2022
  • September 2022
  • August 2022
  • July 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • December 2021
  • November 2021
  • October 2021
  • September 2021
  • July 2021
  • June 2021
  • May 2021
  • March 2021
  • February 2021
  • January 2021
  • December 2020
  • October 2020
  • September 2020
  • June 2020
  • February 2020
  • August 2019
  • June 2019
  • April 2019
  • March 2019
  • February 2019
  • January 2019
  • December 2018
  • November 2018
  • September 2018
  • August 2018
  • June 2018
  • May 2018
  • April 2018
  • March 2018
  • February 2018
  • January 2018
  • December 2017
  • November 2017
  • October 2017
  • July 2017
  • June 2017
  • May 2017
  • April 2017
  • March 2017
  • February 2017
  • January 2017
  • December 2016
  • November 2016
  • October 2016
  • April 2016
CoreService ProviderAgents & Binaries
a year ago

Introducing Kentik's Newest Agent: Kentik BGP Proxy (kbgp)

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 benefit of using **kbgp** is:  - It is possible to perform the BGP enrichment of the flow data coming from internal network devices without global IP connectivity - The BGP data is secured and encrypted during the transfer from customer network to Kentik

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. 


Avatar of authorDušan Pajin
Agents & BinariesBETA
2 years ago

kbgp (Kentik BGP proxy) goes Beta

BGP enrichment to flow-collected telemetry from a Kentik user’s network was historically made possible via public peering of a Kentik registered device to Kentik’s public BGP cluster (or leveraging the BGP table from another, BGP-peered device).

However, there are situations where devices exporting flow telemetry to Kentik cannot reach the public internet (e.g., have no public IP address for a BGP session with Kentik).

Enters Kentik’s BGP proxy, aka kbgp.


What is kbgp ? tl;dr

Kentik BGP proxy, aka kbgp has just been released in its initial beta version. It can be deployed in a private environment — upon deployment, the aforementioned devices will be able to peer with the kbgp instance which will multiplex and relay in real time, all BGP updates “as if” these devices were peering with our public BGP ingest layer.

Initial discussions took place around making kbgp a part of kproxy, Kentik's well known flow proxy. There's a variety of pros and cons, but for now, the main deciding factor was separation of concerns: the BGP and Flow proxy functions being fundamentally different, we wanted to avoid building a monolithic agent that would instantly become a single point of failure and also avoid situations where flow export could be interrupted by the BGP portion and vice versa. 

How does kbgp work ?

We are pretty proud of the design behind kbgp — a lot of engineering forethought was put into it and the early testing customers have been impressed with the polish, stability and scalability of this early version and are already starting to adopt it quickly.

Multiple Kentik registered devices can peer with a single kbgp instance, as it is highly scalable and takes care of all the multiplexing over a secure gRPC transport. Kbgp will not store BGP state to remain the least intrusive possible and will just manage state of the peering sessions established with it, as well as forward in real time, any BGP updates directly to Kentik.

This offers a few additional side benefits:

  • kbgp scales very well (since there’s no storing of routes) and can accept peering sessions from a lot of devices — the max # BGP sessions per kbgp agent is yet unknown, make sure not to create a single point of failure.
  • The transport that was chosen back to Kentik's BGP ingest layer offers a layer of encryption over the public internet to relay the BGP updates — it is an added benefit offered by gRPC.
  • A great side benefit is that it unlocks IPv6 BGP peering (and therefore BGP related enrichments to IPv6 flows) without the need of establishing a public IPv6 BGP session. All that’s needed is an internal IPv6 address to peer with from the device, and the updates will be transported by kbgp using IPv4.

What comes next / How can you gain access to it?

As any Beta software, kbgp comes with a few rough edges, but our closed-beta testers have so far been very positive about it.

Contact your Customer Success Engineer if you want to get access to the agent and deploy it on your system, our engineering team is ready to welcome your feedback to make it better !

As we build kbgp's roadmap towards a GA, more features will be added to upgrade kbgp so that you can manage it more efficiently, this will likely include things such including it as a first class citizen in Kentik Portal, reporting the health of its host and the BGP sessions it proxies ... Stay tuned !

We may in the future consolidate kproxy and kbgp into a single binary, but to avoid each function competing for resources on the host and prevent the resulting agent from becoming a single point of failure, we may very well favor a mutually exclusive switch, turning the agent into one or the other. 
Don't hesitate to let us know what your thoughts are on this.

Avatar of authorGreg Villain
SyntheticsAgents & Binaries
2 years ago

Synthetics: 17 new Global Agents in Lumen (AS3356)

We're happy to announce the availability of 17 new Global agents, distributed globally (8 Americas, 5 EMEA, 4 APAC) and connected to Lumen's network (AS3356). Stay tuned for even more geo locations within Lumen's network!


Avatar of authorAnil Murty
SyntheticsAgents & Binaries
3 years ago

Synthetics: Introducing "Broadband Agents" in 11 ISPs

We're excited to announce 16 new Global Agents distributed globally and located in several major Broadband ISPs: AT&T, Altice (Suddenlink), Cox, Comcast, KDDI, SK Broadband, Spectrum (Charter), Vectra, Verizon and Vodafone



Avatar of authorAnil Murty
ImprovementSyntheticsAgents & Binaries
3 years ago

Synthetics: Private "App Agent" now available

Kentik continues to expand the agent fleet for synthetics, giving users more flexibility and locations from which to originate tests.

App agents, which until now were only available as global agents, can now be deployed as a private agent. App agents differ from network agents in that they support both network and web layer tests.


With private app agent support, customers can run network and web layer tests from within their environment. For example, customers can run Page Load tests to measure the performance of key websites from their branch or data center locations or any location they can install a private agent. In addition to web performance metrics, they can also collect network performance metrics — loss, latency, jitter, etc., to these destinations, with an app agent.

The app agents are initially targeted towards supporting new web layer test types (Page Load and transaction tests) but they are able to run all test types so users that want to install a single agent for all test types can use the app agent. The app agent can be deployed using Debian/Ubuntu, RPM or Docker packaging.

The agent will be marked beta as we continue to collect usage data/feedback from users. We recommend the existing network agent for non-web layer testing.

The Private Agent Setup now allows the selection of app agents (beta)

Read the Knowledge Base entry for Kentik App Agents.

Avatar of authorAnil Murty
CoreAgents & Binaries
4 years ago

Kproxy Enhancements

This January, we introduce the 1st round towards a better way to manage your fleet of kproxy agents.
You can deploy kproxy agents to secure the network telemetry data between your own devices and Kentik's public Flow/SNMP/BGP ingest front-doors, configuring your routing gear to ship this data to a kproxy instance in your network, which will relay the resulting multiplex securely to Kentik's SaaS Clusters.
More information about kproxy here in our knowledge base.


Kproxy is now a first-class citizen in the portal, i.e. it comes with its own Settings screen. This screen comes with the following elements:

  • Ability to name and locate your agents in sites that you've configured for other routing devices, and set flow listening IP (mostly useful for config snippets)
  • A new onboarding path that will let users deploy a kproxy instance in the first touch experience as a first step in the flow-generating device provisioning first touch onboarding flow.

    • The onboarding flow, as well as the modal from the Flow Proxy Agent screen in Settings now displays updated instructions to deploy kproxy both in an ad-hoc manner as well as using the industry-standard systemd service manager.
  • The updated deployment method for kproxy now alleviates the need for user-specific API credentials to launch a kproxy instance. Company-global credentials are provided in the instructions, whether in onboarding or on the kproxy settings screen.
  • Multiple screens in the existing Kentik UI have been updated to reflect a flow device’s dependency on kproxy as follows:
    • The Network Explorer Device Details page, in the “More Info” section
    • The Settings > Device page with its device details drawer

Note that existing kproxy-based users will see their kproxies show up in the UI without the site, name and IP metadata associated with them. These can freely be updated as suggested by the UI.

Avatar of authorGreg Villain
ImprovementCoreAgents & Binaries
4 years ago

Kproxy Custom DNS Option

In lieu of using Kentik’s on-the-fly reverse DNS, customers can leverage kproxy and have it query their own DNS and insert rDNS values into the Kflow data. Among other things, it allows resolution of private IPs reverse DNS, but the initial tradeoff was that it cost customers two of their own custom dimensions. Upon rollout of this feature, native Kentik dimensions will be used.

How can I use this feature?
The following Knowledge Base Article will help you configure kproxy to perform this task.

Avatar of authorGreg Villain
CoreNew featureAgents & Binaries
4 years ago

Introducing Kentik Firehose

The Kentik Network Observability Platform provides the most comprehensive data across all public, private, and hybrid networking environments, including flow records, streaming telemetry, SNMP data, device configurations, and synthetic performance metrics. 

With Kentik Firehose, you can now send all this data from Kentik into your application monitoring tools (e.g., New Relic, Splunk, InfluxDB, Elasticsearch, AWS S3, etc.), and publishing platforms (e.g., Kafka, AWS Kinesis, Google Pub/Sub, etc.).

For further information see the Kentik Firehose Solution Overview. 


Firehose closes the network observability gap and lets you uncover insights, and effectively troubleshoot your apps with full context and data about your networks included in the tools you use.

Firehose exports enriched network traffic data to your analytical systems

Examples of exportable data include:

  • Flow data from NetFlow, sFlow, IPFIX
  • VPC flow logs from all major public clouds
  • Streaming telemetry from all major vendors (Juniper, Cisco, Arista)
  • SNMP device metrics (CPU, memory, network interface)
  • Synthetic measurements
  • Internet, ISPs, CDNs
  • Correlated and context enriched data from the customer’s application, infrastructure, geo-location, business environment, and other customer-defined dimensions

Data formats include:

  • Output formats: JSON, NetFlow, AVRO, InfluxDB line protocol, Prometheus endpoint
  • Compression algorithm: none, gzip, snappy, null, deflate
  • Data sinks: .Net, Kafka, Kentik, stdout, file, New Relic, HTTP, Splunk, and more coming
  • Rollups groups: type, metric, dimension 1, dimension 2, …, dimension n.
  • Filters: string, src_addr, ==, 12.0.1.2

Customers are using Kentik Firehose to:

  • Troubleshoot performance in complex application environments. Network data from Kentik allows teams to understand application performance in context.
  • Combine network and infrastructure data all in one place for analysis and storage. IT teams use Firehose to send data to other systems like data lakes, with formats like JSON and AVRO. This data enables more cost-effective storage and the ability to perform complex analysis, with the data all in a single place.
  • Enhance cross-domain analytics to detect threats. Security and risk management teams can correlate Kentik’s Firehose data to rapidly detect, analyze, investigate, and actively respond to threats. Using data like geolocation and network flow allows for a better understanding and easier identification of threats.


Avatar of authorDušan Pajin
ImprovementAgents & Binaries
7 years ago

Agent Improvements: kprobe

Back in October we launched kprobe, our improved host agent software that can be deployed anywhere (in your data center or in the cloud) to gather all kinds of useful data from real traffic on your hosts. We’ve been steadily enhancing kprobe ever since; this month we have a new release that includes a couple new CLI parameters:

  • –status-port gives you the ability to check the status of the agent by defining the port to listen on.
  • –status-host enables access beyond the localhost IP address (127.0.0.1).

Once the new parameters are configured, you can point your browser to http://host:port/v1/status to get a JSON output of the status.

{  
 “flows-in”: {  
   “count”: 953,  
   “1m.rate”: 4.297123404852097,  
   “5m.rate”: 2.286167148965094  
 },  
 “flows-out”: {  
   “count”: 953,  
   “1m.rate”: 4.297123404852097,  
   “5m.rate”: 2.286167148965094  
 }  
}

For more information on installing and configuring kprobe, check the Knowledge Base (KB) article on Host Configuration.

Avatar of authorGreg Villain
ImprovementAgents & Binaries
7 years ago

Cloud Aware kprobe

This month, our kprobe agent got a couple of updates to make it easier to adopt in a “cloud-native” environment. Let’s take a look at what we mean by that:

In cloud deployments there is often a load-balancer that is front-ending a cluster of application server instances. An example diagram is below:

cloud-load-balancer-454w.png

The load-balancer is accepting the HTTPS (TCP port 443) connections and then forwarding the requests to a number of cloud instances. In this type of setup, users typically look at Kentik Detect to get the sum of all HTTPS traffic handled by the instances behind the load-balancer. The ‑‑translate command line option of kprobe now allows you to map the load-balancer IP/TCP:443 to the instance IP/TCP:8080 on each of the instances.

Another cloud deployment trend is VMs being created on the fly using things like auto-scaling or stale instance killer where kprobe needs to be included in a custom image and started with each new cloud instance. This requires that the configuration of kprobe be independent of the VM hostname, IP address, or Kentik device ID. To accommodate this, we have added a couple new features:

  • Kentik Detect Plans now have an “Active Device” count, in addition to the existing “Total device” count. When kprobe first communicates with Kentik Detect, if active count < total count, a new device will automatically be registered. To facilitate this, a new command line argument: ‑‑device-plan option has been made available.
  • If ‑‑device-name isn’t specified, the instance’s hostname will be used, otherwise it’ll be overridden by this flag and appear in the Kentik Detect platform with this name.

To learn more about the current kprobe startup options, check out our Knowledge Base article.

Avatar of authorGreg Villain