WIP: Info PromQL function prototype

[aknuds1]

Prototype of info PromQL function. The implementation looks up info metrics, with the right identifying labels and time range, in the TSDB.

NB: I use ValueTypeVector for the "label-selector" argument to info, but that's just a quick/imperfect hack, and we should probably have a dedicated ValueTypeLabelSelector that doesn't indicate the argument being for selecting an instant vector. Also see Beorn's comment below on the context of this prototype.

Screenshot of example usage:

TODO:

• Fix info metric TSDB chunks (currently buggy)
• Try to write benchmark to compare against corresponding join queries

[beorn7]

Just to get us all on the same page: This is just a proof of concept. Should we decide to implement this approach for real, what we want as the final result is what I have described in the design outline.

The PoC makes the following concessions to simplify the implementation:

1. It identifies info metrics by searching all metrics for those with a name ending on _info. This is all of (a) expensive, (b) prone to false positives (a metric with a name ending on _info that is not an info metric), and (c) prone to false negatives (it will not find an info metric that does not have a name ending on _info).
2. It uses all labels shared by the input metric and each candidate info metric as identifying labels. This can lead to underselecting identifying labels (e.g. only job if the input metric misses an instance label), leading to a too broad selection of info metrics. It could also lead to overselecting identifying labels if there is a label that shares a name just by coincidence, which could exclude info metrics we actually would like to use.

The real implementation needed to maintain additional data records to tracks all known info metrics at a given timestamp together with the information which of their labels are identifying labels and which are data labels.

Note that this additional information isn't readily available from exposition formats and the remote write protocol right now. See details in the design outline. In short:

• OpenMetrics protobuf is (almost) perfect here because it marks the labels of info metrics as identifying labels and data labels. The only problem is that OpenMetrics enforces a magic _info suffix on all info metrics, which prevents marking info-like metrics like kube_pod_labels as info metrics without changing their name. (And of course the other problem is that nobody actually uses OpenMetrics protobuf right now.)
• OpenMetrics text has the additional problem that it doesn't mark the labels of info metrics as identifying labels and data labels. They all look the same.
• When directly ingesting OTLP into a Prometheus compatible backend, resource attributes can be converted into fully fledged info metrics, but already existing info metrics (including things like kube_pod_labels) would still have the same problems as above.
• Classic Prometheus exposition formats don't even have a notion of an info metric.

Therefore, more work than just implementing the info function in Prometheus is needed. Protocols need to be extended for full support. However, ingestion into Prometheus could be configured to mark specific metrics and specific subset of their labels as info metrics and their identifying labels. That would be a somewhat laborious process, as it had to be customized to specific classes of targets. (For example, you could configure the scrape of kube-state-metrics to identify kube_pod_labels as an info metric with pod and namespace as identifying labels.)

[beorn7]

/cc @SuperQ as the comment above extends on our discussion on Slack.

[colega]

You don't need to hold the mutex for the first part where you're separating labels info identifying/data.