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

Exporters not loaded when using auto root span #1410

Open
xvilo opened this issue Oct 17, 2024 · 2 comments
Open

Exporters not loaded when using auto root span #1410

xvilo opened this issue Oct 17, 2024 · 2 comments
Labels
bug Something isn't working

Comments

@xvilo
Copy link
Contributor

xvilo commented Oct 17, 2024

Describe your environment

Steps to reproduce

  • Add the auto_root_span.php example script to the public dir of my project
  • Run it with the php -S command from the script
  • Change the putenv OTEL_TRACES_EXPORTER to otlp
  • Then curl to the page I see the following logs in the console:

What is the expected behavior?
What did you expect to see?
It either:

  • Working
  • Giving errors about no OTLP exporter config being added

What is the actual behavior?
It can't load the OLTP exporter as a whole

$ php -S localhost:8080 test_otel.php
[Thu Oct 17 08:56:52 2024] PHP 8.3.12 Development Server (http://localhost:8080) started
[Thu Oct 17 08:56:55 2024] [::1]:44470 Accepted
[Thu Oct 17 08:56:55 2024] OpenTelemetry: [warning] Error during opentelemetry initialization: Span exporter factory not defined for: otlp
#0 /my_project_location/vendor/open-telemetry/sdk/Trace/ExporterFactory.php(28): OpenTelemetry\SDK\Registry::spanExporterFactory()
#1 /my_project_location/vendor/open-telemetry/sdk/SdkAutoloader.php(87): OpenTelemetry\SDK\Trace\ExporterFactory->create()
#2 /my_project_location/vendor/open-telemetry/sdk/SdkAutoloader.php(62): OpenTelemetry\SDK\SdkAutoloader::environmentBasedInitializer()
#3 /my_project_location/vendor/open-telemetry/api/Globals.php(93): OpenTelemetry\SDK\SdkAutoloader::OpenTelemetry\SDK\{closure}()
#4 /my_project_location/vendor/open-telemetry/api/Globals.php(43): OpenTelemetry\API\Globals::globals()
#5 /my_project_location/vendor/open-telemetry/sdk/Trace/AutoRootSpan.php(39): OpenTelemetry\API\Globals::tracerProvider()
#6 /my_project_location/vendor/open-telemetry/sdk/SdkAutoloader.php(69): OpenTelemetry\SDK\Trace\AutoRootSpan::create()
#7 /my_project_location/vendor/open-telemetry/sdk/_autoload.php(5): OpenTelemetry\SDK\SdkAutoloader::autoload()
#8 /my_project_location/vendor/composer/autoload_real.php(43): require('...')
#9 /my_project_location/vendor/composer/autoload_real.php(47): {closure}()
#10 /my_project_location/vendor/autoload.php(25): ComposerAutoloaderInit075534cb7854c559e471b4339a4e7714::getLoader()
#11 /my_project_location/public/test_otel.php(26): require('...')
#12 {main} in /my_project_location/vendor/open-telemetry/api/Globals.php(95)
[Thu Oct 17 08:56:55 2024] [::1]:44470 Closing

Additional notes?

From my debugging this happens because:
The auto root span _register.php is loader earlier in the chain then the _register.php of the oltp exporter, not sure if it's alphabetical or something else in composer?
The auto root span kicks of everything in the sdk package, and then also tries to set up the tracer
The tracer has an in memory list of registered exporters, which is usually filled through the _register.php scripts.
As that didn't happen yet, the exporter does not exist (yet)

If it were to used as a class, e.g. a list of predefined FQCN's then it could work since it would kick in the class loader in the background.

So you either need to find a way to chain these dependencies (don't think there is a composer way), or, from the tracer factory stuffs, directly depend on a list of predefined classes as a fallback. That could work, but will give some overhead if no authoritative classmap is used

@xvilo xvilo added the bug Something isn't working label Oct 17, 2024
@IAmAndre
Copy link

IAmAndre commented Oct 28, 2024

Hi @xvilo . Has there been any update/workaround regarding this issue?

@xvilo
Copy link
Contributor Author

xvilo commented Oct 28, 2024

Uhm, work is being done on this so it isn’t an issue anymore. (#1412) Another work around for now would be to change the order of the dependencies in your composer.json, and then to dump the autoloader again

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants