Forum Discussion

Tore_Anderson_9's avatar
Tore_Anderson_9
Icon for Nimbostratus rankNimbostratus
Nov 27, 2012

Multiple cases of ISTATS weirdness

I'm having some problem with ISTATS on a LTM 8900 running version 11.2.0. Perhaps anyone here could help me out shed a light on what is the reason for these cases of weird behaviour.

1) The counter name apparently requires to have three spaces in it. For example, this works:

ISTATS::incr "foo bar baz zoo" 1

However, this doesn't:

ISTATS::incr "foo bar baz" 1

It fails with the following error message:

01220001:3: TCL error:
/Common/istats_debugging  -  Error: Fact0: requested Id0
(type=HEADER) as type FACT (line 1)     invoked from within
"ISTATS::incr "foo bar baz" 1"     ("/incr" arm line 2)     invoked from
within "switch [HTTP::uri] {     "/get" {       HTTP::respond 200
content " counter is now: [ISTATS::get "foo bar baz zoo"] "     }
"/incr" {       ISTATS..."

As far as I can tell, this restriction isn't documented at https://devcentral.f5.com/wiki/iRules.iStats.ashx. What is the reason for this?

2) The third word in the counter name appears to be ignored. In other words, if I have done:

ISTATS::incr "foo bar baz zoo" 1

...and later check the value of another counter that share the first two and the last word in the key, for example:

ISTATS::get "foo bar HAHA zoo"

..it will return 1, even though this particular counter was never initialised.

3) ISTATS::set appears to be interpreted as ISTATS::incr. For example, after doing:

ISTATS::incr "foo bar baz zoo" 100
ISTATS::set "foo bar baz zoo" 50

When reading this counter:

ISTATS::get "foo bar baz zoo"

I get the value 150. I would have expected 50 instead.

This makes it impossible to reset the counters, as using ISTATS::set with the value 0 does nothing (probably "adds" 0 to the existing value).

4) There is a noticable delay in updating the counters. For example, if i have an iRule that says:

ISTATS::incr "foo bar baz zoo" 1      
HTTP::respond 200 content "counter increased by 1, current value: [ISTATS::get "foo bar baz zoo"]"

The actual output of this iRule will be:

counter increased by 1, current value: 0

...which ought to have been impossible the way I see it.

5) There is a certain "wobblyness" in updating the counters too. In the example below, the /incr URI will increment and print the value, while the /get URI will only print the current value of the counter (I will attach the iRule).

$ wget -qO- http://192.168.0.254/get
counter is now: 11
$ wget -qO- http://192.168.0.254/incr
counter increased by 1, current value: 11
$ while sleep 1; do wget -qO- http://192.168.0.254/get; done  poll the counter every second
counter is now: 11
counter is now: 11
counter is now: 12
counter is now: 12
counter is now: 11
counter is now: 11
counter is now: 12
counter is now: 11
counter is now: 12
counter is now: 11
counter is now: 11
counter is now: 12
counter is now: 11
counter is now: 12
counter is now: 11
counter is now: 11
counter is now: 11
counter is now: 12
counter is now: 11
counter is now: 11
counter is now: 11
counter is now: 11
counter is now: 11
counter is now: 11
counter is now: 12
counter is now: 12
counter is now: 12
counter is now: 11
counter is now: 12
counter is now: 12
counter is now: 11
counter is now: 12
[permanently 12 from now on]

This means that from the stats gathering tool, it may appear as if the counter is going backwards, which is usually considered a counter wrapping, either leading to lost data points or huge spikes in the generated graphs.

3 Replies

  • Hi Tore,

     

     

    Colin wrote up a great intro to iStats that addresses most of your points. If you still have questions after reading it, reply back here and we'll try to help.

     

     

    https://devcentral.f5.com/tutorials/tech-tips/introduction-to-istats-part-1-overview

     

     

    Thanks, Aaron
  • Thanks for that pointer Aaron. It sure explains a lot (which IMHO should really have been in the documentation as well). It explains my points 1 and 4, and when I started using "counter" for word 3, issue 2 went away (i.e., incrementing "x y counter z" did not change the value of "x y gauge z").

     

     

    However, I found no explanation in that article for issues 3 and 5 (both of which I could reproduce even after changing the name of my stat to "a b counter c").
  • For what it's worth, here's my current debugging iRule. To reproduce issue 5, do first one call to /incr, then perform repeated calls to /get. The reported counter value will oscillate between 0 and 1, until finally settling on the value 1.

    Next, to reproduce 5, do one call to /set42. Assuming the value of the counter was 1 to begin with, you'll see the counter increase by 42 and report the value 43, rather than being set to exactly 42. Also you can try a call to /reset and see that it has no effect whatsoever.

    when HTTP_REQUEST {
      switch [HTTP::uri] {
        "/get" {
          HTTP::respond 200 content "counter is now: [ISTATS::get "x y counter z"]
    the gauge is: [ISTATS::get "x y gauge z"]
    "
        }
        "/incr" {
          ISTATS::incr "x y counter z" 1
          HTTP::respond 200 content "counter increased by 1, current value: [ISTATS::get "x y counter z"]
    "
        }
        "/reset" {
          ISTATS::set "x y counter z" 0
          HTTP::respond 200 content "counter set to 0, current value: [ISTATS::get "x y counter z"]
    "
        }
        "/set42" {
          ISTATS::set "x y counter z" 42
          HTTP::respond 200 content "counter set to 42, current value: [ISTATS::get "x y counter z"]
    "
        }
      }
    }