service.instance.id is sent as an integer, not as a string in protobuf messages

[aquap]

I am consuming OpenTelemetry events from an Elixir Phoenix application that depends on the hex package :opentelemetry 1.3.1 and exported using the http_protobuf exporter.

The service.instance.id is being received unexpectedly not as a long UUID-like string, but as a large negative integer by my consumer.

The OpenTelemetry documentation indicates that the (experimental) service.instance.id parameter should be a string, and the examples show some kind of UUID string.

https://opentelemetry.io/docs/specs/semconv/resource/#service

To consume this value from BEAM language opentelemetry, it would be useful if it were either a UUID or a long hex string.

I have instrumented the protobuf decoder in my collector, and it appears that service.instance.id is being sent by opentelemetry-erlang as a protobuf integer, rather than a protobuf string or binary. The resource attributes aren't definitively typed in the proto definitions, so the protobuf type is probably being identified from the type of the erlang variable.

Quickly reviewing the code in otel_resource_detector.erl shows this value being generated from otel_id_generator:generate_trace_id/0 which in other contexts - providing trace.id in spans - delivers a protobuf binary which is easily, consistently and mostly automatically coerced to a long hex string by the consumer because of the typing in the proto definition for spans.

As a guess (not being somebody comfortable with erlang), I'd suggest stringifying the values in otel_resource_detector.erl in the function add_service_instance/1 and hopefully the protobuf encoder in the exporter will pick the right type.

[tsloughter]

Thanks for the report! This should definitely be converted to a string in otel_resource_detector. We will get that fixed.

[Annosha]

Hi @tsloughter if this is a beginner friendly issue can I work on it?

[tsloughter]

@Annosha yes, I think it is actually. I just forgot all about it. Happy to help you with digging in if you need.

[tsloughter]

Update on this: Thanks to @Annosha for opening a PR but when reviewing I checked the semantic conventions (https://github.com/open-telemetry/semantic-conventions/blob/d9d1e21a5bbb37fe8facea323491d59342a5f810/docs/attributes-registry/service.md#service-instance-id) and we are actually all wrong at the moment.

Not only should this not be an integer but we shouldn't be using the node name as we are doing but instead using that as input to create a UUIDv5.