Forum Discussion
Bobbybobby
Altostratus
AltostratusGTM - Metric Timers
Can someone that is really familiar with GTM LS metrics help me understand the difference between these configuration settings. Their descriptions and default seconds seems to overlap/conflict.
Paths TTL - 2400s - number of seconds GTM considers path data valid
Inactive Path TTL - 604800s - number of seconds path remains in GTM cache after last access
Metrics Caching - 3600s - number of seconds which GTM dumps path and other metrics data
Inactive LDNS cache TTL - 2419200s - numer of seconds that inactive LDNS remains in GTM
If we were to go by descriptions alone and take an example metric of RTT. Path TTL would seem to say how long the RTTs are valid for consideration in LB determination - so 2400s by default. However, after the path TTL timer, the RTTs would remain on the GTM cache for which? the inactive path ttl like it says, so until the 604800 expires? If the answer is yes, then the inactive path ttl value would seem to never come into play because of the other setting - Metrics Caching - which says that all path metrics will be removed from BGP after 3600s. So, we would never reach the inactive path TTL time because the metric-cache would be removed way before the inactive paths ttl. So, the inactive paths ttl would seem irrelevant/redundant as it would seem to never be used because of the metric-caching timer would be reached way before.
Hi Bobbybobby ,
You can run
tmsh show net cmetrics
Are you using Prometheus or docker images to export GTM metrics.
Could you please share your scenario for using GTM metrics.Metric values are cached only when a session is active, only when requested, and only when the value is no longer considered useful (fresh). Consider these factors when viewing Metrics, especially when trending.
path-ttl
Specifies the number of seconds that the system considers path
data to be valid for name resolution and load balancing purposes.
The default value is 2400. Note that this option must be greater
than the paths-retry option and less than or equal to 2419200 (28
days).inactive-paths-ttl
Specifies the number of seconds that a path remains in the cache
after its last access. Valid values are 60 - 31536000 (1 year).
The default value is 604800 (7 days).metrics-caching
Specifies the interval (in seconds) at which the system dumps path
and other metrics data. Valid values are 0 through 604800. The
default value is 3600; 0 (zero) turns this feature off.
inactive-ldns-ttl
Specifies the number of seconds that an inactive LDNS remains in
the cache. Each time an LDNS makes a request, the clock starts
again. Valid values are 60 - 31536000 (1 year). The default value
is 2419200 (28 days).
Please refer to
https://clouddocs.f5.com/cli/tmsh-reference/v14/modules/gtm/gtm_global-settings_general.html
https://clouddocs.f5.com/cli/tmsh-reference/v15/modules/gtm/gtm_global-settings_metrics.html
https://support.f5.com/csp/article/K9629
https://support.f5.com/csp/article/K14938
BobbybobbyHi F5_Design_Engineer ,
I am not trying to export the data.
The issue is their is a conflict between the metric-caching definition and the remaining definitions even as you laid out. If the cache is being removed per the metrics-caching every 3600s by default, then some of the other values (ie inactive-ttl with a default value of 604800) will never be reached hence it seems pointless. That is unless the definitions of "the path" and "path metrics" means two different things. And if they do mean different things, what are those specific differences?
- JRahm
Admin
I don't have access to source code, so I can't tell you for sure, but writing the metrics to file once an hour by default doesn't invalidate the other metrics, it's just taking a moment-in-time snapshot of what's present in the system so they don't all have to be looked up for every decision.
- Bobbybobby
There was a very simple answer from what looks to be an archived article:
https://support.f5.com/csp/article/K11678
Now, compare that "definition/description" in the article
"You can change the frequency at which the BIG-IP system writes path and persistence information to the ldns.gz file. "
to the current one:
"Specifies the interval (in seconds) at which the system dumps path
and other metrics data. Valid values are 0 through 604800. The
default value is 3600; 0 (zero) turns this feature off."When I see "dumps path and other metric data", to me that sounds like DELETES, REMOVES, CLEARS, etc.. but its more like dumping as in a core dump where you are writing data locally. All that had to be added to the "dumps path and other metrics" was "to local file or remote destination" and that would have been 20 times more clear.
- JRahm
good find, and good point. I'll mention this to the docs owner.
