Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make opentelemetry-javaagent and OpenTelemetry Spring Boot starter/autoconfigure compatible #12381

Open
spockz opened this issue Oct 2, 2024 · 6 comments
Labels
enhancement New feature or request

Comments

@spockz
Copy link

spockz commented Oct 2, 2024

Is your feature request related to a problem? Please describe.

We develop our applications using Spring Boot based on an in-house framework. This in-house framework (traditionally) takes care of all observability aspects, such as reporting targets and standard (resource/span) tags. Most of the data we set by default is known only after Spring context evaluation.

The framework takes care of this because we have a myriad of different deployment targets using different pipelines and different compute hosts and this mechanism allows is to generate a self-contained binary/jar.

The spring boot starter gives us the customisability of the resources attributes and the automatic determination of OTLP targets, but lacks the wide instrumentation that agent provides.

The agent gives us the broad instrumentation but lacks the (ease) of customisation that the spring boot starter offers. It has mechanisms for customisation through SPI, however, this code runs before the Spring Context is evaluated meaning we need to duplicate code to do the same determinations. Because much of the code is written in the Spring ecosystem and used in the rest of the application as well, we need to duplicate the code, which we would rather avoid.

Describe the solution you'd like

Provide the option for the agent to do all the instrumentation, rewriting bytecode, etc. without initialising the actual OpenTelemetry(SDK) so that can be left to the Spring Boot Autoconfiguration to configure and initialise.

Describe alternatives you've considered

  • Duplicate code for determining the targets and standard attributes
  • Be able to modify OTLP targets after initialisation (this is less critical as the logic is relatively easy to extract and have the values provided as ENV vars.)
  • Be able to modify the default resource attributes after initialisation.

Additional context

No response

@spockz spockz added enhancement New feature or request needs triage New issue that requires triage labels Oct 2, 2024
@jeanbisutti
Copy link
Member

Could you please elaborate "The spring boot starter gives us the customisability of the resources attribute"?

@trask
Copy link
Member

trask commented Oct 3, 2024

Could you please elaborate "The spring boot starter gives us the customisability of the resources attribute"?

I think it means the ability to configure otel.resource.attributes via normal spring configuration

@spockz
Copy link
Author

spockz commented Oct 3, 2024

The Autoconfigure also allows for something like a "Custom Resource Configurer", the exact name eludes me at the moment. It is a bean you can define which gets passed in the Resource which you can modify before it is finalised. This also is available for some of the other types.

@jeanbisutti
Copy link
Member

jeanbisutti commented Oct 4, 2024

The Autoconfigure also allows for something like a "Custom Resource Configurer", the exact name eludes me at the moment. It is a bean you can define which gets passed in the Resource which you can modify before it is finalised. This also is available for some of the other types.

You may refer to

and https://opentelemetry.io/docs/zero-code/java/spring-boot-starter/sdk-configuration/#programmatic-configuration

The spring boot starter gives us the customisability of the resources attributes and the automatic determination of OTLP targets, but lacks the wide instrumentation that agent provides.

The agent gives us the broad instrumentation but lacks the (ease) of customisation that the spring boot starter offers.

The starter provides out of the box instrumentation: https://opentelemetry.io/docs/zero-code/java/spring-boot-starter/out-of-the-box-instrumentation/

You can also enable additional instrumentation: https://opentelemetry.io/docs/zero-code/java/spring-boot-starter/additional-instrumentations/

Is there an instrumentation you need not available with the starter?

@steverao steverao removed the needs triage New issue that requires triage label Oct 7, 2024
@cbos
Copy link

cbos commented Oct 14, 2024

The list of https://opentelemetry.io/docs/zero-code/java/spring-boot-starter/out-of-the-box-instrumentation/ contains 9 integrations, while this list contains 100+ integrations: https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/supported-libraries.md#libraries--frameworks

How to bring that together?

Integrations which are missing in the Spring boot starter which we would like to use:

  • Cassandra
  • Spring Integration
  • JMS
  • Executors
    And there are more.

It feels weird to reimplement them again in the Spring boot starter project while they are already implemented for the agent.
So how to combine that in such a way that you have the convenience of the Spring boot starter project and use the Spring configuration to do the configuration for OpenTelemetry at one side and use the agent instrumentation of all the libraries at the other side.

Or will this not come together and be separate tracks which can both be used to achieve the same in 2 different ways?

@spockz
Copy link
Author

spockz commented Oct 14, 2024

Is there an instrumentation you need not available with the starter?

The Jersey instrumentation would also be interesting for us still, or actually at the Tomcat level.

We would either need that we can run the OpenTelemetry agent as a "pre-processing" or get the agent to be compatible with the application level OTel instrumentations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants