Half the "problems" on a marketplace GPU host are required config. So we taught Glassmkr the difference.
Three alert rules fired on every box in our 20-box GPU fleet on Vast: no firewall, automatic updates disabled, GPU power cap throttling. All three were correct readings of the system. All three were the wrong thing to alert on, because that configuration is exactly what a marketplace GPU host is supposed to have. The same signal that is a finding on one host is required config on another. So we stopped treating every host the same.
Same signal, different meaning
A firewall that is off is a real finding on a public web server. On a Vast GPU host it is mandatory: the box has to keep its rental port range open, and a host firewall fights Docker's own iptables rules. Turn it on and you break the box.
Automatic security updates being disabled is a finding on a normal Linux server. On a GPU host it is deliberate: an unattended upgrade will bump the NVIDIA driver out from under the running CUDA stack, fail to match the loaded kernel module, and de-verify the host on the marketplace. You disable auto-updates on purpose and patch in a controlled window.
A GPU sitting under its factory power cap is worth a look on a box you own and tune. On a fleet of rented A16s and A6000s that ship a conservative default, it is just the default.
None of these readings are wrong. The mistake would be to nag the operator about all of them, on every box, forever. That is how a monitor trains you to ignore it.
Muting one rule at a time does not scale
The blunt tool is muting: silence no_firewall on box 1, box 2, box 3, and so on. We did exactly that to get our fleet quiet, and it works, but it has three problems. It is manual and per-host, so a new box starts noisy again. It records that you silenced a rule but not why, so the next operator cannot tell an intentional mute from a forgotten one. And it hides the rule entirely, so if the meaning ever changes you do not find out.
Host-type profiles
So Glassmkr now understands that a host has a role. Set a server's profile to Marketplace GPU host and the rules that are expected-by-design for that role stop nagging: the firewall, the auto-updates, and the default power cap go quiet for that profile, with the reason recorded, while everything that is genuinely a problem (a failing drive, the driver-will-not-survive-reboot check) keeps firing exactly as before. We later folded the kernel-CVE alert into the same profile, for the same reason: on these hosts those CVEs are patched on a scheduled maintenance reboot the operator chooses, not auto-applied. The profile silences the rules that are wrong for this host type, not the ones that matter.
The difference from muting is that this is declarative and correct by construction. A box you onboard into the profile is born quiet on the expected noise and loud on the real problems. The suppression is documented as "expected for this host type," not buried as a per-rule mute. And the alerts are suppressed, not deleted: you can still see them when you want the full picture.
Shipping the feature was not enough
There is a postscript worth telling, because it is the kind of thing that usually goes unsaid. We shipped host profiles, and a few days later looked at the fleet: every box still read "no profile." The feature worked. Nobody had applied it, so it was suppressing nothing. A feature that needs a manual step on twenty boxes is a feature that mostly does not happen.
So we made the monitor do the noticing. A host whose tags mark it as a marketplace box, with no profile set, now gets a one-click prompt on its page: this looks like a marketplace GPU host, apply the profile? The suppression you would have configured by hand is offered at the moment you are looking at the noise. The lesson generalizes past this one feature: context-awareness you have to switch on by hand mostly stays off.
This is the same principle, applied to context
We have written before about monitoring that punishes the people it is supposed to help: alerts that fire on things the operator cannot or should not change, until the operator stops reading them. Host profiles are the same idea pointed at host context. An alert is only useful if it is actionable for this host. A marketplace GPU box and a database server are not the same machine wearing different names, and a monitor that pretends they are will be wrong on one of them.
A monitor should know what it is looking at
If you run hosts you do not fully control, or fleets where the "right" configuration is unusual on purpose, the answer is not to lower your standards or to drown in mutes. It is for the monitor to understand what kind of host it is looking at. That is what host profiles do, and it is why our 20-box fleet went from a wall of expected noise to a short list of things actually worth your time.