Closed pdelewski closed 1 year ago
I think that the problem here is a race condition specific to the WordPress auto-instrumentation: it tries to start a span (ie actually use the SDK) as part of its autoloading initialisation. A solution might be to instead of prepending the composer autoloader (eg in .htaccess
) we instead prepend a php file which runs the autoloader and then starts that span. I think that will ensure that everything is loaded and available before anything tries to use the SDK.
Describe your environment PHP 8.2.1 (cli) (built: Jan 12 2023 19:14:53) (NTS) Copyright (c) The PHP Group Zend Engine v4.2.1, Copyright (c) Zend Technologies with Zend OPcache v8.2.1, Copyright (c), by Zend Technologies
Steps to reproduce
composer create-project slim/slim-skeleton:dev-master slimauto
composer require opentelemetry-api, opentelemetry-sdk, opentelemetry-sdk-contrib, opentelemetry-auto-wordpress
cd slimauto
export OTEL_PHP_AUTOLOAD_ENABLED=true
export OTEL_TRACES_EXPORTER=zipkin
export OTEL_EXPORTER_ZIPKIN_ENDPOINT=http://localhost:9411/api/v2/spans
export OTEL_PHP_TRACES_PROCESSOR=simple
php -S localhost:8080 -t public public/index.php
or follow steps described https://github.com/open-telemetry/opentelemetry-php-instrumentation/tree/main/bin
What is the actual behavior? What did you see instead?
Additional context
I tried to use zipkin exporter. The problem seems to be related to autoload order as composer loads auto instrumentation packages before sdk and contrib. For instance
I solved that (brute force solution) by adding into
opentelemetry-auto-wordpress\_register.php
before creating
CachedInstrumentation
instance, but it's not proper solution.