Scaphandre Energy Metrics for Hosts and QEMU/KVM Virtual Machines

What Scaphandre Measures on Computing Infrastructure

Scaphandre addresses a measurement gap that ordinary application telemetry does not cover. The README says that technology services often do not track their electrical power consumption or expose those figures to clients. Its purpose is to measure power and energy consumed by those services and pass the results into an existing monitoring or analysis toolchain.

The supported measurement targets are specific. Scaphandre can measure power and energy use on bare-metal hosts, including systems running GNU/Linux or the supported Windows releases. It can also measure a QEMU/KVM virtual machine from its host. That distinction matters because Scaphandre is not presented as a profiler that assigns every watt to an individual process, function, or request. The documented scope concerns machines, hosts, and virtual machines.

The agent targets two audiences. Infrastructure operators can use it to add electricity metrics to host and VM monitoring. Technology providers can expose consumption data to clients instead of discussing sustainability without machine-readable measurements. The repository topics also associate Scaphandre with electricity meters, virtual machines, Prometheus, and energy efficiency, which matches the README's focus on infrastructure-level metrology.

This boundary makes Scaphandre more useful for a fleet or virtualization platform than for a developer trying to optimize one function. The README does not document per-process measurement, source-level attribution, or an API for calculating the energy cost of a single HTTP request. Those capabilities should not be assumed.

Scaphandre Host, VM, and Exporter Data Paths

Based on the repository layout and `Cargo.toml`, Scaphandre is a Rust application with OS-specific platform code and optional integrations. The Linux target includes `procfs`, while the Windows target includes `windows`, `windows-service`, and CPU-related dependencies. This indicates separate native paths for reading system information and managing execution on the two supported operating-system families.

At the VM boundary, the README describes two related but distinct operations. Scaphandre can measure a QEMU/KVM virtual machine from the host. It can also expose a VM's power and energy metrics so that they can be manipulated inside the VM as if it were bare metal. The README explicitly says that this second capability relies on hypervisor features. Host-side attribution and guest-side visibility are therefore not interchangeable operations.

Once Scaphandre has measurements, the output layer determines where they go. It can display basic figures in the terminal or store them in a JSON file. Network-oriented integrations include a Prometheus HTTP exporter, Prometheus Pushgateway delivery, Riemann output, and Warp10 output. Kubernetes support is also listed. The Cargo manifest reinforces these integration paths through optional dependencies such as `riemann_client`, `warp10`, `hyper`, `tokio`, `docker-sync`, and `k8s-sync`.

The repository includes `helm/`, `docker-compose/`, `packaging/`, and a multi-stage `Dockerfile`, indicating several possible deployment routes. Those paths show that Scaphandre was designed to sit beside services and monitoring systems. However, the README does not provide the commands needed to execute a complete Kubernetes, Docker, Pushgateway, or guest-metric propagation setup. Those configurations must be checked in the linked documentation before adoption.

Getting Started Through Scaphandre's Published Packages

The README directs new users to the Getting started guide and to separate GNU/Linux and Windows installation pages in the Scaphandre documentation. It also says that packages are available for RHEL 8 and 9, Debian 11 and 12, and Windows. NixOS has community support. This gives prospective users more than a source-only route, although the README does not identify repository keys, package commands, version selectors, or Docker invocation parameters.

The README does not provide an exact installation command. Start with the project's official Installation and compilation on GNU/Linux guide for a Linux package or source-build workflow. Windows operators should use the corresponding Windows installation guide. The repository's `Dockerfile` confirms that a release binary is built with Cargo and copied to `/usr/local/bin` in an Ubuntu 22.04 runtime image, but it does not document a supported image tag or a first-run command.

The first useful operation depends on the host. On bare metal, the project is intended to collect the machine's power or energy readings. In a QEMU/KVM environment, collection from the host is the documented starting point for VM measurement. Before wiring the output into Prometheus or another destination, terminal output can serve as a basic visibility check because the README explicitly lists terminal display as a supported feature.

The project documentation also links code documentation on `docs.rs`. That is useful when selecting package features or reviewing the public Rust API. The version and command surface should still be checked against the documentation matching the selected release, because the README does not present a standalone quick-start command.

Choosing Between Scaphandre Output Modes

Scaphandre is useful partly because it does not force every deployment into a single monitoring architecture. Prometheus HTTP exposure suits environments in which a collector can scrape a running agent. The Pushgateway option is a different delivery model: the agent sends metrics to a gateway rather than relying on that pull relationship. Riemann and Warp10 provide alternatives for installations whose time-series or event pipelines already use those systems.

