Continuous SMART Monitoring with Performance Co‑Pilot on Fedora

By the end of this guide the reader will be able to install the Performance Co‑Pilot (PCP) SMART agent on Fedora, verify that drive health metrics are being collected, query key SMART attributes, and integrate the data into a Grafana dashboard for long‑term analysis.

Understanding PCP and the SMART PMDA

Performance Co‑Pilot (PCP) is an open‑source framework that provides a unified interface for collecting, storing, and visualizing system performance metrics. Metrics are exposed through Performance Metrics Domain Agents (PMDAs), each responsible for a specific subsystem. The pcp-pmda-smart package supplies a PMDA that reads SMART data from block devices and presents it as PCP metrics.

SMART (Self‑Monitoring, Analysis and Reporting Technology) is embedded in modern HDDs, SSDs, and NVMe devices. It continuously records parameters such as temperature, wear‑leveling count, error rates, and power‑on hours. When accessed through a single‑shot tool like smartctl, the data represents a snapshot. The PCP SMART PMDA, however, polls the device at regular intervals, stores the values in the PCP repository, and enables historical trend analysis.

Installing and Enabling the PCP SMART Agent

The required components are the core PCP daemon (pcp) and the SMART PMDA (pcp-pmda-smart). Installation uses Fedora’s package manager:

sudo dnf install pcp pcp-pmda-smart

The pcp-pmda-smart package installs the PMDA files under /var/lib/pcp/pmdas/smart/. To register the agent with the PCP collector daemon, run the installer script provided in that directory:

cd /var/lib/pcp/pmdas/smart/
sudo ./Install

The installer prompts for configuration options such as the polling interval and the list of devices to monitor. Accepting the defaults configures the agent to scan all block devices that expose SMART data. The installation creates a systemd unit (pmcd) that runs the collector daemon.

Start the collector immediately and enable it to start on boot:

sudo systemctl start pmcd
sudo systemctl enable pmcd

If the daemon needs to be stopped or disabled, use the corresponding systemd commands (systemctl stop pmcd and systemctl disable pmcd). The configuration files remain unchanged, allowing a quick re‑enable later.

Verifying Metric Availability

PCP provides the pminfo utility to list available metrics. To confirm that SMART metrics are being exported, query the metric namespace:

pminfo -t smart

A successful output lists metric identifiers such as smart.attributes.temperature_celsius.value for SATA/SAS drives and smart.nvme_attributes.temperature_sensor_one for NVMe devices. If no SMART metrics appear, verify that the SMART PMDA is enabled in /etc/pcp/pcp.conf and that the collector daemon is running.

Key SMART Metrics for Drive Health

While the SMART namespace contains dozens of attributes, a small subset provides the most actionable insight for proactive maintenance:

  • Temperaturesmart.attributes.temperature_celsius.value (SATA/SSD) or smart.nvme_attributes.temperature_sensor_one (NVMe). Sustained temperatures above 60 °C for HDDs and 70 °C for SSD/NVMe indicate inadequate cooling.
  • Wear Leveling – NVMe devices expose a wear percentage through smart.nvme_attributes.media_and_data_integrity_errors or similar attributes; increasing values over months signal approaching endurance limits.
  • Reallocated Sectors / Bad Blocks – For HDDs, the smart.attributes.reallocated_sector_ct counter increments when the drive remaps defective sectors.
  • Read/Write Errors – Attributes such as smart.attributes.read_error_rate or smart.nvme_attributes.error_log_entries capture error frequencies.
  • Power‑On Hourssmart.attributes.power_on_hours helps correlate wear with device age.

Monitoring these metrics over time allows administrators to spot gradual degradation before it manifests as data loss.

Querying Metrics on Demand

The pminfo command can retrieve the latest value of any metric. For example, to display the current temperature of all detected drives:

pminfo -ft smart.attributes.temperature_celsius.value
pminfo -ft smart.nvme_attributes.temperature_sensor_one

