Take your original query that returns only the results with matching key(s) augmented with the extra label("label3")
and "or" it with a version of metric1 with an added label3 populated with a default/None/Null label value.
metric1 + on(label1) group_left(label3) metric2*0
or
label_replace(metric1, "label3", "None", "label1", ".*")
See https://prometheus.io/docs/prometheus/latest/querying/functions/#label_replace
label_replace(v instant-vector, dst_label string, replacement string, src_label string, regex string)
Note that you cannot use an empty string as a default label value,
because that apparently results in the label being removed completely from the element.
Any label present in all of the metric1 elements could be used instead of "label1" as the src_label.
We just need a src_label,regex combination that will match all elements.
I chose "label1" because that is what we want to join on anyway.
Note that first part of the "or" expression loses its metric name because of the arithmetic + operation.
The label_replace expression after the "or" retains the metric name.
I don't know if that would ever be a problem,
but the metric name can be eliminated in the second expression with an identity arithmetic operation.
metric1 + on(label1) group_left(label3) metric2*0
or
label_replace(metric1, "label3", "None", "label1", ".*")+0
Now I'm just making things up,
but I kinda wish Prometheus supported an outer join for labels with something like
metric1 + on(label1) join_left(label3="None") metric2*0
Or supported default values in expressions such as
really_complicated_expression > on(threshold_key) group_left() default(42) custom_thresholds_timeseries
that did not require repeating really_complicated_expression.
The solution described at https://www.robustperception.io/using-time-series-as-alert-thresholds
seems verbose for what I would consider a common use case.
-tim
that did not require repeating really_complicated_expression.
The solution described at https://www.robustperception.io/using-time-series-as-alert-thresholds
seems verbose for what I would consider a common use case.
Put "really_complicated_expression" in a recording rule? Works for me...
metric1 + on(label1) group_left(label3) metric2*0
or on(label1)
label_replace(metric1, "label3", "None", "label1", ".*")
regex
against the label src_label ?)
and {label1=v1, label2=v2} doesn't have dst_label=label3 (How did we replace label dst_label
by the expansion of replacement seen that label3 doesn't exist).