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.