Comments (7)
In my opinion if the operation makes sense and something is returned from that operation but we have ignored histogram in the vector ( like 2/foo ) then we can add an info level annotation stating that histograms are ignored in the operation and if the operation does not makes any sense (like float+histogram ) then I think we should add a warn level annotation that this operation for the given arguments is not possible (or something like that). These are my thoughts pls correct me.
That's also an option. If I understand you correctly, you would add an info annotation to the 2 / foo
expression if foo
contains both histograms and floats (so something is returned) but if foo
is a pure histogram vector, you would add a warning annotation (because nothing is returned). That might be hard to implement (you can only decide about the level of the annotation when looking at the whole vector), but maybe it's doable. I'm a bit more concerned about the change of behavior that a "float divided by histogram" operation becomes "more bad" if the histogram is not accompanied by a float in the same vector.
Another thought in this regard: A mix of floats and histograms in the same vector should be a very rare case. So maybe we don't need to think too much about treating that case specially or with concerns about spammy annotations. It shouldn't really happen in practice, and if it does, it's probably a faulty setup or a transition period and will be fixed soon. So maybe let's say for now, whenever we ignore a histogram in an operation because it doesn't make sense, we add an info-level annotation saying that an operation wasn't performed, even if the expression still yields a result from other vector elements. We can do this first, it's easy, and then iterate on it once we see how it plays out in practice.
from prometheus.
Related: #11973
from prometheus.
My thoughts:
I think the (float, histogram) args for arithmetic binary operators needs to be broken up. For example, float + histogram
or histogram - float
doesn't work, but float * histogram
and histogram / float
is just fine (but float / histogram
is not). histogram + histogram
is fine, but histogram * histogram
is not.
For min
and max
, I think it's fine to just return nothing for aggregations of only histograms. The warning should only be issued if the aggregation tries to aggregate histograms and floats into the same key. (For example, if foo
is a vector that has both floats and histograms, and all the histograms have a kind="histogram"
label and all the floats have a kind="float"
label, then min by (kind)(foo)
should not give a warning (but the only element in the result vector has kind="float"
), but min(foo)
should give a warning.)
I think the current behavior of count
is fine. count
just counts sample, and a float and a histogram should be counted the same. (I think that's even documented.)
histogram / 0
should return sum
and count
and the zero bucket "normally" (I assume in the way it is done already), but then all (normal) buckets should be removed (because all the non-represented empty buckets should be NaN
now, which we cannot represent. So better have no buckets at all. (This case is anyway pathologic.)
from prometheus.
The basic idea is this: Where operations and aggregations make sense (between histogram and histogram, or between histogram and float), they happen. Where they don't make sense, the histogram is treated as if the vector element with the histogram did not exist. This is not an error, but we attach a "warn"-level annotation (or maybe "info"-level only?) if any vector element is label-matched with an ignored histogram. That implies no annotation is added if two ignored histograms are matched or if an ignored histogram is matched with a scalar (which is not label-matching).
The rationale here is that label matching might be complex, and if a label match leads to an impossible combination, it might be accidental and the user should know about it. In contrast to that, 2 / foo
essentially means "Divide 2 by all the float elements and ignore the histogram elements" and that's just fine and can deliberately be used for filtering. However, if I write foo + bar
, the user's idea is probably that the label-matched elements should also have the same type, and if a float gets matched with a histogram, it's probably an error. (And the "probably" makes me think we should perhaps use "info" level, which implies that false positives are possible, while "warn" level is meant for annotations that are always triggered by something that is "wrong" in some way and could be fixed somehow.)
(This is all just my stream of thoughts. Feel free to express other viewpoints.)
from prometheus.
I think the (float, histogram) args for arithmetic binary operators needs to be broken up. For example, float + histogram or histogram - float doesn't work, but float * histogram and histogram / float is just fine (but float / histogram is not). histogram + histogram is fine, but histogram * histogram is not.
Yes, sorry, I missed this case. I'll break the operators further with different arguments and update the table.
For min and max, I think it's fine to just return nothing for aggregations of only histograms. The warning should only be issued if the aggregation tries to aggregate histograms and floats into the same key. (For example, if foo is a vector that has both floats and histograms, and all the histograms have a kind="histogram" label and all the floats have a kind="float" label, then min by (kind)(foo) should not give a warning (but the only element in the result vector has kind="float"), but min(foo) should give a warning.)
So the gist here is that after grouping the labels if the vector contains both histogram
and float
then we'll issue a warning otherwise we will return the min
in case of float
only vector and nothing in case of histogram
only vector. Please correct me if I misunderstood something.
I think the current behavior of count is fine. count just counts sample, and a float and a histogram should be counted the same. (I think that's even documented.)
yeah, my bad, I somehow got confused between count
and histogram_count
.
I'll make all these changes into the table.
from prometheus.
The rationale here is that label matching might be complex, and if a label match leads to an impossible combination, it might be accidental and the user should know about it. In contrast to that, 2 / foo essentially means "Divide 2 by all the float elements and ignore the histogram elements" and that's just fine and can deliberately be used for filtering. However, if I write foo + bar, the user's idea is probably that the label-matched elements should also have the same type, and if a float gets matched with a histogram, it's probably an error. (And the "probably" makes me think we should perhaps use "info" level, which implies that false positives are possible, while "warn" level is meant for annotations that are always triggered by something that is "wrong" in some way and could be fixed somehow.)
In my opinion if the operation makes sense and something is returned from that operation but we have ignored histogram in the vector ( like 2/foo
) then we can add an info level annotation stating that histograms are ignored in the operation and if the operation does not makes any sense (like float
+histogram
) then I think we should add a warn level annotation that this operation for the given arguments is not possible (or something like that). These are my thoughts pls correct me.
from prometheus.
So the gist here is that after grouping the labels if the vector contains both histogram and float then we'll issue a warning otherwise we will return the min in case of float only vector and nothing in case of histogram only vector.
Yes, that's the idea (but the case of how to deal with histogram-only could still be debated, see your later comment).
from prometheus.
Related Issues (20)
- promtool syntax detects errors HOT 1
- Please sign your releases HOT 2
- Default --storage.tsdb.retention.time HOT 6
- Prometheus too old sample issue
- docs: Remove the section about remote read JSON responses - it only supports proto response or errors HOT 2
- Corrupting data written to remote storage in case sample_age_limit is hit HOT 2
- Implement support for dots in metric and label names. HOT 1
- Do the remote-write support the recording rule data? HOT 1
- Unable to add namespace in nomad_sd_configs HOT 1
- remote write 2.0 - benchmarking HOT 6
- The results calculated by irate are different.
- Ever-growing WAL folder
- Zookeeper service discovered adding matedata
- Range-vector functions double-count samples if their timestamps align with query step HOT 4
- Queries failing after upgrade to v2.52.0rc0 HOT 5
- api/v1/metadata and api/v1/label/__name__/values returning different values HOT 1
- Malformed JSON in query API result, 2.52-rc.0 regression HOT 5
- Remote-write: threshold to skip resharding should be higher HOT 8
- scrape: Allow to disable end-of-run staleness marker injection for targets HOT 1
- PromQL: Multiplication by 1 creates additional floating point errors (but should be a no-op) HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from prometheus.