Add disk UUIDs as labels.

[raypettersen]

In short:

Today:
node_disk_sectors_written{device="sdj"}

Suggestion:
node_disk_sectors_written{device="sdj", uuid="e7821b62-64a0-4f24-a19a-85ed74da0c14"}

Reason for this request is that we have external USB devices that we want monitored, but dashboards and so forth break when devices are occasionally mapped to new device-names. My understanding is that UUIDs are persistent, or maybe not?

[raypettersen]

To answer my own question, UUIDs seem to be persistent as they are generated from device metadata. Ref: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Online_Storage_Reconfiguration_Guide/persistent_naming-uuid_and_others.html

[SuperQ]

👍 I think this would be useful. The difficulty is getting the UUIDs based on the name of the device read from /proc/diskstats.

[raypettersen]

Since the UUIDs are generated from metadata, I guess its just a matter of figuring out how the generation is made and do the same?

[SuperQ]

Sorta, it's complicated. Many of the UUIDs come from reading the filesystem metadata, not generating them programatically.

For example:

# ls -l /dev/disk/by-uuid/ | grep sda1
lrwxrwxrwx 1 root root 10 Jul 24 08:29 1196ae70-dca7-4c89-8ea7-52456bf23052 -> ../../sda1
# tune2fs -l /dev/sda1 | grep UUID
Filesystem UUID:          1196ae70-dca7-4c89-8ea7-52456bf23052

[raypettersen]

Investing this further shows that you can infact manipulate the UUIDs. This would break any logic in node_exporter if it were to auto-generate them. I guess the easiest thing to do, would be to read /dev/disk/by-uuid, but that is not optimal. For example, my zfs array is not visible on my storage server. blkid however manages to fetch everything. Perhaps there is something in the blkid source worth looking at?

[brian-brazil]

It wouldn't be appropriate to have both labels on the disk metrics, as each uniquely identifies a disk. This may be best something handled by textfile collector.

[raypettersen]

/dev/sdx does not uniquely identify a disk. If you for example plug-in random usb devices you're going to get burned if you're using node_exporter to monitor these disks. The devicelabel alone is not a good solution. UUIDs on the other hand, does in fact uniquely identify a disk.

[brian-brazil]

That depends on entirely your use case.

[raypettersen]

From my point of view, I could debate that it makes more sense having the UUID as a label than the /dev/ name. It offers superior identification as it can even identify disks that are moved across servers/instances. I'm just sharing my suggestion that will make the node_exporter perform better in storage-environments. If its more hazzle than it's worth, then I'll just close this issue and do my own work-around.

[SuperQ]

I agree that device label is insufficient to uniquely identify devices. I'd prefer both device and UUID.

[brian-brazil]

Device label is sufficient, and labels should be minimal. You either get UUID or device as a label.

[raypettersen]

Respectfully disagree that device label is sufficient. It's not a unique identifier for a drive or a partition.

[brian-brazil]

You can't have two /dev/sda, thus it is unique. It uniquely identifies a controller. These are per-device stats, not per-partition stats.

[SuperQ]

@brian-brazil Sorry, but that's not how hardware works. Device label is an indication of where it is connected, and UUID is an indication of what is connected. We want both.

[brian-brazil]

I am well aware of how hardware works. I consider the UUID to be an annotation, so it doesn't belong on these metrics. I'd expect the vast majority of our users not to care about UUIDs and device name order is pretty consistent these days particularly in cloud environments.

If you're looking for this then it should come as other annotations do, via another metric taking the machine roles approach.