How to Run the Scrutiny Docker Image on TrueNAS Scale

Scrutiny is a “WebUI for smartd S.M.A.R.T monitoring.” With TrueNAS Scale applications now running via Docker Compose, I needed to do some reconfiguration to get Scrutiny running again. This post is about how I have it configured to run via Compose.

Scrutiny logo

About Scrutiny

Why am I interested in running Scrutiny on my TrueNAS machine? Well, that machine has 11 data disks in it, so I appreciate the quick visualization Scrutiny provides into drive health. I also find it cute to review the temperature data over time, and see how the seasons affect my basement’s temperature. :)

Prerequisites

If you haven’t worked through prepping the Scale environment for running Docker, please review my prior post on that topic. Or, at a minimum, watch Tom Lawrence’s extremely helpful guide for creating a dataset with permissions matching what the apps use.

Running the image via docker compose

Here is what the relevant section of my compose.yml file looks like:


networks:
  scrutiny:

  scrutiny:
    container_name: scrutiny
    image: ghcr.io/analogj/scrutiny:v0.8.1-omnibus
    restart: unless-stopped

    cap_add:
      - SYS_ADMIN
      - SYS_RAWIO
    devices:
      - /dev/nvme0:/dev/nvme0
      - /dev/nvme1:/dev/nvme1
      - /dev/nvme2:/dev/nvme2
      - /dev/sda:/dev/sda
      - /dev/sdb:/dev/sdb
      - /dev/sdc:/dev/sdc
      - /dev/sdd:/dev/sdd
      - /dev/sde:/dev/sde
      - /dev/sdf:/dev/sdf
      - /dev/sdg:/dev/sdg
      - /dev/sdh:/dev/sdh
    env_file:
      - ./common.env
    networks:
      - scrutiny
    ports:
      - 8080:8080
      # - 8086:8086
    volumes:
      - ${SERVICE_DATA_DIR}/scrutiny:/opt/scrutiny/config
      - ${SERVICE_DATA_DIR}/scrutiny-influxdb:/opt/scrutiny/influxdb
      - /run/udev:/run/udev:ro

About This Configuration

First, we define the network and image to use for this container. Here, I’m choosing to use the omnibus Scrutiny image, which includes everything Scrutiny needs in one image. I always prefer to pin to specific versions when possible.

Next, we add capabilities to the container, in this case, SYS_ADMIN and SYS_RAWIO. This gives the container needed permissions to scrape data from the data devices. If you don’t have NVMe drives like I do, then you may elide the SYS_ADMIN capability.

Now the big section: devices. This is where I enumerate every drive I’d like monitored — both the NVMe and SATA drives. I think some sort of globbing syntax is available for reducing the number of lines here, but I haven’t tried that. I do not mind being explicit about precisely what should be included and what shouldn’t.

I then pull in the common.env file with environment variables common across all of my containers, like TZ.

Unlike most containers I run, this one does not need any specific environment variables set. It does support a handful of debug customizations, but I don’t need them.

Next, I specify the container’s port mappings. In this case, there’s a sole mapping being used: port 8080 both inside and outside the container. This image also exposes the 8086 port. However, that is for accessing InfluxDB’s web interface, which I have no plans to do. I left that line present and commented out for future reference.

Lastly, I have my volume mappings. First is the configuration directory for Scrutiny itself. Second is the directory for the InfluxDB that Scrutiny uses under the hood. On this computer, service-data resides on the Apps dataset we created within Scale. The final volume mapping is a read-only mapping for the /run/udev file that Scrutiny needs to do its job. It only needs read access; hence we make it read-only.

And, with that, we can now use compose to launch the Scrutiny container and visit the web app on port 8080.

Conclusion

With Scrutiny running, we do need to give it some time to collect data. By default Scrutiny collects data once a day, so after a few weeks, we’ll have some nice data retrieved and visuals to look at.

Thanks to the Scrutiny project for producing this handy tool and Docker image for running it!

Past Posts in This Series

Over the last several years I have produced a number of posts like this for various applications. Below is the complete list. Note: I do not maintain these posts over time, so some may be out of date or otherwise irrelevant. They are left as references only.

Conversation

Join the conversation

Your email address will not be published. Required fields are marked *