feat: hide __aggregated_metric__ in /series and /labels

[trevorwhitney]

What this PR does / why we need it:

This PR removes {__aggregated_metric=~".+"} streams from the /series endpoint, unless an __aggregated_metric__ matcher is explicitly requested. It does the same for /labels, so __aggregated_metric__ will not appear in a /labels response, but you can still request /labels/__aggregated_metric__/values.

This will alleviate confusion for people using a tool like logcli series --analyze-labels for cardinatlity analysis.

Special notes for your reviewer:

Checklist

• Reviewed the CONTRIBUTING.md guide (required)
• Documentation added
• Tests updated
• Title matches the required conventional commits format, see here
  • Note that Promtail is considered to be feature complete, and future development for logs collection will be in Grafana Alloy. As such, feat PRs are unlikely to be accepted unless a case can be made for the feature actually being a bug fix to existing behavior.
• Changes that require user attention or interaction to upgrade are documented in docs/sources/setup/upgrade/_index.md
• If the change is deprecating or removing a configuration option, update the deprecated-config.yaml and deleted-config.yaml files respectively in the tools/deprecated-config-checker directory. Example PR

[benclive]

This works if running Loki all-in-one or sharing a config file, but I don't think it will work if the pattern-ingester and querier are running as separate components and this cfg is set using a flag on the pattern-ingester so the querier doesn't see it

[trevorwhitney]

True, but since we already follow this pattern in many other places I think we've already created a dependency on a shared config file.

• We check bloom gateway config in the index gateway
• We already check pattern config in the querier
• We check ingester config in the querier

Would your preference be we specify -querier.metric_aggregation_enabled as a command line flag as well (as opposed to hiding it)?

[trevorwhitney]

I'm closing this for now, we'll see if we want it again in the future

[trevorwhitney]

and it's come up again 😺

[svennergr]

I think we used the presence of a __aggregated_metric__ label as the indicator that we can use aggregated metrics. How would we do that in the future? Just rely on the feature flag?
cc @gtk-grafana

[trevorwhitney]

@svennergr could you point me to code, do you know if we search explicitly for that label vs just hitting /labels? This PR still allows /label/__aggregated_metric__/values, which could be a simple solution?

Relying on the feature flag seems reasonable to me as well.

[svennergr]

@svennergr could you point me to code, do you know if we search explicitly for that label vs just hitting /labels? This PR still allows /label/__aggregated_metric__/values, which could be a simple solution?

Relying on the feature flag seems reasonable to me as well.

I think I'm working too much with LLMs nowadays. I hallucinated - we don't look for that in /labels response. Thanks and sorry, @trevorwhitney!