prometheus-community / ipmi_exporter Goto Github PK

Remote IPMI exporter for Prometheus

License: MIT License

Go 95.69% Makefile 1.28% Dockerfile 0.56% Shell 2.47%

ipmi_exporter's Introduction

Prometheus IPMI Exporter

This is an IPMI exporter for Prometheus.

It supports both the regular /metrics endpoint, exposing metrics from the host that the exporter is running on, as well as an /ipmi endpoint that supports IPMI over RMCP - one exporter running on one host can be used to monitor a large number of IPMI interfaces by passing the target parameter to a scrape.

The exporter relies on tools from the FreeIPMI suite for the actual IPMI implementation.

Installation

For most use-cases, simply download the the latest release.

For Kubernets, you can use the community-maintained Helm chart.

Building from source

You need a Go development environment. Then, simply run make to build the executable:

make

This uses the common prometheus tooling to build and run some tests.

Alternatively, you can use the standard Go tooling, which will install the executable in $GOPATH/bin:

go get github.com/prometheus-community/ipmi_exporter

Building a Docker container

You can build a Docker container with the included docker make target:

make promu
promu crossbuild -p linux/amd64 -p linux/arm64
make docker

This will not even require Go tooling on the host. See the included docker compose example for how to use the resulting container.

Building a RPM Package

See how to build a RPM package.

Running

A minimal invocation looks like this:

./ipmi_exporter

Supported parameters include:

web.listen-address: the address/port to listen on (default: ":9290")
config.file: path to the configuration file (default: none)
freeipmi.path: path to the FreeIPMI executables (default: rely on $PATH)

For syntax and a complete list of available parameters, run:

./ipmi_exporter -h

Make sure you have the following tools from the FreeIPMI suite installed:

ipmimonitoring/ipmi-sensors
ipmi-dcmi
ipmi-raw
bmc-info
ipmi-sel
ipmi-chassis

Running as unprivileged user

If you are running the exporter as unprivileged user, but need to execute the FreeIPMI tools as root, you can do the following:

Add sudoers files to permit the following commands

ipmi-exporter ALL = NOPASSWD: /usr/sbin/ipmimonitoring,\
                              /usr/sbin/ipmi-sensors,\
                              /usr/sbin/ipmi-dcmi,\
                              /usr/sbin/ipmi-raw,\
                              /usr/sbin/bmc-info,\
                              /usr/sbin/ipmi-chassis,\
                              /usr/sbin/ipmi-sel

In your module config, override the collector command with sudo for every collector you are using and add the actual command as custom argument. Example for the "ipmi" collector:
```
collector_cmd:
  ipmi: sudo
custom_args:
  ipmi:
  - "ipmimonitoring"
```
See the last module in the example config.

Running in Docker

NOTE: you should only use Docker for remote metrics.

See Building a Docker container and the example docker-compose.yml. Edit the ipmi_remote.yml file to configure IPMI credentials, then run with:

sudo docker-compose up -d

By default, the server will bind on 0.0.0.0:9290.

Configuration

The configuration document describes both the configuration of the IPMI exporter itself as well as providing some guidance for configuring the Prometheus server to scrape it.

TLS and basic authentication

The IPMI Exporter supports TLS and basic authentication.

To use TLS and/or basic authentication, you need to pass a configuration file using the --web.config.file parameter. The format of the file is described in the exporter-toolkit repository.

Exported data

For a description of the metrics that this exporter provides, see the metrics document.

ipmi_exporter's People

Contributors

Stargazers

Watchers

Forkers

kuckkuck jenningsloy318 sapcc squawell sysbot esapozhnikov-wish acdc-cloud automatedops dannyk81 adiantum hholst80 00arthur00 nitisht superq erimar77 wxcen pandada8 ektich tom2jack msherman64 dtsre neoaggelos zliuva 12bay imdingtalk treydock cawamata danjpar justereseau havefun83 pritpal-sabharwal shiresn cdn77 101101 itboon ccbt87 smil-infra lars2206 yftian wright08 nccloud jephilc cremator zwb-github l337ch aashley adenau ainamori alvinlv00 congtong rezabojnordi 1714801500 isgasho junneyang ealgra yaolong01 neredera qd888 netmax79 sgargel tommy-dimitrio lanulihes scrin xibolun gabornj xcc-git jadyndev wangjiadongpro whoyz oliverpool kitter wajianming l19891223j xllping tomhughes mnaser duangx yostlfog k0ste veera444 pgorniak8 stefanhipfel isabella232 todufeso astappiev jlrgraham yanghesong zhejiang-lab-pangu tobymcclean smithx10 wykeinstein liuxfsky leonzhao2020 maplewhitezzz pkuwangh petshopjke1337 pnw-ryanmcgr uwrc-hyak fadewalk hydrapozza

ipmi_exporter's Issues

collect metrics from ipmi sel log

Unfortunately some data is not available directly from sensors but rather from their log ipmi-sel.
Most interesting for me is "Memory Status" data, where you can get info about "Uncorrectable memory error" but may be more info. Is there any nice way to pull this data and user it in to prometheus?

When to support raw command?

As I see, the exporter worked depends on some binary tool installed like ipmitoool ipmi-dcmi and so on. But why not send a request to target ipmi with raw command like 0x20 ? We can work it with no dependance and get much more metrics as we can.

FreeIPMI VS ipmiutil

Hi guys,
I have a question about why we use FreeIPMI instead of ipmiutil, as I test, ipmiutil compatibility is better than FreeIPMI, is there any plan to switch from FreeIPMI to ipmiutil, or you can accept a MR about ipmiutil replacement？ Thank you very much.

Older ipmimonitoring does not support --ignore-unrecognized-events and --output-event-bitmask

Older ipmimonitoring does not support --ignore-unrecognized-events and --output-event-bitmask flags.

ipmimonitoring: unrecognized option '--ignore-unrecognized-events'

ipmimonitoring: unrecognized option '--output-event-bitmask'

ipmimonitoring - 0.8.12
Copyright (C) 2007-2010 Lawrence Livermore National Security, LLC.
Copyright (C) 2006-2007 The Regents of the University of California.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.

I know it's very old and outdated but it would be nice if it's possibile to skip passing that flags.

"unsupported value type" on FreeBSD

Build ipmi_explorer on FreeBSD.

root@stor:/usr/local/src/ipmi_exporter # /usr/local/sbin/ipmi_exporter --freeipmi.path=/usr/local/sbin
level=info ts=2021-10-23T19:53:18.323Z caller=main.go:101 msg="Starting ipmi_exporter" version="(version=1.4.0, branch=master, revision=b806738818fe9e6bf5dbf23abba97392bf53786b)"
level=info ts=2021-10-23T19:53:18.323Z caller=main.go:166 msg="Listening on" address=:9290
level=debug ts=2021-10-23T19:53:31.777Z caller=config.go:282 msg="Needed default config for, but none configured, using FreeIPMI defaults" target=[local]
level=debug ts=2021-10-23T19:53:31.778Z caller=collector.go:100 msg="Running collector" collector=ipmi
level=debug ts=2021-10-23T19:53:31.778Z caller=freeipmi.go:139 msg=Executing command=/usr/local/sbin/ipmimonitoring args="unsupported value type"
level=debug ts=2021-10-23T19:53:32.044Z caller=collector_ipmi.go:161 msg="Got values" data="unsupported value type"
level=debug ts=2021-10-23T19:53:32.044Z caller=collector_ipmi.go:161 msg="Got values" data="unsupported value type"
level=debug ts=2021-10-23T19:53:32.044Z caller=collector_ipmi.go:161 msg="Got values" data="unsupported value type"
level=debug ts=2021-10-23T19:53:32.044Z caller=collector_ipmi.go:161 msg="Got values" data="unsupported value type"
level=debug ts=2021-10-23T19:53:32.044Z caller=collector_ipmi.go:161 msg="Got values" data="unsupported value type"

