You wake up one morning to find your home server unresponsive, after some investigation you discover a failed NVMe drive taking your self-hosted services and data with it. Perhaps you’re a system administrator and a workstation’s SSD has been silently accumulating errors for months, and now a user is reporting corrupted files. Drive failures are rarely instant, they give subtle warnings (through rising temperatures, increasing error counts, and wear indicators) but only if you’re watching. Most people will only check on disk health after problems start, by then it may be too late. Performance Co-Pilot (PCP) is an open source…
Read More
Sorry, I don’t quite understand what Grafana has to do with this. Do we need a warning that something bad is about to happen, or should we monitor it ourselves?
And I especially don’t understand why we can’t use any nvme_exporter, of which there are quite a few.
Thanks.
P.S. For example: GitHub - fritchie/nvme_exporter: Prometheus exporter for nvme smart-log metrics · GitHub
Hi,
Grafana was included as a way to visualise the data collected by PCP and the disk monitoring agents covered in the article. There are other options for visualisation, pmchart is one example but the PCP Grafana integration is popular and felt like a natural fit here.
The PCP based setup in the article is intended as an introduction and a taster of what Performance Co-Pilot can do. One of PCP’s strengths is that it monitors system-wide health (CPU, memory, GPU, drives and even running applications) through a single framework, so you get drive monitoring alongside everything else without needing separate tools for each.
The provided pmie rules can serve as a starting point for automating warnings when drive health metrics change and I would encourage exploring the PCP docs in the conclusion for more information about what can be done with PCP and how to expand on this.
The nvme_exporter you linked is a Prometheus exporter, which is a valid alternative monitoring approach. The article focused on PCP since it’s well-integrated with Fedora and covers more than just NVMe drives.
Thanks
Hi system, I see the SynthID watermark in the right corner, so this is AI generated. Check here for more info. the linked message goes to packages, but it’s for all fedora for what I know.
Thank you very much. Everything is clear.
What are the pros and cons of pmcd vs smartd? I’ve always used smartd, and this article is my first introduction to pmcd. Why should I switch?
Great question, smartd and pmcd serve different purposes and you don’t necessarily need to switch from one to the other.
smartd is focused specifically on SMART monitoring. It polls drives at a set interval, tracks attribute changes and can send email alerts or run scripts when thresholds are crossed. It’s lightweight and does its job well. If all you need is drive health alerts smartd is perfectly good choice.
pmcd (via the SMART PMDA) collects the same SMART data but brings it in the PCP’s broader monitoring framework. The main advantages are:
- Unified monitoring: Drive health sits alongside CPU, memory, GPU, networks and other system metrics in one place.
- Historical logging: pmlogger records metrics over time so you can look back at trends, not just react to threshold crossings.
- Flexible visualisation: Tools like Grafana, pmchart and pmrep let you explore and correlate drive data with other system activity.
- WWID-based tracking: Drive identities survive device name changes across reboots.
The trade-off is complexity, smartd is a single service with a straightforward config file. PCP is a full monitoring framework with more moving parts (pmcd, PMDAs. pmlogger, pmie, pmproxy if using Grafana). If you’re looking at widening to full system monitoring alongside drive metrics PCP is a great option. If you only care about drive health alerts and nothing else, smartd is simpler to maintain.
They can also coexist, there’s nothing stopping you from keeping smartd for alerts while using PCP to log and visualise the same data over time.
Thanks
You wake up one morning to find your home server unresponsive because you activated these logging service that filled you ROOT filesystem. And this will only be fixed if you create another filesystem mounted on /var/log/pcp
This is a fair concern, any logging service needs to manage its disk footprint. Although not covered in the article PCP manages this out of the box.
The pmlogger_daily service runs automatic log rotation, compression (using xz by default) and pruning on a configurable retention schedule (by default this is 14 days). You can adjust the retention period and maximum space used to fit your available storage.
On a typical home server with default SMART metric collection, you’re looking at a modest footprint in the size of tens of megabytes a day, this isn’t the kind of unbounded growth that would fill a root filesystem.
That said, dedicating a separate partition or filesystem for /var/log can be best practice choice for any server regardless of what services you are running, though filesystem layout is outside the scope of this introductory post.
Thanks
Thank you Paul. I was looking for better general performance logging and your article was very welcome. I wish I could have more educational materials and videos about these packages and tools, PCP, Grafana etc. I appreciate if you have something to recommend. Thank you in advance.