__name__ selector can potentially be harmful

[yacoob]

I was playing with the network stats I get out of node_exporter. I wasn't exactly sure what kind of stuff is there, so I've asked for {__name__=~"node_network_transmit.+",device="eth1"}. This gave me following vector:

node_network_transmit_frame{device="eth1",instance="localhost:9100",job="node_exporter"}         0
node_network_transmit_fifo{device="eth1",instance="localhost:9100",job="node_exporter"}          0
node_network_transmit_drop{device="eth1",instance="localhost:9100",job="node_exporter"}          0
node_network_transmit_multicast{device="eth1",instance="localhost:9100",job="node_exporter"}     0
node_network_transmit_packets{device="eth1",instance="localhost:9100",job="node_exporter"}       1660881
node_network_transmit_compressed{device="eth1",instance="localhost:9100",job="node_exporter"}    0
node_network_transmit_bytes{device="eth1",instance="localhost:9100",job="node_exporter"}         1742321141
node_network_transmit_errs{device="eth1",instance="localhost:9100",job="node_exporter"}          0

Happy with the results, I've decided to graph it, so I've changed the expression to:

irate({__name__=~"node_network_transmit.+",device="eth1"}[5m])

which resulted in following vector:

{device="eth1",instance="localhost:9100",job="node_exporter"}    0
{device="eth1",instance="localhost:9100",job="node_exporter"}    233.7
{device="eth1",instance="localhost:9100",job="node_exporter"}    0
{device="eth1",instance="localhost:9100",job="node_exporter"}    2.6
{device="eth1",instance="localhost:9100",job="node_exporter"}    0
{device="eth1",instance="localhost:9100",job="node_exporter"}    0
{device="eth1",instance="localhost:9100",job="node_exporter"}    0
{device="eth1",instance="localhost:9100",job="node_exporter"}    0

As you can see, you get 8 row vector, each row having identical labels. This is rather unexpected. If you ask me, the __name__ label should have been preserved, but I can see how this can throw people off in other situations.

Thoughts?

[brian-brazil]

It's not correct to preserve the __name__ as it's no longer the same metric. Doing this sort of operation across multiple metric names is unusual, and if you'd tried an aggregation on top of it it'd have errored out.

If you really want to do this, use label_replace to copy out the metric name to another label name.

[brian-brazil]

Fundamentally there's a number of ways you can end up in this situation with any labels. It follows logically from how the language semantics, and while it may seem a little odd it is the correct behaviour. Trying to impose different semantics in these corner cases would add complexity for little gain, so I don't think we're going to change anything here.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.