It would be nice if the exporter could expose the network interface link speed, this would permit us to calculate net utilization %
If this is available via proc/sysfs it should be possible. If it's available via netlink it's also possible, but we don't have support for this yet.
Seems the Linux way is an ioctl :-/
http://stackoverflow.com/questions/2872058/get-link-speed-programmatically
Confirmed that ethtool also uses this to get interface stats.
Ah, /sys/class/net/<device>/speed seems to work in some cases. At least it did for me for eth0.
See also http://stackoverflow.com/questions/36262078/how-to-get-network-speed-in-linux-using-golang
+1
It would also be nice to directly expose link states. Looking over the code/strace of ip link, the tool gets things from netlink. But similar information is available via /sys/class/net/...
$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp0s25: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
5: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
6: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
This may also provide a nice info metric that would let users map devices to mac address.
/cc @mdlayher
This screams rtnetlink to me. Probably doable, but I'm working on some improvements to my netlink packages before I have time to tackle this.
hi, any progress on this one? Thanks
This is also related to https://github.com/prometheus/node_exporter/issues/794. We need to add support for the sysfs data in the procfs library, or as @mdlayher says, implement this via netlink.
@klatys Any ability to sponsor this work? As the node_exporter is a purely volunteer maintained project, we currently don't have the resources to implement things on any kind of schedule. :cry:
@SuperQ I suppose we can help out with that :) it's just a quick draft, but how about this
@klatys We're trying to move more of the procfs/sysfs parsing code to our procfs librarary so the code is more reusable.
Np, I鈥檒l check it out and get back to you.
@SuperQ so I suppose this would be step 1
followed by implementing this into node exporter?
@klatys Yes, something like that, but there's no need to do anything with json, just use Go structs. Take a look at the other code in the procfs repo.
@SuperQ yes, that was wrong naming of a tag, the struct is actually used, the tag I took was based on net_dev.go. I changed it's name - It's for identifying filename to be scraped (which is different from other modules as far as I can tell). I opened a pull request, hope it's ok now, otherwise feel free to comment
Thanks! It looks OK to me, but I'd like to have the other maintainers take a look at it.
Solved by #851
Most helpful comment
Thanks! It looks OK to me, but I'd like to have the other maintainers take a look at it.