Change:
} return result, status } <ins> type instrumentedPreScorePlugin struct { framework.PreScorePlugin metric compbasemetrics.CounterMetric } var _ framework.PreScorePlugin = &instrumentedPreScorePlugin{} func (p *instrumentedPreScorePlugin) PreScore(ctx context.Context, state *framework.CycleState, pod *v1.Pod, nodes []*v1.Node) *framework.Status { status := p.PreScorePlugin.PreScore(ctx, state, pod, nodes) if !status.IsSkip() { p.metric.Inc() } return status } type instrumentedScorePlugin struct { framework.ScorePlugin metric compbasemetrics.CounterMetric } var _ framework.ScorePlugin = &instrumentedScorePlugin{} func (p *instrumentedScorePlugin) Score(ctx context.Context, state *framework.CycleState, pod *v1.Pod, nodeName string) (int64, *framework.Status) { p.metric.Inc() return p.ScorePlugin.Score(ctx, state, pod, nodeName) } </ins>

Discussion:
metrics to see more details related to scheduler's decisions in Filter phase In some cases (e.g. new feature is in scheduler and want to see if it works or not), we may want to see which filter plugin affected Pod's scheduling results and it would be nice if we can observe that in metrics. Ref: /cc /sig scheduling
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
So, your imagined metrics is like counter that has the label (i.e. one counter for one plugin) the count represents how many times did plugin have an impact on the scheduling of the pod. Am I correct? (I'm not sure if I am understanding your imagined metric correctly.)
I would also add an label that can be or . We probably need some common implementation between this and
do you have time to work on this in 1.26?
Yes, I'm gonna take time to work on this (+ ) in the next release. Let me try. /assign
We should probably extend this to Score as well
/retitle metrics to see which plugins affect to scheduler's decisions in Filter/Score phase
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale After supporting Skip in Filter and Score.
memo: is the issue to support Skip in Score.
/cc Will work on part after
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
It's time! /assign