> Source: https://glassmkr.com/vs/collectd

# Glassmkr vs collectd: a monitoring product vs a collection daemon.

collectd collects system statistics; Glassmkr collects them, evaluates them, and tells you what to run. Different layers, compared honestly.

Last verified: 2026-08-25. Glassmkr is not affiliated with the collectd project.

> collectd has collected system statistics on Unix machines for about twenty years. It is packaged in essentially every distribution, its plugin model became the default of its era, and an enormous amount of infrastructure has depended on it. Its daemon is MIT licensed, with plugins licensed individually (mostly MIT or GPL-2.0-only) [1](#fn1). Project status, stated factually: the last stable release is 5.12.0, published September 2020; a 6.0 series exists as release candidates (latest rc3, February 2024) described by the project as a preview with expected breaking changes [2](#fn2). Glassmkr is a monitoring product rather than a collection daemon: the AGPL-3.0-only Crucible agent collects hardware-level signals, and the dashboard (same license) evaluates 72 alert rules over them, each with a remediation command attached. Both deployment forms are free: self-hosted with no node limits, or hosted with a 10-node per-account cap.

## Signal coverage, honestly

We audited every collectd host- and hardware-relevant read plugin against Crucible's collectors, row by row, and published the full matrix in the agent repository [3](#fn3). Of 63 rows, Crucible covers 21, partially covers 16, and does not read 26 [3](#fn3). Read that plainly: collectd reads more distinct things than Crucible does. Where Crucible goes further is depth on the hardware-failure signals below, and what it does with them. The short version:

| Signal family | collectd | Glassmkr |
| --- | --- | --- |
| CPU, load, memory, swap, filesystems, disk I/O | Yes | Yes, plus per-signal alert rules |
| SMART and NVMe health | Basic attributes | Attributes, self-test log, NVMe critical warnings, wear, hardware-RAID passthrough, trend evaluation |
| RAID (mdadm), ZFS, hardware RAID CLIs | md plugin; ZFS ARC | mdadm incl. resync progress, ZFS pool + ARC, PERC/MegaRAID/SmartArray/Adaptec |
| IPMI, thermal, fans, voltages | Sensors | Sensors, SEL events, chassis facts, PSU redundancy, hwmon fans and voltages |
| ECC and machine-check | Via mcelog plugin | EDAC counters, IPMI ECC sensors and SEL correlation |
| Network interfaces | Counters | Counters, error subtypes, link state, flap detection, bonding, conntrack, TCP health |
| Open rows | collectd reads some things Crucible does not (per-process aggregates, active ping probing, IB counters, and more). Every open row is listed in the public matrix rather than papered over [3](#fn3). |  |

Cadence is a real difference: collectd samples at ten-second defaults; Crucible snapshots roughly every five minutes. Sub-interval transients can be missed by Glassmkr and caught by collectd. We do not claim high-frequency parity.

## The footprint trade

Crucible is a Node agent shipped as a single binary; it uses more memory than a C daemon and we are not going to pretend otherwise. Measured rather than estimated: on a two-disk Supermicro running Rocky 9.8, 40 samples over 20 minutes spanning four collection cycles gave 77 to 82 MB resident, with a high-water mark of 103 MB that did not move across the run. Hosts with more disks and sensors to enumerate will sit higher, because the cost scales with what there is to walk. An earlier version of this page claimed a transient peak near 875 MB; that figure came from a single process instance we could not reproduce, and the corrected measurement is above. In exchange: it runs unprivileged, with the few root reads going through a narrow fixed-argv wrapper with an allowlisted action set, where collectd's hardware plugins typically want root or broad capabilities. Heavier runtime, smaller blast radius.

## What Glassmkr adds above collection

collectd hands its statistics to whatever you wire behind it; the judgment layer is yours to build. Glassmkr ships it: 72 alert rules tuned on bare-metal failures, a remediation command and verification step on every alert, a trend engine over the latching counters with published evidence [4](#fn4), notification routing, an API, and MCP. If you already run collectd into a mature pipeline you trust, that stack works; this page exists for the people still assembling one.

A migration guide (plugin-to-collector mapping, config translation) is coming; the mapping data is already public in the parity matrix [3](#fn3).

See it on real infrastructure.

The live demo is a seeded, read-only dashboard with real alerts firing. No signup, no card.

[Browse the live demo](https://app.glassmkr.com/demo) [Start free](https://app.glassmkr.com/register)

## Sources

1. collectd licensing: COPYING in the collectd repository (daemon MIT; plugins licensed individually, mostly MIT or GPL-2.0-only). Verified 2026-08-25.
2. collectd releases page on GitHub: 5.12.0 (2020-09-03); 6.0.0-rc0 through rc3 (2024-01-23 to 2024-02-21). Verified 2026-08-25; re-verify at publish.
3. The full parity audit: docs/COLLECTD_PARITY.md in [github.com/glassmkr/crucible](https://github.com/glassmkr/crucible), including every open row and the honesty caveats this page summarizes.
4. [The drive that failed while SMART said PASSED](/blog/smart-said-passed): the trend-engine evidence.

## Compare Glassmkr to other tools

- [Glassmkr vs Datadog](/vs/datadog)
- [Glassmkr vs Prometheus](/vs/prometheus)
- [Glassmkr vs Netdata](/vs/netdata)
- [Glassmkr vs Checkmk](/vs/checkmk)
- [Glassmkr vs Zabbix](/vs/zabbix)
- [Glassmkr vs LibreNMS](/vs/librenms)
- [Glassmkr vs AWS CloudWatch](/vs/cloudwatch)
- [Glassmkr vs New Relic](/vs/newrelic)