System
The system view is the honesty check for every other page. It reports what is delivering, what is stale, and what is missing — and it is the reason the rest of the interface can be read at face value.
Overall status
Section titled “Overall status”Three states, and the API returns them as such: ok, degraded, unavailable.
Alongside it, the watermark: the timestamp up to which data is considered complete. Every view is honest about the watermark rather than presenting a partial recent window as finished.
Components
Section titled “Components”One line per component, whether it is a store, a sensor or a connector:
| Column | Means |
|---|---|
| Status | ok, stale, degraded, unavailable |
| Last event | When this component last delivered |
| Lag | How far behind it is, in seconds |
| Message | What is wrong, in words |
Freshness uses the server’s own receipt time, not the timestamp inside the record. A source with a skewed clock cannot forge its own health, in either direction.
A non-admin sees the same shape with host-local detail redacted. Not a different, quietly shortened document — the same document, with the sensitive strings removed.
Ingest
Section titled “Ingest”| Figure | Means |
|---|---|
events_last_5m |
Accepted records |
unparsed_last_5m |
Syntactically valid, semantically un-normalisable, stored as raw |
rejected_last_5m |
Durably rejected individual lines, from the failure ledger |
oldest_buffered_at |
How far back the transport buffer reaches |
A nonzero unparsed count is normal at small scale — sources emit odd records. A steady rejected count is a configuration problem: a wrong token, a wrong record kind for that sensor, or a transport sending something the registry does not allow. It is a thing to fix, not a number to get used to.
Capture
Section titled “Capture”The capture loss percentage, with the time it was sampled. If no packet source
is configured, both are null rather than zero — because “no mirror” and “a
mirror losing nothing” are different facts and should not look identical.
Loss above one percent means the appliance is not keeping up. Check CPU, check that the capture offloads are actually disabled, and check whether the loss coincides with your backup window.
Coverage and blind spots
Section titled “Coverage and blind spots”The view also states what the current source set structurally cannot see: physical intra-VLAN traffic that crosses neither a monitored hypervisor nor a firewall, unidirectional exporter counters, and the possibility that address translation prevents two sensors from recognising the same session.
Those limits stay visible here and on the evidence views. A tool that displays its coverage as complete when it is not is the one that gets you, and the discipline of naming the gap is cheaper than the confidence of ignoring it.
Connectors
Section titled “Connectors”Each configured connector instance shows its state, last success, last failure
with a code, remaining backoff, items in the last hour, and cursor position —
plus a test-connection button. One component row per declared instance, named
connector:<id>. See the connector framework.
Telemetry & registration
Section titled “Telemetry & registration”The section that makes the daily heartbeat checkable rather than promised. It
shows the status (on, off or failing), the endpoint, whether the
installation is registered, the last attempt with its result — and the exact
last payload as expandable JSON. Not an example of the format: the stored
record of what actually went out.
Below it, the name of the variable that switches it off. A switched-off installation reads a neutral off rather than a red state, because turning it off is a choice and not a fault.
The field list, the retention and the switch are documented under instance registration and telemetry.