Change:
<ins> /* Copyright 2017 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package metrics import ( "strings" "testing" "k8s.io/client-go/util/flowcontrol" ) func TestRegisterMetricAndTrackRateLimiterUsage(t *testing.T) { testCases := []struct { ownerName   string rateLimiter flowcontrol.RateLimiter err         string }{ { ownerName:   "owner_name", rateLimiter: flowcontrol.NewTokenBucketRateLimiter(1, 1), err:         "", }, { ownerName:   "invalid-owner-name", rateLimiter: flowcontrol.NewTokenBucketRateLimiter(1, 1), err:         "error registering rate limiter usage metric", }, } for i, tc := range testCases { e := RegisterMetricAndTrackRateLimiterUsage(tc.ownerName, tc.rateLimiter) if e != nil { if tc.err == "" { t.Errorf("[%d] unexpected error: %v", i, e) } else if !strings.Contains(e.Error(), tc.err) { t.Errorf("[%d] expected an error containing %q: %v", i, tc.err, e) } } } } </ins>

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Shows that prometheus.MustRegister will panic on things like dashes in the metric name. There are currently 138 calls to prometheus.MustRegister in the Kubernetes code base almost exclusively from controllers. We should audit the code to ensure that panic is the desirable response to a bad metric name for these calls vs. something like prometheus.Register which will instead return an error. What you expected to happen: See above How to reproduce it (as minimally and precisely as possible): See Anything else we need to know?: No Environment: All Kubernetes version (use ): 1.9 Cloud provider or hardware configuration**: All OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
I did an analysis on this issue, and this is what I found: of the calls use a static metric name (hardcoded at the method invocation via a string and/or constant); is only a single case where the metric name is constructed dynamically (from a parameter), at the file (and happens to be where panicked); My proposal is: a. For static metric names (1), leave them as they are; b. For dynamic metric names (2), where the caller might not know that a parameter will be used to construct a metric name: Update the file to use instead of , and return the error if the metric cannot be registered (already submitted PR ); A quick search from the method invocation (from the above file) results in 17 invocations, mostly controllers, but although returns an error, no one of those 17 results is catching the error. So, we need to update all invocations to catch the error (I plan to submit new PRs to address this).

/sig instrumentation
We can trace all the task for update metrics.RegisterMetricAndTrackRateLimiterUsage invocations, and I am very happy to help fix it. [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [ ] [ ] [x] [x] [x]
Please go ahead with the ones not yet updated if you want.
OK, thanks!
now, we catch the error and when there return an error, we return in the function . But in the test file we use function for many times and Then there will be a lot of error in the test file, such as: then the test will always go fail. I think we should distinguish the error and when the error is Duplicate registration we dhould ignore it and return the normal controller.
Can you please provide an example where this is happening? I ran the tests on several controllers and haven't found that error. Ignoring this error doesn't seem a good idea IMO, if there're some tests that fail, we should investigate why are failing and fix them appropriately.
Sorry, I thought you were talking about the unit tests, didn't see the integration tests problem. I've submitted to fix this and ran the integration tests to check that creating multiple controllers don't fail anymore.
actually in some cases the unit tests is also failed such as endpoint controllerreplicaset controller. because different set up before test. So we should take a action to resolve it.