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