Sensaka Platform Architecture for Data Center Operations
Sensaka Platform Architecture
A four-layer architecture from device collection to intelligent application — covering every aspect of datacenter operations.
Application Layer
Processing Layer
Resource Layer
Collection Layer
Why the Layers Are Ordered This Way
The diagram above reads top-down, but the data flows bottom-up. Everything starts at the collection layer, which connects directly to servers, network devices, storage, environmental sensors, virtual machines, databases, and applications — agentless, over the protocols each device already speaks. The resource layer turns that raw stream into organized records: alarms, configuration data, operational metrics, power consumption, and logs. The processing layer is where records become meaning — alarms are correlated and deduplicated, IT events are associated with the business services they affect, and energy and spatial data are analyzed together. Only then does the application layer present results: centralized alarms, topology and business monitoring, energy dashboards, reports, and 3D visualization.
The order matters because each layer can only be as trustworthy as the one beneath it. A dashboard built on uncorrelated alarms produces noise; correlation built on incomplete collection produces blind spots. This is why Sensaka's collection layer is deliberately broad — including out-of-band hardware access described below — before any intelligence is layered on top. The same architecture underpins all three product tiers: DCOS for infrastructure monitoring, iDCOS for CMDB, ITSM, and automation, and SmartBSM for the business service view.
Direct Hardware Access Network
Connecting directly to BMC management ports (iLO, iDRAC, iBMC, IMM) through a dedicated out-of-band network, enabling real-time hardware monitoring independent of the OS.
Network Setup
Data Collection
In-Band and Out-of-Band, Side by Side
The collection layer uses both paths deliberately. They answer different questions, and together they close the gap that either one alone leaves open.
| Dimension | In-Band | Out-of-Band |
|---|---|---|
| Where data comes from | The operating system, queried remotely | The BMC management controller, below the OS |
| Works when the OS is down | No | Yes — hardware status and power control stay reachable |
| What it sees best | Processes, services, applications, resource usage | Component health, temperatures, power draw, firmware |
| Typical protocols | SNMP, SSH/CLI, API, JDBC | Redfish, IPMI, iDRAC, iLO, XCC, iBMC |
| Role in the platform | Server, network, storage, and application monitoring | Hardware monitoring and remote management |
Where the Architecture Is Applied
Each solution family is the same four-layer platform pointed at a different part of the data center. They share collection, data, and alarms — adopting one does not wall you off from the others.
For AI Infrastructure
The same platform extends to GPU clusters, where power density, cooling, and utilization behave differently from general-purpose compute.
What Teams Deploy It For
Lights-out and remote sites
Out-of-band access keeps hardware visible and controllable at unstaffed sites, even when the OS or the in-band network is unreachable.
Tool consolidation
Replace separate vendor-specific monitors for servers, network, storage, and facilities with one platform and one alarm stream.
Multi-site standardization
Roll the same monitoring model out across data centers and colocation footprints, so every site reports health, assets, and energy the same way.
Energy and PUE programs
Track power and cooling per rack alongside IT load to find stranded capacity and measure efficiency work over time.
AI cluster build-outs
Extend the same architecture to GPU nodes and liquid cooling loops as clusters grow, and meter how accelerators are used.
Business-aware operations
Map infrastructure to the services it supports through SmartBSM, so an alarm arrives with its business impact attached.
Common Questions About the Platform
Why is the platform organized into four layers?
Because each layer can only be as good as the one beneath it. The collection layer gathers raw data from devices; the resource layer normalizes it into alarm, configuration, operational, and energy records; the processing layer correlates those records with each other and with business context; and the application layer turns the result into monitoring, reporting, and visualization. A gap in collection is inherited by everything above it — which is why Sensaka invests in broad, agentless, multi-protocol collection first.
Does Sensaka require agents on monitored devices?
No. Collection is agentless: SNMP, SSH/CLI, APIs, and JDBC gather in-band data, while Redfish, IPMI, iDRAC, iLO, XCC, and iBMC provide out-of-band hardware data. An agent option exists for cases where remote query is not possible, but the platform does not depend on it.
What is the difference between DCOS, iDCOS, and SmartBSM?
DCOS is the infrastructure layer: monitoring of hardware, servers, network, storage, power, and cooling. iDCOS adds CMDB, ITSM, and automation on top of that data. SmartBSM is the business service layer, mapping infrastructure to the services it supports so impact is expressed in business terms. They share the same architecture, so they can be adopted separately or together.
Can one deployment monitor hardware from multiple vendors?
Yes. Redfish and IPMI are open standards, and Sensaka also speaks the vendor implementations — iDRAC, iLO, XCC, iBMC — so a mixed server fleet is covered from a single deployment. The same multi-vendor approach applies to network and storage devices.
Which solution should we start with?
Start with the layer that hurts most. If hardware failures keep surprising you, begin with hardware monitoring; if you cannot say what sits in which rack, begin with asset management; if power is the constraint, begin with energy management. The families share one platform, so each addition builds on the data the previous one already collects.