versus{ networks }
Diagnostics

Velos Chassis Monitoring

Continuous health monitoring for an F5OS / VELOS chassis — every system controller, blade, chassis power supply, front-panel port, partition, tenant guest, and license, plus the interfaces of the switches wired to it. A sustained fault opens a Versus Desk incident and hands off to AI AutoPilot, scoped to the chassis, its connected switches, and the surrounding network map. Monitors live under Diagnostics → Velos Chassis; the chassis themselves (controllers, blades, partitions, tenants) are inventoried under Inventory → F5 Chassis once their F5OS device is added.

NoteSame loop, chassis-shaped. Velos Chassis Monitoring is a sibling of Versus Path Monitoring — the monitor → incident → diagnose → remediate → recover loop, specialised for chassis hardware and its fabric. Diagnosis and remediation run through the same governed AutoPilot engine.
Velos chassis monitor dashboard showing a healthy chassis and its checks
One monitor covers an entire chassis plus the switches connected to it. Every element reports a live verdict.
The CX410 chassis faceplate with live health overlaid — blade slot 2 lit red, standby controller degraded
The physical CX410 front panel, lit with live health: the failed blade glows red in its slot at 84 °C, the degraded standby controller and the critical alarm are called out by name. It's the same diagram as the inventory chassis view — now driven by the monitor's own checks, so a fault is located on the hardware at a glance.

What it watches

A single Velos monitor is bound to one chassis device and automatically discovers its components from the F5OS model — both system controllers, every installed blade and its front-panel ports, the chassis power supplies, the partitions and tenant guests, and the license — then seeds one tunable check per element. When Also monitor connected switches is on, it walks the CDP/LLDP topology to find the switches physically wired to the chassis and adds a check for every uplink interface.

Chassis
  • Reachable — The F5OS management endpoint is reachable (not unreachable/offline).
  • Overall health — The chassis's rolled-up platform health is healthy.
  • Active alarms — No un-cleared critical/major F5OS platform alarms.
System controllers
  • Health — Each controller reports healthy (not degraded/failed).
  • HA / redundancy — An active peer and in-sync redundancy are intact.
  • Controller PSU sensors — Every power-supply sensor reported by each controller is OK.
  • Fans — Every fan unit on each controller is OK.
  • Temperature — Controller temperature under the warn/crit thresholds.
  • CPU — Controller CPU utilization under threshold.
  • Memory — Controller memory utilization under threshold.
Blades
  • Health — Each installed blade reports healthy.
  • Power state — Each enabled blade is powered on.
  • Temperature — Blade temperature under the warn/crit thresholds.
  • CPU — Blade CPU utilization under threshold.
  • Memory — Blade memory utilization under threshold.
Front-panel ports
  • Link state — Each populated (SFP present) port is up, not down.
Chassis power supplies
  • Power supply — Each power-shelf PSU is present, its input feed is live, and it is delivering output. A failed unit or lost output is critical; a lost input feed or an empty bay is a redundancy warning.
Partitions & tenants
  • Partition status — Each chassis partition is running.
  • Guest health — Each deployed tenant (BIG-IP) guest is operational.
License
  • License valid — The chassis license is valid and not expired/expiring.
Connected-switch interfaces
  • Link state — Each connected-switch uplink interface stays up.
  • Errors — Input/output error rate under threshold (per interval).
  • Drops — Discard/drop rate under threshold (per interval).
  • CRC — CRC error rate under threshold (per interval).
The chassis component tree with per-element check verdicts
Green where healthy, red where it hurts — the component tree makes the blast radius obvious at a glance.

Enabled by default, tunable to silence false positives

Every check ships enabled — you get full coverage the moment you build a monitor. From there you tune it down to your environment's tolerance, so a transient blip never pages anyone:

  • Debounce — require N consecutive breaches before an incident opens. Mission-critical monitors confirm on the first breach; raise it for noisy signals.
  • Thresholds — temperature, CPU, memory, and the per-interval error / drop / CRC rates are all adjustable, per monitor or per individual check.
  • Per-check toggles — switch off any single check (say, a blade port you know is intentionally down) without losing the rest of the coverage.
  • AutoPilot toggle — decide whether a breach triggers an AI investigation at all.
The Tune panel with debounce, thresholds, and per-check toggles
The Tune panel: raise the confirmation threshold, adjust thresholds, or disable individual checks.

From breach to autonomous diagnosis

When a check breaches for long enough to clear its debounce, the monitor runs the whole loop on its own:

1

Detect & confirm. The element breaches its threshold; after the debounce count, the monitor escalates (transient blips are suppressed as flaps).

2

Open a Desk incident. One priority-scaled INC per chassis (deduped), with the chassis and every connected switch attached as configuration items — so the investigation starts with the full blast radius.

3

Trigger AutoPilot. An AI war room is convened, scoped to the chassis and its connected switches and grounded in the surrounding network map, correlating hardware, redundancy, and fabric symptoms into a root cause.

4

Govern the fix. Remediation is gated by severity — read-only diagnosis, a fix held for approval, or (on P1, when enabled) autonomous execution.

5

Auto-resolve. When every check returns to healthy, the monitor resolves its incident automatically.

Chassis + switch checkscontrollers · blades · ports · uplinksBreach + debounceconfirm, suppress flapsDesk incidentchassis + switches as CIsAutoPilot war roomchassis + fabric + mapGovern → resolveapprove · auto · recoverrecovery auto-resolves the incident and re-arms the monitor
A breached chassis with a P1 incident and AutoPilot engaged
A multi-domain fault — a failed PSU, an overheating blade, a downed switch uplink, and climbing errors — caught in one sweep, with a P1 incident and AutoPilot already engaged.

Connected-switch interface monitoring

A chassis is only as healthy as the fabric it plugs into, so the monitor watches the switch side too. For every connected-switch interface it tracks link state directly, and computes rates for input/output errors, discards, and CRC errors by differencing consecutive counter snapshots — so a port that is quietly accumulating CRC errors is caught as a rising rate, not just an absolute count. Thresholds are per-interval and fully tunable.

How it runs

The recurring sweep is driven by an in-process scheduler that is opt-in(VELOSMON_SCHEDULER_ENABLED) and gated to scheduler-owning processes with a cross-worker advisory lock — so the feature ships inert. Checks also run on demand from the Run now button or the run_velos_monitors management command (cron / scheduled task). Each check honours its own interval, and mission-critical monitors sweep most frequently.

Real F5OS devices

Against a real chassis, the monitor refreshes component health from the device through the Versus collector (the f5os.chassis_health operation) before each sweep — an opt-in per monitor (live_poll) so demo and lab environments read their last-known model data without a round-trip. Credentials are resolved on the collector and never leave the customer network.

The AutoPilot investigation opened from a chassis breach
AutoPilot reasons across the chassis and its connected switches, grounded in the surrounding map, then proposes a governed remediation.