boblemaire / IoTaWatt

IoTaWatt Open WiFi Electric Energy Monitor
https://iotawatt.com
GNU General Public License v3.0
639 stars 177 forks source link

Add support for Prometheus Open Metrics format #333

Closed snowzach closed 2 years ago

snowzach commented 2 years ago

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.

boblemaire commented 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.

snowzach commented 2 years ago

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.

ormandj commented 8 months ago

@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.