Add Quarkus documentation

[brunobat]

This PR adds documentation on how to use the zero-code OpenTelemetry instrumentation with the Quarkus java runtime.

[brunobat]

CC @trask @jeanbisutti

[chalin]

Hi. The build is failing, see the following log for details: https://app.netlify.com/sites/opentelemetry/deploys/679caf7a75f6fc0008075aa4. See inline suggestions for a possible fix.

[jeanbisutti]

Thank you @brunobat!

[chalin]

A partial copyedit pass.

[svrnm]

Hey @brunobat, thanks for raising this issue! We talked about this (and Deno) last Monday during the SIG communcations call, since both set precedence for having documentation for external projects. Overall we are excited for other projects to take on the instrumentation directly, but we need to make sure we provide some guidance here (when do we accept such a page and when do we decline, etc.), please give us some more time to evaluate.

cc @open-telemetry/docs-approvers @jack-berg

[brunobat]

@svrnm do you need me in the next communications meeting?

[trask]

I strongly support 💪

@brunobat and the Quarkus team have been active members of the OpenTelemetry Java community for a long time, and Quarkus represents an important alternative to the Spring ecosystem for our users

let me know if I can help further, thanks!

[chalin]

Thanks for commenting already @svrnm. Let me share some of what I recall from our discussion during the last Comms meeting.

Actually, first let's consider that we already have:

• Registry entries already: https://opentelemetry.io/ecosystem/registry/?s=quarkus
• The main entry has a link to https://quarkus.io/guides/opentelemetry

The main question I have is What added value is there for the content of this PR vs. the Quarkus docs referenced above? Is there anything new and exclusive here? If so, why isn't it a part of the Quarkus docs? If it is just a repetition, then it introduces a maintenance overhead.

Some repetition can be ok in a blog post, so maybe that is what is needed here?

As @svrnm mentioned, we're trying to find a solution that we can apply uniformly.

My 2 cents. Open to further discussion.

cc @svrnm @tiffany76 @jack-berg

[jeanbisutti]

The OpenTelemetry instrumentation developed on the Quarkus side covers one important use case in the Java world not possible with the OpenTelemetry Java agent today: instrument a Quarkus GraalVM native application with OpenTelemetry. This use case was an important reason to make the OTel starter stable.

From my side, it would make sense to highlight this in a very visible way for the OpenTelemetry users (with a new page for example).

There are also other scenarios exposed on the OpenTelemetry starter page for which the OpenTelemetry instrumentation developed on the Quarkus side is an alternative to the OpenTelemetry Java agent:

cc @chalin @svrnm @tiffany76 @jack-berg @trask @brunobat

[brunobat]

@svrnm I think this shouldn't be about what the PR adds in terms of documentation completeness but:

1. A recognition that the Quarkus team has done extensive OpenTelemetry instrumentation of their framework
2. Provide another option to the users when they search about zero code instrumentation in Java.
3. Do we want the OpenTelemetry documentation to ignore all the OpenTelemetry work done outside of the OpenTelemetry project?

[maxandersen]

"The main question I have is What added value is there for the content of this PR vs. the Quarkus docs referenced above"

mainly visibility to those looking into using OpenTelemetry standards sees that there a ways beyond just the opentelemetry github org provided libraries that enable great support for OpenTelemetry in Java ecosystem.

I definitely grok how it would be relevant to clearly mark that the Quarkus effort is from "outside" the github org/opentelemetry. Would that help to be called out more explicitly ?