Agent Installation
What is a probe agent
The probe agent is the small program SBN Monitor installs on a monitored host to take host-level readings locally - disk, CPU, memory, service and process state, OS logs, web-server health - and to run network probes and script checks from a vantage point close to the target. It is the same binary the cores run, started in agent mode. A host that cannot take an agent is still covered by agentless checks from a core or a nearby agent, but where an agent can run it gives the fullest picture and the lightest network footprint.
Supported platforms
The agent installs as a managed background service so it starts on boot and stays running:
Platform | Runs as |
|---|---|
Windows | a Windows service |
Linux | a systemd unit |
One binary covers both. The reading it takes never changes with the operating system - a disk check on Windows and a disk check on Linux report the same channels the same way; only the collection underneath differs.
Enrolling a host
A host joins the fleet with a one-time enrollment code. From the install page, create a code (it is valid immediately and expires after a bounded time if unused), then run the install path on the host: open the install page on that machine, download the ready-made installer for its platform, and run it. The installer arrives with the code and the expected file fingerprints already built in, so a single run downloads the agent, checks it is intact, installs the service, and confirms enrollment before it finishes. A typed one-line fallback is offered on the same page for hosts without a browser.
The enrollment code is the only secret involved, and it is short-lived and single-use.
What the agent does after enrollment
Once enrolled, the agent trades the code for its own certificate identity and never needs a code again - it re-authenticates with that certificate on every reconnect. From then on it makes a secure, certificate-authenticated connection outbound to each core and keeps it open. Only outbound connectivity is required; no inbound firewall openings are made on the host.
The agent carries no local configuration. It receives its collection manifest - what to read and how often - from the core over that connection when it connects and again whenever configuration changes. All thresholds, timing, and routing stay on the core. Because it holds both cores' addresses and reports to each, a standby taking over never leaves the host unwatched.
Where it runs and its footprint
The agent is one static binary plus a small protected state directory for its certificate and cursors. It runs at low priority with a bounded number of checks in flight and a hard timeout on each, so a busy manifest can never crowd out the host's real work. The agent reports its own resource use back to the core, so its overhead is visible and can itself be alerted on.
Keeping an agent up to date
An installed agent is never upgraded by hand. New releases are distributed from the core, verified and applied by the agent itself, and rolled back automatically if the new build does not come up healthy - see Agent Updates.
When an agent loses its core
An agent that cannot reach a core keeps probing and buffers the readings it takes in the meantime, then replays them when the connection comes back. The buffer is bounded - about five thousand readings per core, roughly six hours of a typical manifest - and past that the oldest reading is dropped, so an outage costs a known slice of history instead of the host's memory. It is held in memory only, so an agent restart during the outage loses what was buffered.
Replayed readings are history. They are recorded as the gap they came from and never move the current state or raise an alert, because a two-hour-old Down must not page now and a two-hour-old Up must not clear an alarm that is still true. The gap leaves one entry in the permanent record naming the agent, how many readings were backfilled, the span they cover, anything that had to be dropped, and which sensors were not Up while the agent was dark - which is what answers "was anything actually broken while we could not see it".
Confirming a new host appears
After enrollment, open the dashboard and look for the host by name. Within seconds it shows up with its discovered surface - disks, services, web servers - and its standard environmental sensors begin reporting. If the host does not appear, the code was likely already used or expired; mint a fresh one and run the installer again.
Removing an agent
Stop and uninstall the agent service on the host, then remove the host and its sensors from central configuration. With the service gone the outbound connections close and the host drops off the dashboard. The retired certificate identity is no longer accepted, and rejoining later is a fresh enrollment with a new one-time code.