Fleet management and sensor health
A finding is only trustworthy if you know the sensor that produced it was healthy and telling the truth about time. Cernity ships a central sensor registry and continuous health telemetry so the SOC always knows which sensors are up, which are dropping packets, and which have drifted out of sync — before it trusts what any of them reported.
The sensor registry
Every sensor is a known object in a central registry, not an anonymous producer. The registry records:
| Attribute | Purpose |
|---|---|
| Identity | The stable identifier for this sensor |
| Tenant | Which tenant the sensor belongs to (multi-tenant isolation) |
| Site | Physical or logical location |
| Tags & groups | Operator-defined grouping for filtering and organization |
| Capabilities | What the sensor is configured to observe |
| Versions | Running software versions |
| Last-seen | When the sensor last reported in |
Because capabilities are declared per sensor, the rest of the system can reason about what a given sensor can observe — which ties directly into the evidence plane’s capability flags.
Health heartbeats: sensor-health.v1
Sensors emit sensor-health.v1 heartbeats alongside their EVE telemetry. Each heartbeat carries:
- CPU and memory — is the sensor resource-starved?
- Capture drops — is it losing packets before analysis?
- EVE rates — is it still producing telemetry at the expected volume?
- Ingest backlog — is it falling behind?
- Disk — is local storage running out?
- Connectivity — can it reach the central bus?
- Versions — what is actually running right now?
- Clock offset — how far is its clock from reference time?
Together these answer the question that precedes every investigation: was this sensor healthy in the window I care about? A quiet queue from a dropping or backlogged sensor means something very different from a quiet queue from a healthy one.
The fleet API and clock skew
A read-only fleet API lists the fleet and its current state, and it explicitly flags clock skew. Clock skew is called out on its own because it silently corrupts time-ordered evidence: if a sensor’s clock has drifted, correlation, sequencing, and “what happened first” become unreliable without any obvious error. Surfacing skew as a first-class flag lets an analyst discount or re-anchor evidence from a drifting sensor rather than trust it blindly.
The fleet-health data surfaces in Cernity Vantage so analysts see sensor health during triage, not in a separate tool.
Scope: read-only, by design
Fleet management today is observability, not control. It answers what is the state of my fleet? It does not push configuration, upgrade sensors, or roll changes back. That boundary is deliberate — the shipped capability is a trustworthy read model of the fleet.
Roadmap — not available yet
The following are planned and are not claimed as shipped:
- Remote policy rollout — pushing configuration to sensors centrally.
- Coordinated upgrades and rollback — orchestrated version changes across the fleet.
- Verified producer identity — cryptographically verifying that a heartbeat or telemetry stream genuinely comes from the sensor it claims to be, part of broader secure-bus hardening.
Until those ship, treat fleet management as the read-only registry and health telemetry described above. See how Cernity works for where health telemetry enters the pipeline.