The Incident Log has been enhanced with some powerful new features.

The log now supports a time series stacked bar chart displaying the volume of alerts by alert severity. This enables users to quickly identify alerting trends over time.

The log also supports many new filtering options that allow the log and the stacked bar chart to be filtered by alert severity, alert status, test name, test type, label and agent (private/global).

When one or more filters are selected an indicator displays the total number of filters currently enabled along with the time range selection.

The selection is also persistent, so navigating away from this page will not cause the selection to be lost.

Finally, we will be collapsing the Performance Dashboard menu item into the Synthetics title itself. 

Clicking on "Synthetics >" will bring you to the (soon to be) newly named "Synthetics Dashboard"

The new Alert Policy editor introduces a common policy authoring experience for both Custom policies and DDoS policies. You can navigate here from the Policies page, or by selecting a template from the Policy Templates page to use as the prototype for a new policy. 

We’ve redesigned this experience to simplify configuring and enabling a policy to trigger alerts. The same configuration options apply for constructing both DDoS detections and custom alerts, and the workflow to configure these is the same. 

Configuring alerts can be complex, but constructing the conditions for alerts is both powerful and very flexible. We've done some work in this revision to accelerate and simplify the process of building a policy.

Let's start with navigation. There are four tabs in the policy editor; you navigate to each of them by selecting the heading at the top of the form.

You'll also notice a new "Summary" display on the right side of the page, to help keep track of values from other tabs as you work, and also to see and correct validation issues that arise. Clicking on validation issues will navigate directly to the tab where you can resolve the issue.

In the General tab, you'll describe the policy - naming it, and providing a description of your intent. This is also where you'll enable the policy to create alerts, or to silence it while it build baselines. This is also where you can specify a dashboard to display alerts triggered by this policy.

In the Dataset tab, you'll define the focused subset of data you're interested in evaluating. This is the data that will be examined and tested against the conditions that will be defined in the Thresholds tab.

The controls on this page are similar to the controls you're familiar with from the Data Explorer - defining sources of data, and the specific dimensions and metrics that will make up the information this policy will evaluate against each of the threshold defined in the next tab. This is also where specific filters can be applied to refine or exclude data that should not be evaluated.

You can read more detail about the dataset selection dialogs in the Kentik Knowledge Base article "Alert Policies" topic.

One new feature you'll notice here is that the content of this page has been simplified, compared to the previous release - and all of the more complex and detailed options have been moved into an expandable area at the bottom of the page in "Advanced Settings."

For most alerts, you won't need to change the configurations here, but they are available to advanced users for specific use cases.  Refer to the Knowledge Base for more detailed guidance on setting these parameters.

Moving to Thresholds, you'll see five tabs that define threshold conditions and actions for each of the five levels of severity.

Conditions describe when alerts will be triggered for this level of severity; you can define conditions for traffic volumes, presence in the top keys, capacity for an interface, or ratios between metrics. Ratio conditions are new with this release, and evaluate the relationship between metrics to determine a trigger for the alert.

Actions describe automated notifications or DDoS mitigations that will be executed when the alert is triggered.

Finally, the Baseline tab has been simplified to offer one of three presets. Each of these describes how baselines for threshold conditions are constructed.

In most cases, the Default preset will produce a useful baseline for most alerting applications. You can select "Express" to produce a baseline more rapidly, or "Precision" to build a more detailed baseline over a longer period of time.

In this tab, you also have access to the individual detailed configuration parameters through the "Advanced Options" area.

Finally - there are preconfigured Policy Templates you can access from the Policies page, or through the "Add Policy" dialog: 

Policy Templates are prototype policies you can copy and customize for your requirements. Selecting a policy template here provides the same Summary view of the values in the template to guide you make a useful selection.

This represents our initial body of work to simplify the Alerting workflow, and we hope you find these changes easier to work with. We appreciate that with each changes comes a learning curve, so we'll work to improve this area of the product incrementally. 

As always, please let us know what you think in the comments!

Building on the work to navigate alerts, we've modernized the Policies page and unified the view of DDoS and Custom policies into a single flexible browser. 

We're making use here of our new standard table layout with common controls, filters, and workflow navigation. This is where you'll find a list of your configured policies for custom volumetric and dimension based alerting, as well as your DDoS policies for detection.

Navigation to the Policies page is contextual; you can find Policies from the unified Alerting page, as well as from the "Configure Policies" link on the DDoS defense page. When you navigate from DDoS Defense, you'll land with the appropriate filter to see your DDoS policies.

