[Bug]: Symfony HTTP Traces are not sent about dd-trace-php HOT 5 CLOSED

@PROFeNoM thanks for digging! I can see the traces in datadog UI with my local environment. I guess something is wrong with our agent in production.

I am closing and will re-open if I have more evidence.

Thanks again, much appreciated 👍

from dd-trace-php.

Hi @B-Galati,

Just to confirm, is it indeed that you don't receive any spans at all from automatic instrumentation?

When you say "traces are sent when they are going through our custom instrumentation", do you mean that automatic instrumentation spans are being sent and displayed on the Datadog UI only when using the code snippet you provided? (Thank you for providing the code snippet; it is always helpful.)

When using DD_TRACE_DEBUG=1, do you see the SymfonyIntegration loaded when receiving an HTTP request?

from dd-trace-php.

Just to confirm, is it indeed that you don't receive any spans at all from automatic instrumentation?

Exactly.

When you say "traces are sent when they are going through our custom instrumentation", do you mean that automatic instrumentation spans are being sent and displayed on the Datadog UI only when using the code snippet you provided? (Thank you for providing the code snippet; it is always helpful.)

Yes!

When using DD_TRACE_DEBUG=1, do you see the SymfonyIntegration loaded when receiving an HTTP request?

Yes, I can see it is always loaded ✔️

from dd-trace-php.

Okay, so far, I haven't been able to reproduce the issue on Symfony 6.3.

There is one thing that I want to make sure of. Looking at your phpinfo() output, I can see:

datadog.trace.symfony_enabled => Off => Off

This shouldn't be the case. By any chance, haven't you disabled Symfony through the DD_TRACE_SYMFONY_ENABLED environment variable or the datadog.trace.symfony_enabled ini? This configuration is enabled by default.

Otherwise, at that point, since you confirmed through the debug logs that the Symfony Integration was indeed loaded and that I assume you didn't see any exceptions until it eventually flushed the trace, we can look at the agent logs for something.

You can even try with a basic controller - e.g., something along the:

<?php

declare(strict_types=1);

namespace App\Controller;

use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Annotation\Route;

class DefaultController
{
    #[Route('/basic_route')]
    public function index()
    {
        return new Response('Hello world!');
    }
}

The agent log level should be set in debug mode by default. When making a request to this (or another) controller, can you see an associated agent log:

TRACE | DEBUG | (pkg/trace/writer/trace.go:242 in flush) | Serializing 1 tracer payloads.

An even more verbose mode is the trace level. If you look at this mode, do you see anything striking?

In the agent logs, we would first be looking at what's happening between the addSpans and flush function calls, i.e., between:

TRACE | TRACE | (pkg/trace/writer/trace.go:206 in addSpans) | Writer: handling new tracer payload with 7 spans:

and

TRACE | DEBUG | (pkg/trace/writer/trace.go:242 in flush) | Serializing 1 tracer payloads.

from dd-trace-php.

For anyone asking: the root was this config on our agent: DD_APM_IGNORE_RESOURCES=healthcheck,health,ping

from dd-trace-php.