Overview: Traffic Metrics

Overview

The data that F5 NGINX Controller collects can be divided into two categories:

  • System metrics: Data collected from the NGINX Plus API, the NGINX log files, and NGINX process state.
  • Traffic metrics: Data related to processed traffic, with the ability to distinguish the Application, API endpoint, or Environment that traffic is directed through.
Note: The key difference between system and traffic metrics is that traffic metrics are pre-aggregated for each time period.

Metrics are published at a regular interval of 60 or 30 seconds for system and traffic metrics, respectively.

This topic gives an overview of the traffic metrics. Also known as “app-centric” metrics, traffic metrics contain information that lets you easily identify the App to which the data applies.

See Also: Refer to View traffic metrics for instructions on how to view traffic metrics using the NGINX Controller REST API.

Available traffic metrics

  • client.latency.{total | max | min | count}
  • client.network.latency.{total | max | min | count}
  • client.request.latency.{total | max | min | count}
  • client.ttfb.latency.{total | max | min | count}
  • client.response.latency.{total | max | min | count}
  • upstream.network.latency.{total | max | min | count}
  • upstream.header.latency.{total | max | min | count}
  • upstream.response.latency.{total | max | min | count}
  • http.request.bytes_rcvd
  • http.request.bytes_sent
  • http.request.count
See Also: Refer to the NGINX Controller Metrics Catalog for details about these and the other metrics that NGINX Controller reports.

Calculating traffic metrics

As traffic flows through a configured application, NGINX Controller collects the traffic-related data. With heavy traffic, the number of single, distinguishable metrics can be challenging to discern. For this reason, the metric values are aggregated.

The aggregation happens every publish period – this period is stored in the aggregation_duration dimension, and is usually 30 seconds – and is based on metric dimensions.

Metrics are aggregated using four aggregation functions:

  • SUM for http.request.bytes_rcvd, http.request.bytes_sent and all metrics with .total suffix.
  • MAX for metrics with .max suffix.
  • MIN for metrics with .min suffix.
  • COUNT for metrics with .count suffix.

Example

To better understand how metrics are aggregated, consider the following example:

Imagine you have one application configured with one URI (recorded in the http.uri dimension of each traffic-related metric). In the last 30 seconds, a user queried that URI five times. The client.request.latency values for the requests were: 1 ms, 2 ms, 3 ms, 4 ms, and 5 ms.

The final metric values returned by the Metrics API will be:

  • http.request.count = 5
  • client.request.latency.total = 15 ms
  • client.request.latency.max = 5 ms
  • client.request.latency.min = 1 ms
  • client.request.latency.count = 5

This documentation applies to the following versions of NGINX Controller: 3.0, 3.1, 3.2, 3.3, 3.3, 3.4, 3.5, 3.6, 3.7, 3.8, 3.9, 3.10, 3.12, 3.13, 3.14, 3.15, 3.16.1, 3.17, 3.18, 3.18.1, 3.18.2 and 3.18.3.

This documentation applies to the following versions of NGINX Controller API Management module: 3.18, 3.18.1, 3.19, 3.19.1, 3.19.2, 3.19.3, 3.19.4 and 3.19.5.

This documentation applies to the following versions of NGINX Controller App Delivery module: 3.20, 3.20.1, 3.21, 3.22, 3.22.1, 3.22.2, 3.22.3, 3.22.4, 3.22.5, 3.22.6, 3.22.7 and 3.22.8.