From faeb84a60b025b5016ebcbac07a42c233e3f7701 Mon Sep 17 00:00:00 2001 From: Arve Knudsen Date: Mon, 17 Jun 2024 14:10:05 +0200 Subject: [PATCH] Refine proposal Signed-off-by: Arve Knudsen --- ...0-native-support-for-info-metrics-metadata.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/proposals/2024-04-10-native-support-for-info-metrics-metadata.md b/proposals/2024-04-10-native-support-for-info-metrics-metadata.md index 431c4c6..f304116 100644 --- a/proposals/2024-04-10-native-support-for-info-metrics-metadata.md +++ b/proposals/2024-04-10-native-support-for-info-metrics-metadata.md @@ -38,8 +38,8 @@ Based on user demand, it would be preferable if Prometheus were to have better U There are other problems with Prometheus' current method of including info metric labels in queries, beyond just the technical barrier: * Explicit knowledge of each info metric's identifying labels must be embedded in join queries for when you wish to enrich queries with data (non-identifying) labels from info metrics. * A certain pair of OTel resource attributes (`service.name` and `service.instance.id`) are currently assumed to be the identifying pair and mapped to `target_info`'s `job` and `instance` labels respectively, but this may become a dynamic property of the OTel model. - * Both attributes are in reality optional, so either of them might be empty (`service.name` is only mandatory for OTel SDK clients). - * If both identifying attributes are empty, `target_info` isn't generated (there being no identifying labels to join against). + * Both attributes are in reality optional, so either of them might be missing (`service.name` is only mandatory for OTel SDK clients). + * If both identifying attributes are missing, `target_info` isn't generated (there being no identifying labels to join against). * If an info metric's data (non-identifying) labels change (a situation that should become more frequent with OTel in the future, as the model will probably start allowing for non-identifying resource attribute mutations), join queries against the info metric (e.g. `target_info`) will temporarily fail due to resolving the join keys to two different metrics, until the old metric is marked stale (by default after five minutes). If Prometheus could persist info metrics' identifying labels (e.g. `job` and `instance` for `target_info`), human knowledge of the correct identifying labels may become unnecessary when "joining" with info metrics. @@ -61,9 +61,9 @@ Neither can you build dedicated UI for OTel resource attributes (or other info m Goals and use cases for the solution as proposed in [How](#how): -* Persist info metrics with labels categorized as either identifying or non-identifying. +* Persist info metrics with labels categorized as either identifying or non-identifying (i.e. data labels). * Track when info metrics' set of identifying labels changes. This shouldn't be a frequent occurrence, but it should be handled. -* Automatically treat the old version of an info metric as stale for query result enriching purposes, when its data labels change (producing a new time series, but with same identity). +* Automatically treat the old version of an info metric as stale for query result enriching purposes, when its data labels change (producing a new time series, but with same identity from an info metric perspective). * Add TSDB API for, given a certain time series and a certain timestamp, getting data labels, potentially filtered by certain matchers, from info metrics with identifying labels in common with the time series in question. * If no data label matchers are provided, _all_ the data labels of found info metrics are added to the resulting time series. * If data label matchers are provided, only info metrics with matching data labels are considered. @@ -74,11 +74,11 @@ Goals and use cases for the solution as proposed in [How](#how): * A data label matcher like `__name__="target_info"` can be used to restrict the info metrics used. However, the `__name__` label itself will not be copied. * Label collisions: The input instant vector could already contain labels that are also part of the data labels of a matching info metric. - Furthermore, since the info function might find multiple differently named info metrics with matching identifying labels, those might have overlapping data labels. - In this case, the info function has to check if the values of the affected labels match or are different. + Furthermore, since multiple differently named info metrics with matching identifying labels might be found, those might have overlapping data labels. + In this case, the implementation has to check if the values of the affected labels match or are different. The former case is not really a label collision and therefore causes no problem. - In the latter case, however, the function has to return an error. - The collision can be resolved by constraining the labels via the optional label-selector argument of the info function. + In the latter case, however, an error has to be returned to the user. + The collision can be resolved by constraining the labels via data label matchers. And of course, the user always has the option to go back to the original join syntax (or, even better, avoiding ingesting conflicting info metrics in the first place). * Simplify enriching of query results with info metric data (non-identifying) labels in PromQL, e.g. via a new function, based on aforementioned TSDB API.