![]() ![]() /opt/datadog-php/dd-trace-source/bridge/_generated_api.php.If we look into the library's source code, we will find the same namespace ( DDTrace) defined a few times. Even though they theoretically should have. But while figuring it out, I placed a few breakpoints here and there inside the library's code, only to find out the execution had never reached some of them. TL DR - I forgot to enable Datadog for CLI. And it revealed that the tracer that got loaded was a \ DDTracer\NoopTracer. We also have to map the local path to the remote path:Īt this point, our breakpoints with our code worked as expected. datadog_bridge:/opt/datadog-php/dd-trace-sources/bridgeĭevice: '/home/alex/Projects/datadog-debugging/var/datadog_bridge' docker/99-xdebug.ini:/usr/local/etc/php/conf.d/99-xdebug.ini docker/99-ddtrace-custom.ini:/usr/local/etc/php/conf.d/99-ddtrace-custom.ini Here is a minimalistic docker-compose.yml I used to depict how it works: So how do we get this mapped inside PhpStorm? Since this path is inside the container, we need to use a named volume to share it with the host. That glue code is in /opt/datadog-php/dd-trace-source/bridge. It turns out that PHP's Datadog extension has some glue code being executed at the beginning of each request. opt/datadog-php/dd-trace-sources/bridge/dd_wrap_autoloader.php A quick find in the container revealed this: find / -type f -name "dd_wrap_autoloader.php" I thought it was a path somewhere in datadog/dd-trace library. So, the file name is dd_wrap_autoloader.php. Though PhpStorm wasn't very helpful here: Because I had PhpStorm configured to stop on the first line if a file is outside of the project, it meant I didn't map some paths properly. The first thing I noticed was that the code stopped before reaching the breakpoints. But as we all know - xdebug is your best friend when looking for issues in code. I wrote some tests and simple implementation. You might get some residues from the previous tests that interfere with the following tests. Return new \DDTrace\OpenTracer1\Tracer(new \DDTrace\Tracer()) Īnd make sure you run your integration tests in separate processes. You may want to have a function that will create an appropriate tracer for you: private function createTracer(): \OpenTracing\Tracer The same is true when writing integration tests. \OpenTracing\GlobalTracer::set($otTracer) $otTracer = new \DDTrace\OpenTracer1\Tracer(\DDTrace\GlobalTracer::get()) Instantiate the DD tracer ( datadog/dd-trace) and set it as a global tracer with the OpenTracing library ( opentracing/opentracing): require _DIR_. To make the whole implementation more flexible for the future, we opted to implement the OpenTelemetry standard. That required us to write some shared code used across all microservices. At Foodist, we decided to monitor our new services with Datadog. I've only recently had my first encounter with Datadog. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |