Change:
Subsystem:      SchedulerSubsystem, Name:           "schedule_attempts_total", Help:           "Number of attempts to schedule pods, by the result. 'unschedulable' means a pod could not be scheduled, while 'error' means an internal scheduler problem.", <del> StabilityLevel: metrics.ALPHA, </del> <ins> StabilityLevel: metrics.STABLE, </ins> }, []string{"result", "profile"}) e2eSchedulingLatency = metrics.NewHistogramVec( &metrics.HistogramOpts{ <ins> Subsystem:         SchedulerSubsystem, Name:              "e2e_scheduling_duration_seconds", DeprecatedVersion: "1.23.0", Help:              "E2e scheduling latency in seconds (scheduling algorithm + binding). This metric is replaced by scheduling_attempt_duration_seconds.", Buckets:           metrics.ExponentialBuckets(0.001, 2, 15), StabilityLevel:    metrics.ALPHA, }, []string{"result", "profile"}) schedulingLatency = metrics.NewHistogramVec( &metrics.HistogramOpts{ </ins> Subsystem:      SchedulerSubsystem, <del> Name:           "e2e_scheduling_duration_seconds", Help:           "E2e scheduling latency in seconds (scheduling algorithm + binding)", </del> <ins> Name:           "scheduling_attempt_duration_seconds", Help:           "Scheduling attempt latency in seconds (scheduling algorithm + binding)", </ins> Buckets:        metrics.ExponentialBuckets(0.001, 2, 15), <del> StabilityLevel: metrics.ALPHA, </del> <ins> StabilityLevel: metrics.STABLE, </ins> }, []string{"result", "profile"}) SchedulingAlgorithmLatency = metrics.NewHistogram( &metrics.HistogramOpts{

Discussion:
I would like to propose the graduation of the following scheduler metrics from alpha to stable: These metrics have been stable for at least 15 months.
/sig scheduling /sig instrumentation
/cc
IIRC, the last addition to these metrics was the profile name label. I don't foresee need for new labels. I don't see many precedents for graduation in core components. are there any defined criteria for graduation?
As requested, the following is how long it has been since a change has been made to each of the requested metrics: - 2 years; last change was to migrate to the metrics stability framework - 17 months; last change was a renaming of the metric - 15 months; last change was a renaming of the metric - 17 months; last change was to add a label - 17 months; last change was to add a label
It's up to the component owners to commit to graduating these metrics, since the component owners own the metrics and therefore need to agree to support them in accordance to stability requirements. If you guys are okay with promoting these metrics, I don't see a reason, from an instrumentation side, why we would object to promotion.
+1 to graduation then. These metrics are very mature. Although, I'm not sure if all metrics already adhere to naming conventions. and don't have a unit suffix, but they are unit-less. Is that fine
is a gauge so it's fine, is a histogram so it's also fine.
I'm recently working with metrics, I'm glad to provide some help if no one has interest about it.
There is already an open PR for this.
Oh sorry, didn't notice about that. Forget it.
These graduations sound good to me, but I would be inclined to rename . I feel that the part of the metric is unnecessary. Having instead and keeping for the algorithm latency is already descriptive enough to know the difference between both. If that's not the case, then the text of the metric can be used to guide the users.
I agree that is rather confusing, so +1 to removing the prefix. The metric doesn't include retries, for example. We have a separate metric that includes retries: We need to rename that one eventually to e2e, but it can only be done after the existing one has been deprecated and deleted for a few releases. /triage accepted
/assign
/cc
The PR for this is ready to be reviewed: