Infrastructure & Fleet PlatformsField engagement

The node that goes quiet is the one that matters, and naive polling never notices silence.

Architecture and delivery lead.
25,000
nodes at target scale
3
out-of-band protocols, one API
hours to minutes
fault detection
0
models in it
Control plane
fleet scale
RedfishIPMISNMPSSH
heterogeneous fleet
One control plane, four protocols that every vendor implements a little differently, twenty-five thousand nodes. The spec is a starting point, not a guarantee.
What was at stake

Servers across several vendors and hardware generations. Modern baseboard controllers on one protocol, older ones on another, power and network gear on a third. Health split across three tools plus tribal knowledge, remote control inconsistent, and failures found late by a human after impact. Late fault detection means outages found after they have already cost something, and out-of-band power and boot actions are dangerous if issued against the wrong node or on a stale reading.

The constraint

The stated ask was a unified health dashboard. The real problem was two-sided. Normalizing three protocols with different data models, authentication, and failure behaviors into one stream at fleet scale, without hammering the controllers that support only a handful of concurrent sessions. And harder: detecting the absence of a signal, because a node that goes quiet is the one that matters and naive polling never notices silence.

BMC session limit: 4 to 8 concurrent
naive fan-out14 sessions
opens far more sessions than the controller supports, and crashes it
scheduled polling6 sessions
capped per controller, with backoff, so monitoring does not degrade what it monitors
The constraint that separates people who have run a real fleet from people who have read the specification.
The fork

The reflex, and the fix.

Road not taken

Threshold alerting on readings

Pull

Every monitoring tool does this, and it is what a dashboard brief asks for.

Why not

A threshold only fires on a value that arrives. A node that stops reporting entirely produces no value to threshold, so the most important failure is the one the design cannot see.

Road taken

Alert on the absence of a heartbeat

Accepted

A dead-man's-switch alerter, per-controller-class back-off polling, and a protocol abstraction layer built before any dashboard work.

Bought

Silence becomes visible, and fault detection moves from a manual sweep to a live signal.

Decision

Alert on the absence of a heartbeat, because that is how silence becomes visible.

How it was built
01Discover
02Normalize
03Collect
04Detect silence
05Act
01

A protocol-abstracted collector

All three out-of-band protocols map into one common schema behind a single API, so vendor and generation variance is contained at one layer instead of leaking into every feature.

02

Polling that respects the controllers

Per-controller-class back-off, so one slow or flapping controller never stalls the fleet and everything stays inside controller session limits with no throttling.

03

A dead-man's-switch alerter

Every node is expected to check in on a cadence, and a missed cadence pages. Not just an out-of-range value: the absence of a value. This is the part of the design that finds the failures the old tooling could not.

04

Telemetry into a time-series store

Per-rack and per-generation dashboards over one normalized stream, which is only possible because the abstraction layer came first.

05

Guarded out-of-band action

Power and inventory actions that cannot run on a stale reading, because an out-of-band action issued against the wrong node is worse than no action at all.

How it was measured

A single headline number hides where a system fails. This work was scored on the dimensions that actually decide whether it holds in production, measured on real, held-out cases rather than the demo path.

Time to detect a silent nodeProtocol coverage across vendor generationsController load under full-fleet pollingAction safety against stale state
model ~5%
systems engineering ~95%
intelligence on top
drivers, protocols, control plane, distributed telemetry, scale
The model is the small part. The platform underneath, drivers to telemetry to scale, is the system.
figures

Node count is the cleared 25,000 figure. Fault-detection improvement is stated qualitatively.

What it produces
Without this discipline

Three tools, tribal knowledge, and a dashboard that shows every reading it receives while staying silent about the node that stopped reporting an hour ago.

This system

One control plane across the fleet and its vendor generations, three out-of-band protocols behind one API, unified telemetry and action, and fault detection cut from a manual sweep to a live signal, hours to minutes.

three protocols, one APIpages on silence, not just on valuespolling inside controller limitsno model by design
The operating envelope

What it owns, and what it hands to a person.

Handled with confidence
Discovery, health, and guarded control across the fleet
Mixed-vendor hardware across generations
Up to the target node count
Flagged for review
Controllers deviating from specification
Nodes outside the validated firmware range
Out of scope by design
Treating an intelligence layer as the product
Assuming a uniform estate
The honest limit

Fault detection moved from a manual sweep measured in hours to a live signal measured in minutes. That is a change in method, so it is stated as such rather than as a benchmark. The platform is bounded by what the controllers actually expose: hardware whose protocol implementation deviates from specification, and nodes outside the validated firmware range, are flagged rather than silently mishandled.

What it generalizes to

There is no model in this system and none was needed. It is protocol normalization, distributed collection inside hard controller limits, and the one design decision that matters: alerting on absence rather than on value. This is the page that makes a diagnostics-only or AI-only read of the firm impossible, because the highest-value work here happens entirely below the model layer.

How we engage

You have a system like this one.
Tell us where it stands.

Whether it is failing, not yet built, or about to meet a scale it has never seen, we can tell you what we see.

Start a conversation
mostafa@opulion.dev · Response within 24 hours · By inquiry