Implement target metadata API

[yeya24]

As metric metadata API was merged #3686, it would be good to also support the Prometheus target metadata API (https://prometheus.io/docs/prometheus/latest/querying/api/#querying-target-metadata).

As the API response format is very similar to the previous metric metadata API, it would be not so difficult to support it. We can reuse the existing proto file as well.

[crsandeep]

@yeya24 I'd love to take up this issue

[yeya24]

Feel free to take it!

[stale]

Hello 👋 Looks like there was no activity on this issue for the last two months.
Do you mind updating us on the status? Is this still reproducible or needed? If yes, just comment on this PR or push a commit. Thanks! 🤗
If there will be no activity in the next two weeks, this issue will be closed (we can always reopen an issue if we need!). Alternatively, use remind command if you wish to be reminded at some point in future.

[stale]

Closing for now as promised, let us know if you need this to be reopened! 🤗

[philipgough]

@crsandeep I will take a go at this unless you are still working on it in the background?

[crsandeep]

Apologies, I couldn't get to this.
@philipgough please feel free to pick this up

[bill3tt]

Chatted with @philipgough about this ticket earlier, we were a little confused so just wanted to be more explicit about what we expect the output of a call to Query's /api/v1/targets/metadata would be.

Say we had a Querier configured to communicate with two sidecars StoreAPIs with two Prometheus instances. Calling /api/v1/targets/metadata on each Prometheus returns the following...

Example Prometheus target metadata response

{
  "status": "success",
  "data": [
    {
      "target": {
        "instance": "localhost:9090",
        "job": "myself"
      },
      "metric": "prometheus_tsdb_out_of_bound_samples_total",
      "type": "counter",
      "help": "Total number of out of bound samples ingestion failed attempts.",
      "unit": ""
    }
  ]
}

We assume that the expected output of calling Query's /api/v1/targets/metadata would be the same as the above i.e. one entry per (Target, Metric) tuple, rather than one entry per (Store, Target, Metric) tuple.

This behaviour would be consistent with the handling of metadata in the TestMetadataAPI_Fanout integration test.

Is that in-line with what you had in mind @yeya24 ?

[majorpeti007]

I was looking into using the /api/v1/targets/metadata endpoint on Thanos Query, and I would have expected the output to be one entry per (Target, Metric) tuple, the same as on Prometheus.

[stale]

Hello 👋 Looks like there was no activity on this issue for the last two months.
Do you mind updating us on the status? Is this still reproducible or needed? If yes, just comment on this PR or push a commit. Thanks! 🤗
If there will be no activity in the next two weeks, this issue will be closed (we can always reopen an issue if we need!). Alternatively, use remind command if you wish to be reminded at some point in future.

[stale]

Closing for now as promised, let us know if you need this to be reopened! 🤗

[gillg]

Any news around that ? @philipgough @ianbillett I saw your closed PRs... :/ Maybe we should reopen they ?

[philipgough]

@gillg - hey, yes they went stale - I think #4449 can be re-opened and reviewed and I am happy to get back to it if the maintainers find the time.