Scrutiny is “a Hard Drive Health Dashboard & Monitoring solution, merging manufacturer-provided S.M.A.R.T metrics with real-world failure rates.” I have a small network-attached storage (NAS) device at home with pretty much all of my historical data on it — including mine and my wife’s graduate theses — and we really don’t want to lose data like this. Scrutiny helps me get an idea if the system itself thinks a problem may be imminent.
This is my ninth post documenting images I use at home. You can also read about how I run the Unifi controller, how I run Plex, how I update DuckDNS, how I run Duplicacy., how I run Heimdall, how I run Librespeed, how I run Home Assistant, and how I run NetBox.
About LinuxServer.io
LinuxServer.io describes their organization as:
A group of like-minded enthusiasts from across the world who build and maintain the largest collection of Docker images on the web. At our core are the principles behind Free and Open Source Software. Our primary goal is to provide easy-to-use and streamlined Docker images with clear and concise documentation.
I’ve been using LinuxServer.io images for a couple of years. That’s because they’re easy to use, and they’re clearly and concisely documented. I tend to check here first when I need a new image.
Server and Client Arrangement
Thus far, every container I’ve set up runs exclusively on one system. My arrangement for Scrutiny is different — I have one instance running as a client on my Synology DS218+ device, and another instance running on my primary container host running as a server. If I had more clients, I’d point them to the same server, which will helpfully aggregate the data into one place.
Running the Containers Via docker-compose
LinuxServer.io only officially supports running a container via docker run or, preferably, docker-compose.
Client configuration
Here is what the relevant section of client’s docker-compose.yml file looks like:
networks:
scrutiny-nas:
name: scrutiny-nas
services:
scrutiny-nas:
container_name: scrutiny-nas
image: lscr.io/linuxserver/scrutiny:060ac7b8-ls23
restart: unless-stopped
cap_add:
- SYS_RAWIO
devices:
- /dev/sda:/dev/sda
- /dev/sdb:/dev/sdb
environment:
- PUID=1026 # my user id
- PGID=100 # users group
- TZ=America/Detroit
- SCRUTINY_API_ENDPOINT=http://obfuscated.hostname:8081
- SCRUTINY_COLLECTOR=true
networks:
- scrutiny-nas
volumes:
- /volume1/docker/scrutiny-nas:/config
- /run/udev:/run/udev:ro
First, I create an explicitly-named network for Scrutiny to use. This helps ensure services are isolated and avoids the automatic names docker-compose generates. The names aren’t bad, but I like the explicit names better.
Second, I’ve named this service scrutiny-nas based off an obfuscated hostname this client is running on (nas). It’s not strictly necessary, but I appreciate the explicitness.
Third, using the image parameter, I point Docker at the specific version of the Scrutiny image I want to be running.
Now let’s talk through some of the more interesting configuration.
cap_add:
- SYS_RAWIO
devices:
- /dev/sda:/dev/sda
- /dev/sdb:/dev/sdb
environment:
- PUID=1026 # my user id
- PGID=100 # users group
- TZ=America/Detroit
- SCRUTINY_API_ENDPOINT=http://obfuscated.hostname:8081
- SCRUTINY_COLLECTOR=true
networks:
- scrutiny-nas
volumes:
- /volume1/docker/scrutiny-nas:/config
- /run/udev:/run/udev:ro
The cap_add and devices sections and second line of volumes add the access Scrutiny needs to examine the two specified disks.
The environment section contains the usual mix of LinuxServer.io image parameters — PUID, PGID, and TZ. In this case, that means PUID and PGID map to my user id and group id on my NAS. TZ specifies my timezone.
The more interesting parameters are SCRUTINY_API_ENDPOINT and SCRUTINY_COLLECTOR. The former specifies the server URL, and the latter specifies that this instance should run only as a collector (client).
Finally, the /volume1/docker/scrutiny-nas:/config mapping specifies where to store persistent data.
Server configuration
networks:
scrutiny-web:
name: scrutiny-web
services:
scrutiny-web:
container_name: scrutiny-web
image: lscr.io/linuxserver/scrutiny:060ac7b8-ls23
restart: unless-stopped
env_file:
- ./common.env
- ./secret.env
environment:
- SCRUTINY_WEB=true
networks:
- scrutiny-web
ports:
- 8081:8080
volumes:
- ${SERVICE_DATA_DIR}/scrutiny-web:/config
This time, I’ve got a network named scrutiny-web, as this instance will aggregate the data and visualize it via a web app. I’m also using the same version of the LinuxServer.io image but configured differently.
The key configuration difference is the SCRUTINY_WEB environment variable. It is set to true, which means it will accept data from a client. Additionally, in this case, I do not have SCRUTINY_COLLECTOR set, so Scrutiny will not collect any data on this instance. Server only.
I have my port configured to the 8080 port Scrutiny needs inside the container but mapped to 8081 externally, to avoid colliding with my Unifi Controller instance.
Lastly, my persistent data is stored in ${SERVICE_DATA_DIR}/scrutiny-web and mapped to LinuxServer.io images’ typical volume of /config.
Drive Data on Display
Though S.M.A.R.T. data is readily accessible, connecting to multiple machines and reading it from the command line is tedious. Scrutiny aggregates this data into a single point of entry and makes the data super readable.
Big thanks to the authors of the Scrutiny project, and the LinuxServer.io team, for making this application readily available.