Unfortunately this is a breaking change, as this means going from
`-config.file` to `--config.file` syntax, but it needs to happen
eventually. It better aligns the IPMI exporter with the rest of the
Prometheus eco-system.
As a first benefit, expose the command line parameters that control the
logging library.
This was a leftover from when the exporter used more of the Prometheus
build tooling, which was eventually deemed overkill for such a small
project (at least until it has matured a bit).
There is currently no versioning of any significance anyways, so remove
it for now.
This fixes#15.
This enables the standard `/metrics` endpoint. A scrape will trigger the
collection of IPMI metrics from the local machine (that the exporter is
running on).
Instead of failing hard and not returning any metrics at all if just one
(or two) of the three calls to IPMI tools fail, return whatever data was
properly received and add a `collector` label to the `ipmi_up` metric
indicating which tools failed.
This is only a small step towards the concept of "collectors" like they
exist e.g. in the node exporter, but it should help solve #1. Additional
functionality, like disabling certain collectors, can be built on top of
this.
Currently, an error in the `ipmi` collector is always logged as an error,
In the `dcmi` and `bmc` collectors, an error retrieving the data is only
logged as debug output, but an error processing retrieved data is logged
as an error. This should cover most use cases and will be improved upon
once more work is done to make the collectors selectable per scrape.
Use a named pipe with 0600 permissions to pass the credentials to
FreeIPMI instead of using the command line, which certainly constitutes
bad security practice.
Template the `driver-type` while at it to potentially support local IPMI
at some point.
Conrad Hoffmann
Conrad Hoffmann
Alexander Fahlke