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.