Configuration omissions from Using Opentelemetry guide example?

[wabrit]

I've just been working through the 3.2-latest Using Open Telemetry guide and ran into issues when trying to push spans to the jaegertracing/all-in-one:latest docker image suggested in the example.

With the suggested configuration, I received no spans in jaegar at all. I think that was because the default value of quarkus.otel.traces.exporter is cdi, and it needed to be set to otlp.

Once I did that, the running image log reported the following error:

 {"level":"info","ts":1690210946.4101171,"caller":"grpc@v1.56.2/server.go:932","msg":"[core][Server #5] grpc: Server.Serve 
failed to create ServerTransport: connection error: desc = \"transport: http2Server.HandleStreams 
received bogus greeting from client: \\\"POST / HTTP/1.1\\\\r\\\\nUser-Ag\\\"\"","system":"grpc","grpc_log":true}
Gracefully stopping... (press Ctrl+C again to force)

which looked like a protocol error.

I fixed this by setting quarkus.exporter.otlp.traces.protocol=grpc (the default being http/protobuf). Once that was done, spans started appearing in jaegar.

Unless I've missed something, this feels like a doc bug; it should list those 2 extra properties as a necessary part of the configuration.

[quarkus-bot[bot]]

/cc @brunobat (opentelemetry), @radcortez (opentelemetry)

[brunobat]

I think you are right @wabrit
On the latest we changed the exporter implementation but CDI should have continued to work.
I will doublecheck and update the documentation if needed.
CC @geoand

[wabrit]

I'm curious as to what the difference is between cdi and otlp when setting the value of quarkus.otel.traces.exporter?

[geoand]

Weird, I didn't see this, but then again I was working with main :)

[brunobat]

cdi was using our default legacy exporter to maximise compatibility with the old 2.x quarkus-opentelemetry extension version. It was handled by CDI.