Expose network link speed

[syepes]

It would be nice if the exporter could expose the network interface link speed, this would permit us to calculate net utilization %

[SuperQ]

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.

[juliusv]

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.

[juliusv]

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

[alwqx]

+1

[SuperQ]

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.

[SuperQ]

/cc @mdlayher

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

[klatys]

hi, any progress on this one? Thanks

[SuperQ]

This is also related to #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. 😢

[klatys]

@SuperQ I suppose we can help out with that :) it's just a quick draft, but how about this

[SuperQ]

@klatys We're trying to move more of the procfs/sysfs parsing code to our procfs librarary so the code is more reusable.

[klatys]

Np, I’ll check it out and get back to you.

[klatys]

@SuperQ so I suppose this would be step 1
followed by implementing this into node exporter?