And I have no idea on what's wrong. ipmimonitoring works ok.

Problem

Hey,
after setting go environment when i start 'make' a receive the following:

checking code style
running check for unused/missing packages in go.mod
GO111MODULE=on go mod tidy
go: downloading github.com/prometheus/common v0.10.0
go: downloading github.com/prometheus/client_golang v1.7.1
go: downloading gopkg.in/yaml.v2 v2.3.0
go: downloading gopkg.in/alecthomas/kingpin.v2 v2.2.6
go: downloading gopkg.in/check.v1 v1.0.0-20200227125254-8fa46927fb4f
go: downloading github.com/alecthomas/template v0.0.0-20190718012654-fb15b899a751
go: downloading github.com/alecthomas/units v0.0.0-20190924025748-f65c72e2690d
go: downloading github.com/stretchr/testify v1.5.1
go: downloading github.com/sirupsen/logrus v1.6.0
go: downloading golang.org/x/sys v0.0.0-20200724161237-0e2f3a69832c
go: downloading github.com/prometheus/client_model v0.2.0
go: downloading github.com/golang/protobuf v1.4.2
go: downloading github.com/prometheus/procfs v0.1.3
go: downloading github.com/beorn7/perks v1.0.1
go: downloading github.com/cespare/xxhash/v2 v2.1.1
go: downloading github.com/niemeyer/pretty v0.0.0-20200227124842-a10e7caefd8e
go: downloading github.com/konsorten/go-windows-terminal-sequences v1.0.3
go: downloading github.com/pmezard/go-difflib v1.0.0
go: downloading google.golang.org/protobuf v1.25.0
go: downloading github.com/matttproud/golang_protobuf_extensions v1.0.1
go: downloading github.com/davecgh/go-spew v1.1.1
go: downloading github.com/kr/text v0.2.0
go: downloading github.com/google/go-cmp v0.5.0
go: downloading golang.org/x/xerrors v0.0.0-20191204190536-9bdfabe68543
running check for unused packages in vendor/
GO111MODULE=on go mod vendor
Not a git repository
To compare two paths outside a working tree:
usage: git diff [--no-index]
Makefile.common:212: recipe for target 'common-unused' failed
make: *** [common-unused] Error 129

can you please help me

Remote target not working with current version of ipmi-sensors

Remote target auth is not working with current version ipmi-sensors - 1.1.5

When running against a target with username and password seeing following errors:

ERRO[0002] Error while calling ipmimonitoring: /usr/sbin/ipmi-sensors: password invalid  source="collector.go:227"
ERRO[0002] Failed to collect ipmimonitoring data: exit status 1  source="collector.go:369"
ERRO[0002] Error while calling ipmi-dcmi: ipmi-dcmi: password invalid  source="collector.go:227"
ERRO[0002] Error while calling bmc-info: bmc-info: password invalid  source="collector.go:227"

Adding the following lines under line 218 in collector.go fixes the issue:

                        "-u", rmcp.user,
                        "-p", rmcp.pass,

Can we drop the privilege-level to user by default

I see that in the base freeipmiconfig, the privilege-level is hardcoded to "admin".

