Conversation
Signed-off-by: Joe Elliott <number101010@gmail.com>
Signed-off-by: Joe Elliott <number101010@gmail.com>
it's a local variable, so not likely to cause a problem, but this was made less confusing in #193 |
middleware/logging.go
Outdated
| } else if statusCode == http.StatusBadGateway || statusCode == http.StatusServiceUnavailable { | ||
| l.logHighVolumeError(r, "%s %s (%d) %s", r.Method, uri, statusCode, time.Since(begin)) | ||
| if l.LogRequestHeaders && headers != nil { | ||
| l.logHighVolumeError(r, "ws: %v; %s", IsWSHandshakeRequest(r), string(headers)) |
There was a problem hiding this comment.
do you think we want this on a different line to the method?
(I see it did this in the code before, but only at debug level)
There was a problem hiding this comment.
i think it's ok. this way the user can configure LogRequestHeaders and HighVolumeErrorLog independently and any combination works.
There was a problem hiding this comment.
What I'm thinking is: suppose you want to look at logs for a specific request; you can grep for the URI. But the headers are on the next line, which is awkward.
There was a problem hiding this comment.
oh, that's a good point. i hadn't considered that. i'll push a small change to unify them
Signed-off-by: Joe Elliott <number101010@gmail.com>
logging/ratelimit.go
Outdated
| func (l *rateLimitedLogger) WithFields(f Fields) Interface { | ||
| return &rateLimitedLogger{ | ||
| next: l.next.WithFields(f), | ||
| limiter: rate.NewLimiter(l.limiter.Limit(), 0), |
There was a problem hiding this comment.
Why do we get a new limiter here?
Also, does it work with a burst size of zero?
There was a problem hiding this comment.
Yes, the burst limit was wrong. Good catch. Added a test and fixed.
As far as the new limiter I figured calling WithFields() created a new logger that should have an independent rate limit, but I can go either way on this.
There was a problem hiding this comment.
Thing is, code often calls WithFields() on every operation, e.g. the example you gave in the description, or this one:
common/middleware/grpc_logging.go
Line 30 in 61ffdd4
I expect the case you're trying to hit is where a high volume of logs from from lots of operations, so you would want the same rate-limit to be applied across them all. Try it!
There was a problem hiding this comment.
You're right. Thanks man 👍
Fixed.
Signed-off-by: Joe Elliott <number101010@gmail.com>
Signed-off-by: Joe Elliott <number101010@gmail.com>
|
Sorry I haven't been back here for a while. Code looks ok now; do you still want to merge it? |
|
@joe-elliott ping on questions |
|
Honestly, this has kind of fallen off of my radar. The initial need for this no longer something I am no longer involved in. Having said that I do think the rate limited logger has some value perhaps in weaveworks/common if we want to keep it. The original reason this existed was to catch errors returned from Loki in the cortex-gw when the query frontend crashed. @cyriltovena @owen-d what do you think? is there still a need for this? |
|
Right now I have a high rate of errors like this: I think this PR as it stands would not help me, because it is focused on one specific http error. |
This PR attempts to address concerns in #192. It provides
While working on this PR I noticed this:
Particularly the line:
l.Log = l.Log.WithField("traceID", traceID)I'm unsure why the struct var is being overwritten in
logWithRequest. This seems like a possible race condition to me? I assume there's one instance of the middleware that is shared by all requests in the pipeline?