Hey, Kentik community! 👋

Many of you told us that managing alerts can feel too manual, fragmented across tools, and noisy with unnecessary notifications. We've listened to your feedback and have expanded our capabilities to provide you with more granular control over your alerting environment with the launch of Alerting API v6! This new version is available through REST endpoints and gRPC RPCs, extending the existing Alerting API features. That means you can plug alerting directly into your existing workflows and systems, so automation and integration happen where you already work. Enable your teams with automation, cut down on alert fatigue, and gain clearer visibility into your mitigations with this new update. 

What's the Value?

These new capabilities provide you with unprecedented automation and control, saving you time and effort. With Alerting API v6, you can:

• Automate your incident response: Integrate Kentik Alerting with your existing tools to automatically create tickets, trigger scripts, or execute other actions when an alert fires.
• Enhance network visibility: Get real-time, programmatic access to the status of your alerts and mitigations, giving you a clear picture of your network's health.
• Reduce alert fatigue: Use the new silence and suppression features to fine-tune your alerting policies and reduce unnecessary notifications, so your team can focus on what matters most.

What's New?

The new V6 Alerting API is a huge leap forward, offering a comprehensive suite of new methods to streamline your alerting workflows. Beyond the ability to manage alerts, you can now programmatically control the entire alert lifecycle, from suppression to mitigation.

Here's a look at some of the exciting new features:

• List alerts or a single alert: Get a complete overview of all your alerts or drill down into the details of a specific one to investigate and troubleshoot.
• List policies: Pull a list of all your alerting policies to keep a pulse on what's configured in your environment.
• List mitigations: See all active, inactive, and failed mitigations to ensure your network is protected.
• List mitigation methods and platforms: Gain a full view of your mitigation infrastructure, including all available methods and platforms.
• Create a manual mitigation: Start a manual mitigation programmatically without needing to use the Kentik portal.
• Create, update, and delete silences and suppressions: Take control of alert notifications by creating, updating, or deleting silences and suppressions to prevent unwanted noise during maintenance windows or other planned events.
• Acknowledge and clear an alert: Programmatically acknowledge an alert to let your team know you're on the case and clear it once the issue is resolved.

Check out the  API Tester section of the portal to see all the new v202505 Alerting endpoints!  

One of Data Explorer's most advanced and clever features allows users to generate a set of time series, each based on a different set of filters: Filter-Based Dimensions.
Up until now, the Actions > Show API Call menu option would produce a query that wouldn't return the resulting time series but only the total metric value.
We have now backported this feature into our Query API for you to use.

What is a filter-based dimension?

Regular data explorer dimensions will only let you "break down" metrics by dimensions (think of it as a "Group By" on dimensions in the SQL world). Filter-based Dimensions were added to Data Explorer so users could consider slices of traffic that may overlap (and therefore where a "Group By" will not do the job), but that you'd still want to compare to each other within the same chart. With Filter-Based Dimensions, users can define as many time series as they want to be displayed, each one with its own independent filter, regardless to any potential overlap of the traffic slices for each filter.

A good example use for these is displaying subscriber traffic coming from different farms of servers without using a Custom Dimension to discriminate traffic from each farm - let's dive into an example.

• traffic from Farm-1 
  • comes inbound from devices with the compute label
  • on these two routers, it leverages interfaces with a description string containing farm-1
• traffic from Farm-2
  • comes inbound from Router-2
  • is sourced within the 1.2.3.0/24 CIDR

You can define two Filter-based Dimensions to identify traffic from these farms by creating two filters, one for each series which will be displayed in the chart

How can I get the API Call for a Data Explorer Filter-based Dimension query?

All you need to do is create your Data Explorer Filter-based Dimension query and proceed to Actions > Show API Call and a cURL query will be generated for you to use displaying the literal query to use in your code.

If we go back to our initial example, you'll notice that your Filter-based Dimensions are now fully described in the generated API call. 

