OPEN SOURCE LINUX SERVER MONITORING
Know when your server is in trouble, and what to do next.
Glassmkr watches the Linux and hardware signals most people never configure, explains what needs attention, and gives you the next command to run. Install one agent. Use the free hosted dashboard or run the complete stack yourself.
No card. Hosted accounts are free up to 10 nodes. Self-hosted has no node limit. View the source on GitHub
One disk has dropped out of the RAID array. The server is still online, but it has lost redundancy. Replace or safely re-add /dev/sdd before another disk fails.
EVIDENCE
md0 (RAID10) is running degraded: 1 of 6 devices failed (/dev/sdd). Array is still online; rebuild has not started (no spare).
NEXT SAFE STEP
You run the software. Glassmkr watches the server underneath it.
You might run an application, database, game server, storage box, or AI workload. You know how to deploy it and keep it useful, but you do not have an infrastructure team deciding which disk, memory, cooling, kernel, and network signals deserve an alert. Glassmkr brings that judgment with the product.
- You have one to a few Linux servers and no dedicated SRE team.
- You can use SSH and sudo, but monitoring is not your specialty.
- You want defaults that work before you learn a query language.
- You want an alert to explain the risk and the next step.
Glassmkr monitors the server and its hardware. It does not replace application tracing, external uptime checks, or Kubernetes monitoring.
WHAT GLASSMKR WATCHES
WHAT IT CONCLUDED
WHAT YOU DO NEXT
Replace /dev/sdd and re-add it to the array, then watch the rebuild. The alert carries the full remediation, including the path when the hardware is rented and the provider must act.
You should not have to design a monitoring system first.
| Without Glassmkr | With Glassmkr |
|---|---|
| Decide which hardware and Linux signals matter | Supported signals are detected automatically |
| Choose thresholds and write alert rules | The generated rule set ships enabled and opinionated |
| Interpret SMART, IPMI, RAID, kernel, and network output | Each alert shows the evidence in context |
| Search for a fix while the server is failing | The alert includes the next check and remediation workflow |
| Build and maintain a monitoring stack | Use hosted, or self-host when you want full control |
The checks most server owners discover only after something breaks.
Drives and storage
failing drives, NVMe wear, degraded RAID, unhealthy ZFS pools, filesystems filling up.
smartctl · nvme · mdadm · zpool · statvfs
Memory and CPU
memory pressure, ECC errors, machine-check events, thermal problems, abnormal load.
meminfo · EDAC · mcelog · hwmon · loadavg
Power and cooling
failed fans, lost PSU redundancy, critical BMC events, unsafe temperatures.
IPMI sensors · IPMI SEL
Network
link errors, bond degradation, speed drops, saturation, and packet problems.
ethtool · /proc/net · bonding · conntrack
Operating system
unexpected reboots, failed services, missing security updates, firewall and kernel state.
systemd · apt/dnf · uptime · kernel logs
GPU hosts
XID events, ECC, thermal throttling, power state, and link health where supported.
nvidia-smi · NVML
Browse all 72 alert rules, each with its evidence fields and remediation →
This is what an alert should tell you.
Not a red badge and a metric name: what happened, the evidence behind the conclusion, the check to run, and the remediation. One real alert, exactly as the product raised it.
1CONSEQUENCE
Standard security support for Debian GNU/Linux 12 (bookworm) ended on 2026-07-11. Extended support (ESM/EUS) may be available until 2028-06-30, but enrollment on this host could not be verified. If it is not enrolled, it is receiving no base-system security updates.
2EVIDENCE
3CHECK
cat /etc/os-release | grep -E '^(NAME|VERSION|VERSION_ID)='4REMEDIATION
Confirm extended-support enrollment (Ubuntu: "pro security-status"; RHEL: check for enabled EUS/ELS repos). Then upgrade the OS, or enrol to keep receiving security fixes until 2028-06-30.
Optional AI analysis can narrate context after the evidence and the fixed remediation. It never replaces them, and it never executes anything.
Start hosted. Self-host when you need the control.
From no monitoring to your first health snapshot in about five minutes.
- Create a free hosted account.
- Name the server.
- Copy the generated install command into SSH.
- Confirm the first snapshot and notification channel.
Glassmkr detects the supported hardware and starts evaluating the shipped checks. You do not need to build a dashboard or choose thresholds before the first useful result.
HOSTED GLASSMKR RECOMMENDED START
Best when you want monitoring without another service to maintain.
Create a free accountSELF-HOSTED GLASSMKR
Best when telemetry must remain on your network or you want complete operational control. Equally available; you carry the operations.
Read the self-hosting guide| Hosted | Self-hosted | |
|---|---|---|
| Source | Same public AGPL-3.0-only stack | Same public AGPL-3.0-only stack |
| Deployment | Nothing to run; one agent per server | Docker Compose on your host, plus the agent |
| Data location | Glassmkr's dashboard in Amsterdam | Your network; telemetry never leaves it |
| Operations | Updates, storage, and backups operated by Glassmkr | You operate databases, upgrades, backups, and TLS |
| Node limit | Free up to 10 nodes | No node limit |
Monitoring sees deep into your server. You should be able to inspect it.
Crucible runs on the machine and reads health data from Linux and supported hardware interfaces. The agent and the dashboard are public under AGPL-3.0-only. Privileged reads use a narrow, fixed-action boundary rather than running the whole agent as root, and the dashboard can be self-hosted, so the monitoring path remains under your control.
- Does it open inbound ports?
- No. The agent reports outbound over TLS and listens on nothing.
- Does it execute fixes?
- No. Remediation is guidance for you; the agent never changes your server.
- What leaves the server?
- Metrics, alert state, and bounded log excerpts, sent to the dashboard you choose.
- Can I self-host?
- Yes. The complete stack is public and runs from one compose file.
- Can I remove it?
- Yes. One systemd unit, one package, one config directory.
THE PRIVILEGE BOUNDARY
Crucible agent
runs as glassmkr, unprivileged
Root-owned wrapper
allowlisted reads: smartctl · ipmitool · mdadm
See what Glassmkr notices on one server.
Start with a server whose history you know. The hosted service is free, and you can remove the agent or point it at a self-hosted dashboard later.