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).
Some users may have noticed an explanation mark in the Admin sidebar next to Interface Classification or Network Classification.
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.
Speaking of Interface Classification, we have made an improvement here as well. Some of our users have mentioned that they have strict rules in place on how they allocated interfaces on the routers and switches in their network. For example, they might put all the core-facing interfaces on the first linecard and all the edge-facing interfaces on the second linecard. For most major vendors, this gives a consistent naming convention to the interfaces (e.g. xe-0/0 for core and xe-1/0 for edge). Giving our users what they want, we have added support for Interface Classification (more information on IC is available in our KB article) based on the name of the interface, including all types of matches: equals, contains, matches Regex.
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.
One additional change that users may notice is a Description field in the add/edit panel dialog. The description entered here, will appear as a mouse-over popup when viewing the dashboard panel. This allows dashboard creators to deliver more context for each panel.
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.
Changing the direction of a filter in a query just got a whole lot easier. In the Ad-Hoc Filter Groups pane of the Filtering Options dialog, there is now a button for Invert Perspective. In this example, clicking the button would change our filter to Source AS Number.
We now support the ability to quickly remove an active saved filter. In the Filtering pane of the Data Explorer sidebar, clicking the X next to an item listed in the Saved Filters section will remove it. Don’t forget to re-run your query by clicking the blue Run Query button at the top of the sidebar.
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-planoption has been made available.
‑‑device-nameisn’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.
Seeing the raw flow data that your device is outputting can be a great troubleshooting tool. To that end, we have implemented a new feature called Raw Flow Viewer (Analytics » Raw Flow) that allows the user to see their raw flow records without having to build a complicated SQL query. Keep an eye on future product updates as we expand this functionality to allow for CSV export of this data. Formal documentation in our KB is forthcoming but until then here is an example of how one might use this feature.