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

[symfony-auto-instrumentation] Split package into different packages #1365

Open
joaojacome opened this issue Aug 22, 2024 · 3 comments
Open

Comments

@joaojacome
Copy link
Contributor

Due to the possibility of using Symfony components on non-Symfony projects, I'd like to propose splitting the current Symfony Auto-instrumentation package into three different packages:

  • opentelemetry-auto-symfony-messenger
  • opentelemetry-auto-symfony-http-kernel
  • opentelemetry-auto-symfony-http-client

The existing opentelemetry-auto-symfony would become a meta-package for the new packages.

This will allow us to selectively enable those instrumentations.

@brettmc
Copy link
Collaborator

brettmc commented Aug 23, 2024

If the main goal is to be able to enable/disable different parts of the auto-instrumentation, then does it help to know that open-telemetry/opentelemetry-configuration#91 is coming, which will allow fine-grained configuration of auto-instrumentation?
Once we get v1.1 tagged of our core packages, we plan to move auto-instrumentation packages across to supporting this type of configuration. There's an example of how this works: https://github.com/open-telemetry/opentelemetry-php/tree/main/examples/src

@joaojacome
Copy link
Contributor Author

Looks like that would work too, I'm happy with that :)

Although, I still think the Symfony packages should be split in different packages, as they actually instrument different components.

@dkarlovi
Copy link
Contributor

dkarlovi commented Oct 7, 2024

IMO splitting the packages too much creates too much overhead, configuration is preferable.

Symfony itself uses Framework bundle as a catch all instrumentation for a bunch of components, not each component gets a dedicated bundle. I don't see why OTEL instrumentation wouldn't do the same.

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

No branches or pull requests

3 participants