The -f flag formats the output as plain text, and -t adds a timestamp. To watch a metric update in real time, use the pmrep utility with a reporting interval. The following command prints temperature values every five seconds until interrupted:

pmrep -t 5s smart.nvme_attributes.temperature_sensor_one smart.attributes.temperature_celsius.value

Terminate the live view with Ctrl+C. Because pmrep reads from the PCP archive, the same command can be replayed later with a different time window to analyze historic data.

Integrating PCP SMART Data with Grafana

Grafana can visualize PCP metrics through the official PCP data source plugin. The integration steps are:

  1. Install the Grafana PCP plugin on the Grafana server (refer to the plugin documentation for the exact package name).
  2. Configure the plugin to connect to the local PCP collector by setting the address to localhost:44321 (the default PCP port).
  3. Create a new dashboard and add panels that query the desired SMART metrics, for example:
    • Query: smart.attributes.temperature_celsius.value
    • Query: smart.nvme_attributes.temperature_sensor_one
  4. Set the panel’s time range to “last 30 days” or longer to view trends.

Grafana’s alerting engine can also be configured to trigger notifications when a metric exceeds a threshold (e.g., temperature > 70 °C). Alerts rely on the same PCP data, ensuring that notifications are based on the continuous monitoring stream rather than an ad‑hoc snapshot.

Trade‑offs and Operational Considerations

Deploying continuous SMART monitoring introduces a few practical considerations:

  • Resource Overhead – The SMART PMDA polls devices at a configurable interval (default is typically one minute). On systems with many drives, the cumulative I/O load is modest but should be verified on low‑power appliances.
  • Data Retention – PCP archives metrics in a circular buffer. Administrators must size the archive to retain enough history for meaningful trend analysis (e.g., several months). The archive size is controlled in /etc/pcp/pcp.conf via the archive_size parameter.
  • Device Compatibility – Not all drives expose the same SMART attribute set. The PMDA gracefully skips missing attributes, but dashboards should handle absent metrics to avoid false alerts.
  • Security Context – Access to SMART data requires read permissions on the block device. The PMDA runs as the pcp user, which is granted the necessary group membership during package installation. Review the user’s privileges if the system enforces strict SELinux policies.
  • Failure Detection vs. Prediction – SMART provides early warning signs but cannot guarantee failure prediction. Correlating temperature spikes with workload patterns and maintaining regular backups remain essential components of a robust storage strategy.

By balancing these factors, administrators can leverage PCP’s continuous SMART collection to move from reactive troubleshooting to proactive drive health management.

Source: fedoramagazine.org

Popular Posts

Install Ollama and Open WebUI on Ubuntu 24.04 with NVIDIA GPU Acceleration (Step-by-Step)

Install Ollama + Open WebUI on Ubuntu 24.04 with NVIDIA GPU Acceleration (Step-by-Step)

Install a Local AI Chatbot on Ubuntu 24.04 with Ollama and Open WebUI (Step-by-Step)

Trending Now

Recovering from Btrfs Boot Failures Using GUI Tools on Fedora

By the end of this guide the reader will be able to identify a Btrfs‑based Fedora installation, boot from a live USB, list and restore snapshots using the graphical utilities btrfs‑assistant and snapper, and verify that the system returns to a functional state without resorting to the command line. Understanding the Btrfs Layout Used by Fedora Fedora Workstation and Fedora KDE install the root filesystem as a single Btrfs partition that contains two default sub‑volumes. One sub‑volume holds the traditional “/” hierarchy, while the second is dedicated to /var/lib/machines . The latter exists to keep container images out of snapshot operations; it remains empty on systems that do not run virtual machines. Because Btrfs stores data in sub‑volumes rather than separate partitions, a snapshot captures the state of an entire sub‑volume at a point in time. The installer (Anaconda) automatically registers these sub‑volumes with the snapper service. Snapper maintains a series of read‑only ...