We’re providing improved filtering and sorting options, and context specific navigation. You can easily determine the policies that are active, and the types of policies available.

 This page is your path to creating new policies, and modifying existing ones. 

You can also review pre-configured policy templates - prototypes you can use to quickly customize new policies for your environment. 

Bulk operations are supported here - select multiple policies to enable or disable a group of policies, or delete them. 

As with the other pages using this common table layout, some of the columns are sortable by clicking on the column header.

Let us know what you think in the comments!

This month, we are introducing a new experience for submitting product improvement feature requests for the Kentik platform.

In this completely new experience, anyone who uses Kentik can submit feature requests for product improvements, vote and comment on existing requests and get timely updates.

What’s New?

Navigation to the new feature request portal is found in the Contact Support window, where a link for feature requests will automatically open a new tab with the feature request portal.

This link will bring you to the portal dashboard where you can click “Make a suggestion” to open the feature request form. The feature request form consists of the problem you are trying to solve, a details section for in depth criteria for the feature request and a current workaround section (if applicable).

When beginning to type the request in the first open text field, if there are any existing feature requests that sound similar, they will show. From here, you can vote or add comments on any existing feature requests. Once your feature request is submitted any status changes that are made to the feature request will be emailed directly to you, so you can follow your request from idea to release.

Voting on Existing Feature Requests

One of the most impactful advantages of this new feature request system is the ability to go and vote on feature requests that already exist. Voting on requests can be done in two ways.

1. In the above paragraph it was mentioned that as you are typing a feature request on the submission form, existing feature requests that are relevant will populate. Clicking the ‘I want this’ button will cast a vote for that feature request without having to resubmit the same request.
2. On the dashboard landing page, there is a list of recently submitted feature requests. These can be read and voted on at any time by all members of the feature request portal.

Commenting is also available on existing feature requests. Dropping comments on requests with details to your specific use case is helpful for other Kentik users to ideate on how to use the Kentik system, but also incredibly helpful to know what feature requests are in high demand.

Feature Request Status Changes

As feature requests get submitted, they will be regularly evaluated by our teams. When feature requests change status, the submitter and all individuals who have voted or commented on the request will get an email updating them on the status change. This level of transparency is to keep those that need the new feature aware of when they can expect the work to be started and eventually completed.

Let us know what you think in the comments. Happy submitting!

Ensuring that DNS is healthy and working as expected is fundamental to the performance and availability of any network service.

Kentik's DNS Server Monitor and DNS Server Grid tests already allow users to monitor and alert on the DNS Resolution Time - an important metric to track to ensure that no delays are introduced at this step of the interaction.

We've now enhanced these tests with the ability to monitor and alert on the IP mappings returned by the DNS servers being queried. By specifying an allowed list of IP addresses we can alert when an unexpected mapping is returned.

The Allowed DNS Results field under Advanced Options allows users to specify the expected IP results. If the test returns an IP that isn't in this allowed list the test health will be marked as Critical and an alert is triggered based on the alert activation settings.

Websites and web applications rely on SSL certificates to demonstrate their authenticity to end users connecting to them. 

Whether the web application is one the customer owns themselves or one that they consume as a service from a service provider if the server certificate attached to the application expires or is invalid, users will not be able to connect to them securely. It is therefore important to monitor the health of these certificates and alert when one is about to expire or is no longer valid.

With the TLS Certificate Expiry Check feature we have introduced a new column in the Results page of HTTP(S) and Page Load tests displaying the server certificate’s expiry status and we've expanded test Health options to alert when the certificate is about to expire.

When the target website's certificate is valid we will display the expiry date of the server certificate as seen below.

When the certificate is invalid (or expired) we will display an error message indicating the cause of the failure.

Health options now includes the option to alert the user when the certificate is nearing expiry to prevent site outages due to invalid certs.

If the website's certificate is within the specified threshold the Certificate Expiry column values will be colored accordingly.

To disable all certificate checks, enable the "Ignore TLS Errors" switch under Advanced Options > General Options. This will remove the "Certificate Expiry" column in the test results page.

In previous releases we provided the option to include network layer data in web tests by enabling ping and trace route in HTTP(S) and Page Load tests. This allowed us to quickly correlate application and network metrics to identify the root cause of an application's performance or availability issues.

Expanding on our cross layer visibility we can now include BGP data in web tests as well. Allowing us to further improve the time it takes to identify the root cause of issues as originating in either the application, network or routing domain.

Where previously you would need to create a separate BGP Monitor test you can now examine the same BGP data in an adjacent tab on the results page itself. No need to jump between test views!

When included, BGP data will be visible as an additional tab in the test results page.

