----- Original Message -----
> Hi all,
>
> so on my quest to replace all our (RH) internal scripts to collect
> networking stats with PCP.
Awesome :)
> I was thinking of creating a separate PMDA for this. I still need to think a
> bit
> how the namespace will look like. I'll probably prefer using NETLINK and
> fetch
> the info in the PMDA directly and not fork tc and parse the output. Hopefully
> it is not too much work.
Sounds good & yeah, shouldn't be a huge amount of work I'd hope.
> 2) /proc/softirqs
> This should be trivial. Would it be ok to fold this into the Linux PMDA?
Yep (though complicated by need for dynamic metrics a bit). See the
existing kernel.percpu.interrupts metrics (from /proc/interrupts), I
guess these new ones would become kernel.percpu.soft_interrupts.*
> 3) /proc/net/softnet_stat
> Should also be fairly simple. Unsure where to squeeze it in though? Maybe
> a new PMDA linux-networking which holds 1) 3) and 4) ?
Sounds good to me. We have linux_proc, linux_xfs - so linux_net would
be good - the metrics names could match the access methods, like netlink.*
ethtool.* and so on? (/me has a luvly bikeshed now)
> 4) ethtool -S
> I have a prototype ready in python. It crashes when an interface is removed
> and readded (due to the python-pcp limits with dynamic metrics issue).
> Anyhow I will port it to C so we won't be dependant on a too recent
> python-ethtool
> version. Here too, I am unsure if I should put it in a linux-networking PMDA
> or
> an ethtool PMDA or somewhere else completely
C is good (esp for simply talking ioctls like SIOCETHTOOL) - gives you
the DSO PMDA option too, if elevated privileges aren't required (which I
don't think they are here?).
The python wrapper will only fail if you attempt to add an entirely new
metric after startup - adding/removing instances on-the-fly is fine and
generally a better way to go whenever possible.
cheers.
--
Nathan
|