[Cargo] Update opentelemetry crates to their latest version

[jaudiger]

Update all the opentelemetry crates. opentelemetry-jaeger dependency was deprecated in favor of opentelemetry-otlp which provides agnostic APIs to export traces, logs, metrics.

Unfortunately, due to console-subscriber we now have to duplicate some dependencies such as tonic...

It depends on the unreleased version 0.25.0 of tracing-opentelemetry, see PR (for context: tokio-rs/tracing-opentelemetry#155)

[kylewlacy]

Update all the opentelemetry crates. opentelemetry-jaeger dependency was deprecated in favor of opentelemetry-otlp which provides agnostic APIs to export traces, logs, metrics

I think it was already deprecated when I first set it up too 😅 I just couldn't figure out how to get opentelemetry-otlp wired up to talk to Jaeger properly, so I'll have to try this out locally to see if I can get it working...

[jaudiger]

I think it was already deprecated when I first set it up too 😅 I just couldn't figure out how to get opentelemetry-otlp wired up to talk to Jaeger properly, so I'll have to try this out locally to see if I can get it working...

I could set up Jaeger locally if you want and test all of that, I'm familiar with this tool.

[jaudiger]

I finished testing this PR. And the reporting of traces is not broken, but an adaptation could be needed depending on how you're testing before @kylewlacy.

I used the docker-compose.yml below to deploy Jaeger, due to a limitation with the latest version 1.59, a temporary env var needs to be defined in some cases depending on mainly how all the things are deployed, and exposed:

The OTEL Collector upgrade brought in a change where OTLP receivers started listening on localhost instead of 0.0.0.0 as before. As a result, when running in container environment the endpoints are likely unreachable from other containers (Issue jaegertracing/jaeger#5737). The fix will be available in the next release. Meanwhile, the workaround is to instruct Jaeger to listen on 0.0.0.0, as in this fix:

services:
  jaeger:
    image: docker.io/bitnami/jaeger:1.59.0
    ports:
      - 6831:6831/udp
      - 6832:6832/udp
      - 5778:5778
      - 16686:16686
      - 4317:4317
      - 4318:4318
      - 14250:14250
      - 14268:14268
      - 14269:14269
      - 9411:9411
    environment:
      - COLLECTOR_ZIPKIN_HOST_PORT=:9411
      - COLLECTOR_OTLP_ENABLED=true
      - COLLECTOR_OTLP_GRPC_HOST_PORT=0.0.0.0:4317
      - COLLECTOR_OTLP_HTTP_HOST_PORT=0.0.0.0:4318
      - LOG_LEVEL=debug
      - JAEGER_USERNAME=
      - JAEGER_PASSWORD=

Brioche was launched inside another docker container with the following command:

docker run --name brioche-devenv --platform linux/amd64 -v $(pwd):/workspace -v $(pwd)/../brioche-packages:/tmp/brioche-packages -v brioche-cache:/home/container/.local/share/brioche -it --link jaeger-jaeger-1 --net jaeger_default brioche bash

The link and network arguments are here necessary, since I launched Jaeger through docker compose, and a new docker network was created by the compose command. I could have put everything inside the same docker-compose.yml file, though.

And then inside the container:

BRIOCHE_JAEGER_ENDPOINT=http://jaeger:4318/v1/traces cargo run -- fmt -p /tmp/brioche-packages/packages/bat

The difference between main and this branch is the endpoint used. On main, we need to pass jaeger: 6831 whereas now it's http://jaeger:4318/v1/traces.

The port 4318 accepts traces in OpenTelemetry OTLP format .

I could have used the port 4317, but I had issues with gRPC. The traces weren't exported correctly to Jaeger, only the child spans were exported, not the parent ones. The traces were incomplete. I suspect an issue inside one of the otel libraries used.

[kylewlacy]

Tested this out and works great, LGTM!

[kylewlacy]

Oh and it might be worth changing the env vars at some point since this is no longer Jaeger-specific, but since this is more of an internal debugging tool I don't feel strongly about when that happens. I might take it on sometime when doing some code cleanup