Putting it altogether, we can now analyze all layers of information relevant to a target application's health on the same screen, including

Application metrics and Network Ping metrics in the Results tab.

Network Trace metrics in the Path View tab.

To add BGP data to an HTTP(S) or Page Load test turn the switch to "Enable bgp monitoring" (disabled by default) and enter the necessary details as you would for a regular BGP Monitor test including health options for Allowed ASN(s), RPKI status and Reachability (Advanced Options). 

Refer to the KB for more details on configuring BGP Monitor tests.

GeoIP is one of the critical enrichments provided by our ingest layer to your Network or Cloud telemetry.

As our experience with GeoIP data has matured, we have realized that GeoIP datasets from commercial providers are most often strongly accurate for broadband/mobile providers; only moderately accurate for Content Providers, and not accurate at all for Backbone providers.

We have just rolled out an update to the Kentik platform that constantly augments our GeoIP records leveraging an extendable selection of datasets.

State of the GeoIP union

Originally, GeoIP was used to map source_IP and destination_IP from Netflow/sflow data in our unified, enriched flow record data structure, making City, Region and Country available as Flow Dimensions for querying.

Later in the life of the Kentik platform, these GeoIP mappings got used in the portal, under the hood, in a large number of areas, such as:

• In Synthetic testing; we compute the distance of a test based on the sum of the distances for all hops in the traceroute of a Network Test. If GeoIP is off for certain hops along the way, the distance will be incorrect, affecting our inference of the end-to-end latency when we compare it to the latency values obtained during the test.
• In Kentik Market Intelligence; we rank network providers in any market based on the amount of IP prefix space they get from their customer base (the more IPs, the higher the score). This means that the weight of a network can be overplayed or downplayed in the case of incorrect GeoIP data.

How did we fix it?

We initially relied on a simple system that takes in GeoIP data daily from our providers and reloads it into our ingest layer to constantly fetch the provider's updates, and apply them as soon as available.

When you as a customer would notice inaccuracies, we'd relay the evidence to our provider and they would surface them once blessed by their experts in a future update. We were not satisfied with the end-to-end time to satisfy customer requests for relocation so we built an override layer system to which we could feed both:

• Manually, by entering our own overrides
• Programmatically, by using additional external trusted datasets

We landed on a modular and layered architecture below, that does the following with each daily run:

1. fetch the provider GeoIP Dataset
2. overlay our own overrides based on their respective precedence/priority
3. generate a resulting GeoIP custom Dataset
4. swap the dataset on the fly on our ingest memory datastore as part of the daily job

Leveraging your SNMP data

Network Devices exporting flow data to Kentik can have SNMP enabled on them and fed to our ingest. One of the MIBs polled by our SNMP service is the interface MIB. With each poll, we get all interfaces for the network element and the configured IPs on these interfaces.

As part of our enrichments, our customers also declare their network elements in Sites, so they can later query telemetry data by site. The bonus is that users submit an address that we translate in Geocoded data so we can place sites on a map.

Every day, we scan the entire partitions of IP addresses learned on each device via SNMP, and for each public IP address, we associate it to the Geocoded data of the site, which contains the network element, which contains the public IP address.

This is a somewhat unique dataset that no GeoIP provider out there has at their disposal. We now leverage it daily as a "Layer" of overrides superseding this base GeoIP dataset from our provider. 

Benefits for our customers

As of now, if you ever notice an inaccurate GeoIP mapping when using Kentik, we have reduced the time to correction by as much as 15x: while the typical back and forth process with the GeoIP provider would potentially take 15 days (we vet, then the GeoIP provider vets, then slots it to their next synchronous release).

Today, we are able to add an override to our GeoIP system immediately after we have vetted the evidence you submit, cutting this turnaround time to one day or less.

For critical updates, we can even have the engine recompute a complete map on demand.

As of today, our public link sharing capabilities got extended to now include dashboards.

As displayed in this recent update, you can try the feature on a dashboard with the new Share console that appears when you click on the top-right share button:

The new Share console as displayed from a dashboard will look like so, where you can easily change the human-readable URL, rope in email recipients to share it with (including an explanatory message)

And here's a sample example of a publicly shared dashboard:

Why don't you play around with the feature and show us some of your most eye-candy public dashboards ?

We've enhanced the synthetic library widgets to include a scrubbable health status bar! 

While previously the widgets displayed results of just the last test run executed, this enhancement allows you to scroll back and forth to review the results historically on the widget itself without having to jump into the test page itself. This will aid in reducing the Mean Time To Identification (MTTI) of network or application issues.

The health status bar is available for all single test synthetic widgets.