[FEAT] Display Power mode

[15sawyer]

Describe the solution you'd like I'm using hd-idle to spin down my unused disks and save on power costs. There are many things that can wake up a disk unnecessarily. So, to check if this is working as it should, it would be nice to have the current power mode displayed in Scrutiny.

Additional context The power mode can be retrieved with the smartctl -i -n standby /dev/sdX command Possible values: active/idle, standby, sleeping, unknown

[kocane]

I agree. Would be nice to have.

[AnalogJ]

it would be nice to have the current power mode displayed in Scrutiny.

What do you mean by current? Scrutiny does not have the ability to reach out and execute commands on the hosts containing disks. Instead there's an "agent" (the scrutiny collector) that runs on each host and collects data on a specified interval.

The Standby status could be collected, but it may be incorrect when you view the status in the UI. Is that still something you'd find valuable?

[15sawyer]

I guess the information is valuable as long as it is collected regularly enough. Only once a day probably doesn't suffice. But I understand that this may not be worth the effort to implement in the current framework.

[TheLinuxGuy]

I would also appreciated if scrutinize was able to provide a graph/metrics in the web UI showing power consumption stats for each disk:

• % of total time disk has been spinning (spin-up)
• % of total time disk has been idle
• % of total time disk has been spun down (sleep)

[AnalogJ]

something like this would require a different streaming or real-time collector, since the current collector only runs on a cron schedule.

Interesting, but would require a PR from the community.

[TheLinuxGuy]

@AnalogJ could you perhaps give some code pointers if an existing collector can be copied/forked to achieve this?

hd-idle . The logs look this this

date: 2024-07-20, time: 15:19:54, disk: sdc, running: 180, stopped: 664
date: 2024-07-20, time: 15:19:54, disk: sdd, running: 180, stopped: 664
date: 2024-07-20, time: 15:19:54, disk: sde, running: 180, stopped: 664
date: 2024-07-20, time: 15:19:54, disk: sdf, running: 180, stopped: 664
date: 2024-07-20, time: 15:19:54, disk: sda, running: 180, stopped: 664
date: 2024-07-20, time: 15:19:54, disk: sdb, running: 180, stopped: 664
date: 2024-07-25, time: 18:29:18, disk: sde, running: 180, stopped: 1386
date: 2024-07-25, time: 18:29:18, disk: sdf, running: 180, stopped: 1386
date: 2024-07-26, time: 20:37:31, disk: sdd, running: 13571, stopped: 82088
date: 2024-07-26, time: 20:37:31, disk: sde, running: 180, stopped: 93913
date: 2024-07-26, time: 20:38:31, disk: sda, running: 180, stopped: 95540
date: 2024-07-26, time: 20:38:31, disk: sdc, running: 13571, stopped: 82148
date: 2024-07-26, time: 20:38:31, disk: sdf, running: 180, stopped: 93973
date: 2024-07-26, time: 20:38:31, disk: sdb, running: 180, stopped: 95540
date: 2024-07-26, time: 20:55:43, disk: sdc, running: 961, stopped: 70
date: 2024-07-26, time: 20:55:43, disk: sdd, running: 1021, stopped: 70
date: 2024-07-26, time: 20:55:43, disk: sde, running: 1021, stopped: 70
date: 2024-07-26, time: 20:55:43, disk: sdf, running: 961, stopped: 70
date: 2024-07-26, time: 21:11:43, disk: sdb, running: 360, stopped: 1631
date: 2024-07-26, time: 21:11:43, disk: sda, running: 360, stopped: 1631

How to understand these log entries its explained in hd-idle readme.

I'm not sure how the collector exactly works; but a quick look it seems that:

1. A system executes a binary command

2. Output from command is then parsed

3. Parsed output is then submitted to an API endpoint to ingest it into influxdb

   • What kind of API format needs to be used to store this new collector data metrics? how can it be associated reliably with a specific disk already in scrutiny?

4. InfluxDb metrics is retrieved and represented in some graph. Unsure what files need to change to display the new field data (assumed to now be associated with the HDD data primary key)