Monitor Proxmox Disk S.M.A.R.T. with Scrutiny
Install the Scrutiny dashboard in an LXC container, then collect and archive the S.M.A.R.T. data of Proxmox physical disks.
Proxmox VE can read the S.M.A.R.T. information of a drive, but it does not track its evolution. It is impossible, from its native interface, to compare the current temperature with yesterday's or to easily spot a progressive degradation. Scrutiny fills this gap with a Web dashboard, thresholds based on real failure data, and a history kept in InfluxDB.
Why use Scrutiny
The report provided by Proxmox remains useful for a spot check: general status, temperature, volume of data read or written, operating hours, and recorded errors. However, it does not allow visualizing the dynamics of these values over several hours, several months, or a year.
Scrutiny is an open source project dedicated to S.M.A.R.T. monitoring of HDDs, SSDs, and NVMe drives. In a so-called hub and spoke installation, the Web interface and the database form the hub, while one or more collectors query the drives of the hosts to be supervised. This separation suits Proxmox well: the dashboard remains isolated in an LXC, but the collector runs on the hypervisor, where the drives are actually visible.
Create the LXC container
The original installation uses Ubuntu 22.04 LTS. This version remains suited to the scenario reproduced here. Ubuntu 24.04 also works with Docker Compose v2; the difficulty encountered in the initial article mainly stemmed from the old docker-compose package, and not from a fundamental incompatibility of Scrutiny.
In your Proxmox node storage, select Container Templates → Templates, search for ubuntu-22.04-standard, and start the download.
Then create a container with the following parameters:
- 1 vCPU and 512 MB of memory are sufficient for a light trial; 1 GB provides more headroom for InfluxDB.
- 8 GiB of disk is the minimum of the original installation. Plan for 16 GiB or more if you keep measurements of many drives for a long time.
- Enable the Nesting option to allow running Docker inside the LXC.
- Assign a fixed IP address or a DHCP reservation. In the screenshots, Scrutiny responds on
192.168.68.144. - Preferably add your SSH public key during container creation.
From the container console, update the system and install Docker with the current Compose plugin:
apt update
apt full-upgrade -y
apt install -y ca-certificates curl docker.io docker-compose-v2
systemctl enable --now docker
reboot
Install Scrutiny and InfluxDB in the LXC
Reconnect to the container after its restart, then prepare the persistent directories:
mkdir -p /opt/scrutiny/config /opt/scrutiny/influxdb
cd /opt/scrutiny
nano compose.yaml
The following file reproduces the architecture of the original article, with InfluxDB 2.8 and Scrutiny 0.9.3. The version is pinned to prevent an unexpected update from modifying the service. The InfluxDB port is not published on the network: only Scrutiny accesses it inside Docker.
services:
influxdb:
image: influxdb:2.8
container_name: scrutiny-influxdb
restart: unless-stopped
volumes:
- ./influxdb:/var/lib/influxdb2
environment:
TZ: Europe/Brussels
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:8086/health"]
interval: 5s
timeout: 10s
retries: 20
scrutiny-web:
image: ghcr.io/analogj/scrutiny:v0.9.3-web
container_name: scrutiny-web
restart: unless-stopped
ports:
- "8080:8080"
volumes:
- ./config:/opt/scrutiny/config
environment:
SCRUTINY_WEB_INFLUXDB_HOST: scrutiny-influxdb
TZ: Europe/Brussels
depends_on:
influxdb:
condition: service_healthy
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:8080/api/health"]
interval: 5s
timeout: 10s
retries: 20
start_period: 10s
Start both services and check their status:
docker compose up -d
docker compose ps
docker compose logs --tail=50
Then open http://192.168.68.144:8080, replacing the address with that of your LXC. The interface should appear, but it remains empty before the first send from the collector.
Do not directly expose port 8080 to the Internet. Limit it to the administration network or place Scrutiny behind your reverse proxy with HTTPS and appropriate authentication.
Install the collector on the Proxmox host
The commands in this section must be executed in the shell of the Proxmox host, and not in the LXC container. First install smartmontools and verify that the drives are detected:
apt update
apt install -y ca-certificates curl smartmontools
smartctl --scan
Download the collector corresponding to the server version:
install -d -m 0755 /opt/scrutiny/bin /opt/scrutiny/config
curl -fL \
https://github.com/AnalogJ/scrutiny/releases/download/v0.9.3/scrutiny-collector-metrics-linux-amd64 \
-o /opt/scrutiny/bin/scrutiny-collector-metrics-linux-amd64
chmod 0755 /opt/scrutiny/bin/scrutiny-collector-metrics-linux-amd64
To clearly identify the drives of this host, create /opt/scrutiny/config/collector.yaml:
version: 1
host:
id: "pve20"
Replace pve20 with the actual name of the node. Then launch a first manual collection:
/opt/scrutiny/bin/scrutiny-collector-metrics-linux-amd64 run \
--api-endpoint "http://192.168.68.144:8080"
The command should list the detected drives, read their attributes with smartctl, then confirm the send to the server. If a drive is missing, compare the result with smartctl --scan. A RAID controller may require an explicit device type in collector.yaml.
Automate the collection with systemd
Create the service /etc/systemd/system/scrutiny-collector.service:
[Unit]
Description=Collecteur S.M.A.R.T. Scrutiny
Wants=network-online.target
After=network-online.target
[Service]
Type=oneshot
ExecStart=/opt/scrutiny/bin/scrutiny-collector-metrics-linux-amd64 run --api-endpoint http://192.168.68.144:8080
Then create /etc/systemd/system/scrutiny-collector.timer:
[Unit]
Description=Collecte S.M.A.R.T. périodique pour Scrutiny
[Timer]
OnBootSec=5min
OnUnitActiveSec=60min
Persistent=true
Unit=scrutiny-collector.service
[Install]
WantedBy=timers.target
Reload systemd, enable the timer, and immediately trigger a control report:
systemctl daemon-reload
systemctl enable --now scrutiny-collector.timer
systemctl start scrutiny-collector.service
systemctl status scrutiny-collector.timer
systemctl list-timers scrutiny-collector.timer
OnUnitActiveSec=60min reproduces the frequency used in the original article. A 15-minute interval draws the temperature curve more finely; a daily collection is sufficient if only slow trends interest you.
Verify the data in Scrutiny
A few minutes after the first execution of the collector, the drives should appear in the Web interface. Open a device to find its detailed attributes, then return to the dashboard to display the temperature evolution.
If the interface remains empty, check both sides:
journalctl -u scrutiny-collector.service -n 100 --no-pageron Proxmox;docker compose logs --tail=100 scrutiny-web influxdbin the LXC;- TCP access to port
8080between the host and the container; - the devices returned by
smartctl --scan; - the time and timezone of both machines.
Multiple Proxmox nodes and notifications
In a cluster, install the collector on each node that has physical drives. Give each file collector.yaml a distinct host.id identifier — for example pve20, pve21, and pve22. This label prevents mixing drives from multiple servers in an unreadable dashboard.
Scrutiny can also send alerts using Shoutrrr. Destinations are configured in /opt/scrutiny/config/scrutiny.yaml or with the SCRUTINY_NOTIFY_URLS variable. Keep notification tokens out of the published file and test each channel before relying on these alerts.
Conclusion
This installation preserves the simple logic of the original guide: the interface and InfluxDB live in a small LXC container, while the collector remains as close as possible to the drives on Proxmox. This provides what the native S.M.A.R.T. screen lacks: a centralized view, historical temperatures, and trends long enough to spot a change before the failure.
Discussion
Comments
No comment yet. Feel free to open the discussion with a question or your own experience.