"filterDimensions": {
          "connector": "All",
          "filterGroups": [
            {
              "name": "Farm 1",
              "named": true,
              "connector": "All",
              "not": false,
              "autoAdded": "",
              "filters": [
                {
                  "filterField": "i_device_label",
                  "metric": "",
                  "aggregate": "",
                  "operator": "=",
                  "filterValue": "21"
                },
                {
                  "filterField": "i_input_snmp_alias",
                  "metric": "",
                  "aggregate": "",
                  "operator": "ILIKE",
                  "filterValue": "farm-1"
                }
              ],
              "saved_filters": [],
              "filterGroups": []
            },
            {
              "name": "Farm 2",
              "named": true,
              "connector": "All",
              "not": false,
              "autoAdded": "",
              "filters": [
                {
                  "filterField": "i_device_name",
                  "metric": "",
                  "aggregate": "",
                  "operator": "ILIKE",
                  "filterValue": "Router-2"
                },
                {
                  "filterField": "inet_src_addr",
                  "metric": "",
                  "aggregate": "",
                  "operator": "ILIKE",
                  "filterValue": "1.2.3.0/24"
                }
              ],
              "saved_filters": [],
              "filterGroups": []
            }

The Connectivity Cost Edge workflow has gotten its initial Read API released: a proportion of our existing users were waiting on this API to better integrate Kentik with their own internal systems and I'm happy to report it is now live.
They can now, via the API, pull the summary monthly data for any month, from all and any of the providers they have configured.

See the API tester here:
https://portal.kentik.com/v4/core/api-tester/cost-v202308/swagger if you are a US SaaS customer, or here https://portal.kentik.eu/v4/core/api-tester/cost-v202308/swagger if you are an EU SaaS customer.

Today, we are adding a set of new endpoints related to various workflows in the Kentik Portal. 

Read on!

The first thing to know before we get into the details is that you can always access our API sandbox from the navigation menu here:

We have recently added a set of previously unreleased endpoints to our v6 API, all can be visible at the following URLs in the portal:

• https://portal.kentik.com/v4/core/api-tester/ on the US SaaS Cluster
• https://portal.kentik.eu/v4/core/api-tester/ on the EU SaaS Cluster

These new endpoints cover three main areas of functionality:

• Custom AS Groups CRUD functionality
  This new endpoint set only covers the management of these AS Groups. Ongoing work is scheduled for the Data Explorer Query API to be compatible with AS Group rollups, but the release date isn't yet set.

  

• Workflow APIs

  • for Capacity Planning
    The set of endpoints we’ve added to Capacity Planning is for now exclusively centered around viewing either a summary of all capacity plans or details of specific plans. 
    

    

    

  • for Kentik Market Intelligence
    This set of API endpoints allows users to either get any ranking with any Customer-base type in any market or get customers and providers of any given network in any given local market.

    
    

    

Important note
The sandbox shown in the article is the one of the v6 of our API. We still have a v5 API which still covers a large amount of legacy unmigrated endpoints - the testing UI for them is located here:
https://api.kentik.com/api/tester/v5

Several Kentik’s APIv6 endpoints reached the Stable Release status:

• BGP Monitoring API - Provides management and access to the data of the Kentik’s BGP Monitoring functionality.

  • Admin service: provides management of the BGP Monitor objects of the Kentik’s Synthetics product
  • Data service: provides access to the BGP related data collected from various Vantage Points used by Kentik. A user is able to retrieve data about the global IP BGP prefixes, like reachability, AS paths changed and routes for the particular timeframes.

• Cloud Export Configuration API - Provides management of the Kentik’s Cloud Export objects. These objects provide a relevant configuration for Kentik to be able to retrieve and export Flow logs and metadata from user’s Public Cloud infrastructure. The API endpoint provides configuration capabilities of these object and basic status information about the active export processes. Currently supports the following public cloud providers:

  • Amazon Web Services (AWS)
  • Microsoft Azure
  • Google Cloud (GCP)
  • IBM Cloud

• Label Management API - Provides CRUD operations of the Label objects, which are used to tags certain objects in Kentik, for example, devices, synthetic tests, and ksynth agents in order to create logical groups. This API endpoint is used to manage Labels, however, the application of a Label to a given object is done with the API corresponding to the type of that object.

  Object type	API for attaching labels
  Device	Device Apply Labels
  Synthetic monitoring test	SyntheticsAdminService API
  Synthetic monitoring agent	SyntheticsAdminService API
  BGP monitor	BgpMonitoringAdminService API

• Notification Channel API - Provides List and Search operations of the Kentik’s Notification objects. Each Notification channel includes a Type (e.g. email, Slack, PagerDuty, etc.) and a set of Targets (recipients). The use of this API is currently subject to the following limitations:

  • Creation, modification, and deletion of channels is not supported.
  • There is no support for the notification channels created in Kentik's “v3” portal.

The important characteristics of the Kentik Platform are rich API capabilities and the supporting SDKs. For the last two years Kentik has supported the development of the community Python SDK which is based on the Kentik’s APIs. This SDK enables our customers to use Kentik’s Platform APIs natively in the Python programming language, with Python Objects and Methods instead of dealing with the details of the API syntax.

The Community Python SDK is available on GitHub: https://github.com/kentik/community_sdk_python.

Just over a month ago, we released a new version 1.0.0. Until this version, the community Python SDK supported objects and methods that are exposed within Kentik’s REST API v5. With this new release, the support has been extended to some of the endpoints of our new gRPC-based Kentik API v6, specifically supporting Synthetics monitoring and Cloud Export configuration.

Important note on breaking changes

As it is already mentioned, Kentik’s API v6 is natively a gRPC API, but it also supports the REST access. The community Python SDK is using the Kentik API v6 directly over gRPC. To accommodate communication with the Kentik backend using both REST-based Kentik API v5 and gRPC-based Kentik API v6, the necessary change has been introduced that would require a change of your existing Python scripts and programs.

In most of the cases, you would initialize the KentikAPI object with the constrictor that is using the api_url argument, for example:

from kentik_api import KentikAPI

client = KentikAPI(api_url=KentikAPI.API_URL_US, auth_email=email, auth_token=token)

The api_url argument would expect the URL to the Kentik’s API endpoint, which would be in the form: https://api.kentik.com or https://api.kentik.eu. However, the endpoint that is used for the Kentik’s API v6 is in the form of the host, for example: grpc.api.kentik.com.

For this reason and to be able to configure API access information with the single parameter, it was decided that api_url argument of the KentikAPI constructor should be replaced with api_host argument. The argument is expected to contain only the fully qualified hostname of the server hosting the target Kentik API instance (the default value is KentikAPI.API_HOST_US which is equal to api.kentik.com). Consequently, the Class variable KentikAPI.API_URL_US has been replaced with KentikAPI.API_HOST_US and KentikAPI.API_URL_EU with KentikAPI.API_HOST_EU

To summarize, if you upgrade the version of your Python SDK to 1.0.0 or later, you will need for adjust the initialization of the KentikAPI to use the changed argument, for example:

from kentik_api import KentikAPI

client = KentikAPI(api_host=KentikAPI.API_HOST_US, auth_email=email, auth_token=token)

Installation

You can easily install the latest version of the Python SDK using pip, for example:

$ python3 -m pip install kentik-api

Let us know what you think about our Python SDK and feel free to submit any contributions or issues over GitHub. Happy coding!

My Kentik™ Portal is a built-in feature of the Kentik platform that enables curated, self-service network traffic visibility for downstream customers (solution brief here). Because we’re strongly committed to supporting features not only through our portal but also via APIs, we’ve now introduced the My Kentik API.

Providing an initial set of four methods, the My Kentik API enables Kentik customers to programmatically manage settings for their My Kentik Portal tenants. Development work is ongoing to achieve full parity with the functionality that’s available in the Kentik portal via the My Kentik Portal page.

The following methods are available now, and can be tested with the V5 API Tester for our US and EU clusters:

• Tenant List (GET): Returns an array that contains information about all tenants
• Tenant Info (GET): Returns a tenant object containing information about an individual tenant
• Tenant User Create (POST): Creates a tenant user object and Returns information about that individual tenant user
• Tenant User Delete (DELETE): Deletes a tenant user from the system

For more information, please see the My Kentik API topic in the Kentik Knowledge Base or contact our Customer Success team.

Last month, we announced VRF Awareness Phase 1, including new dimensions associated with VRFs (virtual routing and forwarding). We’ve now added support for VRF attributes in the Interface methods of our Device API, which you can experiment with in our API tester (EU customers will find the tester here). The new parameters for these methods give you programmatic control of VRF attributes associated with each interface.

If SNMP polling is enabled in your Kentik instance, the VRF attributes of each interface would normally be discovered automatically as Kentik polls the VRF MIB (refer to our KB topic on Kentik-polled SNMP OIDs to see the OIDs we poll). But with VRF support in our Interface methods you can now programmatically define or redefine mappings (including RT/RD related data) between physical interfaces and the VRFs to which they belong. This could be particularly useful in the following situations:

• If your Kentik instance doesn’t use SNMP polling.
• If you have SNMP polling enabled on your device, but either:
  • Your device doesn’t support the VRF MIB.
  • The device SNMP policy doesn’t allow polling the VRF OIDs.
• If you want your VRFs to appear in Kentik Detect with names that are more human-readable than the names retrieved from SNMP.

The new parameters in the Interface methods of the Device API support both of the following cases:

• Interface creation: VRF parameters have been added to the Interface Create method.

• Interface updating: VRF parameters have also been added to the Interface Update method.

For additional information, please contact our Customer Success team.

Both Custom Dimensions and Flow Tags allow you to label flow records based on criteria defined in advance and evaluated at ingest. As announced in the HSCD topic of our May/June 2018 Product Update, our backend engineering team has been hard at work re-engineering these systems under the hood to drastically increase their capacity, scalability, and agility. As of September, all Custom Dimensions natively support this increased scale.

As part of enhancing the usability of Custom Dimensions and Flow Tags, we’ve also added a new Batch API that simplifies management by enabling bulk loading of either Populators (for Custom Dimensions) or Tags. To help you get started, we’ve posted a Hypertagging API in GitHub that you can use in Python to call our Batch API. For additional information, please refer to the Batch API topic in the Knowledge Base or contact the Kentik Customer Success team at support@kentik.com.

In our November 2017 Product Update we mentioned that we have added the ability to start a manual mitigation as opposed to triggering one off an alert. We’ve now implemented this capability as an API and added it to the extensive list of REST APIs we’ve made available to programmatically manage Kentik Detect.

Our KB article contains more information and be sure to check out our API tester, which will help guide you on using this new method.