Glassmkr Documentation

#What Glassmkr Monitors

Glassmkr is a monitoring agent for bare metal and dedicated servers. The agent collects hardware and OS metrics every 5 minutes and pushes them to the Glassmkr dashboard, where 38 alert rules evaluate each snapshot automatically.

38 alert rules evaluate on every collection cycle. All rules included on every plan, including Free.

#Quick Start

Docker (recommended)

# 1. Create config directory
sudo mkdir -p /etc/glassmkr

# 2. Add your collector key (get it from glassmkr.com after signing up)
sudo tee /etc/glassmkr/collector.yaml << 'EOF'
server_url: https://app.glassmkr.com
collector_key: gmk_cru_live_YOUR_KEY_HERE
interval: 300
EOF

# 3. Download and start
curl -O https://raw.githubusercontent.com/glassmkr/crucible/main/docker-compose.yml
docker compose up -d

# 4. Verify
docker compose logs glassmkr-crucible

The container runs with --privileged and network_mode: host for IPMI, SMART, and bond monitoring. See Security for details.

npm alternative

npm install -g @glassmkr/crucible
sudo glassmkr-crucible --config /etc/glassmkr/collector.yaml

Requires Node.js 24+. System packages smartmontools, ipmitool, dmidecode needed for full hardware monitoring.

Your server appears in the dashboard within 5 minutes.

Sign up free to get your collector key.

#Alert Rules Reference

State alerts auto-resolve when the condition clears. Event alerts (unexpected_reboot) stack occurrences and have a Resolve button. Acknowledged alerts still auto-resolve.

#Trend Warnings

A Pro-tier feature that surfaces early warnings when metrics show degradation trends before the alert thresholds fire. Separate from the 38 alert rules (which fire on current state).

Trend warnings run in a 6-hour batch process on Glassmkr's backend. They analyze up to 90 days of metric history per server, apply correlation rules that require two independent signals, and optionally consult an internal ranking model trained on Backblaze's public drive failure dataset. The result is a small number of high-confidence warnings per server, not noisy anomaly detection on every metric.

What gets monitored

Severity tiers

• Imminent (red): projected failure within 7 days, or critical pattern (SMART 187 appearance, NVMe critical_warning). Push notification immediately.
• Soon (orange): projected within 30 days, or high-severity evidence. Push notification once.
• Scheduled (blue): projected within 90 days, or medium-severity. Dashboard only.
• Watch (grey): low confidence or more than 90 days out. Dashboard collapsed.

Correlation requirement

Where two signals exist on the same device, correlation is required before a notification. Several v1 categories fire on a single high-confidence signal because the underlying source is itself authoritative (a SMART step-change from zero, NVMe critical_warning bits, a PSU rail at 11.62V). The asymmetry is deliberate.

Multi-signal categories shipped in v1:

• Drive SMART signal + ZFS errors on the same device = storage device degradation
• Fan RPM decline + chassis temp rise in the same zone = cooling failure

Multi-signal categories planned for v1.1 once the underlying collector work lands:

• NVMe health signal + p99 latency inflation = NVMe pre-failure (fail-slow)
• NIC CRC errors + TCP retransmits on the same interface = NIC hardware failure
• ECC burst + MCE entries for the same DIMM = DIMM pre-failure

This approach trades some recall (failures that only show one signal) for high precision. Google's FAST 2007 study found roughly 40-50% of drive failures in the field show no SMART-visible warning, so trend warnings are a meaningful reduction of surprise failures, not a guarantee that every failure becomes predictable.

What we explicitly don't do

• No general-purpose anomaly detection on every metric. Netdata's own docs demote their anomaly ML to "investigation aid, not alert source." We agree.
• No per-customer model training. With 3-50 servers per account, customer-specific models are base-rate-dominated. We use global thresholds plus an offline-trained ranker on Backblaze's public dataset.
• No LLM-based trend classification. Linear regression, CUSUM, and first-differences do this job better and cheaper. We use AI only to narrate deterministic findings in plain English.
• No confident failure predictions. We say "likely within 7-14 days", never "will fail on Tuesday." The underlying signals carry real uncertainty and we surface it.

Data requirements

• Trend warnings for SMART, NVMe, ECC, cooling, PSU, and NIC require 90-day metric retention (Pro feature).
• Disk space projection works on 7-day data (available on Free tier).
• A server needs at least 3 days of contiguous data to receive any warnings. Freshly added servers are in an observation period.

Self-audit

The dashboard shows the feature's own track record: how many warnings were sent in the last 90 days, how many users confirmed were valuable, how many were dismissed, and how many were followed by a matching alert firing within 30 days. No other monitoring tool surfaces this, and it exists so you can audit whether trend warnings are actually earning their keep for your fleet.

#Configuration Reference

# Required
server_url: https://app.glassmkr.com
collector_key: gmk_cru_live_YOUR_KEY_HERE

# Optional
interval: 300          # Collection interval in seconds (default: 300)
# hostname: my-server  # Override auto-detected hostname
# modules:             # Disable specific collection modules
#   ipmi: false
#   smart: false
#   zfs: false
#   security: false

server_url

The Glassmkr ingest endpoint. Always https://app.glassmkr.com for the hosted service.

collector_key

Your server's authentication token. Generated when you add a server in the dashboard. Prefixed with gmk_cru_live_ (older keys may still use the legacy col_ prefix until rotated).

interval

How often (in seconds) the agent collects and pushes a snapshot. Default is 300 (5 minutes). Minimum is 60.

hostname

Override the auto-detected hostname. Useful when the system hostname is generic or changes between reboots.

modules

Disable individual collection modules. Set any module to false to skip it. The agent will not attempt to read sensors for disabled modules.

#System Requirements

Operating System

Linux with systemd. Tested on Debian 11/12, Ubuntu 20.04 to 24.04, Rocky 8/9, AlmaLinux 8/9.

Runtime

Docker (recommended) or Node.js 24+.

Privileges

Root access required for IPMI, SMART, and /proc system reads.

Network

Outbound HTTPS on port 443 to app.glassmkr.com. No inbound ports needed.

Resource usage

Approximately 90 MB RSS. Varies by hardware; servers with more IPMI sensors or drives use slightly more.

Optional packages (npm install only)

smartmontools, ipmitool, dmidecode for full hardware monitoring. Missing packages are silently skipped.

#How It Works

• The agent is MIT open source: github.com/glassmkr/crucible
• Agent pushes outbound only, opens no inbound ports
• Snapshots contain hardware metrics only, no user data
• Dashboard runs on EU dedicated servers, no cloud providers
• AI analysis runs on a self-hosted GPU, no external AI providers

#Notification Channels

All channels support per-priority filtering (P1 to P4). Agent update notifications send major version alerts to everyone; patch notifications are opt-in.

#Pricing

#FAQ

#Links