The outcome attribute in Pipeline Component Telemetry RFC isn't scoped

[dmitryax]

The outcome attribute is not scoped as other attributes for the internal collector metrics. According to https://opentelemetry.io/docs/specs/semconv/general/naming/#general-naming-considerations all the attribute name should be globally unambiguous. This attribute cannot be added to the global attributes registry in its current form.

I haven't found any discussion related to picking up this attribute name. If there is a reason to go with the exception, this issue can be closed. Otherwise, we could rename it to something like otelcol.component.consume.outcome while the new metrics aren't released yet.

cc @djaglowski @jade-guiton-dd

[jade-guiton-dd]

I wouldn't interpret these recommendations as saying that attributes should be globally unambiguous. They only state that they should be "unambiguous", and to use namespaces "whenever it makes sense", which to me implies that they should be unambiguous in context.

Because component attributes like otelcol.component.kind are generic attributes, that can and will be added to any and all internal telemetry, and which will end up juxtaposed with arbitrary library names, it's very important that they be namespaced.

However, outcome is a metric attribute which was only meant to be added to specific metrics produced by pipeline instrumentation (otelcol.receiver.produced.items and co). It is not the kind of generic attribute that would be added to the registry so it can be reused across semantic conventions. And since the metrics it is found in are namespaced themselves, I don't think there is much ambiguity.

outcome would not be the first instance of this either: there are already a number of unscoped metric attributes used in internal Collector telemetry, such as the "receiver" and "transport" attributes on metrics generated by receiverhelper.

This is only my opinion, and I don't have strong objections to modifying the attribute name besides the work it implies. If the overall consensus is that the recommendation should be interpreted as you say, I have no issues with making the attribute name more specific. If we go that way however, I think we will want to clarify our guidelines, and modify receiverhelper and other core internal telemetry producers to match them.

[djaglowski]

I'm in favor of using a more specific name. There might be a way to justify avoiding it but I don't see it as an important enough distinction to argue against the general trend that the semantic conventions are encouraging.

otelcol.component.consume.outcome seems like a good name but my concern is that it may be confusing if used on both "consumed" and "produced" metrics. The meaning is the same in both cases really but a slightly more generic name might appear more natural.

What do we think of otelcol.component.outcome?

Considering a few examples (Capitalization is for emphasis only)

• otelcol.processor.consumed.items with otelcol.component.outcome=success indicates that the processor successfully consumed the items.
• otelcol.processor.produced.items with otelcol.component.outcome=success indicates that the processor produced items which were successfully consumed.
• otelcol.processor.consumed.items with otelcol.component.outcome=failure indicates that an error occurred within the processor when consuming the items.
• otelcol.processor.produced.items with otelcol.component.outcome=failure indicates that the items produced by the processor caused an error in an immediate next component.
• otelcol.processor.consumed.items with otelcol.component.outcome=refused indicates that an error was propagated back through the processor. (i.e. originated downstream of the processor)
• otelcol.processor.produced.items with otelcol.component.outcome=refused indicates that an error was propagated back to the processor. (i.e. originated downstream of the processor's immediate next components)

[jade-guiton-dd]

(I think refused and failure should be swapped there)

[dmitryax]

otelcol.component.outcome sounds good to me 👍

[djaglowski]

PR to implement this decision: #12951