CH logo® Knowledge Base
Contents Search
   

 

Kentik Quick Start

Onboarding with Kentik Detect involves first adding additional users (if needed) and devices via your Kentik Detect portal, and then configuring those devices (routers, hosts) to export flow. Then you’re ready to start viewing data in the portal, making queries in SQL, and creating alerts. These basic steps are detailed in the following topics:

 

 
 top

Add Users

When you sign up for Kentik Detect, you’ll create your first (admin) user. If needed, use the Add Users page of your Kentik Detect portal to add more users (see Add or Edit User).

 

 
 top

Add Devices

Kentik Detect collects flow records from devices (routers, hosts, etc.) for ingestion into the Kentik Data Engine (KDE). To receive flow from a device, that device must be registered with Kentik Detect, which involves the following:

  • Each device to be registered must be configured to send flow to Kentik Detect; see Configure Devices. We recommend that you review the configuration process for your router/host prior to registering it with Kentik Detect.
  • If you’ll be encrypting flow data to send it to Kentik Detect, you’ll be working with chfagent, our NetFlow Proxy Agent.
  • Each router that will send data directly to Kentik Detect (rather than via an agent) must also be configured with the ingest IP, ingest UDP port, and SNMP polling IP information provided in the Add Device dialog in Admin » Devices (see Device Config Info).
  • Each device must be registered with Kentik Detect using the Add Device page of the Kentik Detect portal (see Add or Edit Device).

To complete device settings for a router or switch, you will need to know the following:

  • The flow protocols (NetFlow, IPFIX, sFlow, etc.) supported by that device.
  • The desired flow sample rate. A rate of 8192 means that the device sends traffic metadata to Kentik Detect for one of every 8192 flows or packets (depending on the device). For best results, follow the sample rate guidelines in Flow Sampling.

Note: For assistance walking through this process please email support@Kentik.com.

 

 
 top

Configure Devices

Adding a device in the Kentik Detect portal creates a place for that device’s data in the Kentik Detect system, but the device itself must also be set to send flow records to Kentik Detect. The steps involved vary depending on the type of device (e.g. router or host). Refer to the following articles for further information:

 

 
 top

View and Query Data

Once a device is configured to send flow data to Kentik Detect you can view that data in a variety of ways in the Kentik Detect portal. The portal provides various views for graphing and drilling down into the data:

  • For ad-hoc querying of traffic data, using multiple dimensions and filters to show source, destination, performance, etc., see Data Explorer.
  • For continually updated customizable real-time views of any aspect of traffic data, see Dashboards.
  • For in-depth analysis of routing and peering, see Peering Analytics.

 

 
 top

Use SQL and APIs

In addition to queries that are built automatically by Data Explorer in the Kentik Detect portal, Kentik Detect also enables the creation of custom queries using either of the following additional approaches:

  • Kentik’s query language (a subset of SQL), which can be used to access your Kentik Data Engine (KDE) database via a command line interface (e.g. Terminal) or a database management application. The Query Editor view in the Kentik Detect portal includes a number of readymade queries that can serve as a starting point for experimentation with query modification and displays results either graphed or in rows.
  • Kentik’s V5 APIs provide RESTful access to your database via HTTP methods (GET, PUT, POST, DELETE):
    - For documentation, see About the V5 APIs.
    - To experiment with the API, see the V5 API tester.

 

 
 top

Set Up Alerting

Kentik Detect includes a policy-based alerting system to identify anomalous traffic conditions, including DDoS attacks, notify you of any traffic condition that you define in an alert policy, and, optionally, apply mitigation. The policy-based alerting system is built around alert policies that define the conditions in which an alert will enter alarm state and the actions (notification and/or mitigation) that result. To set up policy-based alerts, see Policy Alert Overview.

Note: Our SQL-based alerting system is now deprecated and can be accessed only by organizations that have existing SQL Alerts (see SQL-based Alerts).
 

In this article: