ipmi_exporter: turning server hardware sensors into Prometheus metrics

Two endpoints, and they solve different problems

This is an IPMI exporter for Prometheus, and its most important structural decision is that it exposes two endpoints rather than one.

The regular /metrics endpoint exposes metrics from the host on which the exporter runs. That is the local mode, and it is what an agent-style deployment uses, with the exporter installed on each machine you want to observe.

The /ipmi endpoint supports IPMI over RMCP and implements the multi-target exporter pattern. The exporter runs in one place and Prometheus scrapes it once per target, with the target machine selected by URL parameter rather than by where the exporter happens to be installed. The documentation points at the Prometheus guide to the multi-target exporter pattern for an overview of that paradigm, and this is the mode that makes a fleet of a hundred machines practical.

That distinction explains most of the operational advice that follows. A local exporter needs privileges and driver access on the machine it monitors, and it is a process per machine. A multi-target exporter is a single process that needs credentials for many machines and a network path to their baseboard management controllers.

The audience is a datacenter or platform team, not a hobbyist. IPMI is an interface that server motherboards expose for out of band management, and the exporter's job is to translate what it finds there into the metric format Prometheus expects.

FreeIPMI does the work, with a Go native path still experimental

By default the exporter relies on tools from the FreeIPMI suite for the actual IPMI implementation. That is a design decision with real consequences, and the documentation is explicit about it.

FreeIPMI is a suite of command line tools. The exporter drives them and parses their output, which means the machine running the exporter needs those binaries installed, and the exporter has to be told where to find them if they are not on the default path.

There is, however, experimental support for using the Go native go-ipmi library instead of FreeIPMI, and the documentation says feedback to help mature that support would be greatly appreciated, with a separate document for the native IPMI path.

The repository structure makes the two paths obvious. There is a collector.go at the top level, and then a family of collectors that each cover a domain of the IPMI data: chassis, dcmi, ipmi, sel, sel events, the bmc collectors for the baseboard management controller itself including a watchdog variant, and the system management lan mode collector. Most of those exist in two forms, one that shells out to FreeIPMI and one marked native, so the native path is implemented domain by domain rather than all at once.

The go.mod confirms the shape. The module requires the bougou/go-ipmi library alongside the Prometheus client, the Prometheus common libraries and the exporter toolkit, and the module targets Go 1.26.0.

Running it: port 9290, a config file, and the FreeIPMI tool list

A minimal invocation is just the binary with no arguments.

    ./ipmi_exporter
    ./ipmi_exporter -h

The documented parameters are few. The web.listen-address parameter sets the address and port to listen on and defaults to :9290. The config.file parameter is the path to the configuration file and defaults to none. The freeipmi.path parameter points at the FreeIPMI executables and defaults to relying on $PATH.

The list of tools that has to be present on the machine is explicit, because a missing binary shows up as missing metrics rather than as an error message. From the FreeIPMI suite you need ipmimonitoring or ipmi-sensors, ipmi-dcmi, ipmi-raw, bmc-info, ipmi-sel and ipmi-chassis.

Privileges are the other requirement. Collecting host local IPMI metrics requires root privileges, and there is a separate privileges document that describes how to avoid running the exporter as root, with two example configurations in the repository for that purpose.

One more rule governs containers. The documentation states plainly that containers should be used only when collecting remote metrics, and when running a container image you have to set config.file to the path as seen within the container and expose the default TCP port 9290 or set web.listen-address accordingly. That is not a limitation of the image, it is a statement that a container cannot read the host's IPMI device.

Configuration files and the container example

The configuration document describes both how to configure the exporter itself and how to configure the Prometheus server to scrape it. The repository ships several ready made examples, which is the fastest way to see the shape of a configuration file.

There is ipmi_local.yml for local collection, ipmi_local_sudo.yml for local collection with the sudo based approach to avoiding root, and ipmi_remote.yml for the multi-target case. The docker-compose.yml in the repository shows the remote configuration mounted into a container.

version: '3.7'
services:
  ipmi_exporter:
    build:
      context: .
    command: --config.file /config.yml
    volumes:
      - ./ipmi_remote.yml:/config.yml:ro    # replace with your own config
    ports:
      - 9290:9290                           # bind on 0.0.0.0
      # - 127.0.0.1:9290:9290               # or bind to specific interface
    hostname: ipmi_exporter_docker

Three things are worth copying from that. The command line passes the config path as it is seen inside the container, which is /config.yml rather than the host path. The configuration file is mounted read only, so the container cannot rewrite the credentials it was given. And the port mapping is deliberately shown twice, once binding on all interfaces and once commented to bind on a specific one, because an IPMI exporter that speaks to many machines should not be exposed to a network it has no business being on.

