When querying the STATS API, you will notice the resolution of the data changes over time. This is due to the downsampling that occurs. Downsampling is performed to reduce the amount of data persisted to disk, ultimately purging the data from the system after a period of time.
The system samples data every 5 seconds. The sampling interval is configurable under authority > router > system > metrics > sample-period <value>.
It is not recommended to change the sample-period. Increasing the value reduces the resolution of the information collected. Decreasing the value will create a greater computational load on the system. The software has been tuned to operate optimally at a sampling interval of 5 seconds.
The full resolution of 5 second sampled data is kept for 1 hour.
Every five minutes, the sampled data is aggregated. The 5 minute values are kept for a day.
Every hour the 5 minute values are aggregated. The 1 hour values are kept for 6 months.
By default, not all metrics are persisted to disk and subject to downsampling. When executing show stats commands utilizing the since argument, the command will report that the requested data will be unavailable.
In-memory metrics can be configured so that only metrics matching a filter are persisted. For more information refer to Configuring In-Memory Metrics.
Care should be taken to avoid overloading the system with the metrics. Many metrics are currently in-memory because of the heavy load they introduce to the system if they were all persisted.
An Example of show stats command using a since argument is shown below:
firstname.lastname@example.org# show stats ipfix since 5:30
Tue 2020-03-15 13:07:06 UTC
WARNING: Some metrics are not available historically. Their current values will be displayed.
A key indicator of application performance is the time it takes to establish the TCP session between client and server. This is effectively the time it takes to get to the first data packet between endpoints. This metric is more telling than packet transmission rates because it is directional and end to end. Importantly, this information can be used as a measure of SLA to influence path selection.
Session establishment metrics have been created and are gathered on a per service, per interface, per destination, per traffic-class basis. This level of granularity provides surgically accurate information on how the network treatment and performance is impacting application behavior. A capability that is unique only to the 128T router.
To add more context to the sessions traversing the 128T router, the newly added session establishment metrics detailed below will be collected in protocol based buckets TCP, UDP, ICMP, and TLS. Each protocol has its own determination of what qualifications need to be met for a session to become established. In turn there is protocol/application-specific handling of each of these, defined by what is considered established. For the remainder of the document, the following definitions of establishment are implied per protocol:
TCP - session has seen an acknowledgement to the first packet after the TCP handshake that contains payload
UDP - session has seen a packet in the reverse direction
ICMP - session has seen a packet in the reverse direction
TLS - session has seen an acknowledgement to the first packet after the TLS handshake that contains payload
This is a grouping of 3 different metrics: min, max, and mean. The time from session start to when it reaches the established state as defined above per-protocol. The exception is for TLS, the start time will be at TCP establishment instead of session start.
email@example.com# show stats highway destination-reachability tcp time-to-establishment
Counts of how many sessions timed out without ever reaching establishment, as defined per-protocol above. The TLS bucket of this metric is incremented only when the TCP established state has been reached but before the TLS established state has been reached.
firstname.lastname@example.org# show stats highway destination-reachability tcp timeout-before-establishment
Counts the number of sessions that are closed by reset or fin before the session has finished the TCP handshake and data has been acknowledged. This can be a server responding to a SYN with a reset or a proxy terminating a session it can’t complete.
email@example.com# show stats highway destination-reachability tcp close-before-establishment