Forum Discussion

Bobbybobby's avatar
Bobbybobby
Icon for Altostratus rankAltostratus
Dec 08, 2022

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

 

5 Replies

  • 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

     

    • Bobbybobby's avatar
      Bobbybobby
      Icon for Altostratus rankAltostratus

      Hi 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?

  • 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's avatar
      Bobbybobby
      Icon for Altostratus rankAltostratus

      JRahm F5_Design_Engineer 

      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's avatar
        JRahm
        Icon for Admin rankAdmin

        good find, and good point. I'll mention this to the docs owner.