It’s hard to believe it, but we are already wrapping up the first quarter of 2018. As usual, our development team has been hard at work bringing you, our customers, some new features and functionality. Let’s take a look at the latest…
We introduced quite a few Bracketing Enhancements in last month’s product update but the news doesn’t end there. This month, we added support for the following view types:
Additionally, we’ve refined the way Bracketing works by adding a couple useful controls based on popular demand:
For more detailed information on bracketing, check out our Bracketing Pane Settings Knowledge Base (KB) article.
Sankey Diagrams have historically required a minimum of two dimensions to be selected in the Group-By selector in the Query pane since this visualizations shows a “from” and “to” relationship. We have now relaxed this requirement for Destination BGP AS_PATH given the fact that this dimension has both a “from” and “to” relationship within it.
It is now possible to generate a series of charts based on the top-N matches for a query dimension. These panels are calculated dynamically at query time, not pre-calculated. For example, this is a set of generated charts showing the top sites for each CDN.
To get started using this feature, enable the Generate One Chart Per Series selector in the Advanced Options of the Query pane in the Data Explorer sidebar. You can choose how many columns you want and what level of visualization is used for these generated charts.
This feature can be used for configuring panels on a Dashboard — where it can be turned into an Interactive Dashboard (more on that below).
A lot of pre-configured dashboards rely on Interface Classification, Network Classification, and Provider Classification being configured by the user. Due to this, we now alert the user when a dashboard, or Data Explorer query for that matter, requires one of these configurations and it is not matching at least 80%.
As mentioned, a notification will also be present in the Admin screen. For more information on configuring these items, check out our Interface Classification KB article or blog, as well as our articles on Network Classification and Provider Classification.
As mentioned previously, Dashboards are becoming a central focus for Kentik Detect. To make dashboards more intuitive and easy to work with, we have made a few enhancements this month:
In the past, EDIT mode looked too much like VIEW mode, so we have now added a few visual clues to make it easier for the user to see at a glance which mode they are currently in.
We also created a much cleaner and easier flow for adding new panels or editing existing ones. You no longer have to switch between Data Explorer and the add/edit panel dialog. We now include the query sidebar and the resulting visualization right in the panel dialog window.
Another new feature we added is called Interactive Dashboards. This feature allows users to click on an item in a panel to get a filtered view based on that data item. The filter applies to all panels on the dashboard and can be seen by viewing the Filters pane in the sidebar.
This feature is enabled using the Cross-Panel Filtering selector in the add/edit panel dialog.
The following view types currently support Cross-Panel Filtering:
We will be adding support for the remaining view types in the near future. Keep an eye on upcoming product updates for more information.
This month, quite a bit of work also went into improving a few different areas of Kentik Detect’s filtering capabilities:
Interface Classification results in the following filter criteria being available:
These criteria can now be applied as Source or Destination meaning if either direction matches, the filter will apply.
For more detailed information on how to use filters in Kentik Detect, check out our KB article.
Kentik Detect’s powerful anomaly detection, alerting, and mitigation platform has gotten some improvements this month as well. Let’s take a look:
We have added support for nested filters in the alert policy dataset – similar to what has been available previously in Data Explorer’s sidebar. This is accessed from the Policies list (Alerting » Policies) by either clicking on an existing policy or clicking the blue Add Policy button. On the Dataset tab, you click on the Edit Filters button to bring up the Filtering Options dialog. For more information on configuring nested filters, check out our AdHoc Filter Interface KB article.
In our November Product Update we mentioned that we have added the ability to start a manual mitigation as opposed to triggering a one-off alert. We’ve now taken this a step further and added the ability to set a time to live (TTL) on the mitigation so it will automatically stop when the timer expires.
Our alerting system now supports escalating thresholds. A user can configure multiple Alert Thresholds with different criteria to trigger the threshold. As traffic matching the criteria increases or decreases, the appropriate thresholds will trigger. Different notifications can be tied to threshold level, but mitigation escalation is still under development. Stay tuned to future product updates for more details on that.
For more information on Kentik Detect’s powerful alerting system, check out our alerting KB articles or our recent blogs:
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:
‑‑device-plan
option has been made available.‑‑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.