S.M.A.R.T collector

[prologic]

It would be great if someone with bandwidth could spend effort/time looking into building a PoC with this nifty (not tested personally) library that seems to provide pureGo platform-independent access to S.M.A.R.T data from a number of devices:

https://github.com/dswarbrick/smart

[mdlayher]

I like the idea but suspect that SMART data will require root to access, meaning no go for node exporter. Did you see the smartmontools text file script in the repo? That's what I use.

[prologic]

I did and to be honest a "scripted" solution dumping to /path/to/textfile for collection seems unideal to me.

There is another non-root approach to this (written in Python) that does not require node_exporter to run as root -- if a solution were to be written and integrated into node_exporter it could use this approach:

https://github.com/CloudAndHeat/prometheus_smart_exporter

[mdlayher]

It's shelling out to smartctl too, so same thing. We also don't want to shell to external utilities.

[prologic]

You missed my point 🗡

With the pure-Go library + the design in prometheus_smart_exporter whereby it runs a listening socket as root to itnerface with.

[mdlayher]

But now you have to bundle an external helper that runs as root and couples with the node exporter.

I don't think this is an approach we'd want to take within node exporter, but I'm open to thoughts from the maintainers.

[brian-brazil]

Cronjobs are a more secure way to handle metric gathering that requires root. We want to avoid having a socket listened to by root on every machine in the fleet.

[SuperQ]

Replacing the current collector script with a Go binary would be nice. I agree with @mdlayher, we would not want to bundle an external binary this way.

One interesting approach would be to have a smartd replacement in Go that exposes SMART metrics directly, no need to bundle SMART in the node exporter this way.

[discordianfish]

So we can't depend on root nor on shelling out. I don't see the reason to replace the script by a to-be-built go binary that arguably requires more maintainance than a script calling smartctl. Agreeing with the smartd replacement, that would be rad. But out of scope of the node_exporter.

It's always an option to create a standalone smart_exporter, that should be easier to handle than something that integrated with the node_exporter via some socket.

[SuperQ]

I think the @discordianfish has this correct. This is currently out of scope for the node_exporter.