Survey how metrics/traces/logs can be exported via OTLP with Armeria

[jrhee17]

This issue is similar to #5736, but focuses on tracing instead of migrating metrics.

Since OTLP seems to be gaining popularity, it may be worth checking and documenting the current state.

We may want to:

• Check a basic user journey using Observation[Client|Service] with otel bridges
• Add documentation to our website. This can also result in more exposure.
• Add utilities to make the developer experience smooth (e.g. check how other projects like Spring Actuator are doing this)
• Check if all of the functionality of Brave[Client|Service] can be supported using Observation[Client|Service].
  • Or at least list the differences between the two
• Add an example so that we can easily guide users

[anuraaga]

Things to consider adding are OTel's instrumentation for Armeria

https://github.com/open-telemetry/opentelemetry-java-instrumentation/tree/main/instrumentation%2Farmeria%2Farmeria-1.3%2Flibrary

And the OTel collector to receive zipkin and export otlp.

The latter isn't very good but while I may be wrong I suspect micrometer bridges to be not that different. OTLP is just a relatively simple format but I have seen that if a backend only accepts otlp it almost always has strong ties to OTel semantic conventions which are populated best by instrumentation coupled with it without conversion layers.

Documentation could potentially link to it though also if there is interest in the Armeria project I'm sure OTel would be happy to contribute the library instrumentation to this repo if that seems worthwhile since there is an interest in more native instrumentation /cc @trask

[jrhee17]

populated best by instrumentation coupled with it without conversion layers.

I see

library instrumentation to this repo

I think adding a native implementation would be a good idea - I think it could also help the instrumentation agent implementation by providing a stable API.
I'm not sure about the idea of the other maintainers though @line/dx

[jrhee17]

Talked with the others, I think the general consensus is that armeria will support otel clients/service decorators natively.

@ikhoon commented that perhaps it would be a better idea that the code lives in the upstream repo, and we contribute to it.

[jrhee17]

Discussion 2 summary

---

• On the decision of where OTel[Client|Service] lives
  • We prefer that the OTel[Client|Service] lives in the armeria repo due to
    • Easier to control the lifecycle of releases
    • The review process is easier
    • Shorter compile time since Armeria + gradle enterprise
• On the decision of scope of whether to also support armeria-grpc functionality
  • It seems like the implementation is simple enough, so users can add it themselves
  • https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/f46e4f14dda0075d523c387e8253e1eda5d67ff1/instrumentation/armeria/armeria-grpc-1.14/javaagent/src/main/java/io/opentelemetry/javaagent/instrumentation/armeria/grpc/v1_14/ArmeriaGrpcServiceBuilderInstrumentation.java#L39C7-L39C97