/sig scheduling
/sig instrumentation

/cc @alculquicondor @ahg-g @logicalhan

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. @ehashman 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:

• pending_pods - 2 years; last change was to migrate to the metrics stability framework
• preemption_attempts_total - 17 months; last change was a renaming of the metric
• preemption_victims - 15 months; last change was a renaming of the metric
• e2e_scheduling_duration_seconds - 17 months; last change was to add a label
• schedule_attempts_total - 17 months; last change was to add a label

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. @ehashman are there any defined criteria for graduation?

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. pending_pods and preemption_victims don't have a unit suffix, but they are unit-less. Is that fine @logicalhan?

+1 to graduation then. These metrics are very mature.

Although, I'm not sure if all metrics already adhere to naming conventions. pending_pods and preemption_victims don't have a unit suffix, but they are unit-less. Is that fine @logicalhan?

pending_pods is a gauge so it's fine, preemption_victims 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 e2e_scheduling_duration_seconds. I feel that the e2e part of the metric is unnecessary. Having scheduling_duration_seconds instead and keeping scheduling_algorithm_duration_seconds for the algorithm latency is already descriptive enough to know the difference between both. If that's not the case, then the Help text of the metric can be used to guide the users.

I agree that e2e 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: #105941