Closed snowzach closed 2 years ago
If you want to take this route, you can maintain your own branch of the firmware. The resources in IoTaWatt are limited and adding what I would consider redundant functionality to reformat data that is already available isn’t a good use of what little resources are left.
Most of what you are extracting, and more is available in the existing status endpoint. You could easily request that and reformat with something like Node-RED.
There are many thousands of IoTaWatt in service worldwide. It makes little sense to burden all of those units with this change when there is very little demand for Promethius support, that can be accomplished with existing off-the-shelf tools.
Hi @boblemaire, is there any chance you would reconsider? I am happy to maintain my own fork but I believe there is just going to be more and more demand for Prometheus going forward. It's probably one of the most widely used metrics collectors in the world (if not the most used) especially when it comes to cloud computing.
While I understand the concern for resources, the code in this PR should have zero impact on performance unless you call the endpoint and as far as resources utilized on the Esp8266 , I believe the footprint is acceptably small:
Current master branch:
RAM: [===== ] 53.8% (used 44084 bytes from 81920 bytes)
Flash: [===== ] 54.7% (used 570897 bytes from 1044464 bytes)
With this PR:
RAM: [===== ] 55.0% (used 45028 bytes from 81920 bytes)
Flash: [===== ] 54.9% (used 573013 bytes from 1044464 bytes)
The way that prometheus operates using a pull mechanism makes it more difficult to manage. It's not like scraping an endpoint and putting the metrics somewhere. You would need to setup another webserver, point Prometheus at it and have it translate the metrics.
@boblemaire
Is there any chance there is more appetite for this change now? Almost every bit of infrastructure deployed now uses prometheus-style data exporters as a standard mechanism for exposing internal metrics, and from the above post, it looks like the overhead is quite low. This would be a nice and standard access mechanism for these data types and allow ingestion by any type of upstream system by an industry-standard method for metric/data collection.
This adds support for a
/metrics
http endpoint that exposes basic metrics in Open Metrics format.I hope I got all the units right and if there's anything else I should expose, I'd happily add it.