Metrics Overview

The metrics used in Kentik Detect queries are discussed in the following topics:

Notes:
- Additional information about some metrics (e.g. Per-flow Metrics may be found in Dimensions Reference.
- In addition to being used for settings in the Kentik Detect portal, metrics are also used for the Query API.

 

 
 top

About Metrics

A metric is a combination of a unit (e.g. a bit) with a method of calculation (e.g. average per second) to create a quantifiable measurement (average bits/second). In Kentik Detect, metrics represent measurements made on flows, which are used for counts, rankings (e.g. in a top-X list), and thresholds (e.g. in alerting). The following table shows the main places in the Kentik Detect portal where metrics are specified and used:

Portal location Primary Metric Secondary Metric
Library » Dashboards: Add View Panel or Edit View Panel dialog Query tab » Query pane, either:
Metrics field
Customize Metrics » Metrics dialog (see Metrics Dialog).
Query tab » Query pane » Customize Metrics » Metrics dialog.
Data Explorer: Sidebar Query pane. Sidebar » Query pane, either:
Metrics drop-down (see Query Basic Options).
Customize Metrics » Metrics dialog.
Sidebar » Query pane » Customize Metrics » Metrics dialog.
Alerting » Policies: Add Policy or Edit Policy dialog Dataset tab » Data Funneling pane » Primary Metric drop-down. Dataset tab » Data Funneling pane » Secondary Metric field.

 

 
 top

General Metrics

General metrics are metrics that aren’t specific to a particular device, such as a model of router. The general metrics that are available in a given setting such as the Metrics Selector in the Data Explorer sidebar (see Query Basic Options) vary depending on the category of the device (Router or Host; see Supported Device Types) as well as the specific device type.

Note: In addition to the metrics generally available from generic Router and Host devices there are also some metrics available from individual specific device types, which are covered in Device-specific Metrics.

 

 
 top

Metrics from All Devices

If the traffic being queried comes only from devices in the “Routers” category then metric options include only the following (for descriptions of the KDE columns from which metrics are derived, see Metrics Columns):

Metric in portal Variations Calculated as... Derived from KDE column(s)
Bits per second Sampled at:
- Ingress and Egress
- Ingress
- Egress
- Average
- 95th Percentile
- 99th Percentile
- Max
- Total
in_bytes,
out_bytes
Packets per second Sampled at:
- Ingress and Egress
- Ingress
- Egress
- Average
- 95th Percentile
- 99th Percentile
- Max
- Total
in_pkts,
out_pkts
Flows per second N.A. - Average
- 95th Percentile
- 99th Percentile
- Max
- Total
Based on rows per KDE main table
Source IPs - Unique Count
- Bitrate per IP
- Average
- 95th Percentile
- 99th Percentile
- Max
- Total
inet_src_addr
Destination IPs - Unique Count
- Bitrate per IP
- Average
- 95th Percentile
- 99th Percentile
- Max
- Total
inet_dst_addr
Unique Route Prefixes - Source
- Destination
- Average
- 95th Percentile
- 99th Percentile
- Max
- Total
inet_src_route_prefix,
inet_dst_route_prefix
Unique Ports - Source
- Destination
- Average
- 95th Percentile
- 99th Percentile
- Max
- Total
inet_src_route_prefix,
inet_dst_route_prefix
Unique ASNs - Source
- Destination
- Next Hop Destination
- Average
- 95th Percentile
- 99th Percentile
- Max
- Total
src_as,
dst_as,
i_dst_nexthop_as_name
Unique Countries - Source
- Destination
- Average
- 95th Percentile
- 99th Percentile
- Max
- Total
src_geo,
dst_geo
Unique Regions - Source
- Destination
- Average
- 95th Percentile
- 99th Percentile
- Max
- Total
src_geo_region,
dst_geo_region
Unique Cities - Source
- Destination
- Average
- 95th Percentile
- 99th Percentile
- Max
- Total
src_geo_city,
dst_geo_city
Sample rate - Max
- Average
- Average
- 95th Percentile
- 99th Percentile
- Max
sample_rate

Notes:
- When “Total” is shown in the “calculated as” list for a metric above, the Total metric will only be available if the chart type is set to Table or Matrix (see Chart View Types).
- Metrics whose name includes “unique” involve evaluating all instances across all queried devices within each individual time slice covered by the query’s time range (see Table Time-slicing) but not between time slices.

 

 
 top

Host Traffic Metrics

If the traffic being queried includes traffic from any devices in the category of “Host” (i.e. kprobe host agent; see About kprobe) then data from those hosts will be stored in KDE to make available host-only metrics, which are covered in the following topics:

 

 
 top  |  section

Host Metrics by Protocol

As shown in the table below, the availability of a given metric varies depending on the protocol:

Metric in portal TCP HTTP DNS Calculated as... Derived from KDE column(s)
Retransmits - Per second
- Repeated per second
- Percent
- Percent Repeated
- Repeated Retransmits
- Retransmitted Packets Out
N.A. - Average
- Percentile (95th or 98th)
- Max
- Total
retransmitted_out_pkts, repeated_retransmits,
both_pkts (for %)
Out-of-order packets - Per second
- Percent
- Per second (In) N.A. - Average
- Percentile (95th or 98th)
- Max
- Total
ooorder_in_pkts,
ooorder_out_pkts,
both_pkts (for %)
Fragments - Per second
- Percent
- Per second - Per second - Average
- Percentile (95th or 98th)
- Max
- Total
fragments,
both_pkts (for %)
Zero Windows - Count
- Percent
- Per second N.A. - Average
- Percentile (95th or 98th)
- Max
zero_windows
Receive Window N.A. N.A. N.A. - Average
- Percentile (95th or 98th)
- Max
receive_window
Latency - Client
- Server
- Application
- First Payload Exchange
- Client
- Server
- Application
- FPEX
- Application - Average
- Percentile (95th or 98th)
- Max
client_nw_latency_ms,
server_nw_latency_ms,
appl_latency_ms,
fpex_latency_ms

Note: When “Total” is shown in the “calculated as” list for a metric above, the Total metric will only be available if the chart type is set to Table or Matrix (see Chart View Types).

 

 
 top  |  section

Host Metrics Descriptions

The following descriptions apply to the host-only metrics listed in the table above:

  • Retransmits: Packets that are re-sent from source to destination; applies only to traffic using a reliable transport protocol such as TCP. Retransmission indicates network delivery issues that can degrade application/service performance. Retransmits are measured per second and also as a percentage of all packets sent, which reveals aggregate efficiency in the full context of expected total capacity.
    Note: “Repeated” represents the number of times a given packet was retransmitted 3 or more times.
  • Out of order: Packets that arrived at the destination out of sequence. A high value indicates potential variability in delivery paths and is particularly detrimental to latency-sensitive traffic such as real-time audio or video. Out of order packets are measured per second and also as a percentage of all packets sent.
  • Fragments/second: Packets per second that have been split into smaller packets for delivery across the network. Fragmentation and reassembly can increase CPU load and also cause retransmits when fragments arrive out-of-order. Fragments are measured per second and also as a percentage of all packets sent.
  • Zero Windows: Count of TCP receive windows with value of zero (indicating full buffer).
  • Receive Window: Size of TCP receive window.
  • Latency: Several different measure of latency are provided:
    - RTT/2 client latency (derived): One-way network latency as measured from the client perspective (in a client-server relationship). High values indicate latency problems in the network or at the server end of the flow.
    - RTT/2 server latency (derived): One-way network latency as measured from the server perspective (in a client-server relationship). High values indicate latency problems in the network or at the client end of the flow.
    - RTT/2 application latency (derived): A measure of one-way network latency that is derived by examining request/response pairs at the application layer (i.e. HTTP GET vs. first response). While this measure can be a reasonable proxy for end-user experience of application response, it only works for application protocols that have clear request/response pairings.
    - First Payload Exchange Latency: Used to measure application response time, particularly when the protocol isn’t understood or can’t be decoded (e.g. HTTPS, SQL, etc.). The time, which excludes TCP setup, starts with the first packet sent (typically the request) and stops with the first packet returned (typically the response).

Note: If you’d like to limit your results to series in which a given metric is above a minimum value, you can set a threshold in the Metrics Dialog (see Set Threshold in Metrics Dialog UI).

 

 
 top  |  section

Host Metrics KDE Columns

The following table shows the correspondence between the metrics described above and the columns of the KDE:

Metric in portal Type:
value
column
Derived from KDE column(s)
Retransmits bigint
Native
retransmitted_out_pkts, repeated_retransmits,
both_pkts (for %)
Out-of-order packets bigint
Native
ooorder_in_pkts,
ooorder_out_pkts,
both_pkts (for %)
Fragments bigint
Native
fragments,
both_pkts (for %)
Zero Windows bigint
Native
zero_windows
Receive Window bigint
Native
receive_window
Latency bigint
Native
client_nw_latency_ms,
server_nw_latency_ms,
appl_latency_ms,
fpex_latency_ms

Note: The KDE columns corresponding to the metrics listed above are shown in NPM Columns.

 

 
 top

Synthetic Metrics

Note: Queries using Synthetic metrics are subject to the following restrictions:
- Synthetic metrics cannot be mixed with metrics from any other category.
- Results will return only if the query’s dimensions are from the Synthetic category in the Query Dimension Selectors.

When kproxy is used for synthetic measurement (see kproxy Synthetic Measurement) it generates both dimensions and metrics that are stored in or derived from KDE columns. The following table shows the metrics from synthetic measurement that may be used in queries via the metric selector (see Metrics Dialog UI):

Metric in portal Calculated as... Metric type Description
TCP Receive Window - Average
- 95th Percentile
- Max
- Total
Sum Size of TCP receive window.
TCP Sender MSS - Average
- 95th Percentile
- Max
- Total
Sum Maximum segment size.
TCP RX - Average
- 95th Percentile
- Max
- Total
Sum Maximum receive transmission throughput.
TCP Pacing Rate - Average
- 95th Percentile
- Max
- Total
Sum Packets per second when using TCP pacing.
TCP RTT - Average
- 95th Percentile
- Max
- Total
Sum Round trip time for TCP packets.
TCP RTT Variance - Average
- 95th Percentile
- Max
- Total
Sum The variance in the measured RTT.
ICMP Hop Latency MS - Average
- 95th Percentile
- Max
- Total
Sum The round-trip sum of the hop-by-hop latency.

Note: For dimensions related to synthetic measurement, see Synthetic Dimensions.

 

 
 top

SNMP Metrics

Note: Queries using SNMP metrics are subject to the following restrictions:
- SNMP metrics cannot be mixed with metrics from any other category.
- Results will return only if the query’s dimensions are from the SNMP category in the Query Dimension Selectors.

If SNMP polling is enabled on a router (see SNMP OID Polling) then Kentik is able to enrich the KDE with the SNMP-derived metrics listed below. These metrics are stored in Kentik Detect using Universal Data Records (UDR), allowing flexible allocation of data to the columns of the Kentik Data Engine. See also Counter SNMP OIDs.

Note: UDR metrics have no persistent KDE columns.

Metric in portal Variations OID Calculated as... Description
Bit Rate - Input
- Output
- ifHCInOctets
- ifHCOutOctets
- Average
- 95th Percentile
- Max
- Total
Rate of bits received/transmitted on the interface, including framing characters.
Packets - Input
- Output
- ifHCInUcastPkts
- ifHCOutUcastPkts
- Average
- 95th Percentile
- Max
- Total
Rate of packets, including discards, that were not addressed to a multicast or broadcast address.
Errors - Input
- Output
- ifInErrors
- ifOutErrors
- Average
- 95th Percentile
- Max
- Total
The number of inbound/outbound packets that contained errors preventing them from being delivered/transmitted.
Discards - Input
- Output
- ifInDiscards
- ifOutDiscards
- Average
- 95th Percentile
- Max
- Total
The number of inbound/outbound packets that were chosen to be discarded even though no errors had been detected, possibly to free up buffer space.
Multicast Packets - Input
- Output
- ifHCInMulticastPkts
- ifHCOutMulticastPkts
- Average
- 95th Percentile
- Max
- Total
The number of inbound/outbound packets that were addressed to a multicast address.
Broadcast Packets - Input
- Output
- ifHCInBroadcastPkts
- ifHCOutBroadcastPkts
- Average
- 95th Percentile
- Max
- Total
The number of inbound/outbound packets that were addressed to a broadcast address.

 

 
 top

Streaming Telemetry Metrics

Note: Queries using Streaming Telemetry metrics are subject to the following restrictions:
- Streaming Telemetry metrics cannot be mixed with metrics from any other category.
- Results will return only if the query’s dimensions are from the Streaming Telemetry category in the Query Dimension Selectors.

If streaming telemetry publishing is enabled on a router (see Streaming Telemetry Device Support) then you can run queries in the portal that return the values of ST metrics. The metrics that are available for these ST queries have the same names as the metrics listed in the SNMP Metrics table above, but they appear in the Streaming Telemetry section of the list in the portal’s Metrics dialog (e.g. in Data Explorer).

 

 
 top

Application Decodes Metrics

When kprobe is used for application decodes (see About Application Decodes) it generates both dimensions and metrics that are stored in or derived from KDE columns. The following table shows the metrics from application decodes that may be used in queries via the metric selector (see Metrics Dialog UI):

Metric in portal Description Type:
value
column
Connection Name TCP connection ID. bigint
UDR
Application Latency One-way network latency derived by examining request/response pairs at the application layer. bigint
UDR
FPEX Latency Elapsed time from first packet sent to first packet returned. bigint
UDR

Note: For dimensions related to application decodes, see Application Decodes Dimensions.

 

Legacy Application Decodes Metrics

The “legacy” metrics in the table below are from kprobe versions before 1.3.0:

Metric in portal Description Type:
value
column
KDE name(s)
Connection ID TCP connection ID.
Note: Superseded by Connection Name.
bigint
Native
connection_id
Application Latency (ms) One-way network latency derived by examining request/response pairs at the application layer. bigint
Native
appl_latency_ms
First Payload Exchange Latency (ms) Elapsed time from first packet sent to first packet returned.
Note: Superseded by FPEX Latency.
bigint
Native
fpex_latency_ms

 

 
 top

Device-specific Metrics

Device-specific metrics are covered in the following topics:

 

 
 top  |  section

About Device-specific Metrics

Device-specific metrics are metrics that are generated and stored in KDE only for certain types of devices (physical or virtual). These metrics are stored in Kentik Detect using Universal Data Records (UDR), allowing flexible allocation of data to the columns of the Kentik Data Engine.

Note: UDR metrics have no persistent KDE columns.

 

 
 top  |  section

Cisco ASA Metrics

These metrics represent traffic volume of flow through Cisco Adaptive Security Appliances (ASA), which may be standalone appliances, blades, or virtual appliances. ASA uses bidirectional flow records in which the “initiator” (source) is the entity that initiates a request and the “responder” (destination) is the entity that replies with a response.

Notes:
- These KDE flow fields store a sum for the flow, which is used to derive the Average, 95th Percentile, and Max numbers that return from queries (e.g. the columns of the tables returned in Data Explorer).
- For more context on these dimensions, see the Cisco document ASA NetFlow Implementation Guide.

Metric name (portal) Description Type:
value
column
Initiator Bytes The bytes going from the initiator to the responder. integer
UDR
Responder Bytes The bytes going from the responder to the initiator. text
UDR

 

 
 top  |  section

Cisco Meraki Metrics

Like Cisco ASA, Cisco Meraki uses bidirectional flow records. Kentik’s Meraki-specific UDR fields, listed below, store the volume of the flow’s “responder” (destination) traffic, whose direction is from the Meraki firewall back to the “initiator” (source) of a request. These fields correspond to the OUT_BYTES and OUT_PKTS data fields in Meraki’s NetFlow Version 9 Templates.

Note:
- These KDE flow fields store a sum for the flow, which is used to derive the Average, 95th Percentile, and Max numbers that return from queries (e.g. the columns of the tables returned in Data Explorer).
- The volume from the initiator to the responder is stored in the standard KDE metrics fields in_bytes and in_packets (see General Metrics).

Metric name (portal) Description Type:
value
column
Out Bytes Number of bytes leaving the firewall for this flow. integer
UDR
Out Packets Number of packets leaving the firewall for this flow. integer
UDR

 

 
 top  |  section

Cisco Zone-based Firewall

These metrics represent traffic volume of flow through Zone-based Firewalls (ZFW) on Cisco IOS devices. ZFW uses bidirectional flow records in which the “initiator” (source) is the entity that initiates a request and the “responder” (destination) is the entity that replies with a response.

Notes:
- These KDE flow fields store a sum for the flow, which is used to derive the Average, 95th Percentile, and Max numbers that return from queries (e.g. the columns of the tables returned in Data Explorer).
- For more context on these dimensions, see the Cisco document Zone-based Policy Firewall Guide.

Metric name (portal) Description Type:
value
column
Initiator Bytes The bytes going from the initiator to the responder. integer
UDR
Responder Bytes The bytes going from the responder to the initiator. text
UDR

 

 
 top  |  section

Istio Metrics

These metrics represent telemetry data from Istio, which is an open source insight and control layer that enables you to secure, connect, and monitor the applications that make up a distributed microservices architecture for hybrid and multi-cloud deployments. For an overview of Istio telemetry, see the Istio document Policies and Telemetry.

Metric name (portal) Description Type:
value
column
Request Total Size Total size of HTTP request in bytes, including request headers, body and trailers. integer
UDR
Response Total Size Total size of HTTP response in bytes, including response headers and body. integer
UDR
Response Duration The time taken to generate the response. integer
UDR

In this article: