End of Sale Notice:

F5 NGINX is announcing the End of Sale (EoS) for NGINX Controller API Management Module, effective January 1, 2024.

F5 maintains generous lifecycle policies that allow customers to continue support and receive product updates. Existing NGINX Controller API- Management customers can continue to use the product past the EoS date. License renewals are not available after September 30, 2024.

See our End of Sale announcement for more details.

End of Sale Notice:

F5 NGINX is announcing the End of Sale (EoS) for NGINX Controller Application Delivery Module, effective January 1, 2024.

F5 maintains generous lifecycle policies that allow customers to continue support and receive product updates. Existing NGINX Controller Application Delivery customers can continue to use the product past the EoS date. License renewals are not available after September 30, 2024.

See our End of Sale announcement for more details.

Overview: Traffic Metrics

Understanding how traffic metrics are collected, aggregated, and reported.

Overview

The data that 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