Skip to content
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

query-frontend: pass on limit parameter for label names and values requests #7722

Conversation

dimitarvdimitrov
Copy link
Contributor

@dimitarvdimitrov dimitarvdimitrov commented Mar 25, 2024

What this PR does

This PR passes on the limit parameter from requests using the new prometheus codec types. The new codec is only used for caching logic at present, so limit wasn't being ignored on requests.

However, previously cache keys wouldn't include the parameter and there would be cache pollution. This PR includes limit in cache keys to fix that bug.

Which issue(s) this PR fixes or relates to

Fixes #7721

Checklist

  • Tests updated.
  • Documentation added.
  • CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX].
  • about-versioning.md updated with experimental features.

@dimitarvdimitrov dimitarvdimitrov requested a review from a team as a code owner March 25, 2024 17:51
Copy link
Contributor

@56quarters 56quarters left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM with some non-blocking comments.

@@ -311,12 +313,18 @@ func (prometheusCodec) DecodeLabelsQueryRequest(_ context.Context, r *http.Reque

labelMatcherSets := reqValues["match[]"]

limit, err := strconv.ParseInt(reqValues.Get("limit"), 10, 64)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason to not use ParseUint() here since a limit of less than 0 doesn't really make sense? Does Prometheus accept negative values?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason to not use ParseUint() here since a limit of less than 0 doesn't really make sense?

no reason. I changed the unit of the limit to uint64 throughout

Does Prometheus accept negative values?

no it doesn't

func parseLimitParam(limitStr string) (limit int, err error) {
limit = math.MaxInt
if limitStr == "" {
return limit, nil
}
limit, err = strconv.Atoi(limitStr)
if err != nil {
return limit, err
}
if limit <= 0 {
return limit, errors.New("limit must be positive")
}
return limit, nil
}

pkg/frontend/querymiddleware/codec.go Outdated Show resolved Hide resolved
if IsLabelNamesQuery(r.URL.Path) {
return &PrometheusLabelNamesQueryRequest{
Path: r.URL.Path,
Start: start,
End: end,
LabelMatcherSets: labelMatcherSets,
Limit: limit,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIUC, passing the limit value no matter what means we rely on whatever ParseInt() returns in the error case when there's no limit. Would it be better (more obvious) to set a default value above and conditionally call ParseInt()?

Copy link
Contributor Author

@dimitarvdimitrov dimitarvdimitrov Apr 3, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense.

this made me realize that I had missed setting the limit parameter on the HTTP request which the query-frontend creates (after processing the protobuf model). This wasn't a problem because the protobufs were only being used in caching logic (so no encoding into HTTP happens). Fixed in the last commit 663121c and added some more tests to make sure this happens properly

…requests

This PR passes on the `limit` parameter from requests. It also includes it in cache keys if it's present

Signed-off-by: Dimitar Dimitrov <dimitar.dimitrov@grafana.com>
Signed-off-by: Dimitar Dimitrov <dimitar.dimitrov@grafana.com>
Signed-off-by: Dimitar Dimitrov <dimitar.dimitrov@grafana.com>
Signed-off-by: Dimitar Dimitrov <dimitar.dimitrov@grafana.com>
@dimitarvdimitrov dimitarvdimitrov force-pushed the dimitar/query-frontend/pass-limit-parameter-on-labels-requests branch from 9a99a24 to 663121c Compare April 3, 2024 15:26
@dimitarvdimitrov
Copy link
Contributor Author

thanks for the review @56quarters, do you want to take another look or can I merge on green?

@@ -205,7 +206,7 @@ func TestLabelsQueryRequest(t *testing.T) {
expectedGetEndOrDefault: 1708588800 * 1e3,
},
{
name: "label names with start timestamp, no end timestamp, multiple matcher sets",
name: "label names with start and end timestamp, multiple matcher sets",
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

noticed that the test description here and below doesn't match the actual test case. Confirmed with @francoposa that it's the description that's wrong not the implementation

@dimitarvdimitrov dimitarvdimitrov enabled auto-merge (squash) April 5, 2024 10:29
Copy link
Contributor

@56quarters 56quarters left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, sorry for the delay

…-parameter-on-labels-requests

# Conflicts:
#	pkg/frontend/querymiddleware/model.pb.go
#	pkg/frontend/querymiddleware/model.proto
Signed-off-by: Dimitar Dimitrov <dimitar.dimitrov@grafana.com>
@dimitarvdimitrov dimitarvdimitrov merged commit 24cfe31 into main Apr 12, 2024
29 checks passed
@dimitarvdimitrov dimitarvdimitrov deleted the dimitar/query-frontend/pass-limit-parameter-on-labels-requests branch April 12, 2024 13:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

query-frontend: label names and values endpoints cache ignore limit parameter
2 participants