Summary
Implement the GET /api/v1/features endpoint to expose which features and capabilities are enabled in a Cortex instance.
Background
Prometheus introduced this endpoint to allow clients (e.g., Grafana) to discover which features a backend supports without relying on version strings from /status/buildinfo. This is especially important for Prometheus API implementations like Cortex, where version numbers don't map to Prometheus feature availability.
See the original Prometheus proposal: prometheus/prometheus#10022
Motivation
- Grafana and other clients use this endpoint to enable/disable UI features (e.g., exemplars, label matchers on label-values requests)
- Cortex has several feature-gated capabilities (streaming ingestion, query sharding, parquet queryable, remote write v2, etc.) with no single endpoint to discover what's active
- Operators currently have to parse
/config output or logs to determine which experimental features are enabled
Scope
- Register
GET /api/v1/features on both the Prometheus and legacy HTTP prefixes
- Return a response compatible with the Prometheus format
- Include Cortex-specific feature flags and experimental capabilities
Summary
Implement the
GET /api/v1/featuresendpoint to expose which features and capabilities are enabled in a Cortex instance.Background
Prometheus introduced this endpoint to allow clients (e.g., Grafana) to discover which features a backend supports without relying on version strings from
/status/buildinfo. This is especially important for Prometheus API implementations like Cortex, where version numbers don't map to Prometheus feature availability.See the original Prometheus proposal: prometheus/prometheus#10022
Motivation
/configoutput or logs to determine which experimental features are enabledScope
GET /api/v1/featureson both the Prometheus and legacy HTTP prefixes