Sum by null - unexpected result

[kevinbla...@gmail.com]

When doing a sum with a valid number with a null value, the result is null. This seems unexpected and has confused more than a few users. It's fairly easy to get why dividing when a metric doesn't exist will not be valid, but it seems more intuitive for sum to work.
I completely understand that users shouln't have an invalid metric name in their graphs, but in the last few cases that have came up, it is a metric name that is typically valid and present on some shared/common dashboards, but just don't exist in a couple environments which causes the otherwise useful graph to always show null. Verified behavior in 2.0.0 and 2.2.1.

Simple example:

count(up) + count(fake_name)

In general since up has a value (in this case 1,566, it seems reasonable that it would be displayed, but instead "no data" is returned. It seems fairly safe/reasonable to assume a zero here, or is the null being generated looked at as a positive since if a metric goes away it's a potential way for people to be able to know something's wrong?

[kevinbla...@gmail.com]

Please note that I do know how to get the query to work by having an "or" in there and setting the value to zero that way, but the question is more along the lines of if it makes sense to have the sum treat the null as zero since I think that's how most users would expect it to behave.

[Brian Brazil]

Prometheus has no notion of null, what it does have is empty vectors. When you are using a binary operation such as + we look for matching samples on both sides, and if there's no match then that sample is ignored. Any change here (aside from being massively breaking) would have to make sense for all arithmetic operators, and while 0 is the identity element for addition; - ^ % and / are not commutative and don't have an identity element for one of their operands.

Generally you should be looking for consistency in your metrics. Time series that only exist sometimes are difficult to deal with, and making up data would only make the problems that arise more intricate and harder to understand.

--

Brian Brazil

www.robustperception.io