This issue was detected when deploying the OpenTelemetry demo and using the Elastic's OpenTelemetry endpoint. In case the service is doing internal calls using gRPC (e.g. the checkout service), all the span.destination.service.* attributes are set to the value :0:
The issue is solved if the corresponding services include the peer.service attribute in their spans, but I reckon it would be more informative for the user to provide a different value other than :0 if peer.service is not defined. For example, unknown or just not providing the default port value?
For HTTP services, the span.destination.service.* are populated accordingly, my guess is because of the library extracting the destination values from the HTTP URL instead of the peer attribute: https://github.com/elastic/apm-data/blob/main/input/otlp/traces.go#L1006
Ongoing work to add peer.service in the OpenTelemetry demo: open-telemetry/opentelemetry-demo#1635
This issue was detected when deploying the OpenTelemetry demo and using the Elastic's OpenTelemetry endpoint. In case the service is doing internal calls using gRPC (e.g. the checkout service), all the
span.destination.service.*attributes are set to the value:0:The issue is solved if the corresponding services include the
peer.serviceattribute in their spans, but I reckon it would be more informative for the user to provide a different value other than:0ifpeer.serviceis not defined. For example,unknownor just not providing the default port value?For HTTP services, the
span.destination.service.*are populated accordingly, my guess is because of the library extracting the destination values from the HTTP URL instead of the peer attribute: https://github.com/elastic/apm-data/blob/main/input/otlp/traces.go#L1006Ongoing work to add
peer.servicein the OpenTelemetry demo: open-telemetry/opentelemetry-demo#1635