Centralized S.M.A.R.T Management: Monitoring Dozens of Hard Drives with Scrutiny – ITFROMZERO

Table of Contents

Don’t wait for your hard drive to “die suddenly” before scrambling for data recovery

Early in my career, I managed a storage server array with 24 drive bays running 24/7. Every time I heard reports of slow performance or strange “clicking” sounds, I had to manually SSH into each machine.

Then followed a series of commands like smartctl -a /dev/sda while staring at raw data to find any abnormal metrics. The hardest part was when my boss asked, “How’s the hard drive health lately?”, and I had no visual charts or reports to show him immediately.

Many of you might wonder: “Why not use Zabbix or Prometheus for a professional touch?”. In fact, I tried that, but parsing individual S.M.A.R.T attributes (like Reallocated Sector Count or Power On Hours) and building Grafana dashboards took too much time. That’s why I switched to Scrutiny. This tool does only one thing, but it does it exceptionally well: monitoring hard drive health via a modern web interface.

Why should you choose Scrutiny over traditional methods?

Before we dive into the installation, let’s look back at common monitoring methods to see the difference:

Using smartmontools (CLI): This is the root of all tools. It’s lightweight and available on Linux but only suitable for quick checks. If you’re managing 10 or more drives, SSHing into each machine becomes a nightmare.
Zabbix / Prometheus: Very powerful for overall infrastructure monitoring. However, to configure detailed disk attribute extraction, you have to install agents, write scripts, and customize complex Regex.
Scrutiny: Combines the power of smartmontools with a streamlined Web UI. It automatically analyzes metrics, compares them with manufacturer safety thresholds, and provides clear Pass/Fail alerts. Notably, the Hub-Spoke model allows you to aggregate data from 10 servers onto a single screen.

Quick Review of Scrutiny

Pros:

Minimalist Web UI, displaying temperature and drive lifespan in real-time.
Great compatibility with HDD, SSD, and even modern NVMe drives.
Extremely fast deployment with a single Docker Compose file.
Supports notifications via Telegram, Slack, Discord, or Email as soon as an error occurs.

Cons:

Requires root privileges or privileged mode in Docker to read hardware data directly.

Deploying Scrutiny using Docker Compose

I always prefer Docker for its clean packaging and ease of upgrades. Scrutiny consists of two parts: Web (Hub) to store data and Collector to gather metrics. If you’re only using it for a single machine, you can run the Omnibus (all-in-one) version.

Step 1: Create the configuration file

Create a new directory and save the following content into a docker-compose.yml file:

version: '3.5'

services:
  scrutiny:
    container_name: scrutiny
    image: ghcr.io/analogj/scrutiny:master-omnibus
    restart: always
    ports:
      - "8080:8080" # Web UI access port
    volumes:
      - /run/udev:/run/udev:ro
      - ./scrutiny/config:/opt/scrutiny/config
      - ./scrutiny/data:/opt/scrutiny/influxdb
    devices:
      - "/dev/sda:/dev/sda"
      - "/dev/sdb:/dev/sdb"
    environment:
      - SCRUTINY_WEB_INFLUXDB_HOST=localhost

Pro tip: If the server has too many drives, instead of listing each device under devices, you can use privileged: true and map /dev:/dev. However, specifically listing them is preferred for better system security.

Step 2: Start the system

Activate the container with the familiar command:

docker-compose up -d

After about 30 seconds, open your browser and go to http://Server-IP:8080. You will see a modern dashboard listing all hard drives along with their current health status.

Centralized Monitoring for Multiple Servers (Hub & Spoke Model)

This is the most valuable feature for Sysadmins. Suppose you have 5 storage servers; you don’t need to install 5 dashboards. Just install one Scrutiny Hub as the center and lightweight Scrutiny Collectors on the satellite machines.

On the satellite machines, run the following Docker command:

docker run -d \
  --name scrutiny-collector \
  --device=/dev/sda \
  -e SCRUTINY_API_ENDPOINT=http://MAIN-SERVER-IP:8080 \
  ghcr.io/analogj/scrutiny:master-collector

The Collector will periodically scan S.M.A.R.T metrics and push them to the main server. Now, you only need to manage a single browser tab for your entire infrastructure.

Setting up Telegram Alerts

A monitoring system is useless if you don’t know when it fails. I once paid a heavy price for being complacent and not checking the dashboard regularly, resulting in a drive dying completely without me knowing. Configure notifications immediately.

Open the scrutiny.yaml file in the config folder and add the Telegram configuration:

notify:
  urls:
    - "tgram://bottoken/chatid"
  # Scrutiny supports the Apprise standard, compatible with most current chat apps

When the temperature exceeds a threshold (usually 55°C) or the Pending_Sector count increases, Scrutiny will immediately send a message to your phone. It provides great peace of mind!

3 “Hard-learned” lessons for monitoring drive health

After years of working with hundreds of TBs of data, I’ve gathered a few experiences:

Don’t worry too much about Power_On_Hours: An HDD running for 30,000 hours (over 3 years) can still be perfectly fine. Focus on Reallocated_Sector_Count instead. If this number jumps from 0 to 1, it’s a sign you should prepare a spare drive.
Temperature is a silent killer: Most physical damage comes from poor cooling. If a drive consistently stays above 50°C, check the airflow in your case immediately.
NVMe specifics: NVMe SSDs don’t use the same metrics as HDDs. Pay attention to Percentage Used. When this number approaches 100%, the memory chips have reached the end of their write/erase cycle and need early replacement.

Deploying Scrutiny helped me escape tedious manual tasks. Instead of typing commands to check logs, I spend that time optimizing the system, while ensuring data always remains in the safe zone.