The exporter also supports TLS and basic authentication, and the documentation says the format for that is the one described in the exporter-toolkit repository. There is a small inconsistency in that section, since it names the parameter --web.config.file while the parameter list earlier calls the configuration file config.file, so it is worth checking which one your build accepts before you wire up a password.

Building from source and producing a container image

Building requires a Go development environment, and the Makefile handles both the binary and the image.

    make
    go install github.com/prometheus-community/ipmi_exporter@latest

The make route uses common Prometheus tooling to build the exporter and run the tests, and the alternative is standard Go tooling, which installs the executable in $GOPATH/bin. The go install form pins to the latest published version, so it does not build the working tree.

For the container image there is a dedicated target sequence. The make promu target prepares the build, promu crossbuild builds for the target platforms, and make docker produces the image. The Makefile sets the image name to ipmi-exporter and the repository to prometheuscommunity by default, both overridable, and it includes a shared Makefile.common that carries the standard Prometheus build rules.

The Dockerfile itself is short and shows what the image is made of.

ARG ARCH="amd64"
ARG OS="linux"
FROM --platform=${OS}/${ARCH} alpine:3
RUN apk --no-cache add freeipmi
LABEL maintainer="The Prometheus Authors <[email protected]>"

ARG ARCH="amd64"
ARG OS="linux"
COPY .build/${OS}-${ARCH}/ipmi_exporter /bin/ipmi_exporter

EXPOSE      9290
USER        nobody
ENTRYPOINT  [ "/bin/ipmi_exporter" ]

The base is Alpine, the FreeIPMI tools are installed with apk, the binary is copied in from the crossbuild output, port 9290 is exposed, and the process runs as nobody rather than as root. Pre-built images are published to Docker Hub and to quay.io, and for Kubernetes there is a community maintained Helm chart.

Where the IPMI exporter is the wrong tool

There are four situations where it does not apply.

The first is hardware without usable IPMI. A consumer machine, a virtual machine or a laptop has no baseboard management controller to talk to, and there is no redfish fallback documented here. The exporter is specific to servers with an IPMI interface, and for anything else a normal node exporter on the host is the right answer.

The second is a single machine. Installing a binary, a set of FreeIPMI tools and root level access to collect one server's temperatures is more work than running a node exporter on that server and reading the same values a different way.

The third is the local mode in a container, and the documentation says this plainly: containers are for remote metrics only. If your deployment pattern is a container per host, this exporter is the wrong shape, because the container cannot reach the host's IPMI device.

The fourth is the Go native library. It is described as experimental, and support is being asked for, so betting a production rollout on it means betting on a code path that the project itself is asking people to help test. The stable choice remains the FreeIPMI tools.

Licence, release rhythm and what a community project means here

The repository licence is MIT, with the LICENSE file at the top level, and the topic is the Prometheus community organisation, so the code can be used, modified and redistributed in commercial products with the notice kept. This is not legal advice, and the shared Prometheus build tooling the Makefile pulls in carries its own Apache 2.0 header, so a company doing a licence sweep should look at both files rather than just the root licence.

On maintenance, the last push was on 2026-10-19 and the repository is not archived, so the code is being worked on. The published releases tell a different story. Version 1.10.1 was released on 2025-07-11, 1.10.0 on 2025-02-12 and 1.9.0 on 2024-10-17, so there has been no tagged release in more than a year even though commits continue to land.

That has a practical effect. If you pin to a release, you are pinning to a build from 2025, and the fixes and collector work that landed since are only in the repository. If you run from a container tag, you need to know whether that tag was rebuilt from master, and the release list alone will not tell you.

The other signals are conventional Prometheus ones. There is a CHANGELOG.md, a MAINTAINERS.md, a SECURITY.md, a CODE_OF_CONDUCT.md and a CONTRIBUTING.md, a VERSION file, a NOTICE file, and the .promu.yml, .golangci.yml and .yamllint configuration files that the Prometheus build tooling expects. The metrics themselves are documented separately in docs/metrics.md, so the exact series and labels the exporter produces are defined there rather than in the readme.

Editorial conclusion

ipmi_exporter is the right tool for a datacenter team that wants fan speeds, temperatures, voltages and disk state from server baseboards in Prometheus, and for a fleet where the exporter is deployed centrally and scrapes remote machines, since the multi target pattern is the documented design for that case. It is the wrong tool for a single laptop, for hardware without a working IPMI interface, and for a setup that assumes a container can read local sensors, because the documentation says containers are for remote metrics only. Before deploying, confirm that the BMC credentials and RMCP network path work from wherever the exporter runs, decide whether to use the FreeIPMI tools or the experimental Go native library, and check the parameter name for the web configuration file, since the documentation mentions both config.file and web.config.file.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. prometheus-community/ipmi_exporter on GitHub
4. README
5. Releases