PoE numeric data is encoded as labels, not as numeric metric values

[jktjkt]

I'm interested in plotting power consumption of my PoE IoT devices which is connected to my router. Unfortunately, the exporter currently encodes these data as labels for a single metric. I would prefer a bunch of metric like mikrotik_poe_out_power[port=...], mikrotik_poe_out_voltage[port=...], etc.

[akpw]

@jktjkt just checking, is there anything that prevents you using the current single metric for plotting your PoE devices consumption? The data should be already there, so are you asking for a more comfortable representation for a specific task at hand? would appreciate some more details on this

[jktjkt]

The problem is that any change in power consumption generates a new time series in the backend. That's a problem because the native way of representing "the amount of power delivered through a single port" is via a single time series. It's perfectly OK to have labels ("cardinality") so that the power is tracked per-device per-port, etc, but it's not OK to have 100 "independent time series" when the power goes from 1.0W to 11.0W in 0.1W increments on a single port of a single device. I actually have no idea if PromQL is capable of aggregating 100 individual TS "with holes in time" like that, but I'm quite sure that this way of gathering metrics is not what the rest of the ecosystem (grafana, prometheus/victoriametrics,...) expects.

In the end I followed the general recommendation and wrote a script which gathers the PoE-out voltage and the PoE-out current, and builds the resulting power. This is super-easy with the REST API, basically just a curl -k -u user:pw -X POST https://.../rest/interface/ethernet/poe/monitor -d '{"numbers":"0,1,2,3,4,5,6,7","once":1}' -H 'content-type:application/json'.

[akpw]

OK, so basically we're talking about these three poe-related metrics here:

poe-out-voltage
poe-out-current
poe-out-power 

Since those indeed could be high cardinality / generate unnecessarily load on prometheus tsdb storage if delivered as labels, the proposal is to add those as additional POE-related metrics of gauge type, i.e. smth like:

mktxp_poe_info_voltage{name="ether1", ...} 23.9

Is this correct / complete understanding of the request, or smth still missing?

[jktjkt]

Correct.

[akpw]

should be fixed by this one: PoE numeric data as gauge values