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:

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.