Hi
I’m not sure if this is a bug or a feature request or both.
Currently the F5 LB module is graphing the VS connection rate and not concurrent connections but it’s labelled connections.
Current VS Connection MIB being collected (Rate)
Connection Rate
walk
value
output
.1.3.6.1.4.1.3375.2.2.10.2.3.1.11
Concurrent connection mib (counter)
Concurrent Connections
walk
value
output
.1.3.6.1.4.1.3375.2.2.10.2.3.1.12
Both are useful statistics that should be collected.
Moved to feature requests.
1.3.6.1.4.1.3375.2.2.10.2.3.1.12 is technically Client Current Connections, however I’m 100% in agreement that this is a very, very useful statistic, if not more so than Client Total Connections (at least for Big Fish Games, where I work).
I would love to see this either added or changed to replace total connections, which ever makes the most sense.
I might take some times to implement those changes
We could also regroup the Packets In|Out and Bytes In|out graphs together
I’ll give it a shot
Any ideas on how to add the additional metric without breaking existing .rrd files? I’ve already written the code to add the metric and it works great… But only if you add the new DS via rrdtool tune or delete your .rrd files entirely.
Here’s what I’ve got so far:
https://github.com/bfg-agoulet/librenms/commit/157072519d732664601444db6da98720e4b6ed6b
It has to be by a new rrd file, we have no way to tune existing rrd files to support a new DS at present.
Ah, understood. Do you have any recommendations on how to best approach this, from a design perspective? E.g. new module, custom rrd code for these components, etc?
I was going to ask basically the same thing. Connection rate is useful, but I rely on concurrent connections as a metric for many of my VS (especially Citrix/Xenapp VS) because rate is useless for them except for specific times of the day.
Just create a new file within the code. It’s made harder because it’s in a loop but you can create a new one easy enough.
Yup. I think that’s the case for other users, Brian. While the connection rate is useful, it is not NEARLY as useful as current connections. Indeed, if you’re feeding those metrics into Graphite as well (and I’d recommend it), you can easily get the connection rate (connections per second) via derivatives, but you can’t really do the reverse (at least I think).
I’ve resorted to keeping a separate fork for my company that uses my changes, as adding an additional RRD for each VS and pool on JUST our busiest LTM means over 1,400 new RRDs. The load balancer page is slow enough loading graphs without doubling the number of rrdtool calls and IO operations.
I wish there were a better solution though. Given how LTMs are used in larger enterprise environments, situations like ours are probably not uncommon. 
An increase in the number of files doesn’t add that much / if any over head to rrdtool.
If you think the performance impact will be minimal, I’ll try to find some time to build it and do some testing. Ideally I’d like to implement in such a way that adding new metrics to the F5 module in the future won’t require someone to manually write the extra code I’m writing, to make future extensions easier.
Hi, great news you are changing the source of F5 graphs. I’m really looking forward to that changes. If you need someone for testing, I have a testing environment with F5 systems.
Has there been any update to this feature request? We’re a big F5 shop and it is preventing us from retiring our old monitoring solution. Thanks.