-
Notifications
You must be signed in to change notification settings - Fork 864
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
Comments
Could you please elaborate "The spring boot starter gives us the customisability of the resources attribute"? |
I think it means the ability to configure |
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 Line 88 in f235209
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? |
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:
It feels weird to reimplement them again in the Spring boot starter project while they are already implemented for the agent. Or will this not come together and be separate tracks which can both be used to achieve the same in 2 different ways? |
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. |
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
Additional context
No response
The text was updated successfully, but these errors were encountered: