Proxmox and Monitoring 12 min read

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.

Proxmox window displaying raw S.M.A.R.T. data of an NVMe drive
Proxmox can display an instantaneous S.M.A.R.T. report, but does not keep its evolution over time.

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.

Downloading the Ubuntu 22.04 template in the Proxmox interface translated into French
In the Proxmox storage, open Container Templates, then download Ubuntu 22.04 Jammy.

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.
Steps to create the Scrutiny LXC container in Proxmox with an 8 GiB disk and a fixed IP address
The container in the example uses ID 110, the name scrutiny, Ubuntu 22.04, an 8 GiB disk, and the fixed address 192.168.68.144/24.

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.

Empty Scrutiny dashboard before the first S.M.A.R.T. collection
The dashboard remains empty as long as no collector has sent it measurements.

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.

Detailed sheet of a Kingston NVMe SSD in Scrutiny
Scrutiny groups the model, serial number, capacity, temperature, and important attributes of the drive.
Complete list of NVMe S.M.A.R.T. attributes in Scrutiny
The detailed view allows browsing the NVMe attributes and their individual history.
Scrutiny dashboard with two NVMe SSDs and their temperature curve
After collection, the drives appear with their status, temperature, capacity, and a historical curve.

If the interface remains empty, check both sides:

  • journalctl -u scrutiny-collector.service -n 100 --no-pager on Proxmox;
  • docker compose logs --tail=100 scrutiny-web influxdb in the LXC;
  • TCP access to port 8080 between 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.

References

About the author

Jeremy Kraft runs the infrastructure and the self-hosted services of the IBCSC. These guides describe configurations that were actually deployed and re-checked before publication.

Discussion

Comments

0

No comment yet. Feel free to open the discussion with a question or your own experience.

Have an account? Sign in

Plain text, 2 000 characters maximum. New comments are moderated. Your name is shown with the comment. No e-mail address is asked; only a non-reversible fingerprint of your IP address is kept to fight spam.