Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
aquap opened this issue Feb 7, 2024 · 4 comments · May be fixed by #793
Open

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

aquap opened this issue Feb 7, 2024 · 4 comments · May be fixed by #793
Labels
bug Something isn't working semconv Semantic Convetions spec A change to the SDK specification that must be implemented.

Comments

@aquap
Copy link

aquap commented Feb 7, 2024

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
Copy link
Member

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

@tsloughter tsloughter added bug Something isn't working spec A change to the SDK specification that must be implemented. semconv Semantic Convetions labels Feb 7, 2024
@Annosha
Copy link

Annosha commented Oct 17, 2024

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

@tsloughter
Copy link
Member

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

@tsloughter
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working semconv Semantic Convetions spec A change to the SDK specification that must be implemented.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants