Of the existing low-cardinality keys for spring.ai.advisor, none of them vary much...
gen_ai.operation.name is always "framework"
gen_ai.system is always "spring_ai"
spring.ai.kind is always "advisor"
spring.ai.advisor.type could be BEFORE, AFTER, or AROUND, but in reality it is always AROUND because that's the only kind of advisor that currently exists in Spring AI.
As a result, none of these keys are useful for filtering the metric.
But what might be interesting is to be able to filter the metric based on what advisor is in play. That is, if the spring.ai.advisor.name were a low-cardinality key, then you could do this.
It is conceptually possible that there could be several advisors in play, which is likely the reason it is a high-cardinality key. But I'd think that in most application, there wouldn't be that many advisors...likely less than 10...so while it has potential for being high-cardinality, in practice it will probably be low-cardinality.
Therefore, I would like to consider making it a low-cardinality key so that it can be used to filter the spring.ai.advisor metric.
Of the existing low-cardinality keys for spring.ai.advisor, none of them vary much...
As a result, none of these keys are useful for filtering the metric.
But what might be interesting is to be able to filter the metric based on what advisor is in play. That is, if the spring.ai.advisor.name were a low-cardinality key, then you could do this.
It is conceptually possible that there could be several advisors in play, which is likely the reason it is a high-cardinality key. But I'd think that in most application, there wouldn't be that many advisors...likely less than 10...so while it has potential for being high-cardinality, in practice it will probably be low-cardinality.
Therefore, I would like to consider making it a low-cardinality key so that it can be used to filter the spring.ai.advisor metric.