Bug 1205231
| Summary: | RFE: provide IPVS/LVS metrics | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Marko Myllynen <myllynen> | ||||
| Component: | pcp | Assignee: | pcp-maint <pcp-maint> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | rawhide | CC: | lberk, mgoodwin, nathans, pcp | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2022-04-05 00:25:22 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Marko Myllynen
2015-03-24 13:30:53 UTC
Hi Marko, From a look through the kernel code, we're talking about stats exporting from net/netfilter/ipvs/ip_vs_ctl.c::ip_vs_stats_show (amongst others). There is a netfilter PMDA someone began awhile back which could be extended to handle this, perhaps. Or they could live in pmdalinux. Or they might be suited to the specialist networking PMDA Michele has been working on. Quickest will probably be to add it to the perl netfilter PMDA I guess... anyone have any preferences here? The stats output you've given there is very helpful, thanks Marko - interesting that these counters are exported in hex (!) - first time I've ever seen that - and for PCP's needs we really just need that first row of values. The second row contains constantly updating 2-second timer-based rate converted values - which we can do more effectively in userspace, without loss of information. Comment toward the head of ip_vs_est.c (which houses ip_vs_read_estimator(), from whence the second line is calculated) is spot on - "it is easy to implement a user level daemon which periodically reads those statistical counters and measure rate." :) cheers. Thanks for looking into this. I think any of those PMDAs would do just fine but perhaps the netfilter PMDA would be my least preferred choice as it's a different subsystem. Also, the other related proc files (ip_vs, ip_vs_app, ip_vs_conn, ip_vs_conn_sync) contain information about current rules and current connections but I'm not sure are those worth to add. Thanks. (In reply to Marko Myllynen from comment #2) > Thanks for looking into this. I think any of those PMDAs would do just fine > but perhaps the netfilter PMDA would be my least preferred choice as it's a > different subsystem. Hmm, the location of the kernel code net/netfilter/ipvs/ip_vs_ctl.c::ip_vs_stats_show ^^^^^^^^^^^^^' suggested otherwise - no big deal though, those other options are fine too. Also, the other related proc files (ip_vs, ip_vs_app, > ip_vs_conn, ip_vs_conn_sync) contain information about current rules and > current connections but I'm not sure are those worth to add. Not sure - could you add sample output from a working setup just in case? thanks Marko. (In reply to Nathan Scott from comment #3) > (In reply to Marko Myllynen from comment #2) > > Thanks for looking into this. I think any of those PMDAs would do just fine > > but perhaps the netfilter PMDA would be my least preferred choice as it's a > > different subsystem. > > Hmm, the location of the kernel code > net/netfilter/ipvs/ip_vs_ctl.c::ip_vs_stats_show > ^^^^^^^^^^^^^' > suggested otherwise - no big deal though, those other options are fine too. Ah, I stand corrected. In that case the netfilter PMDA might be a good candidate also. I think we could follow the good olde "doer decides" principle :) > I think we could follow the good olde "doer decides" principle :)
Yep, agreed.
I'm going to close this out based on #c9 - let's get an upstream issue opened if these metrics are useful to folk. |