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

Receive requests are required to have partitionKey label #279

Merged

Conversation

metalmatze
Copy link
Contributor

Let's decode the receive requests and check if the partitionKey (for us mostly _id) is available in the request and otherwise reject the request.

@openshift-ci-robot openshift-ci-robot added approved Indicates a PR has been approved by an approver from all required OWNERS files. size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Dec 12, 2019

var ErrRequiredLabelMissing = fmt.Errorf("a required label is missing from the metric")

// TODO: Make this a middleware eventually
Copy link
Contributor

Choose a reason for hiding this comment

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

can we actually make this part of this same PR? Now that we are rewriting key pieces of telemetry, it's a good time to start writing more maintainable and composable funcs. Let's make a write-request validation middleware that can take a variable amount of func(* prompb.WriteRequest) error funcs and returns a handler. This way we can wrap the forwarder easily and separate concerns

Copy link
Contributor

Choose a reason for hiding this comment

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

can we still address this ^ before merging?

@metalmatze
Copy link
Contributor Author

/uncc @lilic @paulfantom
/assign @squat

@openshift-ci-robot openshift-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jan 31, 2020
@openshift-ci-robot openshift-ci-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Feb 6, 2020
Copy link
Contributor

@squat squat left a comment

Choose a reason for hiding this comment

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

This approach looks a lot better now! I have some more comments to fix some issues

found := false
for _, ts := range wreq.GetTimeseries() {
for _, l := range ts.GetLabels() {
if l.Name == h.PartitionKey {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this logic is wrong. This currently checks if at least one time series on the request contains the label. We want to ensure that every time series has that label.

var ErrRequiredLabelMissing = fmt.Errorf("a required label is missing from the metric")

// ValidateLabels makes sure that the request's content contains the required partitionKey
func (h *Handler) ValidateLabels(next http.Handler) http.HandlerFunc {
Copy link
Contributor

Choose a reason for hiding this comment

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

It doesn't seem like this really needs to be a method of the handler struct. IMO it should be an function that accepts a label name and an next and returns an HandlerFunc. This would also eliminate the need for the constructor func NewHandler to accept an extra argument.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I guess the reason I did it that way was to cut down on the amount of args being passed around on the caller side.
Happy to change it though 😊

Copy link
Contributor

Choose a reason for hiding this comment

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

yes, I think it's better; these two things should be entirely separate concerns that are not coupled. It will also allow us to generalize the label requirement more: rather than enforcing _id=$token we can enforce any arbitrary $key=$label

@@ -61,6 +70,9 @@ func (h *Handler) Receive(w http.ResponseWriter, r *http.Request) {

defer r.Body.Close()

// Limit the request body size to a sane default
r.Body = http.MaxBytesReader(w, r.Body, requestLimit)
Copy link
Contributor

Choose a reason for hiding this comment

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

This request limit should really be configurable via a command line argument so that we don't need to PR a golang change to bump the limit.

Copy link
Contributor

Choose a reason for hiding this comment

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

We should also be able to disable the limi, eg if the limit is 0

Copy link
Contributor

Choose a reason for hiding this comment

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

This limiter should also be its own Middleware i think. It doesn't really need to be couped to the logic of forwarding requests.

Copy link
Contributor

Choose a reason for hiding this comment

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

This limiter should also be its own Middleware i think. It doesn't really need to be couped to the logic of forwarding requests.

@metalmatze metalmatze force-pushed the receive-enforce-partition-key branch from a866630 to 8888b95 Compare March 18, 2020 14:15
@metalmatze
Copy link
Contributor Author

/test integration

1 similar comment
@metalmatze
Copy link
Contributor Author

/test integration

@@ -49,6 +56,8 @@ func NewHandler(logger log.Logger, forwardURL string, reg prometheus.Registerer)
reg.MustRegister(h.forwardRequestsTotal)
}

h.logger.Log("msg", "running receive handler")
Copy link
Contributor

Choose a reason for hiding this comment

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

this log is a bit funny to me sine we're not running a goroutine here but creating a struct

Copy link
Contributor Author

Choose a reason for hiding this comment

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

this might have been a test of mine with the logger not logging anything at first... 😁

@@ -91,3 +99,89 @@ func (h *Handler) Receive(w http.ResponseWriter, r *http.Request) {
h.forwardRequestsTotal.WithLabelValues("success").Inc()
w.WriteHeader(resp.StatusCode)
}

func LimitBodySize(limit int64, next http.Handler) http.HandlerFunc {
Copy link
Contributor

Choose a reason for hiding this comment

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

could you add a short comment here


"github.com/openshift/telemeter/pkg/authorize"
)

const forwardTimeout = 5 * time.Second
const RequestLimit = 15 * 1024 // based on historic Prometheus data with 6KB at most
Copy link
Contributor

Choose a reason for hiding this comment

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

can we make this DefaultRequestLimit? Eventually we'll make the request limit overridable via flags, no?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes. 😊

@squat
Copy link
Contributor

squat commented Mar 20, 2020

/lgtm

super cool 😎

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Mar 20, 2020
@openshift-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: metalmatze, squat

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-merge-robot openshift-merge-robot merged commit 6dd8385 into openshift:master Mar 20, 2020
@metalmatze metalmatze deleted the receive-enforce-partition-key branch March 20, 2020 16:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants