All Prometheus metrics should have an application prefix
(https://prometheus.io/docs/practices/naming/#metric-names).
Historically a few produced by Tasmota didn't. With this change the
function writing metrics always outputs the prefix.
Signed-off-by: Michael Hanselmann <public@hansmi.ch>
The "memory fragmentation" value named "memory_ratio" was always
truncated to an integer, so in all likelyhood 0. It didn't work anyway
until the incorrect line termination was fixed in an earlier commit.
Neither could the Psram metric be parsed correctly due to the the same
incorrect line termination.
With this change memory usage is reported in line with Prometheus'
upstream recommendations (https://prometheus.io/docs/practices/naming/).
Labels are no longer used to separate distinct dimensions. Total and
free memory as well as the maximum allocation size are reported as
separate metrics where available while labels are used to differenciate
the separate kinds of memory (heap on all, psram on ESP32).
Label values are now also lowercase on ESP32 to match ESP8266.
Metrics should report their base values, not the result of
a calculation. Therefore the already non-working "fragmentation" metric
is dropped. It can easily be calculated in PromQL instead.
The renaming of metrics and label values makes this a breaking change,
especially on ESP32. With the aforementioned formatting errors which
made them unusable that shouldn't be a problem.
Signed-off-by: Michael Hanselmann <public@hansmi.ch>
Format strings for Prometheus metrics were written manually and the
`# TYPE` lines needed to be kept in sync with actual metrics. As
indicated by the previous commit it wasn't always as consistent as
desired. In addition there was a lot of repetition among the strings
which couldn't be reduced at build time.
With this change utility functions are introduced which eliminate the
need for specifying the same metric name more than once. At the same
time the proper escaping for label values, initially added in commit
16b5f2fe9, is now applied for all labels.
The size of the program shrinks slightly by 212 bytes on ESP8266 in the
"tasmota" configuration with Prometheus enabled and 412 bytes on ESP32
with the "tasmota32" configuration.
Signed-off-by: Michael Hanselmann <public@hansmi.ch>
When built for ESP32 the memory fragmentation metric was incorrectly
terminated (likely a typo). The type information for
"tasmota_global_humidity_percentage" didn't include the "_percentage"
and "tasmota_sensors" wsa incorrect too.
Signed-off-by: Michael Hanselmann <public@hansmi.ch>
Either ESP32 rev1/2 that needs special fixes
`-DHAS_PSRAM_FIX -mfix-esp32-psram-cache-issue -lc-psram-workaround -lm-psram-workaround`
or ESP32-PICO-V3-02 that requires esp-idf 4.4
The device name can be useful to identify a particular instance in
Prometheus.
Example:
```
tasmota_info{...,devicename="livingroom"} 1
```
Signed-off-by: Michael Hanselmann <public@hansmi.ch>
This was a problem for me when trying to get output from an SDS011 Nova
PM sensor. When parsed by the pometheus code it returns labels / metrics
like:
```# TYPE tasmota_sensors_pm2.5_ gauge
tasmota_sensors_pm2.5_{sensor="sds0x1"} 2.2```
The error from prometheus was:
```"append failed" err="invalid metric type \\"5_ gauge\\"```
Exports version, image type, and build timestamp.
It's common to export something like this to show version numbers across the fleet.
For example, the golang exporter exposes version:
```
go_info{version="go1.14.4"} 1
```
And prometheus exposes:
```
prometheus_build_info{branch="HEAD",goversion="go1.14.4",revision="eba3fdcbf0d378b66600281903e3aab515732b39",version="2.19.1"} 1
```
Stephan Hadinger
Theo Arends
Michael Hanselmann
twollweber
Alex Brown
lucs7
Alexander Kabakaev
Patrick Fruh
Mark Hansen