Code may look something like:

prysm/validator/client.go Global Var

	// ValidatorIdentityGaugeVec used to track validator identity
	ValidatorIdentityGaugeVec = promauto.NewGaugeVec(
		prometheus.GaugeOpts{
			Namespace: "validator",
			Name:      "identity_info",
			Help:      "Identifying information for the validator",
		},
		[]string{
			"pubkey", "index",
		},
	)

prysm/validator/client.go logForEachValidator(...)

ValidatorIdentityGaugeVec.WithLabelValues(pubKey, index).Set(1) 

I'm not sure we'd need to care too much de-registering exited validators too much given this is an info metric

Hi @0xste we've talked about this before but adding the pubkey would increase the cardinality of our metrics significantly. We have tried this and it affects operators that are running a lot of keys

Alternatively @rauljordan, we could add validator index to an existing high-cardinality metric behind the "emitAccountMetrics" flag to reduce the need for additional active series, would this approach satisfy the cardinality non-functional requirement?

becomes ->

...
		[]string{
			"pubkey", "index"
		},
...

becomes ->

		if v.emitAccountMetrics {
			fmtKey := fmt.Sprintf("%#x", status.publicKey)
			ValidatorStatusesGaugeVec.WithLabelValues(fmtKey, status.index).Set(float64(status.status.Status))
		}

☝️getting index is a bit more involved in this instance

My understanding is that there's a 1:1 relationship between pubkey + index and that it's assigned on validator activation? I may be missing some context

The validator is then assigned an index number and placed into a queue for activation

https://docs.prylabs.network/docs/how-prysm-works/validator-lifecycle#pending-state