-
Notifications
You must be signed in to change notification settings - Fork 529
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
Update vendored mimir-prometheus #7057
Conversation
45d9b01
to
8b0e00a
Compare
@@ -60,5 +64,5 @@ func NewPromQLEngineOptions(cfg Config, activityTracker *activitytracker.Activit | |||
NoStepSubqueryIntervalFn: func(int64) int64 { | |||
return cfg.DefaultEvaluationInterval.Milliseconds() | |||
}, | |||
} | |||
}, cfg.PromQLExperimentalFunctionsEnabled |
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.
Note to reviewers: the reason why I propose to return cfg.PromQLExperimentalFunctionsEnabled
from NewPromQLEngineOptions()
even if it's based on the input cfg
is to have a stronger way to signal the callers to also set the PromQL parser's option to enable the experimental functions.
Should this be in the changelog? |
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.
LGTM, just wondering about the following:
I've introduced -querier.promql-experimental-functions-enabled CLI flag (and respective YAML config option) to allow to enable experimental functions (disabled by default).
Should this be in the changelog?
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.
Changes lgtm. Agree with Arve that we should include new option in the changelog. I think we should also document which functions it affects.
(Personal note: It's funny to see sort by labels function added, as the PR implementing this function was based on my old PR from 7 years ago. Seeing it now in Mimir, I'm not sure it's a good fit, but here we are... 😂).
pkg/querier/engine/config.go
Outdated
@@ -44,10 +46,12 @@ func (cfg *Config) RegisterFlags(f *flag.FlagSet) { | |||
f.IntVar(&cfg.MaxSamples, "querier.max-samples", 50e6, sharedWithQueryFrontend("Maximum number of samples a single query can load into memory.")) | |||
f.DurationVar(&cfg.DefaultEvaluationInterval, "querier.default-evaluation-interval", time.Minute, sharedWithQueryFrontend("The default evaluation interval or step size for subqueries.")) | |||
f.DurationVar(&cfg.LookbackDelta, "querier.lookback-delta", 5*time.Minute, sharedWithQueryFrontend("Time since the last sample after which a time series is considered stale and ignored by expression evaluations.")) | |||
f.BoolVar(&cfg.PromQLExperimentalFunctionsEnabled, "querier.promql-experimental-functions-enabled", false, sharedWithQueryFrontend("True to enable support for experimental PromQL functions.")) |
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.
[nit] It can also be set without passing =true
value, simplify wording:
f.BoolVar(&cfg.PromQLExperimentalFunctionsEnabled, "querier.promql-experimental-functions-enabled", false, sharedWithQueryFrontend("True to enable support for experimental PromQL functions.")) | |
f.BoolVar(&cfg.PromQLExperimentalFunctionsEnabled, "querier.promql-experimental-functions-enabled", false, sharedWithQueryFrontend("Enable experimental PromQL functions.")) |
Shall we include list of experimental functions? How does user know when to use this?
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.
Simplified CLI description in 35db456.
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.
Shall we include list of experimental functions? How does user know when to use this?
Yes, it's in about-versioning.md
and I've just added to CHANGELOG too.
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.
We should document the behaviour for the CT zero samples (and implement them eventually because they look cool)
I also agree with Arve about the changelog :)
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.
LGTM, thank you for carrying this out
(Assuming you address Peter's and Arve's comments)
9283af6
to
fdfcd20
Compare
Added PR number to CHANGELOG Do not use errors.Cause() on errors returned by Prometheus Fixed TestConfig_TranslatesToPrometheusTargetGroup Fixed TestConfig_ConstructsLookupNamesCorrectly Updated query sharding with new PromQL experimental functions Added -querier.promql-experimental-functions-enabled support Fix linter issues Added new CLI flag to list of experimental features Signed-off-by: Marco Pracucci <marco@pracucci.com>
…ns-enabled Signed-off-by: Marco Pracucci <marco@pracucci.com>
fdfcd20
to
35db456
Compare
Yes, absolutely. I just forgot about it, and added in 35db456. |
Signed-off-by: Marco Pracucci <marco@pracucci.com>
What this PR does
In this PR I'm upgrading the vendored
mimir-prometheus
and their deps.Prometheus changes
The analysis of all Prometheus changes can be found here: grafana/mimir-prometheus#580
In particular, what's affecting Mimir:
MetricType
moved fromgithub.com/prometheus/prometheus/model/textparse
togithub.com/prometheus/common/model
Histogram.ToFloat()
now takes in input*FloatHistogram
to eventually reuse it (ifnil
the old behaviour is preserved). In this PR I'm always passingnil
to try not burying any logic change. As separate work we can investigate if we would get any perf benefit recycling theFloatHistogram
.discovery.NewManager()
now takes in input the metricsRegisterer
instead of registering metrics on the global one. I've changed Mimir code to pass the per-tenant registerer, so metrics will be renamed and will have theuser
label attached (see CHANGELOG for the list of renamed metrics). Similar change forrefresh.NewDiscovery()
. It's important to note that these metrics are only exposed when ruler is configured to discover Alertmanager via service discovery, which is not how we run Mimir in Jsonnet, Helm or at Grafana Labs. None of our dashboards / alerts queries such metrics.AppendCTZeroSample()
. It's still a work in progress in Prometheus. We can defer the actual support for now.github.com/pkg/errors
to the standarderrors
package. This means thatgithub.com/pkg/errors.Cause()
will not work anymore on errors wrapped by Prometheus. To avoid subtle bugs, I've removed the usage ofCause()
on errors returned by Prometheus TSDB and PromQL. There are few other places where we're still usingCause()
, but these are in few selected places where there shouldn't be any Prometheus error. In a separate PR, I will propose to get rid oferrors.Cause()
completely (but I prefer to keep it separated, to make the review process safer).mad_over_time
: the function is shardable, like other_over_time()
functions (conceptually it's not different thanquantile_over_time()
).sort_by_label
andsort_by_label_desc
: likesort()
andsort_desc()
, these functions are currently not safe to be parallelised by query sharding, so I've added them to the exclusion list.-querier.promql-experimental-functions-enabled
CLI flag (and respective YAML config option) to allow to enable experimental functions (disabled by default).Other vendored libs changes
Cheched the release notes. Many changes on tracing, few on metrics. Since many of such changes are related to packages we don't import, I've checked the actual code diff (it's small).
The change in this PR affects us. The PR description explains the rationale, but basically any OTel tracer implementation needs to define a fallback for non implemented functions (I've picked the noop one, we aim to implement all functions anyway).
Checked the diff and looks just adding new features:
Checked the diff and looks mostly code cleanup:
Other deps we don't use directly
github.com/felixge/httpsnoop
github.com/fsnotify/fsnotify
github.com/go-logr/logr
Which issue(s) this PR fixes or relates to
N/A
Checklist
CHANGELOG.md
updated - the order of entries should be[CHANGE]
,[FEATURE]
,[ENHANCEMENT]
,[BUGFIX]
.about-versioning.md
updated with experimental features.