Start Here
SBN Monitor is the monitoring system for the SBN cloud estate. It watches Windows and Linux hosts, IIS and .NET services, Go services, and database servers (Sybase ASE and SQL Server), and raises alerts when something is wrong. It is the in-house replacement for PRTG.
Lightweight agents on the monitored hosts collect readings and send them to the core servers, which evaluate them against per-sensor thresholds and trigger timing. Conditions that breach a threshold raise alerts through the normal notification paths, and a live dashboard shows current estate state to operators.
Architecture
SBN Monitor runs as a high-availability pair of core servers in an active/passive arrangement. The active core owns alerting; the passive core runs the same build and configuration as a warm standby, probing everything it can reach but routing its alerts to a log sink until it takes over. If the active core becomes unreachable, the standby promotes itself automatically and arms its alert routing. Handback to the recovered core is a deliberate operator action.
Lightweight probe agents are installed on monitored hosts and collect host-level readings locally. Agents make a secure, certificate-authenticated outbound connection to each core, so a promotion never leaves the standby cold. A host runs a single small binary and one enrollment credential; there is no per-host configuration and no inbound firewall opening. A host joins with a one-time enrollment code from the install page, after which the agent identifies itself with its own certificate and never needs a code again.
For devices that cannot host an agent, the core runs agentless network sensors - ping, HTTP, and TCP reachability checks - so switches, firewalls, and receivers are covered from the core or from an agent acting as a local prober.
Sensors and roles
A sensor is a single check with its own thresholds, trigger timing, and pause state. Sensors are assigned to a host either directly or through reusable roles from a role library: a database-server role, for example, bundles the relevant service, disk, and database sensors so that assigning the role instantiates them all. Per-site overrides win over the library defaults, so a host can tune a threshold or opt out of a sensor without editing the shared template.
All sensor configuration lives centrally on the core. Agents carry no configuration - they receive their collection manifest over the transport at connect and again whenever configuration changes. Configuration hot-reloads without restarting the cores or the agents.
Alerting
Where an alert goes is a route, and a sensor can name more than one. Routine conditions raise an ordinary service request in SRM that the monitor closes itself on the restore. A Priority-1 condition raises a Priority-1 service request automatically, with the on-call page, and repeat conditions inside the re-open window are folded into the request already open rather than opening a new one each cycle. A route can also open a Jira issue, send an email, or deliver a signal into an SBN installation on a receiver account of the monitored host's own, so the alarm reads like any other on the operator's screen. A sensor that names no route follows a routing policy by priority. While a new sensor is being brought up it can be routed to log-only, recording what it would have alerted on without paging anyone. Every alert and recovery is written to a permanent record.
Dashboard
A live web dashboard, in a desktop browser or on a phone, shows current estate state; changes appear within seconds. Its views cover sensors, alerts and the permanent record, alert routing, overrides, maintenance windows, probe agents, uptime reports, tuning proposals, and coverage gaps. Sensors group by host cluster, agent, tag, priority or type, roll their status up per group, and healthy sensors stay folded away so the trouble is visible on arrival. Sensors can be acknowledged or disabled for a set time directly from the page, resuming automatically when the timer expires. Operators sign in with a user name and password; the first sign-in with the shipped default credential changes it before anything else renders.
Status page
A separate public status page presents a coarse-grained view for customers, modelled on a Statuspage-style layout: an overall banner, named components grouped per stack, and an incident history derived automatically from component state changes. It exposes only component names, states, and timestamps.
Desktop tray companion
A desktop tray application mirrors the estate's worst state at a glance and lists the non-OK sensors with their current messages. It fires native OS notifications on new problems, is read-only, and clicks through to the dashboard.
Agent auto-update
The cores distribute agent releases so no one logs into a monitored host to upgrade it. Before running a release, each agent verifies it is ours and refuses any version older than the one it runs, then stages the new binary, swaps it, checks its own health, and rolls back automatically if the new build fails to come up. Rollout is canary-first and staged across the fleet, and every update, failure, and rollback is recorded.
Database monitoring
On a database server, SBN Monitor runs a small set of read-only checks installed in a dedicated health database. A restricted monitor login runs them, so no privileged database credentials are handed to the monitoring path. The checks report row counts, database and log space, replication state, long-running queries, queue depth, and deadlocks, and per-database sensors are created from what the server actually holds.