This only adds the facilities to do so, the version information itself
is currently only a git hash, as we have not tagged any releases so far.
With this in place, let's set up some CI system, maybe a few test stubs
and then we can do a 1.0 release.
Specifically, allow definition of a set of settings as module in the
configuration file, and the ability to use these settings by setting the
`module` URL parameter to the respective module name when scraping.
THIS COMMIT CHANGES THE CONFIG FORMAT IN A NON-BACKWARDS-COMPATIBLE WAY!
Based on this, the following "side effects" are noteworthy:
- the exporter no longer requires a config file
- the IPMI "privilege level" can be set in the config file
- collectors can be enabled/disabled in the config file
- anonymous IPMI access is now theoretically possible
- there are now two example configurations (local & remote)
This fixes#10 by allowing to set the privilege level.
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).
Conrad Hoffmann
Alexander Fahlke