A JSON file is the most direct documented persistence option. It can support local inspection or later ingestion, but the README does not describe a schema guarantee, retention policy, rotation mechanism, or companion import command. It should therefore not be treated as a complete time-series storage system without checking the implementation and documentation.

Terminal output is convenient for a first look, yet it is not a durable observability interface. The choice of exporter is consequently an architectural decision rather than a cosmetic setting. Operators need to compare Scaphandre's documented delivery modes with the systems already responsible for collection, storage, retention, dashboards, and alerting. The example dashboard linked by the README demonstrates that Scaphandre data can feed a visualization stack, but the README does not reproduce its configuration.

Scaphandre's feature list also includes Kubernetes support. Based on the presence of `helm/` and `k8s-sync` dependencies, deployment assets exist. Required privileges, service discovery, and permissions are not stated in the README, so those details must be verified in the project's Kubernetes documentation.

Scaphandre Constraints and Measurement Boundaries

The largest documented limitation is the maturity warning itself. The README says Scaphandre is still a very early-stage project and asks users to refer to its contribution material for feedback. That warning matters even though the repository is not archived and the last push was on 2026-07-19. Recent repository activity reduces one obvious maintenance concern, but it does not remove the project's own characterization of its maturity.

Operating-system coverage is bounded. The README lists GNU/Linux, Windows 10, Windows 11, and Windows Server 2016, 2019, and 2022. Packages are listed for selected RHEL, Debian, Windows, and community-supported NixOS distributions. Other hosts are not claimed as supported in the README. A platform outside that list would require source inspection and direct validation before it could be considered deployable.

The VM path also has a hard dependency on hypervisor support, according to the README. Guest-side metric propagation cannot be assumed merely because Scaphandre can measure a VM from its host. The distinction may complicate deployments where VM ownership is separated from host administration, because the hypervisor-side and guest-side arrangement must be designed as a unit.

Finally, Scaphandre aims for measurements close to zero monitoring overhead, but the README states this as a project goal rather than supplying a benchmark. It would be incorrect to cite that goal as proof that the agent has negligible CPU, memory, or energy cost in every deployment. Repository layout offers another useful alternative approach: DC Watts is not described in the README, so no unsupported competitor comparison is made. The meaningful choice is instead between infrastructure-level electrical metrology, such as Scaphandre, and application telemetry that reports estimated energy use without Scaphandre's host measurement mechanism.

Scaphandre Release and Apache-2.0 Upgrade Considerations

The repository is not archived, and its last push was on 2026-07-19. Release information lists `v1.0.3` on 2026-07-17, following `v1.0.2` on 2025-02-11 and `v1.0.0` on 2024-02-12. This release history indicates recent project activity, but the README does not define an upgrade schedule or support duration, so neither should be inferred from the release list.

There is also a concrete versioning detail to check. `Cargo.toml` identifies package version `1.0.2`, while the release list includes `v1.0.3`. Neither the README nor the manifest explains whether that state is expected in the default branch or whether the release was prepared from another source state. Operators considering a packaged release should reconcile the package version, binary version, and selected documentation before deploying it.

The project is licensed under Apache-2.0, as stated in both the repository metadata and `Cargo.toml`. That license permits broad use under its terms, but the project does not provide a separate warranty or assurance of measurement accuracy in the README. Users still need to assess how collected operational data fits their own compliance and reporting processes. This is not legal advice.

Upgrade cost depends on the integration path. Replacing a terminal-only check is comparatively simple. Moving among Prometheus exposure, Pushgateway, Riemann, Warp10, JSON, or Kubernetes changes deployment and monitoring behavior. VM propagation adds host permissions and hypervisor configuration. The README does not quantify these costs, but they follow directly from the distinct interfaces the project supports.

Editorial conclusion

Operators who need host-level or QEMU/KVM energy visibility should evaluate Scaphandre when Prometheus, JSON, or one of its other documented outputs fits their collection stack. It is a poorer choice when you need application-level energy attribution, require an officially packaged deployment on an unsupported platform, or need documentation that no longer describes the project as early stage. Verify first that the target host exposes the meter information Scaphandre expects, then confirm that the selected exporter or metric propagation method works with your monitoring environment.

Frequently asked questions

Official sources

1. hubblo-org/scaphandre on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases