General Metrics

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

• About General Metrics
• Metrics from All Devices
• Host Traffic Metrics
• Application Decodes Metrics

Notes:
- The categorization of metrics in the topics below corresponds to the categories by which they are grouped in the Metrics dialog (see Metrics Dialog UI).
- For general information about metrics in Kentik, see About Metrics.
- For metrics that aren’t transmitted via a flow protocol, see Non-flow Metrics.
- For metrics that are device-specific, see Device-specific Metrics.
- Metrics that are available as filter or group-by dimensions are covered in the KB’s Dimensions Reference (see Per-flow Metrics).
- In addition to being used for query settings in the Kentik portal, metrics are also used for the Query API.

In Kentik, general metrics are metrics that are transmitted via a flow protocol (e.g. NetFlow, sFlow, etc.) and aren’t specific to a particular device, such as an individual model of router. The general metrics that are available in a given setting, such as the Metrics Pane of the Query sidebar in Data Explorer, vary depending on the category of the device (Router or Host; see Supported Device Types) as well as the specific device type.

If a given query includes only traffic from data sources (see About Data Sources) in the “Routers” category then only the metrics in the table below are available (for descriptions of the KDE columns from which metrics are derived, see Metrics Columns):

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.

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:

• Host Metrics by Protocol
• Host Metrics Descriptions
• Host Metrics KDE Columns

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

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).

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).

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

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

When Kentik’s kprobe host agent 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):

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

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