[Feature] Improve phpinfo output

[NickStallman]

I've been trying to debug an issue with enabling dd-trace selectively via .htaccess and naturally I used phpinfo() to see what's going on.

Unfortunately the phpinfo() output isn't very helpful at the moment.

First I can't figure out what "Datadog tracing support: disabled" means. That string isn't found in any documentation nor is it clear why it's disabled and how to enable it from there.

Then below that it only lists three Directives.

• ddtrace.disable (which is set to off which doesn't help with telling why tracing support is disabled)
• ddtrace.request_init_hook
• ddtrace.strict_mode

Since ddtrace is largely configured by environment variables, I would have expected these to be listed also on the phpinfo() page That would make it way easier to see what ddtrace is seeing and make configuring ddtrace much easier.

This was with a fresh install of datadog-php-tracer_0.46.0_amd64.

[morrisonlevi]

Nick, can you comment a bit on how you are thinking about selectively enabling ddtrace based on .htaccess? Is this multiple sites from the same server kind of configuration, or folders on the same site? I am trying to understand the use-case.

In any case, the ini knob ddtrace.disable=1 will disable the tracer (and "Off" is probably a double negative, meaning the tracer is enabled).

[NickStallman]

I actually have this working already with version 0.40.0 on a different server. Simply adding this to the .htaccess file will enable tracing for a folder. Apache + PHP-FPM 7.4 setup.

SetEnv DD_TRACE_ENABLED true
SetEnv DD_SERVICE_NAME label_for_the_site

For some reason it doesn't want to work with 0.46 hence getting stuck and trying to use phpinfo() to debug. Might still be a config somewhere no that's not nessesarially a regression in 0.46.

The use case is we do a lot of Wordpress development and the sites get built in a single development hosting account and each project is in it's own subfolder. By allowing APM to be turned on easily via .htaccess we can pinpoint specific projects in development for profiling or debugging issues.

[SammyK]

Thanks so much for the suggestion on adding the environment variables to the phpinfo() page, @NickStallman. We haven't added that feature yet, but in the latest 0.47.0 release, we did improve the phpinfo() page to show more configuration options and diagnostic checks. That release also includes a change to the way environment variables are read (it gives priority to SAPI env vars) which might address this specific issue. Let us know if upgrading to 0.47.0 helps solves this issue.

[NickStallman]

Awesome thanks! The JSON isn't very easy to read but it certainly is better than nothing.

Although for my particular case it didn't seem to help. This appears to say it's enabled and running, but I'm getting zero traces (confirmed via tcpdump even). This is on a Wordpress site.

{
  "date": "2020-07-13T00:57:32Z",
  "os_name": "Linux web6 4.4.0-62-generic #83-Ubuntu SMP Wed Jan 18 14:10:15 UTC 2017 x86_64",
  "os_version": "4.4.0-62-generic",
  "version": "0.47.0",
  "lang": "php",
  "lang_version": "7.4.2",
  "env": null,
  "enabled": true,
  "service": null,
  "enabled_cli": false,
  "agent_url": "http://localhost:8126",
  "debug": false,
  "analytics_enabled": false,
  "sample_rate": 1,
  "sampling_rules": null,
  "tags": null,
  "service_mapping": null,
  "distributed_tracing_enabled": true,
  "priority_sampling_enabled": true,
  "dd_version": null,
  "architecture": "x86_64",
  "sapi": "fpm-fcgi",
  "ddtrace.request_init_hook": "/opt/datadog-php/dd-trace-sources/bridge/dd_wrap_autoloader.php",
  "open_basedir_configured": false,
  "uri_fragment_regex": null,
  "uri_mapping_incoming": null,
  "uri_mapping_outgoing": null,
  "auto_flush_enabled": false,
  "generate_root_span": true,
  "http_client_split_by_domain": false,
  "measure_compile_time": true,
  "report_hostname_on_root_span": false,
  "traced_internal_functions": null,
  "auto_prepend_file_configured": false,
  "integrations_disabled": null,
  "enabled_from_env": true,
  "opcache.file_cache": null
}

[labbati]

Hi @NickStallman.

The JSON isn't very easy to read but it certainly is better than nothing.

You are right, but just to provide you with some context. The JSON object is something that collects ALL the info in one unique message that can be copied and pasted either here and on a support ticket in order to avoid back and forth. As naming is consistent (for the most part) consistent across languages, this will let us build tooling to improve recreating issues. Of course any different idea is welcomed. For diagnostics checks that do not work we also print a human readable message that shows the exact problem. One feedback I can get out of your comment is: rather than printing nothing when everything seems correct, lets print something like DATADOG TRACER DIAGNOSTICS - All checks pass so it is clear that they were performed but all succeeded.

Although for my particular case it didn't seem to help. This appears to say it's enabled and running, but I'm getting zero traces (confirmed via tcpdump even).

I propose:

• short-term: I'd suggest you to open a support ticket and reference to this message, as we might setup a call with myself to understand what's going on and enable it for you. This can be done very timely. Please add a reference to this comment.
• long-term: I am very interested in understanding the actual reason you are not seeing traces and add a check into our startup logging to verify that and to print an error/check report.

Would this work for you?

[labbati]

Hi @NickStallman, did you have a chance to work with the suppor team on this? Any progress so far?

[NickStallman]

Hi @labbati no sorry not yet, I got distracted with other priorities. It's still on my todo list to get proper instrumentation working on our in-progress projects so I'm hoping to get back to it soon.