Getting telemetry off a server is supposed to be the easy part and somehow never is — agents to install, configs to write, credentials to manage, a separate tool for metrics and another for logs. The 24Observe Sensor collapses all of that into a single command. Run it on a host and within a minute it is shipping system logs and host metrics, has redacted its secrets at the edge, has self-enrolled with a scoped credential, and has appeared as a live node on your topology map.
The reason so many servers go unmonitored is not that teams do not care. It is that the cost of onboarding each one — install an agent, write a config, manage a credential, do it again for metrics — is just high enough to keep getting deferred.
Every step in a typical agent setup is a small tax, and the taxes compound. You install a logging agent, then a separate metrics agent, because the tooling treats them as different problems. You write a configuration file by hand, which means you maintain a configuration file by hand, which means it drifts. You generate a credential and copy it onto the box, which means you now have a long-lived secret sitting on a server with more access than it should have. Multiply that by a fleet and onboarding becomes a project, so the marginal server — the one that is "probably fine" — never gets instrumented, right up until it is the one that fails silently.
There is a security cost hiding in there too. The credential you copied onto the host can usually do far more than ship telemetry, so a compromised box becomes a foothold. And the logs that agent ships often carry secrets straight off the machine — tokens in stack traces, keys in environment dumps — into your log store, where they sit waiting to be discovered in an audit. The convenience of "just ship everything" quietly becomes a liability.
The Sensor is built to make onboarding cheap enough that you stop deferring it, and safe enough that doing so does not create new problems. One command installs a signed package that ships both logs and host metrics, so there is no second agent. It writes its own configuration and self-enrolls, so there is nothing to hand-maintain. It exchanges a fleet-wide enrollment token — which can only enroll, never read — for a per-host credential scoped to telemetry alone, so a compromised host cannot become a foothold. And it strips secrets at the edge before anything leaves the machine, so the convenience does not cost you your credentials. Onboarding the tenth server is exactly as fast and exactly as safe as the first.
That low, flat cost changes behaviour. When instrumenting a host is a one-liner with no maintenance and no security trade-off, you instrument the marginal server too — and the marginal server is usually the one whose silent failure would otherwise have surprised you.
A server you did not bother to instrument is a server you will debug blind. The fix is to make instrumenting it cost one command and nothing afterwards.
The Sensor is opinionated on purpose: it collects the things almost every host should be reporting, lets you layer on the rest, and makes each host a health-aware node rather than just a log source.
Journald logs ship out of the box, searchable in the same readable language as everything else and watched by the same detections. Logs →
CPU, memory, disk, and network as first-class series — chartable and alertable beside your application metrics, no second agent. Metrics →
Opt-in add-ons for container logs, web-server access and error logs, system audit events, and forwarded syslog — enabled per host with a flag or a checkbox.
Secrets are matched and stripped on the host, before anything is sent — so a credential in a log never crosses the wire or reaches storage.
Each host joins the topology map with a live health state, so it is part of your blast-radius picture, not an isolated stream.
sensor.offline and sensor.online events mean a host dropping off becomes an incident you are told about, not a gap you find days later.
What actually happens between running one command and having a server that is searchable, charted, and watched — and why the fleet that follows is as easy as the first host.
You have a new server — a web box, freshly provisioned, currently invisible. In the dashboard you generate an install command, which mints a scoped enrollment token and drops it into a one-liner with the token already filled in. You run that line on the host as root. The first thing it does is fetch and verify a signed package, so you are not piping an anonymous binary into a root shell and hoping; what installs is what you expect.
The Sensor then does the setup you would otherwise do by hand. It exchanges the enrollment token for a per-host credential that can only ship logs and metrics — the enrollment token itself could never read your data, and now even the host's own token cannot — writes its configuration, turns on edge redaction, and starts as a managed service. No config file authored by you, no long-lived broad credential copied onto the box, no second agent for metrics. Within a minute, journald logs and host metrics are flowing.
Immediately the host stops being a blind spot. Its logs are searchable in the same language as the rest of your estate and are already being evaluated by the security and reliability detections. Its CPU, memory, and disk are chartable series you can put a threshold on. And it has appeared as a node on the topology map with a healthy status — so it is part of your blast-radius picture from the first second, not an island.
Now scale it. The same enrollment token onboards the next host, and the next; one token can bring up your whole fleet because all it can do is enroll. Each host you add becomes another health-aware node, and the platform starts watching for their absence: if one drops off, a sensor.offline event opens an incident, so a dead box is something you are paged about rather than something you discover during the next outage it was silently part of.
A month later, when a host genuinely fails, none of this is a scramble. The box was instrumented because instrumenting it cost one line; its logs and metrics are there to explain the failure; its place on the map shows what depended on it; and its going-offline was itself the alert. The boring discipline of "instrument everything" became achievable precisely because the Sensor made the marginal host free to onboard and safe to trust.
The first install is the demo; the hundredth host is the real test, and that is where the Sensor's design pays off rather than its novelty. Because every host self-enrolled with a per-host credential, rotating a box's token is the same one-liner you used to install it — there is no credential spreadsheet to reconcile, no shared secret whose rotation means touching every server at once. Refreshing a token is a routine, low-stakes act rather than a coordinated event you keep postponing because it is risky.
Decommissioning is just as clean. When a host is retired, its per-host credential is scoped to that host alone, so revoking it closes that box's access without disturbing anything else, and its going-quiet is itself an event the platform already understands. You are not left wondering whether a long-lived broad credential is still floating around on a machine you turned off months ago — there was never a broad credential to worry about.
Profiles are what let one fleet hold many kinds of host without one sprawling configuration. A web server runs the access-and-error-log profile; a container host runs the container profile; a box with compliance requirements runs the audit profile; an appliance forwarding syslog runs the syslog profile. Each host collects exactly what is relevant to its role, chosen with a flag or a checkbox, so you are not shipping irrelevant noise from every machine or hand-authoring a bespoke pipeline per server. The fleet is heterogeneous; the operational model is uniform.
And throughout, the security posture holds without anyone maintaining it. Edge redaction is on by default on every host, so adding the fiftieth server does not add a fiftieth place for a credential to leak into your logs. The enroll-only token cannot read data no matter how many hosts it brings up. The per-host scope means a single compromised box is contained, not a pivot point. The properties that made the first install safe are the same properties that keep a large fleet safe, because they are structural rather than procedural — you did not have to remember to do anything to keep them true.
One command ships logs and host metrics, redacts secrets at the edge, self-enrolls with a scoped token, and puts the host on your topology map — as fast and as safe on the hundredth server as on the first.