-
Notifications
You must be signed in to change notification settings - Fork 1.1k
feat(om2): classic histogram and summary as complex types #2679
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
aca6583 to
4c7a987
Compare
bwplotka
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would love that, but as we discussed on our sync - we need a bigger decision if we want to follow this path.
If we do, we likely need some rough uncomplex inlined format explained that is not meant to be used for scraping and can be surfaced with promtool etc.
this is a draft, changes incoming, also I made a mistake with the quantile values
This change is for demo purposes, exploring the benefits (and downsides) for the complex type format for OM2 captured in prometheus/docs#2679. This assumes Prometheus stores NS and NHCB (and NH) going forward (for best case efficiency), but is expected to work for classic mode too with little overhead (benchmarks will tell us). Part of the PromCon talk we do with @krajorama Signed-off-by: bwplotka <bwplotka@gmail.com>
This change is for demo purposes, exploring the benefits (and downsides) for the complex type format for OM2 captured in prometheus/docs#2679. This assumes Prometheus stores NS and NHCB (and NH) going forward (for best case efficiency), but is expected to work for classic mode too with little overhead (benchmarks will tell us). Part of the PromCon talk we do with @krajorama Signed-off-by: bwplotka <bwplotka@gmail.com>
This change is for demo purposes, exploring the benefits (and downsides) for the complex type format for OM2 captured in prometheus/docs#2679. This assumes Prometheus stores NS and NHCB (and NH) going forward (for best case efficiency), but is expected to work for classic mode too with little overhead (benchmarks will tell us). Part of the PromCon talk we do with @krajorama Signed-off-by: bwplotka <bwplotka@gmail.com>
|
Results are (expectedly) impressive: prometheus/prometheus#17293 One observation is that buckets are a bit dense (readability). However we don't have spaces in any other place (e.g. labels) |
This change is for demo purposes, exploring the benefits (and downsides) for the complex type format for OM2 captured in prometheus/docs#2679. This assumes Prometheus stores NS and NHCB (and NH) going forward (for best case efficiency), but is expected to work for classic mode too with little overhead (benchmarks will tell us). Part of the PromCon talk we do with @krajorama Signed-off-by: bwplotka <bwplotka@gmail.com>
8696022 to
8c8eeae
Compare
4c45623 to
10e9bef
Compare
Ref: prometheus/OpenMetrics#283 Signed-off-by: György Krajcsovits <gyorgy.krajcsovits@grafana.com>
10e9bef to
181db08
Compare
| foo_count 17 st@1520430000.123 | ||
| foo_sum 324789.3 st@1520430000.123 | ||
| foo {count:17,sum:324789.3,schema:0,zero_threshold:1e-4,zero_count:0,positive_spans:[0:2],positive_buckets:[5,12]} st@1520430000.123 # {trace_id="shaZ8oxi"} 0.67 1520879607.789 # {trace_id="ookahn0M"} 1.2 1520879608.589 | ||
| foo {count:17,sum:324789.3,bucket:[0.01:0,0.1:8,1.0:11,10.0:17,+Inf:17]} st@1520430000.123 # {} 0.054 1520879607.7 # {trace_id="KOO5S4vxi0o"} 0.67 1520879602.890 # {trace_id="oHg5SJYRHA0"} 9.8 1520879607.789 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WG discussions: what to do with float vs int histogram
Likely storage optimization, easy in the format.
For syntax:
A)Should we accept the float
B)If we do how:
*. B1) What if we accept floats e.g. and optimize on storage e.g. count:17/17.0 count:17.5 and buckets.
- B2) Strict mode - count decides if it's float or not.
Perhaps B1 or B2 if we want more efficient implementation
Perhaps for RC we do relax mode and try to implement?
| foo_seconds_count{a="ccc"} 0 456 | ||
| foo_seconds_sum{a="ccc"} 0 456 | ||
| # TYPE foo stateset | ||
| foo{entity="controller",foo="a"} 1.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what if we do stateset too:
# TYPE foo stateset
foo{entity="controller"} {states:["a":1.0, "bb":0.0, "ccc":0.0]}
...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One argument against moving to complex type here is the PromQL. We don't have plans to change PromQL for those so far (while we have plans for histograms). We don't have clear plans for summaries, so maybe that's fine 🙃
Ref: prometheus/OpenMetrics#283
It isn't hard to come up with a representation, based on previous work in https://github.com/prometheus/proposals/blob/main/proposals/2024-01-29_native_histograms_text_format.md .