feat: info() data-label autocomplete via /api/v1/info_labels (PoC)

[itsmylife]

What this is

This adds autocompletion for the PromQL info(<base>, { … }) function, for its data-label selector. It uses the new experimental Prometheus endpoint /api/v1/info_labels.

So when you type inside the second argument of info(), you get suggestions for the data-label names and values that come from the info metrics in scope (for example target_info). The suggestions are scoped by the first argument of info().

The whole thing is opt-in per datasource with a new jsonData.infoLabelsAutocomplete toggle, so it never fires against a normal Prometheus.

Warning

This is a PoC. I pushed it as one single commit only to show that it works end to end.
Please don't review or merge it like this, I will split it into small PRs (see "Follow-up").

How to run and test it

The endpoint is experimental and does not exist in normal Prometheus yet, so you need Arve's branch to get a server that serves /api/v1/info_labels.

1. Get @aknuds1 's demo Prometheus and run it:

   git clone https://github.com/aknuds1/prometheus
   cd prometheus
   git checkout arve/info-autocomplete
   go run ./documentation/examples/info-autocomplete-demo

This starts Prometheus on 127.0.0.1:9090 with the needed feature flags already on (search-api and promql-experimental-functions), and it also appends its own demo series (target_info, build_info, http_requests_total, db_queries_total).

This branch already has a provisioned datasource pointing at that demo (provisioning/datasources/datasources.yml, name prometheus-info-labels-demo). Grafana runs in Docker, so it reaches the host demo via http://host.docker.internal:9090. On Linux use the docker bridge gateway or run with --network host. The datasource has jsonData.infoLabelsAutocomplete: true so the feature is enabled.

In Explore, open the code editor with that datasource and try code completion at ^:

info(http_requests_total, { ^gives version, env, cluster
info(http_requests_total, {version="^ gives v1.0, v2.0
info(http_requests_total{job="api-gateway"}, {^ shows the expr scoping in action

There are also unit tests (yarn test). They mock the request layer, so for the unit tests you do not need a live server.

Why frontend only, and no streaming API here

The /api/v1/info_labels endpoint returns NDJSON, so technically it is a stream. But in this PR the frontend just fetches the full response body as text and parses it line by line. It does not consume it as a live stream, and there is no backend streaming plumbing (Grafana Live, StreamHandler, etc).

I did this on purpose:

• For autocomplete this is enough. The completion list needs the full set of labels/values before it can show and rank them, and the response is already bounded by limit (and values_limit), so the payload is small. Buffering the whole body and parsing it once is simple and fast enough, and it keeps this PR frontend only with zero backend changes.
• The proper streaming delivery (reading NDJSON progressively, backend stream handler, Live channels) is a bigger and separate piece of work.
• When we have full streaming api in place I can make a refactor.

Follow-up

I will split this PoC into around 9 or 10 small PRs. Almost all of them are behavior neutral (dead code or a no-op config), so the final PR that actually enables the feature stays very small. The real behavior change is only about 4 lines in monaco-completion-provider.ts.

[github-actions]

This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 2 weeks if no further activity occurs. Please feel free to give a status update or ping for review. Thank you for your contributions!