Shivam
November 15, 2025, 6:20am
1
Fly.io uses VictoriaMetrics,
Our metrics stack — which is built around Prometheus-style metrics — features the following cast of characters:
Victoria Metrics (“Vicky”, for the rest of this post), in a clustered configuration, is our metrics database. We run a cluster of fairly big Vicky hosts.
And it looks like it doesn’t expose type when exporting metric, and hence all datatype of metrics come out as gauge :
opened 07:38PM - 11 Aug 22 UTC
closed 08:29PM - 17 Nov 25 UTC
enhancement
completed
support
prom-compatibility
**Is your feature request related to a problem? Please describe.**
This featu… re request is to support the [Prometheus Metric Metadata API](https://prometheus.io/docs/prometheus/latest/querying/api/#querying-metric-metadata) at `/api/v1/metadata` in Prometheus [v2.15.0+](https://github.com/prometheus/prometheus/blob/main/CHANGELOG.md#2150--2019-12-23). Similar to #643, but this endpoint returns metadata about scraped metrics without any associated target information.
`vmselect` currently returns an empty placeholder response for this endpoint (see e6bf88a4d4948d60b9f1b9c432db46af7001368c).
More generally, the request is for VictoriaMetrics to support metric metadata throughout its Prometheus-compatible components. In addition to implementing `/api/v1/metadata`, metadata would need to be scraped from Prometheus targets and also propagated via Prometheus remote-write, using the `metadata` field added to the Prometheus remote-write protocol in [v2.23.0](https://github.com/prometheus/prometheus/blob/main/CHANGELOG.md#2230--2020-11-26).
**Describe the solution you'd like**
A full solution for Prometheus metadata would require updates to a few components:
- `vmselect` implements the `/api/v1/metadata` endpoint with a response containing at least one metadata object per metric name.
- `vmstorage` adds support for storing metric metadata.
- If implementing separate metadata storage is not feasible, a workaround could be to store metadata using a special internal metric name (e.g., `_prometheus_metadata`) with metadata stored in `metric`, `type`, `help`, `unit` labels, requiring no change to `vmstorage` itself.
- `vmagent` scrapes metadata from Prometheus targets, and add the `metadata` field to `remote_write` requests it sends.
- Both `vmagent` and `vminsert` extract the `metadata` field from `remote_write` requests they receive.
**Describe alternatives you've considered**
Since Victoriametrics currently ignores Prometheus metric metadata, the only alternative would be to proxy this endpoint to another handler which serves metric metadata stored in another system.
**Additional context**
Since the introduction of the Metric Metadata API, metric metadata has become an increasingly critical part of the Prometheus user experience.
One key use-case related to this feature request is to support Grafana's [in-line metrics help text](https://grafana.com/blog/2020/06/15/how-we-made-working-with-prometheus-easier-with-metric-metadata-in-grafanas-explore-view/) when using VictoriaMetrics as a Prometheus datasource:
Why does the federate endpoint return all metrics as untyped?Sadly, Prometheus doesn't really persist the metric type. It does somecaching of this kind of metadata (availably via a separate API, seehttps://prometheus.io/docs/prometheus/latest/querying/api/#querying-target-metadata), but that's only for the most recent scrapes and separate from theTSDB.
Federation data is served from the TSDB, and at that point, Prometheusis completely ignorant of the original type and has to mark everythingas "untyped".
system
November 22, 2025, 6:20am
2
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.