-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Fix potential race with LabelPairs #511
Conversation
@@ -791,7 +791,7 @@ func TestHistogramVecRegisterGatherConcurrency(t *testing.T) { | |||
Help: "This helps testing.", | |||
ConstLabels: prometheus.Labels{"foo": "bar"}, | |||
}, | |||
[]string{"one", "two", "three"}, | |||
[]string{"one", "two", "three", "four", "five", "six", "seven", "eight", "nine", "ten", "eleven", "twelve", "thirteen", "fourteen", "fifteen", "sixteen"}, |
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.
Do we know the sweet spot that this happens? Or, even better, the underlying reason why more makes this break?
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.
@bobbytables i have not yet identified the exact scenario under which things get wonky. My guess is the sorting of the labelpairs can be racy. This PR is really just an attempt to highlight the issue and hopefully lead to further discovery, etc.
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 think the reason is here: https://golang.org/src/sort/sort.go?s=5414:5439#L184
I.e. the sort algorithm changes with more than 12 elements.
labelPairs = append(labelPairs, &dto.LabelPair{ | ||
Name: pair.Name, | ||
Value: pair.Value, | ||
}) |
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.
Do you need to append here since you created the slice with the correct length already? Why not just assign the index of the labelPairs
to the current index in the loop?
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.
This was mostly a copy-paste job from the method above, as I was aiming for consistency. I don't think there is any significant difference in the two approaches, but I don't feel strongly in either direction.
OK. More data points. If I comment out: https://github.com/prometheus/client_golang/blob/master/prometheus/registry.go#L875 Then the issue appears to go away as well. Similarly, if I change:
So, my guess is that the sorting is indeed problematic. I'll defer to @beorn7 on the most proper correction. |
Good catch. I think you found the issue. The The I have an idea how to solve that last detail. Thanks for the detective work so far. |
Thanks once more. I have created #513 to incorporate the findings here. |
Add a
copyLabelPairs
method toprometheus/value.go
and havepopulateMetric
andhistogram.Write
use that method for serialization of labelPairs.This is an attempt to address: istio/istio#10236
There may be better ways to address this, etc. This PR is merely meant to suggest one solution.
Before this PR, with the modifications to the unit test shown in this PR:
With the
copyLabelPairs
patch:cc: @beorn7