Skip to main content
SambaRack hardware monitoring reports the physical condition of the rack: power draw at the PDU, fan speed and temperature at each XRDU, and RDU utilization and health on each host module. Metrics are labeled by node and rack, so you can see the whole fleet or drill into a single RDU.
  • Track how your RDUs are being used. Monitor tile activity per RDU to find idle capacity, balance workloads across nodes and racks, and plan capacity.
  • Catch faults and errors early. Track platform fault and error counts per RDU and alert when they increase, so you act on early warning signs rather than after a failure.
  • Keep your hardware within safe thermal limits. Follow temperatures and fan speeds across the rack to detect cooling problems before they cause throttling or hardware stress.
  • Track rack power consumption. Follow power draw across your racks to understand energy use and plan power and cooling capacity.

​
What hardware monitoring is

Hardware monitoring collects telemetry from the physical infrastructure a SambaRack is built from — power distribution units, baseboard management controllers, and the RDUs themselves. It answers questions about the machine. The two are separate signal sets with separate exporters, but they share one Prometheus and one Grafana. That is deliberate: most real incidents are diagnosed by looking at both at once.

​
Components

​
Architecture

The SambaNova exporter is a host process on the machine it monitors. Prometheus scrapes each host directly, as it would a node exporter. The PDU and XRDU exporters are multi-target exporters. A PDU and a BMC have no operating system to run an agent on, so one exporter process answers for every device. Prometheus names the device in the target query parameter of each scrape (/probe?target=<address>). Adding a rack means adding its device addresses to your values file and running helm upgrade. The exporters themselves do not change.

​
Operating model

  • Prometheus-native — The exporters publish standard Prometheus exposition format. Any scraper that reads that format can collect them.
  • Kubernetes-native deployment — The chart uses prometheus-operator CRDs (Probe, ServiceMonitor) and follows the kube-prometheus-stack values convention.
  • Customer-operated — You install, upgrade, and operate the stack. SambaNova provides the exporters, the chart, the reference architecture, and the dashboards.
  • Dashboards are a starting point — The three bundled dashboards demonstrate the metrics. Copy the panels you need into the dashboards your team already runs.

​
Integration with other monitoring platforms

Nothing in the exporters is proprietary to Prometheus. The chart’s Prometheus-specific parts are the Probe and ServiceMonitor objects, which you can leave disabled.

​
Prerequisites

If you have not installed a monitoring stack already, set up Prometheus and Grafana first using the Prometheus and Grafana reference architecture.

​
Next steps

Hardware monitoring supports connected and air-gapped installs. Install monitoring walks through both in order, starting with enabling the SambaNova exporter on every host module. Before you install, confirm the cluster nodes can reach the PDUs and XRDU BMCs on the management network. See Device reachability.