We are halfway through the first quarter of 2018 and once again we have a bunch of exciting new updates to Kentik Detect® to share with you. As mentioned in previous updates, a lot of development work these days is focused on ease of use for both technical and non-technical users. But we also made improvements to security and network performance management (NPM) and added a few new features. Let’s take a look…
You asked for it, and we added it. Kentik Detect now supports AES in addition to DES for SNMPv3 encryption (also referred to as Privacy Types). To add a new device using this method:
For more information on configuring SNMPv3 authentication, check out our Knowledge Base article.
The latest in our ongoing efforts to ensure the security and privacy of our customers’ data, is support for two-factor authentication (2FA) using a hardware YubiKey. This new user authentication method can be enabled by clicking on your name in the upper right-hand corner, selecting My Profile and clicking the Enable YubiKey button in the Authentication section of the My Profile dialog.
This will bring up the Register YubiKey dialog. Touch your YubiKey to fill the pane with a code and click on Finish Registration. You are now setup to start using your hardware key as an authentication method.
As regular users of Kentik Detect may have already discovered, we gave the Device List table on the Devices page (Admin » Devices) a makeover. We have added a button at the top that can be used to toggle between Device Stats and Device Details views.
The information on the Device Stats view remains the same, although better organized. On the Device Details view we have added Interface Classification, CDN Attribution (shows a check if the device is configured to participate in CDN Attribution feeds), and Plan & Site to give the user more details about the device at a quick glance.
For more information about the redesigned Device List views, check out our KB article.
We have released a new version 0.8.6 of our host agent, kprobe. While not particularly noteworthy by itself, this new version adds a couple new features to the Kentik Detect solution:
First Payload Exchange Latency (FPEX) metric: This new metric measures application response time. After the TCP session is setup, this measures the time between the first request packet and the first response packet. This is especially useful for applications which Kentik cannot decode (HTTP and DNS are currently decoded). You will find this new metric in the Metrics drop-down menu in the Query pane of the Data Explorer sidebar (Data Explorer » Explorer View).
It can also be used in Multi-Metric mode by click on Customize Metrics in the Query pane. You will find the FPEX metric at the very bottom right-hand corner of the Metrics dialog.
At Kentik, we strive to get all of our customers as close to 100% Interface Classification coverage (more on Interface Classification via our blog post or KB article) as possible, where we find they get the best accuracy from this feature. In keeping with this, we have added a new General Settings pane in the Configure Interface Classification screen (Admin » Interface Classification » Configure Interface Classification), which allows the user to simply discard specific interfaces from the rules computation instead of configuring a default matching rule. In this pane, you will find the following:
The first two settings can be evaluated as AND or OR operations by changing the selector between them. The final setting is always evaluated as an AND operation.
Quite a few of our customers use Kentik Detect to answer questions about how much traffic is being sent to and from the networks they are directly connected to (transit providers, private peers, public peers, Internet Exchanges, customers, etc.). To make this task a lot easier we have removed the need to use a Custom Dimension (more details on Custom Dimensions can be found in our KB article), and we’ve introduced a new feature called Provider Classification as part of our existing Interface Classification feature discussed above. This feature matches a string in the interface description and sets the provider name using one of two methods:
Static: This method uses a static, plain-text provider name for interfaces that match. To use this configuration on an existing rule, click on the rule within Interface Classification and fill in the Provider text field in the Then pane. In the pictured example, we are matching on “IX” in our interfaces description and setting the provider for any of these interfaces to “cyrusone” (NOTE: provider names are converted to all lowercase to avoid duplications).
Regular Expression (RegEx): For more complex matching and classification, we support RegEx Capture Group Notation. This method allows for matching using RegEx and extracting the provider name using the RegEx Capture Group Notation. In the pictured example, our group is extracting the word that comes after “TO-” and using that ($1 refers to the first group extracted) as our provider name.
Once you are happy with your RegEx configuration, click on the Test Rule button to see what is matching. You should get a list of Device Matches list the one pictured.
The rows with blue in the bar and a non-zero number in the blue background have interfaces that were matched by the tested rule. Click on one of those rows (e.g. pe1_ord1) and you can see what interfaces matched and what provider was pulled out of the interface description.
To exit this screen and return to your rule, click the X in the upper right-hand corner.
Once you are confident you have matched what you expected, click the Save button to return to the main Interface Classification Screen. Your updated rule will be displayed with the RegEx matching and Provider group:
For more information on Provider Classification, be sure to check out our KB article.
Speaking of Interface Classification (IC), we made it even easier to find which interfaces in your account are not being classified based on your existing rules. In the Classified Devices pane on the right side of the Interface Classification screen (Admin » Interface Classification) you will now see a View X Unclassified Interfaces button like the one highlighted on the right. Clicking this will bring up the Unclassified Interfaces dialog like the one below that shows a list of all the interfaces in your account, by device, that have not matched one of your IC rules.
We have now added the ability to get a Total Overlay line in a Time Series Line Graph in the Data Explorer. In the Data Explorer:
In last month’s product update we announced Gauges Visualization that supports Bracketing to change the background color depending on user-defined thresholds. We have taken this a step further and extended the Bracketing capability:
We have added multiple methods for the bracketing threshold computation:
Amongst others, it will:
All of these are displayed in the example below:
For more information on using Bracketing, head on over to our Bracketing Pane Setting article in the KB.
Adding on to last month’s announcement of Multi-Metric, the user can now set a minimum threshold that must be reached for a data point to appear in a chart or table. In the Metrics dialog (accessed by clicking on the Customize Metrics button in the query section of the Data Explorer sidebar), you will see a new button in the Selected Metrics selector which is highlighted in the graphic to the right. This will bring up a Set Minimum Threshold dialog. Once you have input the threshold minimum you want to see, the button in the Selected Metrics selector will change from grey to orange so you know a threshold is set.
This is a common ad-hoc data filtering tool in the realm of BI tools, often referred to as a ‘Noise Suppressor’ because it will help weed out any background noise from the actual signal useful to the user.