This construction where we increment error metrics both here and down the stack where they occur means that we count the same error in more than one metric. This makes sums over the error metrics very misleading.

A better design is to only increment the metrics here in this function by selecting on the type of error returned by s.sessionStart.

You could create an error wrapper e.g.

type metricError struct {
    err error
    labels prometheus.Labels
} 

func (m metricError) Error() string {
    return m.Unwrap().Error()
}

func (m metricError) Unwrap() error {
    return m.err
}

Then use xerrrors.As to check for this type and increment accordingly. If we forget to wrap some errors, we can have an "unknown" error type that we increment in this case, which could signal us to go back and wrap the missing error.

This construction where we increment error metrics both here and down the stack where they occur means that we count the same error in more than one metric.

I shall disagree, as having a generic metric to indicate that a session error happened is much easier to set up alarming. You don't need to watch every single metric and eventually miss newly added ones, but just have one to depend on.

In prometheus it's easy to query for the sum across the label of error metrics. No chance of missing one if more label values are added later.