[Bug]: Laravel named traces support

[247software-sanket-gandhi]

Bug report

While evaluating datadog, I came across traces where it does not identify API calls properly. In traces it either shows Closure unnamed_route or laravel.event.handle.

We have routes in api.php as follows (btw, we are using API gateway so that's why we have generic routes in laravel).

    // for every HTTP method we have below route
    Route::post('{dir}/{controller}/{action}', function ($dir, $controller, $action) {
        return app()->make('App\Http\Controllers\\' . $dir . '\\' . $controller)->$action();
    });

    // another version of above route
    Route::get('{dir}/{subdir}/{controller}/{action}', function ($dir, $subdir, $controller, $action) {
        return app()->make('App\Http\Controllers\\' . $dir . '\\' . $subdir . '\\' . $controller)->$action();
    });

What configuration do I need to change so that the DD agent can interpret these routes?

For e.g., In newrelic we used to do this -

if (extension_loaded ('newrelic')) {
    newrelic_name_transaction(current(explode('?', $_SERVER['REQUEST_URI'])));
}

PHP version

7.3.3

Tracer or profiler version

0.90.0

Installed extensions

[PHP Modules] apcu bz2 calendar Core ctype curl datadog-profiling date ddappsec ddtrace dom exif fileinfo filter ftp gd gettext hash iconv igbinary imagick json libxml mbstring mcrypt memcache memcached mongodb msgpack mysqli mysqlnd newrelic openssl pcntl pcre PDO pdo_mysql pdo_pgsql pdo_sqlite pgsql Phar posix readline redis Reflection session shmop SimpleXML soap sockets SPL sqlite3 standard sysvmsg sysvsem sysvshm tokenizer wddx xml xmlreader xmlrpc xmlwriter xsl Zend OPcache zip zlib

[Zend Modules] Zend OPcache datadog-profiling ddappsec ddtrace

Output of phpinfo()

No response

Upgrading from

No response

[PROFeNoM]

Regarding the API calls, I think you're looking for DD_HTTP_SERVER_ROUTE_BASED_NAMING=0. These API calls should change from Closure unnamed_route to GET <the accessed uri>.

Regarding the laravel.event.handle problem, could you provide more information? Are you unable to see any resource or service associated with the span? Does this issue occur for all laravel.event.handle spans or just specific ones? Or is it a different problem entirely?

Thanks!

[247software-sanket-gandhi]

Thanks, @PROFeNoM! DD_HTTP_SERVER_ROUTE_BASED_NAMING worked and it is showing all APIs now. I was not able to find this configuration anywhere in the documentation of php traces.

For laravel.event.handle, I see web.request service and in that, there is laravel.event.handle. I'm not sure what exactly it means.

One more question, do I need to do any configuration for logs to appear for particular traces?

[PROFeNoM]

Hey :wave:

I think that I see what's happening with the web.request laravel.event.handle spans, but just to be sure, if you look at the related traces, are these exclusively located at the beginning of a trace? I'll find a fix as soon as possible.

Regarding the logs, I am surprised that you don't experience any correlation with the traces out-of-the-box; that's concerning... Although logs correlation should work for line-formatted messages, it best works when using the Json formatter. You can use the json format by adding the following key/value to your log channels:

'formatter' => Monolog\Formatter\JsonFormatter::class,

By the way, do you receive logs for your application (under the Logs tab)? 😃

If the above doesn't work, do you have any errors appearing? There is a bug that will be fixed in the next version that can impede the proper correlation of traces atm (#2174).

Otherwise, are there any exceptions when setting DD_TRACE_DEBUG=1?

Thanks!

[247software-sanket-gandhi]

Hi @PROFeNoM,

I checked web.request laravel.event.handle span, it is not present at the top of the trace. There is another API call present and after that laravel.event.handle is present. I'm not sure what exactly it is since API does not have any kind of event.

Regarding logs, I have enabled below config in datadog.yaml file

logs_enabled: true

and I have below configuration set in /etc/php-fpm.d/www.conf

; other configurations ...

env[DD_HTTP_SERVER_ROUTE_BASED_NAMING] = 0
env[DD_LOGS_INJECTION] = 1

I do not see logs at all in logs tab. I will check by enabling DD_TRACE_DEBUG and get back.

Thanks

[247software-sanket-gandhi]

Logs are working now, there was a configuration issue on my end. Now only JSON format and correlation with trace are left.

[PROFeNoM]

Hey @sanketgandhi876 :wave:

So I've made an artifact (CI job) regrouping two PRs that may address your issues (#2235 & #2236). Could you please try it out? 😃

When using logs correlation with a JSON format, there shouldn't be any tracer configuration required on your end - that's the goal. That's why I suspect the compatibility issue fixed with #2236 was your problem here.

FYI, to install the artifact, if you followed the extension installation doc, simply change the URL of the official installer by the URL of the artifact and you're good to go :+1:

[247software-sanket-gandhi]

It worked! @PROFeNoM!

I have verified with new artifact and it started showing logs for all traces.

Additionally, I see laravel.event.handle is under proper services -

---

Thank you for the quick fixes. I wanted to know when these fixes will be released?

[morrisonlevi]

The fixes have been merged. They will be included in our next release, which should land sometime next week unless we find issues during the release process (rare).

[PROFeNoM]

These fixes have been released with 0.91.0 😃