Dashboard
The dashboard is the operator's view of the estate: the current state of every sensor, the alerts and the permanent record behind them, and the controls that quiet, re-probe, re-route or re-configure a sensor. It is live: when a sensor changes state, an alert fires, or a core changes role, the page reflects it within seconds. If the live channel cannot be established the page falls back to a short polling interval and keeps retrying; the header word says which mode is in force - Live, Polling, Not connected, or Not updating when the core has stopped answering. It runs in a desktop browser and on a phone.
Layout
The header carries the logo, the product name, the live-mode word, the running core version, and sign-out, which shows the signed-in user's name. Below it a navigation bar lists the views, and the browser tab title follows the open view. Banners above the content appear only when something needs saying: the core is in dry-run and sending no alerts, a deploy is still settling and reds are suppressed until real readings arrive, the core raised warnings against its own configuration, quiet windows are in force, or the picture has stopped updating.
On a phone the navigation scrolls sideways, the version moves into the More actions menu, filter chips become one scrolling row with a Clear that stays put, and a sensor's detail opens full width. Forms go to one column.
The views
View | What it shows |
|---|---|
Sensors | The estate as this core last read it. Chips narrow by status, tag, route and priority; a search box and a grouping pivot narrow further; a row opens the sensor's detail. Bulk actions act on the sensors currently shown. |
Alerts & journal | Every alert this core routed, highest priority first and filterable to the Priority-1 route, and the full permanent record behind it - configuration changes, acknowledgements, disables, promotions - narrowed by sensor or target, event kind, and time window. A sensor name opens its row. |
Routing | Where alerts go, by priority and tier. Each cell names the routes that tier delivers to for that priority and how many sensors it currently serves. A cell is edited in place and saved; the change is journaled and pushed to the peer core. |
Overrides | Every sensor currently acknowledged, disabled, or paused by configuration, with how long it has been that way and when it expires. A sensor hidden from the sensor list is never hidden here. |
Maintenance | Planned windows during which a matched sensor's alerts are suppressed, and a form to create one. A window declared in the sensors file is read-only here. |
Agents | Every enrolled probe agent, its version, and what its host is spending processor and memory on. Enroll host composes a new server's roles, tags and extra sensors, then issues the token that provisions it. |
Reports | Uptime over a chosen period, measured from the history store, and the reports the core has already generated on its schedule, each downloadable. |
Tuning | Where a sensor's thresholds or timing disagree with what it has actually measured, with the evidence on the line. A row opens the sensor, where the proposal can be applied. |
Coverage | What the agents discovered on their hosts that no sensor watches - volumes, services, databases. An item marked deliberate, with a reason, stops counting as a gap. |
A separate read-only wall view, at /wall, puts the same picture on a NOC screen: one tile per state with the counts, the sensors that are not Up, and an all-systems-up banner when nothing is.
Signing in
The sign-in card renders in place with a user name and password field. Five failed attempts from one address lock sign-in for ten minutes, and the card says so. A wrong credential is refused in plain words; a core that does not answer shows a Try again control instead of blaming the password. The session is a browser cookie that ends on sign-out.
A core ships with a default operator credential. The first sign-in with it opens a change-password form before any view renders, and until the password has been changed a banner on every view says the core is still using its default password, with the change action on it.
Which core you are looking at
SBN Monitor runs as an active core and a warm passive standby. Only the active core owns alerting, and the dashboard you want is the active one. A single sign-in address always lands you on whichever core currently holds the active role, so you never have to know which box that is. The active dashboard shows no banner; the passive core's dashboard shows a clear notice that you are on the standby, with a link straight to the active dashboard, and a standby that has promoted itself shows that it is acting as active with the handback control beside it.
Grouping and narrowing
Sensors group by agent, by role and host cluster, by priority, by tag, or by sensor type, or show as one flat list. Each group shows its sensor count and rolls up the worst state beneath it, so a single Down anywhere colours its group without opening it. Chips above the list carry one count per state - Down, Warning, Up, Unreachable, Settling, Stale, Standby, Disabled, Maintenance, Acknowledged - and one per alert route and priority; each narrows the list, and they combine. Healthy sensors stay folded behind an "N OK sensors hidden" count with a show-all control, and every group can be expanded or collapsed at once. An acknowledged sensor leaves the default view until its state changes.
Disable and acknowledge from the page
A sensor is quieted without touching any configuration. Disable offers 15 minutes, 1 hour, 4 hours, 24 hours, a typed number of minutes, or indefinitely; a timed disable counts down on the row and resumes on its own, an indefinite one reads as permanent until someone enables the sensor again, and a sensor disabled in the configuration file reads as a config disable and is managed there. Acknowledge keeps a known problem out of the default view; Probe asks for an immediate reading. Every action can carry a free-text reason, which goes into the permanent record with the change, and a disable survives a core restart and a failover.
The same actions apply to a whole group from its menu, and to everything currently shown from the actions bar: acknowledge shown, clear acknowledgements, disable shown, and raise a service request for shown.
Reading a sensor
A sensor's detail opens as a panel beside the list and has its own address, so a link to one sensor opens on that sensor. The header carries the sensor's name, its state and how long it has held it, its tags, the parent it depends on where it has one, and the controls that act on it - acknowledge, disable or enable, probe now, and the Grafana link where one is configured. A parent's name opens that sensor, so a dependency chain is walked without leaving the panel.
Below the header come the current channel values against the warning and down bands the sensor's own thresholds cut, a strip of the recent results with each result's time, state and value on hover, and a History section that graphs each channel over a window from the live view out to the full ninety days the history store keeps. A flat series sits mid-band. Then the effective configuration, and that sensor's own slice of the permanent record.
Editing a sensor's configuration
The detail panel is also where a sensor's configuration is changed. Every editable field is listed with the value actually in force and where that value came from: the sensor's own entry, a role, the host, the environmental defaults, or an earlier change made here, which is labelled as an override. Because the origin is visible, a field can be written either on this sensor alone or at the shared level the value came from - a role or a host - which is offered next to the field once the field has been edited. Tags are added and removed on the same panel, and a sensor's Down, Warning and Escalation routes are set there; a sensor with no route of its own follows the routing policy.
A change is checked before it is applied, and a rejected edit changes nothing. Preview shows what it would touch: the sensors whose effective values move, and each field's value either side, so a threshold edited on a role is confirmed against the whole set it reaches. Every applied change is stored as an override, takes effect on the next configuration load, and is written to the permanent record with the operator, the reason, and the values either side. A field carrying an override has an Un-override control that drops it and lets the field fall back to the configuration file.
Raising a service request
A service request can be raised by hand from a sensor, with an optional note carried into it, and for everything shown from the actions bar - one request per sensor, in one step. The entry it leaves in the permanent record is marked as manually raised, so it is distinguishable from one the monitor raised on its own. The control is not offered on a core that cannot raise one.
Enrolling a host
Enroll host, on the Agents view and in the header menu, takes the new server's name, site, roles, tags, priority and any extra sensors, and issues a one-time enrollment token. The token is shown once, with its expiry, the roles it provisions, and the one-line install commands for Windows and Linux that carry it; the agent install page carries the same token in its script. The provisioned host then appears in the host list with its owner shown - a host defined in the sensors file is read-only there, one provisioned from the dashboard can be edited again, and a host's priority can be overridden from its row and dropped back.
The probe-agent list
Each agent shows whether it is connected and how long ago it last reported, how many sensors it is assigned, its configured roles and tags, and what it is running on - hostname, operating system, cores, memory, and the volumes and services it discovered. It also shows the host's heaviest processes: the top consumer by processor and the top by memory on one line, with the full list and both numbers per process on hover.
Header actions
The More actions menu holds Test P1, which sends a real Priority-1 through the alert path and says whether that pages the on-call or only logs on this core, behind a confirmation; a diagnostic snapshot, copied to the clipboard or downloaded, for support; and Enroll host.