> 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 MIT Crucible agent collects hardware-level signals, and the AGPL-3.0-only dashboard evaluates 70 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 12-disk Supermicro running Rocky 9.8 we observed about 180 MB resident in steady state, with a transient peak near 875 MB during collection. The peak is brief and it settles back, but size a small host for the peak, not the average, and hosts with more disks and sensors to enumerate will sit higher. 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: 70 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)