Open barcar opened 1 year ago
There hasn't been any activity on this issue recently, so it has been marked as stale. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by leaving a comment. This issue will be closed if no further activity occurs. Thanks!
Still active.
Given that I'm not a Prometheus user and recognizing that my day job is taking 100% of my time these days, it's unlikely that I'll be able to investigate (much less implement this anytime soon). Adding the help-wanted
label in case anyone else wants to take a crack at a PR.
Is your feature request related to a problem? Please describe.
I'm trying to consume more of my metric data into Prometheus (https://prometheus.io) which seems a bit simpler for a novice that InfluxDB. To simplify my metric flow I've been trying to get metrics from source to Prometheus with the fewest number of hops - a bunch of services (esphome, homebridge, ruuvitag) have simple Prometheus exporters.
I found a Prometheus exporter for Ecowitt (https://github.com/JosephRPalmer/ecowitt-bridge) which would allow me to eliminate MQTT for these metrics but it doesn't have the excellent unit conversion and calculated metric capabilities of Ecowitt2MQTT.
Describe the solution you'd like
Ideally I would like the option in Ecowitt2MQTT to enable an additional Prometheus exporter target which would list all the metrics published to MQTT. This endpoint would listen on an alternate port and the metrics would be updated on each refresh from the weather station.
The config would be simply which port to publish the exporter metrics on.
Additional context
This is a sample of the exporter output from the ecowitt-bridge project:
It uses the Python prometheus_client (https://github.com/prometheus/client_python) library and simply builds a dictionary of gauges (one per metric) which is updated when a new metric is received (https://github.com/JosephRPalmer/ecowitt-bridge/blob/main/app/app.py).
The prometheus client is configured to listen on an HTTP port and automatically generates the required format output from the gauge dictionary. I'm thinking the MQTT topic could easily be converted to gauge names.
I would be happy to work on a fork to do this myself but my Python is very basic and I'm not sure where best to integrate this functionality. Would the gauge updating be a new publisher? Or would it just slot into the existing MQTT publisher? Would I just hook into the existing server? Or create an additional server instance?
I'll probably start stumbling around in the dark to try and get this to work for myself but whether the result would be a welcome pull request or of sufficient quality for acceptance is hard to say at this stage.
Anyway - just putting the idea out there... thanks for this project. It's great work.