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 hosted dashboard layer with cloud-aggregated views. Both cover SMART, IPMI, RAID, ECC, ZFS on bare-metal hosts. Both have multi-channel notifications.

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: 70 rules across 9 categories, 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. Every rule ships with deep FIX content (copy-pasteable remediation, verdict prior, rollback notes); 30+ are verified end-to-end on real hardware.

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 five-minute interval monitoring misses. Glassmkr’s five-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 70 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.

70 rules across 9 categories, 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. Agent footprint is under 1% of host RAM on every host we tested (around 110 MB RSS, median 108 across 10 hosts on Crucible 0.13.6), effectively 0% CPU at the default five-minute interval.

You want the whole product open source, web UI included.

Netdata’s agent core is genuinely open (GPL-3.0-or-later), but the dashboard UI you actually look at (v2/v3) is closed source under the Netdata Cloud UI License and delivered via CDN ⁸, and the central multi-node views and SSO live in their closed Cloud. Every part of Glassmkr, web UI included, is in the open AGPL-3.0-only repo; the agent is MIT.

Per-second resolution isn’t worth the cost.

For typical bare-metal failure modes (disk failures, RAID degradation, ECC trends, kernel panics), five-minute sampling is sufficient. Hardware failure modes don’t develop at sub-minute timescales. 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).

Self-hosting

Both agents self-host, but the products diverge above that. Self-hosting Netdata means running open agents whose modern dashboard UI is closed source and CDN-delivered, with the multi-node aggregation and SSO in their closed Cloud. Self-hosting Glassmkr means running the entire product from the open repo: AGPL-3.0-only dashboard, MIT agent, one docker-compose file, no node limits, and no closed component anywhere in the path.

Self-host in 10 minutes.

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 organizational grouping, evaluate whether Glassmkr’s tags cover the use case.

Netdata default alerts → Glassmkr’s 70 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.