func freeipmiConfig(driver, user, password string) string {
	return fmt.Sprintf(`
driver-type %s
privilege-level admin

Is there any specific reason to default to "admin" level here? I changed to "user" level and could fetch the same metrics as when it was set to "admin" level. (PS. I couldn't test ipmi_cmd_dcmi_get_power_reading as its unsupported on my test box). But, I guess that should work too!

The reason I am bringing this up is because, we want to create a separate user for monitoring with a lesser privilege level.

Also, when the privilege-level is lowered here, higher privileged users can connect but not vise-versa. So, couple of options I can think of:

By default, set the privilege-level to user.
Provide a config option to set privilege-level.

Can we have releases of this exporter

Hello,

Can we add version info and metadata to the exporter. And then tag/release it accordingly? Similar to other Prometheus exporters out there.

I am asking so that we can push out this to NixPkgs and download/install it from there. Or in general for any in-house packaging and maintenance.

Thanks,
Raj

missing fan status

Hi,
It seems that ipmitool with the following syntax is able to extract more information, in my case querying an HP DL360 G10 server ilo remotely, its able to get fan status.
However when querying with ipmi_export with the following settings, other info comes up but nothing regarding the fans

            driver: "LAN_2_0"
            privilege: "admin"
            collectors:
            - bmc
            - ipmi
            - chassis
            - sel
            - sm-lan-mode
            - dcmi

Any way to fix this ?

Thanks

ipmitool -H xxxxx -U xxxxxxx -P xxxxxx -I lanplus sdr elist
UID | AEh | ok | 23.1 |
SysHealth_Stat | ACh | ok | 23.1 | Transition to OK
01-Inlet Ambient | A2h | ok | 55.1 | 19 degrees C
02-CPU 1 | 02h | ok | 3.1 | 40 degrees C
03-CPU 2 | 03h | ok | 3.2 | 40 degrees C
04-P1 DIMM 1-6 | 24h | ok | 32.11 | 29 degrees C
05-PMM 1-6 | FEh | ns | 7.1 | Disabled
06-P1 DIMM 7-12 | 25h | ok | 32.12 | 29 degrees C
07-PMM 7-12 | FDh | ns | 7.1 | Disabled
08-P2 DIMM 1-6 | 26h | ok | 32.13 | 32 degrees C
09-PMM 1-6 | FCh | ns | 7.1 | Disabled
10-P2 DIMM 7-12 | 27h | ok | 32.14 | 31 degrees C
11-PMM 7-12 | FBh | ns | 7.1 | Disabled
12-HD Max | 98h | ns | 4.3 | Disabled
13-Exp Bay Drive | 96h | ns | 4.1 | Disabled
14-Stor Batt 1 | BFh | ok | 40.1 | 19 degrees C
15-Front Ambient | A3h | ok | 55.2 | 21 degrees C
16-VR P1 | 0Ah | ok | 20.1 | 34 degrees C
17-VR P2 | 0Bh | ok | 20.2 | 36 degrees C
18-VR P1 Mem 1 | 61h | ok | 20.21 | 25 degrees C
19-VR P1 Mem 2 | 62h | ok | 20.22 | 25 degrees C
20-VR P2 Mem 1 | 63h | ok | 20.23 | 27 degrees C
21-VR P2 Mem 2 | 64h | ok | 20.24 | 29 degrees C
22-Chipset | A4h | ok | 7.1 | 37 degrees C
23-BMC | FAh | ok | 7.1 | 66 degrees C
24-BMC Zone | F9h | ok | 7.1 | 37 degrees C
25-HD Controller | B3h | ok | 11.1 | 52 degrees C
26-HD Cntlr Zone | F8h | ok | 7.1 | 28 degrees C
27-LOM | B4h | ok | 11.3 | 44 degrees C
28-LOM Card | B5h | ns | 11.4 | Disabled
29-I/O Zone | F7h | ok | 7.1 | 29 degrees C
30-PCI 1 | 84h | ns | 49.1 | Disabled
31-PCI 1 Zone | F6h | ok | 7.1 | 30 degrees C
32-PCI 2 | 85h | ns | 49.2 | Disabled
33-PCI 2 Zone | F5h | ok | 7.1 | 30 degrees C
34-PCI 3 | 86h | ns | 49.3 | Disabled
35-PCI 3 Zone | F4h | ns | 7.1 | Disabled
37-Rear HD Max | 99h | ns | 4.4 | Disabled
38-Battery Zone | F3h | ok | 7.1 | 32 degrees C
39-P/S 1 Inlet | 4Bh | ok | 10.1 | 30 degrees C
40-P/S 2 Inlet | 4Ch | ok | 10.2 | 32 degrees C
41-P/S 1 | 43h | ok | 10.1 | 40 degrees C
42-P/S 2 | 44h | ok | 10.2 | 40 degrees C
43-E-Fuse | A5h | ok | 20.0 | 30 degrees C
44-P/S 2 Zone | F2h | ok | 7.1 | 34 degrees C
61-AHCI HD Max | F1h | ns | 7.1 | Disabled
69-PCI 1 M2 | F0h | ns | 7.1 | Disabled
70-PCI 1 M2 Zn | EFh | ns | 7.1 | Disabled
71-PCI 2 M2 | EEh | ns | 7.1 | Disabled
72-PCI 2 M2 Zn | EDh | ns | 7.1 | Disabled
73-PCI 3 M2 | ECh | ns | 7.1 | Disabled
74-PCI 3 M2 Zn | EBh | ns | 7.1 | Disabled
Fan 1 | 03h | ok | 29.1 | Transition to OK
Fan 1 DutyCycle | 01h | ok | 29.1 | 39.98 percent
Fan 1 Presence | 02h | ok | 29.1 | Device Present
Fan 2 | 06h | ok | 29.2 | Transition to OK
Fan 2 DutyCycle | 04h | ok | 29.2 | 39.98 percent
Fan 2 Presence | 05h | ok | 29.2 | Device Present
Fan 3 | 09h | ok | 29.3 | Transition to OK
Fan 3 DutyCycle | 07h | ok | 29.3 | 39.98 percent
Fan 3 Presence | 08h | ok | 29.3 | Device Present
Fan 4 | 0Ch | ok | 29.4 | Transition to OK
Fan 4 DutyCycle | 0Ah | ok | 29.4 | 39.98 percent
Fan 4 Presence | 0Bh | ok | 29.4 | Device Present
Fan 5 | 0Fh | ok | 29.5 | Transition to OK
Fan 5 DutyCycle | 0Dh | ok | 29.5 | 39.98 percent
Fan 5 Presence | 0Eh | ok | 29.5 | Device Present
Fan 6 | 12h | ok | 29.6 | Transition to OK
Fan 6 DutyCycle | 10h | ok | 29.6 | 39.98 percent
Fan 6 Presence | 11h | ok | 29.6 | Device Present
Fan 7 | 15h | ok | 29.7 | Transition to OK
Fan 7 DutyCycle | 13h | ok | 29.7 | 39.98 percent
Fan 7 Presence | 14h | ok | 29.7 | Device Present
Power Supply 1 | 32h | ok | 10.1 | Presence detected
PS 1 Output | 3Ah | ok | 10.1 | 105 Watts
Power Supply 2 | 33h | ok | 10.2 | Presence detected
PS 2 Output | 3Bh | ok | 10.2 | 130 Watts
Power Meter | B6h | ok | 7.1 | 250 Watts
Fans | 31h | ok | 30.1 | Fully Redundant
Power Supplies | 42h | ok | 19.1 | Fully Redundant
Memory Status | 48h | ok | 32.0 | Presence Detected
Megacell Status | BBh | ok | 40.1 | Presence Detected
Intrusion | ABh | ns | 23.1 | Disabled
CPU Utilization | 23h | ok | 3.1 | 48 unspecified
LOM_Link_P1 | 01h | ns | 44.97 | Disabled
LOM_Link_P2 | 02h | ns | 44.98 | Disabled
LOM_Link_P3 | 03h | ns | 44.99 | Disabled
LOM_Link_P4 | 04h | ns | 44.100 | Disabled
ALOM_Link_P1 | 01h | ok | 44.97 | Heartbeat
ALOM_Link_P2 | 02h | ns | 44.98 | Disabled
ALOM_Link_P3 | 03h | ns | 44.99 | Disabled
ALOM_Link_P4 | 04h | ns | 44.100 | Disabled
Dr_Stat_1I1_B001 | 02h | ns | 0.0 | No Reading
Dr_Stat_1I1_B002 | 03h | ns | 0.0 | No Reading
Dr_Stat_1I1_B003 | 04h | ns | 0.0 | No Reading
Dr_Stat_1I1_B004 | 05h | ns | 0.0 | No Reading
CPU_Stat_C1 | 12h | ok | 3.1 | Presence detected
CPU_Stat_C2 | 13h | ok | 3.2 | Presence detected

How to specify host target?

For the exporter configuration, I want to specify the host target info, but haven't been able to fathom how to do so. Looking for a pointer in the right direction.

I am currently attempting to use the following setup:

I have a Supermicro system with a separate IP devoted to IPMI x.x.x.161 and user/pass. How do I configure the exporter yml to use that host?

In particular, how does one specify the host part of a target here:
https://github.com/soundcloud/ipmi_exporter/blob/26628185da9ad4aae11ee5df69d25f57cd4307dd/collector.go#L610

Stale named pipes left behind in /tmp

I noticed after running the exporter for a few weeks, configured to probe several hundred remote hosts, that stale named pipes are being left behind in /tmp.

Looking at the freeipmiOutput function, I see there is a deferred os.Remove of the pipe, so this should be removing the pipe, even if the command execution fails. Obviously however, sometimes the named pipes are not being removed.

In the freeipmiConfigPipe function that creates the named pipes, I see there is a goroutine which actually writes the config to the pipe. AFAICT, the reason why this is a goroutine is that writing to a pipe will block until something reads from the pipe (i.e., when the ipmitool command is executed).

lsof doesn't appear to indicate that the exporter is leaking FDs, so the "bug" seems to be somewhere in the code after the config is written to the pipe and the FD has been closed. Indeed, trying to read from the pipe simply blocks, which indicates that content has already been read from it (i.e., by ipmitool).

Failed COPY ipmi_exporter from=builder

Hi, I found that the Dockerfile needs to change "COPY --from=builder" due to as below.

ISSUE TYPE

HOW TO GET THE INFO

docker build .
(or make docker)

SAMPLE COMMAND OUTPUT

--- snip ---
Setting up libfreeipmi16 (1.4.11-1.1ubuntu4.1) ...
Setting up libipmiconsole2 (1.4.11-1.1ubuntu4.1) ...
Setting up libipmidetect0 (1.4.11-1.1ubuntu4.1) ...
Setting up freeipmi-tools (1.4.11-1.1ubuntu4.1) ...
Processing triggers for libc-bin (2.27-3ubuntu1.2) ...
Removing intermediate container f1a5395f3dd1
 ---> 91f8416c8110
Step 8/11 : COPY --from=builder /go/src/github.com/soundcloud/ipmi_exporter/ipmi_exporter /bin/ipmi_exporter
COPY failed: stat /var/lib/docker/overlay2/dd2f3f0e5d52053eb96a23e586d1e84c319276278249b16e7df6d462cf3f4f1c/merged/go/src/github.com/soundcloud/ipmi_exporter/ipmi_exporter: no such file or directory
ERROR: Job failed: exit code 1

CAUSE

go builder in docker makes ipmi_exporter as ipmi-exporter.

>> running check for unused packages in vendor/
GO111MODULE=on go mod vendor
curl -s -L https://github.com/prometheus/promu/releases/download/v0.5.0/promu-0.5.0.linux-amd64.tar.gz | tar -xvzf - -C /tmp/tmp.3HO4rjwbn0
promu-0.5.0.linux-amd64/
promu-0.5.0.linux-amd64/promu
promu-0.5.0.linux-amd64/NOTICE
promu-0.5.0.linux-amd64/LICENSE
mkdir -p /go/bin
cp /tmp/tmp.3HO4rjwbn0/promu-0.5.0.linux-amd64/promu /go/bin/promu
rm -r /tmp/tmp.3HO4rjwbn0
>> building binaries
GO111MODULE=on /go/bin/promu build --prefix /go/src/github.com/soundcloud/ipmi_exporter 
 >   ipmi-exporter
>> running all tests

Note: go builder on CentOS (yum install golang) makes ipmi_exporter as `ipmi_exporter'. It seems only docker images.

SOLUTION

Change filename.

Will be supported by non-system administrator execution

Hi.
Recently, I found this exporter for monitoring H/W status via freeipmi commands.
However, this exporter is based on running by system administrator because of executing freeipmi commands.

Due to this, http process is also running by system administrator

I think this is not good from security, because if this process was cracked, cracker will get system administrator authority.

My proposal is the followings not to execute by system administrator

Plan1
If you have knowledge to execute non-administrator, can you update README document to support (ex: updating the owner/permission under /dev/)
Plan2
collector.go will support via sudo command if daemon is running by non-administrator.

What do you think about this?

make power consumption collection optional

Thanks for creating this exporter! Some hardware (eg: Cisco) does not appear to support the ipmi dcmi extension, so the ipmi-dcmi command fails with:
ipmi_cmd_dcmi_get_power_reading: command invalid or unsupported

Can you make it so that the collector still collects the monitoring data even if the dcmi command fails?

Some ideas:

Add a flag to disable ipmi-dcmi
Add ipmi_dcmi_up metric to indicate whether dcmi command succeeded, and proceed even if it fails.
Run ipmimonitoring before ipmi-dcmi, and set ipmi_up to 0 only if bmc-info or ipmimonitoring commands fail
Detect whether DCMI is supported before running the ipmi-dcmi command (not sure how to do that).

Example config file

Hello!
I'm trying to set up ipmi_exporter on a host to do remote monitoring on two HP servers.
The problem I'm running into is that I don't quite know how to set up the config file.
(Unless I'm missing something) In the readme it only says the syntax is similar to blackbox. However I don't quite know what modules exist nor do I know what the exact syntax is.

Having an example config.file would be very helpful. If not then just a list of modules and a general overview.

ILO5 and ipmi

hello,

I would like to monitor hardware status of hp server with ipmi, but with ILO5 hp server I don't have disk status ! but I have these info with ILO4.

any idea ?

thank you

sensor reading is unavailable

Hi,
while i was testing this exporter
if i run this command on one host
./ipmimonitoring -Q -b --comma-separated-output --output-sensor-state
the result would be
...... 32,PS Status,Power Supply,Nominal,N/A,N/A,'OK'
and Ipmi exporter will report
ipmi_sensor_state{id="32",name="PS Status",type="Power Supply"} 0
which is totally fine and correct
however on some old BMC's running the command :
./ipmimonitoring -Q -b --comma-separated-output --output-sensor-state
will give
1813,PS Status,Power Supply,N/A,N/A,N/A,'Presence detected' 'Unrecognized Event = 0100h' 'Unrecognized Event = 0200h' 'Unrecognized Event = 0400h' 'Unrecognized Event = 0800h' 'Unrecognized Event = 1000h' 'Unrecognized Event = 2000h' 'Unrecognized Event = 4000h'
and thus ipmi exporter will report
ipmi_sensor_value{id="1813",name="PS Status",type="Power Supply"} NaN
in this case the Presence detected in the event column tells that PSU plugged in and works
my goal is to monitor PSU's and write alerting rules for them
could you please check also the event column
somthing like :
collector.go #396:

              case "N/A":
			log.Debugf("Sensor reading is N/A checking event")
			if strings.Contains(data.Event, "Presence detected") || strings.Contains(data.Event, "OK") {
				log.Debugf("Event has 'Presence detected' or 'OK' setting to nominal")
				state = 0
			} else {
				state = math.NaN()
			}

i will submit a merge request soon
Thanks in advance

Can you provide a grafana dashborder JSON file

Unable to start container

Getting below error while creating container using image.
Error: container_linux.go:370: starting container process caused: exec: "/bin/ipmi_exporter": permission denied: OCI permission denied

Can you please share docker image.

ipmi cache

Is there any way to control the sdr cache? With some latest kernels ipmi tools oftenly refuse to output data because of memory issue. Like

:~# ipmi-sel
ipmi_ctx_find_inband: out of memory

Seems to be related to

https://lkml.org/lkml/2020/4/17/16

Add --web.disable-exporter-metrics

ipmi_exporter returns a bunch of go internal metrics:

curl localhost:9290/metrics
# HELP go_gc_duration_seconds A summary of the GC invocation durations.
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 0
go_gc_duration_seconds{quantile="0.25"} 0
go_gc_duration_seconds{quantile="0.5"} 0
go_gc_duration_seconds{quantile="0.75"} 0
go_gc_duration_seconds{quantile="1"} 0
go_gc_duration_seconds_sum 0
go_gc_duration_seconds_count 0
# HELP go_goroutines Number of goroutines that currently exist.
# TYPE go_goroutines gauge
go_goroutines 9
... etc

It would be nice to have a flag to disable these, as node_exporter has:

                disableExporterMetrics = kingpin.Flag(
                        "web.disable-exporter-metrics",
                        "Exclude metrics about the exporter itself (promhttp_*, process_*, go_*).",
                ).Bool()
...

Otherwise these metrics need to be filtered out by metric relabelling.

"dcmi"-scrape status "0" but data was gathered

Vielen Dank for this software in the first place! I started using this app. a week ago against Dell- and Supermicro-servers (and a cheap HPE Proliant at home).
With the recent commit 109c7ca I see the DCMI-collector has status "0" after a scrape, where in fact is has gathered a value from the power consumption:

grep dcmi output-to-file
# HELP ipmi_dcmi_power_consumption_watts Current power consumption in Watts.
# TYPE ipmi_dcmi_power_consumption_watts gauge
ipmi_dcmi_power_consumption_watts 90
ipmi_up{collector="dcmi"} 0

Scraping with ipmi-dcmi confirms:

# ipmi-dcmi -h 10.11.12.13 -u user -p password -D LAN_2_0 -l user --get-system-power-statistics
Current Power                        : 90 Watts
Minimum Power over sampling duration : 10 watts
Maximum Power over sampling duration : 182 watts
Average Power over sampling duration : 89 watts
Time Stamp                           : 08/03/2018 - 13:15:03
Statistics reporting time period     : 1000 milliseconds
Power Measurement                    : Active

This behaviour is identical on both Dell and Supermicro.
From my point of view, the scrape is successful, but ipmi_exporter thinks not...
Any thoughts about this?

Configuration issues old vs new ipmi.yml

Long time user of ipmi_exporter here! ❤️
I have finally upgraded our version dating from Aug. 2018 to v1.3.2.
Now the changes in ipmi.yml have slapped me in the face pretty hard.

We use a combination of (lets make it) 56 hosts: 40 hosts with password 12345, 8 hosts with password abcde and another 8 with password 1a2b3c used to be working where the 40 hosts where used as default and the other 2x 8 ones as "specialhosts", using their unique IP addresses:

Old ipmi.yml used to be pretty small, using default as expected:

credentials:
  default:
    user: "user1"
    pass: "12345"
  10.20.30.10:
    user: "user2"
    pass: "abcde"

--- and so on for 2x 8 hosts

The only way I could get it to work was adding ALL hosts / IP addresses separately one-by-one into the newer ipmi.yml as "module", like this:

modules:
  default:
    user: user1
    pass: 12345
    driver: LAN_2_0
    privilege: user
  10.20.30.10:               # duplicate from default
    user: user1
    pass: 12345
    driver: LAN_2_0
  10.20.30.11:
    user: user2
    pass: abcde
  10.20.30.12:
    user: user3
    pass: a1b2c3
    collectors:
    - bmc
    - ipmi
    - chassis

--- etcetera - up to > 250 lines

The block with default is needed, otherwise a scrape would give

# curl "http://10.20.30.222:9290/ipmi?target=10.20.30.10"
Unknown module "default"

In file /etc/prometheus/prometheus.yml currently the job is configured like this - I freshly added the source_labels-block with __param_module as suggested here: #50 (comment)

  - job_name: 'ipmi'
    scrape_interval: 1m
    scrape_timeout: 30s
    metrics_path: /ipmi
    scheme: http
    file_sd_configs:
      - files:
        - /etc/prometheus/targets/ipmi_exporter.yml
        refresh_interval: 5m
    relabel_configs:
    - source_labels: [__address__]
      separator: ;
      regex: (.*)(:80)?
      target_label: __param_target
      replacement: ${1}
      action: replace
    - source_labels: [__address__]
      separator: ;
      regex: (.*)(:80)?
      target_label: __param_module
      replacement: ${1}
      action: replace
    - separator: ;
      regex: .*
      target_label: __address__
      replacement: ipmi_exporter.example.com:9290
      action: replace

I hope the above explains the situation where we came from and how it runs as of today.

My question: is this for now the right way to go or is there a better way?
The newer ipmi.yml has grown considerably, in our case to over 260 lines.

impi-dcmi命令报错

Testing a target

Hello,
I am relatively new to prometheus and exporters, and I have configured this exporter to get status info from our out-of-band bmc/ipmi targets. The problem I am having is that no matter what password I enter into the "default" module, I get an error stating
password invalid\n" source="collector.go:249"
If I want to send a curl request to the node exporter to query a remote target, how would I go about doing this?
For example, would this work, or do I have to construct a json string in order to test a target before entering it into my prometheus configuration?

curl http://localhost:9290/ipmi?target=192.168.100.1&user=admin&password=password&driver=lanplus

Thank you.

Question: Help with Local Configuration

I am trying to set up ipmi_exporter locally (without running in Docker) on an Ubuntu Server machine to collect metrics by a Prometheus instance on the same host. However, I am struggling to to get ipmi_exporter to scrape the metrics I want. I have probably missed something, but I cannot seem to figure out what. I am hoping someone can look this over and maybe point out what I need to do differently.

I have installed FreeIPMI and can run the various tools using sudo.
I have set up ipmi_exporter to run as a service with its own system user/group "exporters" and the following config:

[Unit]
Description=Prometheus IPMI Exporter
Documentation=https://github.com/prometheus-community/ipmi_exporter

[Service]
Type=simple
User=exporters
Group=exporters
ExecReload=/bin/kill -HUP $MAINPID
ExecStart=/usr/local/bin/ipmi_exporter \
    --config.file=/usr/local/bin/ipmi-exporter-config.yml \
    --web.listen-address=:9200

[Install]
WantedBy=multi-user.target

Since the FreeIPMI tool are run as sudo I have added the following to the sudoers file to allow the exporters user to run the tools without password.

exporters ALL = NOPASSWD: /usr/sbin/ipmimonitoring,\
                          /usr/sbin/ipmi-sensors,\
                          /usr/sbin/ipmi-dcmi,\
                          /usr/sbin/ipmi-raw,\
                          /usr/sbin/bmc-info,\
                          /usr/sbin/ipmi-chassis,\
                          /usr/sbin/ipmi-sel

I added it after this section in the sudoers file:

# User privilege specification
root    ALL=(ALL:ALL) ALL

The ipmi_exporter configuration file looks like this:

modules:
        default:
                # Available collectors are bmc, ipmi, chassis, dcmi, sel, and sm-lan-mode
                collectors:
                - bmc
                - ipmi
                - dcmi
                - chassis
                - sel
                # Got any sensors you don't care about? Add them here.
                exclude_sensor_ids:
        advanced:
                collectors:
                - bmc
                - ipmi
                - dcmi
                - chassis
                - sel
                collector_cmd:
                        bmc: sudo
                        ipmi: sudo
                        dcmi: sudo
                        chassis: sudo
                        sel: sudo
                custom_args:
                        bmc:
                        - "bmc-info"
                        ipmi:
                        - "ipmimonitoring"
                        dcmi:
                        - "ipmi-dcmi"
                        chassis:
                        - "ipmi-chassis"
                        sel:
                        - "ipmi-sel"

After starting the node_exporter service and use curl to check the endpoint (curl http://localhost:9200/metrics) I get a response, but it does not seem to contain any actual scraped metrics.

As you can see from the service status below I am getting a permissioned denied error for all the collectors.

● ipmi_exporter.service - Prometheus IPMI Exporter
     Loaded: loaded (/etc/systemd/system/ipmi_exporter.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2021-11-01 20:22:55 CET; 39s ago
       Docs: https://github.com/prometheus-community/ipmi_exporter
   Main PID: 1534642 (ipmi_exporter)
      Tasks: 12 (limit: 38232)
     Memory: 2.3M
     CGroup: /system.slice/ipmi_exporter.service
             └─1534642 /usr/local/bin/ipmi_exporter --config.file=/usr/local/bin/ipmi-exporter-config.yml --web.listen-address=:9200

 systemd[1]: Started Prometheus IPMI Exporter.
ipmi_exporter[1534642]: time="2021-11-01T20:22:55+01:00" level=info msg="Starting ipmi_exporter" source="main.go:83"
ipmi_exporter[1534642]: time="2021-11-01T20:22:55+01:00" level=info msg="Loaded config file /usr/local/bin/ipmi-exporter-config.yml" source="config.go:234"
ipmi_exporter[1534642]: time="2021-11-01T20:22:55+01:00" level=info msg="Listening on :9200" source="main.go:147"
ipmi_exporter[1534642]: time="2021-11-01T20:23:25+01:00" level=error msg="Failed to collect BMC data from [local]: error running bmc-info: exit status 1: bmc-info: permission denied\n" source="collector_bmc.go:40"
ipmi_exporter[1534642]: time="2021-11-01T20:23:25+01:00" level=error msg="Failed to collect sensor data from [local]: error running ipmimonitoring: exit status 1: /usr/sbin/ipmi-sensors: permission denied\n" source="colle>
ipmi_exporter[1534642]: time="2021-11-01T20:23:25+01:00" level=error msg="Failed to collect DCMI data from [local]: error running ipmi-dcmi: exit status 1: ipmi-dcmi: permission denied\n" source="collector_dcmi.go:40"
ipmi_exporter[1534642]: time="2021-11-01T20:23:25+01:00" level=error msg="Failed to collect chassis data from [local]: error running ipmi-chassis: exit status 1: ipmi-chassis: permission denied\n" source="collector_chassi>
ipmi_exporter[1534642]: time="2021-11-01T20:23:25+01:00" level=error msg="Failed to collect SEL data from [local]: error running ipmi-sel: exit status 1: ipmi-sel: permission denied\n" source="collector_sel.go:47"

rmcp tools default timeout is greater than scrape timeout

Really awesome tool! thank you for sharing 😄

We've been hitting a small issue when using it for remote metrics collection (rmcp), it seems that the default timeout of the ipmi cli tools is quite long and in some cases we end up with scrape context deadlines so these targets are missing their respective ipmi_up metrics.

We can still rely on up to detect that the target is down but using ipmi_up seems more relevant in this case as it can also indicate which collector is failing/etc.

The underlying ipmi tools all have a session timeout parameter:

--session-timeout=MILLISECONDS
                             Specify the session timeout in milliseconds.

I think it would be great if we could control the timeout via the configuration (ipmi.yaml) so we can tune it to be <scrape_timeout

wdyt?

/cc @bitfehler

Which options are supported for the driver setting？

I command through "man 5 freeipmi.conf" , there is no options:
driver-type IPMIDRIVER
Specify the default driver type to use.

Does not compile on freesd 13.0

Correction it does compile. Case can be closed.

Publish docker image to docker hub?

is there an existing image on docker hub or anywhere so that everyone don't need to build their own?

Collect IPMI metrics locally per node?

The main use case that I would like to use this exporter for would be to collect IPMI metrics locally for each node, similar to the approach that https://github.com/lovoo/ipmi_exporter takes and similar to how node-exporter works.

Is this behavior possible with this exporter?

Enhance config reload HTTP response code

To conform RFC 7231 we should set the 'Allow' field in the http response header to 'POST' and return HTTP 405 (Method Not Allowed) instead of HTTP 400 (Bad Request). This would mirror how it is done in Prometheus web.go

References:

https://tools.ietf.org/html/rfc7231#section-6.5.5 (Method not allowed)
https://tools.ietf.org/html/rfc7231#section-7.4.1 (Allow)

Error to collect dcmi

Using docker, version 1.4.0

Getting below when enable dcmi:

ime="2021-06-04T19:05:40Z" level=error msg="Failed to collect DCMI data from xx: error running ipmi-dcmi: exit status 1: ipmi_cmd_dcmi_get_power_reading: bad completion code\n" source="collector_dcmi.go:40"
time="2021-06-04T19:05:47Z" level=error msg="Failed to collect DCMI data from xx: error running ipmi-dcmi: exit status 1: ipmi_cmd_dcmi_get_power_reading: bad completion code\n" source="collector_dcmi.go:40"
time="2021-06-04T19:05:50Z" level=error msg="Failed to collect DCMI data from xx: error running ipmi-dcmi: exit status 1: ipmi_cmd_dcmi_get_power_reading: bad completion code\n" source="collector_dcmi.go:40"
time="2021-06-04T19:06:50Z" level=error msg="Failed to collect DCMI data from xx: error running ipmi-dcmi: exit status 1: ipmi_cmd_dcmi_get_power_reading: bad completion code\n" source="collector_dcmi.go:40"
time="2021-06-04T19:07:50Z" level=error msg="Failed to collect DCMI data from xx: error running ipmi-dcmi: exit status 1: ipmi_cmd_dcmi_get_power_reading: bad completion code\n" source="collector_dcmi.go:40"
time="2021-06-04T19:08:50Z" level=error msg="Failed to collect DCMI data from xx: error running ipmi-dcmi: exit status 1: ipmi_cmd_dcmi_get_power_reading: bad completion code\n" source="collector_dcmi.go:40"

Don't show password in process list

This had not been a concern for us as we're running this on a restricted access server already, but it's a common security issue nonetheless, so let's fix it.

Support for OEM extensions

I'd appreciate a sense of direction as to how to adapt the code to monitor OEM extensions. I'm thinking particular of the Dell extensions, for which there's a tool idelloem documented here https://linux.die.net/man/8/idelloem

Scraping /metrics endpoint triggers a local execution of bmc-info, ipmimonitoring

We are interested in running ipmi_exporter in VMs and using it to probe multiple remote hosts via the LAN_2_0 driver.

I have noticed that when scraping the /metrics endpoint, this is triggering an unwanted execution of bmc-info and ipmimonitoring commands. This is obviously not going to work in a VM, which has no IPMI device.

Sep 23 14:05:48 ber-prom1 prometheus-ipmi-exporter[5796]: time="2019-09-23T14:05:48Z" level=error msg="Error while calling bmc-info for [local]: hostname not specified\n" source="collector.go:235"
Sep 23 14:05:48 ber-prom1 prometheus-ipmi-exporter[5796]: time="2019-09-23T14:05:48Z" level=error msg="Error while calling ipmimonitoring for [local]: hostname not specified\n" source="collector.go:235"
Sep 23 14:05:48 ber-prom1 prometheus-ipmi-exporter[5796]: time="2019-09-23T14:05:48Z" level=error msg="Failed to collect ipmimonitoring data from [local]: exit status 1" source="collector.go:397"

As far as I can tell, it's due to the fact that the main function registers a collector, which is going to be invoked by promhttp.Handler whenever the /metrics endpoint is hit.

	localCollector := collector{target: targetLocal, module: "default", config: sc}
	prometheus.MustRegister(&localCollector)

	http.Handle("/metrics", promhttp.Handler())       // Regular metrics endpoint for local IPMI metrics.

I'm not sure if the ramifications of this were fully considered. To compare with blackbox_exporter, which is a similar design pattern, I would say it is probably not intended, since scraping blackbox_exporter's /metrics doesn't trigger any probes as such.

Perhaps this local probe could be made optional?

current docker image is not executable

make docker

docker build -t "soundcloud/ipmi-exporter-linux-amd64:master" \
	-f ./Dockerfile \
	--build-arg ARCH="amd64" \
	--build-arg OS="linux" \
	./
Sending build context to Docker daemon  13.99MB
Step 1/9 : FROM quay.io/prometheus/golang-builder:1.13-base AS builder
 ---> 46243b0f7f63
Step 2/9 : RUN go get -d github.com/soundcloud/ipmi_exporter  && cd /go/src/github.com/soundcloud/ipmi_exporter  && make
 ---> Using cache
 ---> 8413e244a1f1
Step 3/9 : FROM ubuntu:18.04
 ---> 4c108a37151f
Step 4/9 : LABEL maintainer="Aggelos Kolaitis <[email protected]>"
 ---> Using cache
 ---> b5f1c2a4d54f
Step 5/9 : WORKDIR /
 ---> Using cache
 ---> e0cf8c41e839
Step 6/9 : RUN apt-get update     && apt-get install freeipmi-tools -y --no-install-recommends     && rm -rf /var/lib/apt/lists/*
 ---> Using cache
 ---> 5514312c0fa1
Step 7/9 : COPY --from=builder /go/src/github.com/soundcloud/ipmi_exporter /bin/ipmi_exporter
 ---> Using cache
 ---> 1cdbf630119c
Step 8/9 : EXPOSE 9290
 ---> Using cache
 ---> bd1e0ffddb76
Step 9/9 : CMD ["/bin/ipmi_exporter", "--config.file", "/config.yml"]
 ---> Using cache
 ---> 2c5d72b255fa
[Warning] One or more build-args [ARCH OS] were not consumed
Successfully built 2c5d72b255fa
Successfully tagged soundcloud/ipmi-exporter-linux-amd64:master

docker run 2c5d72b255fa

docker: Error response from daemon: OCI runtime create failed: container_linux.go:345: starting container process caused "exec: \"/bin/ipmi_exporter\": permission denied": unknown.
ERRO[0001] error waiting for container: context canceled

Log file path optional parameter

Hi,

I am using the ipmi_exporter (works like a charm !) on some huge systems, and sometime when a range of nodes are down (including BMC), I can face thousands of error.

Currently, all logs are sent to system log, which "pollute" it. Is there a simple way to add a login file path to parameters ?

My current systemctl file is:

[Unit]
Description=IPMI Exporter
After=network.target

[Service]
User=ipmiexporter
Group=ipmiexporter
Type=simple
ExecStart=/usr/local/bin/ipmi_exporter \
  --config.file=/etc/ipmi_exporter/ipmi_config.yml

[Install]
WantedBy=multi-user.target

I could find --log.level or --log.format, but nothing related to an optional log file path.

Please consider this not as a critical issue, but only asking if some kind of mechanism exist for this tool to store logs in a dedicated file.

Best regards

New metric for lan mode?

Hi,

first thank you for maintaining this exporter, it is great.

In our case we find out, we had some issue with default network lan mode ("failover"). The problem was when IPMI dedicated link was down IPMI switched to shared iface (server uplink). We use diffent VLANs for IPMI and uplinks, so that is a bit problem, because its stoped working until manual change from the server. We are trying to avoid this by setting that to dedicated from failover and monitor wanted state.

More on this can be read here ServerFault

For this we had monitoring using ipmitool and tracking output ipmitool raw 0x30 0x70 0x0c 0

This can be done with:
/usr/sbin/ipmi-raw 0x0 0x30 0x70 0x0c 0 - which is tool from freeipmi pkg.
It result into:

rcvd: 70 00 00 - dedicated
rcvd: 70 00 01 - shared
rcvd: 70 00 02 - failover

With metric something like:

# Help ipmi_config_lan_mode Return lan mode status (0=dedicated, 1=shared, 2=failover)
# Type ipmi_config_lan_mode gauge
ipmi_config_lan_mode 0

Do you think this could be implemented?

missing IPv4 information

Currently I've set this up to be running within Kubernetes as a daemonset on all nodes that have the label ipmi=true. Prometheus then scrapes it on the metadata annotations given. This works great so far, but I am missing some information, e.g.:

IP_Address_Source
IP_Address
MAC_Address

The tools to provide this are already installed since freeipmi-tools is used:

ipmi-exporter@acd130cc346e:/# ipmi-config -o
...
...
...
#
# Section Lan_Conf Comments 
#
# In the Lan_Conf section, typical networking configuration is setup. Most users 
# will choose to set "Static" for the "IP_Address_Source" and set the 
# appropriate "IP_Address", "MAC_Address", "Subnet_Mask", etc. for the machine. 
#
Section Lan_Conf
	## Possible values: Unspecified/Static/Use_DHCP/Use_BIOS/Use_Others
	IP_Address_Source                             Use_DHCP
	## Give valid IP address
	IP_Address                                    192.168.1.2
	## Give valid MAC address
	MAC_Address                                   AA:AA:AA:AA:AA
	## Give valid Subnet Mask
	Subnet_Mask                                   255.255.255.0
	## Give valid IP address
	Default_Gateway_IP_Address                    192.168.1.1
	## Give valid MAC address
	Default_Gateway_MAC_Address                   00:00:00:00:00:00
	## Give valid IP address
	Backup_Gateway_IP_Address                     0.0.0.0
	## Give valid MAC address
	Backup_Gateway_MAC_Address                    00:00:00:00:00:00
EndSection
...
...
...

Am I just missing a configuration, or is this indeed not available?

Scraping remote metrics with sudo

I am trying to setup one host scraping ipmi-metrics from multiple other ubuntu-machines. Since commands like ipmimonitoring need sudo on the remote machines I am following the instructions from the example config ("advanced" module) and am getting mildly bitten by sharks, apparently. My ipmi_remote.yml looks like this:

  <remote-ip>:
    user: user
    pass: pw
    collectors:
    - ipmi
    collector_cmd:
      ipmi: sudo
    custom_args:
      ipmi:
      - "ipmimonitoring"

I am running the exporter as docker container, so docker logs gives me:

time="2021-08-18T09:31:06Z" level=info msg="Starting ipmi_exporter" source="main.go:83"
time="2021-08-18T09:31:06Z" level=info msg="Loaded config file /config.yml" source="config.go:234"
time="2021-08-18T09:31:06Z" level=info msg="Listening on :9290" source="main.go:147"
time="2021-08-18T09:31:12Z" level=error msg="Failed to collect sensor data from <remote-ip>: error running sudo: exec: \"sudo\": executable file not found in $PATH: " source="collector_ipmi.go:128"

I also added the following to /etc/sudoers on the remote host, as described in this README section (local for good measure):

user ALL=NOPASSWD: /usr/sbin/ipmimonitoring,\
                   /usr/sbin/ipmi-sensors,\
                   /usr/sbin/ipmi-dcmi,\
                   /usr/sbin/ipmi-raw,\
                   /usr/sbin/bmc-info,\
                   /usr/sbin/ipmi-chassis,\
                   /usr/sbin/ipmi-sel,\
                   /usr/local/sbin/ipmimonitoring,\
                   /usr/local/sbin/ipmi-sensors,\
                   /usr/local/sbin/ipmi-dcmi,\
                   /usr/local/sbin/ipmi-raw,\
                   /usr/local/sbin/bmc-info,\
                   /usr/local/sbin/ipmi-chassis,\
                   /usr/local/sbin/ipmi-sel

Executing sudo ipmimonitong on the remote machine by hand as user is working fine and also not prompting for a password, so the sudoers configuration should be fine as far as I am concerned. I am trying to get the exporter to execute that same command, using sudo, while scraping the remote machines.
Thanks!

impimonitor Problem feedback

collect metrics from "bmc getsysinfo system_fw_version"

Hi, I'd like to collect the BIOS version from IPMI.
I tried to add code by myself.
However, I am not familiar with golang so that but I couldn't make packages.
Could you add the feature please ?

ISSUE TYPE

Enhanced

HOW TO GET THE INFO

ipmitool bmc getsysinfo system_fw_version

SAMPLE COMMAND OUTPUT

 $ ipmitool -H <target host> -I lanplus -U <user> -P <password> bmc getsysinfo system_fw_version
  Version1.0

In most cases, the return value is "strings". not integer.

METRICS EXAMPLE

# HELP ipmi_bmc_sysinfo Constant metric with value '1' providing details about the BMC.
# TYPE ipmi_bmc_sysinfo gauge
ipmi_bmc_sysinfo{system_fw_version="Version 1.0"} 1

"Failed to parse bmc-info" when the system does not provide "System Firmware Version"

On my Supermicro servers, I'm getting the following error with the bmc collector enabled:

ERRO[0004] Failed to parse bmc-info data from [local]: Could not find value in output: Device ID             : 32
Device Revision       : 1
Device SDRs           : unsupported
Firmware Revision     : 1.52
Device Available      : yes (normal operation)
IPMI Version          : 2.0
Sensor Device         : supported
SDR Repository Device : supported
SEL Device            : supported
FRU Inventory Device  : supported
IPMB Event Receiver   : supported
IPMB Event Generator  : supported
Bridge                : unsupported
Chassis Device        : supported
Manufacturer ID       : Super Micro Computer Inc. (10876)
Product ID            : 6937
Auxiliary Firmware Revision Information : 00000000h

Device GUID : 00000000-0000-0000-0000-000000000000

System GUID : 00000000-d43a-46ef-ec3c-534d31303136
…

As you can see the BMC on SMCI doesn't always provide a System Firmware Version - can we make this optional?

Failed to parse ipmimonitoring data from ...

there is a problem where scap data from som bmc ip. and I found the error is caused by csv parsing. In the line start with 63, there is one more comma(,), which causes the failure of CSV parsing.

part of data:

55,PSU1_Iin,Current,Nominal,0.00,A,'OK'
56,PSU1_Iout,Current,Nominal,0.00,A,'OK'
57,PSU1_Vout,Voltage,Critical,0.20,V,'At or Below (<=) Lower Non-Recoverable Threshold'
58,PSU1_Vin,Voltage,Critical,0.00,V,'At or Below (<=) Lower Non-Recoverable Threshold'
59,PSU1_Pin,Power Supply,Nominal,0.00,W,'OK'
60,PSU1_Pout,Power Supply,Nominal,0.00,W,'OK'
61,PSU1_Hs_Temp,Temperature,Nominal,20.00,C,'OK'
62,PSU1_Amb_Temp,Temperature,Nominal,23.00,C,'OK'
63,PSU1_Status,Power Supply,Critical,N/A,N/A,'Presence detected' 'Power Supply Failure detected' 'Power Supply input lost (AC/DC)' 'Power Supply input out-of-range, but present'

Documentation bug?

Hi,
maybe i do something wrong or maybe a documentation bug:
my config in prometheus.yml

job_name: ipmi
params:
module: default
scrape_interval: 1m
scrape_timeout: 30s
metrics_path: /ipmi
scheme: http
file_sd_configs:
- files:
  - /data/prometheus/targets/targets_ipmi_exporter.yml
    refresh_interval: 5m
    relabel_configs:
- source_labels: [address]
  separator: ;
  regex: (.*)
  target_label: __param_target
  replacement: ${1}
  action: replace
- source_labels: [__param_target]
  separator: ;
  regex: (.*)
  target_label: instance
  replacement: ${1}
  action: replace
- separator: ;
  regex: .*
  target_label: address
  replacement: localhost:9290
  action: replace

module: default -> shuld look like module: [default]?
failed to reload config: couldn't load configuration (--config.file="/etc/prometheus/prometheus.yml"): parsing YAML file /etc/prometheus/prometheus.yml: yaml: unmarshal errors:
line 38: cannot unmarshal !!str default into []string
config from https://github.com/soundcloud/ipmi_exporter/blob/master/ipmi_remote.yml
sysadmin@prometheus01:bin$ sudo ./ipmi_exporter --config.file=/etc/prometheus/ipmi_exporter.yml
INFO[0000] Starting ipmi_exporter source="main.go:83"
FATA[0000] Error parsing config file: unknown fields in modules: workaround_flags source="main.go:87"

the built docker image will always use latest master

if I understand the Dockerfile correctly, will this not always build the latest master?

when i checkout a commit hash from the past and run "make docker" locally, I would expect to build the version that I checked out.

Can't get metrics directly from prometheus

Hello,
I've configured impi_exporter to scrap data from remote servers and I have a problem getting to those values.

I run ipmi_exporter as follows:
./ipmi_exporter --config.file=config.yml --web.listen-address=":9290"

Where config file and targets.yml are the same as from repo.

As a response I get:

INFO[0000] Starting ipmi_exporter source="main.go:83"
INFO[0000] Loaded config file config.yml source="config.go:115"
INFO[0000] Listening on :9290 source="main.go:147"
ERRO[0005] Error while calling bmc-info for [local]: hostname not specified source="collector.go:249"
ERRO[0005] Error while calling ipmimonitoring for [local]: hostname not specified source="collector.go:249"
ERRO[0005] Failed to collect ipmimonitoring data from [local]: exit status 1 source="collector.go:406"
ERRO[0005] Error while calling ipmi-chassis for [local]: hostname not specified source="collector.go:249"
ERRO[0006] Error while calling bmc-info for [local]: hostname not specified source="collector.go:249"
ERRO[0006] Error while calling ipmimonitoring for [local]: hostname not specified source="collector.go:249"
ERRO[0006] Failed to collect ipmimonitoring data from [local]: exit status 1 source="collector.go:406"
ERRO[0006] Error while calling ipmi-chassis for [local]: hostname not specified source="collector.go:249"
ERRO[0020] Error while calling bmc-info for [local]: hostname not specified source="collector.go:249"
ERRO[0020] Error while calling ipmimonitoring for [local]: hostname not specified source="collector.go:249"

And now, when I open e.g. http://prometheus:9290/metrics?target=1.2.3.4 I'm able to get all collected values, but when I want to get these values directly from prometheus by PromQL, there are only two metrics shown: ipmi_up and ipmi_scrape_duration_seconds.

Am I something missing?

version paramter is reigistered but not proceed

Hi,
found that ipmi_exporter has -version parameter, but in the source code, there no code to return ipmi_exporter version.

prometheus-community / ipmi_exporter Goto Github PK

ipmi_exporter's Introduction

Prometheus IPMI Exporter

Installation

Building from source

Building a Docker container

Building a RPM Package

Running

Running as unprivileged user

Running in Docker

Configuration

TLS and basic authentication

Exported data

ipmi_exporter's People

Contributors

Stargazers

Watchers

Forkers

ipmi_exporter's Issues

ISSUE TYPE

HOW TO GET THE INFO

SAMPLE COMMAND OUTPUT

CAUSE

SOLUTION

ISSUE TYPE

HOW TO GET THE INFO

SAMPLE COMMAND OUTPUT

METRICS EXAMPLE

Recommend Projects

Recommend Topics

Recommend Org