Glassmkr vs Netdata: focused bare-metal monitoring vs broad real-time observability.

What’s the same

Both ship open-source agents you can read before installing (GPL-3.0 vs MIT). Both have a SaaS dashboard layer with cloud-aggregated views. Both cover SMART, IPMI, RAID, ECC, ZFS on bare-metal hosts. Both have multi-channel notifications. Both have per-node SaaS pricing in the same ballpark ($3 vs $4.50/node).

What’s different

Alert philosophy

Netdata’s position is breadth: cover everything with reasonable defaults, give you ML to detect anomalies, and let you tune the noise via Cloud’s Alerts Configuration Manager. The Netdata community has tracker discussions about taming the default alert volume during routine operations ⁶; Netdata explicitly built tooling to manage that surface.

Glassmkr’s position is depth on a narrow surface: 60 rules selected by an operator who’s spent a decade in bare-metal infrastructure. The defaults are tuned to "this is genuinely a problem worth waking someone up about." You don’t triage as much, because there’s less surface to triage.

Neither is wrong. They make different bets about what an operator wants.

Resolution

Netdata’s per-second sampling is a genuine differentiator ³. If you’re debugging performance regressions (transient spikes, cache-warm patterns, IO-storm correlation), per-second resolution sees things 5-minute interval monitoring misses. Glassmkr’s 5-minute interval is fine for "did the disk fail" or "is RAID degraded" but won’t catch sub-minute performance dynamics.

Bare-metal coverage

Both cover the standard bare-metal surfaces. Netdata ships dedicated collectors for SMART (via smartctl), IPMI (via FreeIPMI plugin, which on some distros ships as a separate netdata-plugin-freeipmi package ⁵), MegaCLI/MegaRAID, HPE Smart Arrays, mdadm software RAID, ZFS pool state, and EDAC for ECC memory errors ^{5 7}.

Glassmkr’s coverage is similar in scope (SMART, NVMe wear, IPMI sensors, BMC SEL, RAID state, ZFS, ECC). The difference is that Glassmkr exposes 60 opinionated rules with pre-tuned thresholds and per-alert remediation guidance rendered in the dashboard; Netdata exposes the raw metrics plus default thresholds and asks you to decide which signals matter.

When Netdata is the right choice

You need per-second resolution.

For performance debugging, capacity planning under bursty workloads, or correlating sub-minute events, per-second sampling is structurally better. Glassmkr can’t match this without an architecture change.

You need integration breadth.

800+ collectors covers app stacks, databases, message queues, and SaaS APIs that Glassmkr doesn’t. If your monitoring needs span beyond bare-metal hardware, Netdata covers more ground.

You want a local UI on every node.

The embedded dashboard at :19999 on each agent ⁴ is genuinely useful for ad-hoc inspection. Glassmkr doesn’t have this.

You have time to triage and tune a larger default alert set.

If your team has the bandwidth to engage with Netdata’s broader alert defaults and tune them via the Alerts Configuration Manager, you get more detection coverage out of it.

When Glassmkr is the right choice

You want opinionated bare-metal defaults that don’t need triage tuning.

60 rules tuned for "genuinely worth waking someone up." If you don’t have time to engage with hundreds of default alerts, fewer well-tuned rules win.

You prefer MIT to GPL-3.0.

Both are open source; the licensing difference matters for some compliance contexts. MIT is more permissive; GPL-3.0 is copyleft.

Per-second resolution isn’t worth the cost.

For typical bare-metal failure modes (disk failures, RAID degradation, ECC trends, kernel panics), 5-minute sampling is sufficient. The cost of per-second is bandwidth + storage + the ML model overhead.

You want a smaller agent codebase.

Crucible is targeted: collects bare-metal metrics and ships them. Netdata is a larger codebase by design (the broader collector coverage justifies it).

Migration: switching from Netdata to Glassmkr

Netdata Agent → Glassmkr Crucible agent. One per host. Different license; same install pattern.

Netdata Cloud Spaces / Rooms → Glassmkr Dashboard fleet view. Per-server detail pages. Glassmkr doesn’t have the same multi-tenant Rooms concept; if you use Netdata’s organisational grouping, evaluate whether Glassmkr’s tags cover the use case.

Netdata default alerts → Glassmkr’s 60 rules. Expect fewer alerts firing in steady state. If you depended on Netdata’s broader default detection (process count anomalies, container restart counts, etc.) you’ll have less coverage for those areas after migration.

Netdata Cloud dashboards → Glassmkr server detail pages. Per-server, with metrics charts and alert state.

The honest trade-off: you lose per-second resolution, the embedded local UI, and most app-stack collectors. You gain a smaller opinionated rule set with per-alert remediation guidance built in.