feat(prometheus): support wildcard metric name in prometheus_metrics_…

[ademicho123]

TLDR

Problem this solves:

• No way to filter labels across all metrics without listing each one
• Had to enumerate ~70 metric names just to trim labels down

How it solves it:

• Added a "*" wildcard to prometheus_metrics_config for default labels
• A named metric group still overrides the wildcard when I need one exception
• Found and fixed a missing PrometheusMetricLabels entry the wildcard exposed

Relevant issues

Fixes #30532

Linear ticket

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• I have added meaningful tests
• My PR passes all CI/CD checks (e.g., lint, format, unit tests)
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have received a Greptile Confidence Score of at least 4/5 before requesting a maintainer review (Greptile reviews automatically once the PR is opened; only comment @greptileai to re-request a review after pushing changes)

Delays in PR merge?

If you're seeing a delay in your PR being merged, ping the LiteLLM Team on Slack (#pr-review).

Screenshots / Proof of Fix

I set prometheus_metrics_config to a single wildcard group (metrics: ["*"], include_labels: ["hashed_api_key", "team"]), ran the proxy locally, and sent a request through it.

Before (commit 2bfd50ed37): /metrics shows no series at all for litellm_proxy_failed_requests_metric, litellm_proxy_total_requests_metric, litellm_deployment_failure_responses, litellm_deployment_total_requests, or litellm_llm_api_failed_requests_metric - just the HELP/TYPE lines, no data.

After (commit 4c1166405e), same request:
litellm_proxy_failed_requests_metric_total{hashed_api_key="None",team="None"} 2.0
litellm_proxy_total_requests_metric_total{hashed_api_key="None",team="None"} 2.0
litellm_deployment_failure_responses_total{hashed_api_key="None",team="None"} 1.0
litellm_deployment_total_requests_total{hashed_api_key="None",team="None"} 1.0
litellm_llm_api_failed_requests_metric_total{hashed_api_key="None",team="None"} 2.0

Each of these normally carries 13-14 default labels and they're all different sets between metrics. With the wildcard config, every one collapsed to just the two I configured - proof the filter applies uniformly across metrics that don't share a label schema, not just the one I originally tested against.

Type

🆕 New Feature

Changes

prometheus_metrics_config groups can now set metrics: ["*"] to apply include_labels as the default label set for every metric, instead of listing all ~70 by hand. It only sets defaults - it never disables a metric, that's still controlled separately by naming real metrics in another group. A group naming a specific metric still wins over the wildcard for that one metric, so I can set a broad default and carve out exceptions. A group can't mix the wildcard with named metrics; I raise a clear error if it tries.

While building this I found litellm_in_flight_requests is listed in DEFINED_PROMETHEUS_METRICS but was missing a matching entry in PrometheusMetricLabels. Nothing caught it before because no existing code path iterated over every defined metric name at once - the wildcard is the first thing that does. I fixed get_labels() to default to an empty label list instead of raising, so this metric (and any other one like it) doesn't break when a wildcard group touches it.

Added tests/test_litellm/integrations/test_prometheus_wildcard_labels.py covering: wildcard applying defaults across every metric, a named group overriding the wildcard, the wildcard never disabling a metric it doesn't name, wildcard + a separate enabled-metrics group working together, the mixed-wildcard-and-named-metric error, and an unknown label under the wildcard getting reported instead of silently dropped.

Final Attestation

• The tests check the right things, including the edge cases, and regressions in the respective real-world customer use-cases are not possible after this PR

[ademicho123]

@greptileai

[greptile-apps]

Greptile Summary

This PR adds wildcard label-filter defaults for Prometheus metrics.

• Wildcard groups apply default labels without restricting metric enablement.
• Named metric groups override wildcard defaults.
• Missing label declarations now default to an empty label set.
• Tests cover wildcard validation, overrides, enablement, and test-state isolation.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains; the wildcard is handled before ordinary metric-name validation, and the tests now restore the process-global Prometheus configuration.

Important Files Changed

Filename	Overview
litellm/integrations/prometheus.py	Implements wildcard validation and label-filter expansion while preserving independent metric enablement; the previously reported initialization issue is fixed.
litellm/types/integrations/prometheus.py	Defines the wildcard constant, documents its configuration semantics, and safely handles the existing label-less in-flight metric.
tests/test_litellm/integrations/test_prometheus_wildcard_labels.py	Covers wildcard defaults, named overrides, enablement behavior, invalid configurations, and restores modified global configuration through monkeypatch.

_{Reviews (2): Last reviewed commit: "fix: apply wildcard label-filter logic t..." | Re-trigger Greptile}

[greptile-apps]

Wildcard rejected during initialization

When prometheus_metrics_config contains metrics: ["*"], PrometheusLogger.__init__ passes the wildcard through the existing metric-name validator, which rejects it because it is not in DEFINED_PROMETHEUS_METRICS and raises ValueError. The production parser also lacks the wildcard expansion and enablement handling asserted by these tests, so the advertised configuration cannot apply default labels.

Knowledge Base Used: Logging & Observability Integrations

[codecov]

Codecov Report

❌ Patch coverage is 92.59259% with 2 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
litellm/integrations/prometheus.py	92.00%	2 Missing ⚠️

📢 Thoughts on this report? Let us know!

[codspeed-hq]

Merging this PR will not alter performance

✅ 31 untouched benchmarks

---

_{Comparing ademicho123:feat/prometheus-wildcard-label-filter-clean (aa44477) with litellm_internal_staging (1a0acaa)¹}

Footnotes

1. No successful run was found on litellm_internal_staging (998a372) during the generation of this report, so 1a0acaa was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[ademicho123]

@greptile-apps