PHP Release Notes

 

Restart your web server if you have recently upgraded your agent. This will fix most reporting issues and will load the agent's new features and bug fixes.

Tuesday, June 16, 2020 - 14:00 Download

New Features

Bug Fixes

  • In some cases the newrelic-daemon got caught in an infinite loop on startup when the socket it tried to connect to was already acquired by another process. This behavior has been accounted for and fixed.
Tuesday, May 5, 2020 - 13:30 Download

Bug Fixes

  • In some cases, instrumenting Laravel queue applications while having distributed tracing turned on could potentially lead to a segfault. This has been fixed.
Wednesday, April 29, 2020 - 12:00 Download

Bug Fixes

  • In some rare cases where requests to cloud provider metadata endpoints are blocked via certain methods, the PHP Daemon logged panics from the underlying Go HTTP library. This scenario is now accounted for and handled gracefully.

Upgrade notices

  • On Linux systems, the default value for newrelic.daemon.address changed from /tmp/.newrelic.sock to @newrelic. This means that by default on Linux, agent and daemon communicate via abstract sockets instead of socket files.

  • The PHP Agent installer for Ubuntu/Debian systems now requires Python 3. Debian based distributions with Python 2 are no longer supported.

End of life notices

Wednesday, April 1, 2020 - 11:00 Download

Bug fixes

  • Under some circumstances, Drupal 8 transactions were named after generic controllers. These names were not useful for troubleshooting.

    Drupal 8 transaction naming is now improved and hooks into Symfony routing to resolve the main controller associated with a route.

Wednesday, March 25, 2020 - 13:30 Download

New Features

Support for W3C Trace Context, with easy upgrade from New Relic trace context

  • Distributed Tracing now supports W3C Trace Context headers for HTTP protocols when distributed tracing is enabled. Our implementation can accept and emit both W3C trace header format and New Relic trace header format. This simplifies agent upgrades, allowing trace context to be propagated between services with older and newer releases of New Relic agents. W3C trace header format will always be accepted and emitted. New Relic trace header format will be accepted, and you can optionally disable emission of the New Relic trace header format.
  • When distributed tracing is enabled, there are two new API function calls available that now support W3C tracestate and traceparent distributed tracing headers in addition to the New Relic distributed tracing header information:
  • When distributed tracing is enabled, you can use the new configuration setting newrelic.distributed_tracing_exclude_newrelic_header to exclude the New Relic distributing tracing header and only rely on W3C Trace Context headers.

Bug fixes

Known Issues and Workarounds

  • If a .NET agent is initiating distributed traces as the root service, you must update that .NET agent to version 8.24 or later before upgrading your downstream PHP New Relic agents to this agent release.
Tuesday, February 11, 2020 - 12:00 Download

New Features

Avoid potential memory exhaustion for long running transactions

  • The configuration settings newrelic.transaction_tracer.max_segments_cli and newrelic.transaction_tracer.max_segments_web were added. These settings can be used to limit the number of segments the PHP agent records during a CLI transaction and a web transaction respectively.

    newrelic.transaction_tracer.max_segments_cli defaults to 100000 and thus avoids potential memory exhaustion for long running CLI transactions.

    newrelic.transaction_tracer.max_segments_web defaults to 0, meaning that the PHP Agent shall capture all segments during a web transaction.

    For more information, see the documentation about the PHP agent configuration.

Performance improvements

  • The PHP agent now creates segments in a more efficient way, which results in improved performance.

Bug fixes

  • The Debian init script now uses pidof instead of ps. This solves issues related to starting the daemon with systemctl on Debian. Previously, the daemon would start and immediately stop.
Wednesday, January 22, 2020 - 10:00 Download

Bug Fixes

  • In 9.6.0, custom outbound headers added to curl requests could be silently removed if both newrelic.cross_application_tracer.enabled and newrelic.distributed_tracing_enabled are disabled. This has been fixed.
Thursday, January 16, 2020 - 11:00 Download

New Features

Enhanced visibility into curl_multi_exec calls

  • Previously, curl_multi_exec requests appeared as one segment with one total time. Now, we expose the individual segments of a curl_multi_exec request that include individual times and host details. This provides greater visibility as to which URLs are being called and improved ability to troubleshoot slow curl calls.

Configurable daemon start timeout

  • The PHP Agent has introduced a new configuration newrelic.daemon.start_timeout. Customers may use this to specify a timeout for the agent to wait for the daemon after a daemon was launched by the agent.

    With this timeout set, the agent will not immediately drop a transaction when the launched daemon hasn't acquired a socket yet, but rather grants the daemon time to do so.

    It is recommended to only set this timeout when instrumenting long-lived background tasks, as in case of daemon start problems the agent will block for the given timeout at every transaction start.

Upgrade Notice

  • For cross agent conformance, the agent attribute httpResponseCode has been renamed to http.statusCode. In PHP agent release 9.4, we erroneously introduced httpResponseCode as the replacement for response.statusCode.

    The new http.statusCode agent attribute name will align with other agents and enables standardized alerts and INSIGHTS queries based on a common attribute name.

    Attributes are reported with both the new http.statusCode name and the
    legacy httpResponseCode and response.statusCode attribute names.

    Support for legacy attribute names will be removed in future agent versions.

Known issues and workarounds

Potential memory exhaustion for long running transactions

Monday, January 6, 2020 - 11:00 Download

New Features

  • Support for Real Time Streaming

    • Event data is now sent to New Relic every five seconds, instead of every minute. As a result, transaction, error, and custom events will now be available in New Relic One and Insights dashboards in near real time. For more information on how to view your events with a five-second refresh, see the real time streaming documentation.

    • Note that the overall limits on how many events can be sent per minute have not changed. Also, span events, metrics, and trace data is unaffected, and will still be sent every minute.

  • Laravel 6 is now fully supported by the PHP agent.

Known issues and workarounds

Potential memory exhaustion for long running transactions

Wednesday, December 11, 2019 - 11:00 Download

Bug fixes

  • A potential segfault when using PHP 7.4 in connection with framework instrumentation has been fixed.

Known issues and workarounds

Potential memory exhaustion for long running transactions

Thursday, December 5, 2019 - 11:00 Download

Known issues and workarounds

Potential memory exhaustion for long running transactions

New features in 9.4

Added support for PHP 7.4

Request URI attribute is now captured

Upgrade Notices

  • For cross agent conformance, the agent attributes request.headers.User-Agent and httpResponseCode are renamed to request.headers.userAgent and response.statusCode. The value response.StatusCode is changed to an integer.
    • Attributes are reported with both the new and the legacy attribute names.
    • Support for legacy attribute names will be removed in future agent versions.

Bug Fixes

  • Since 9.0, transaction traces and span events were not created when newrelic_end_transaction was called inside a PHP function. newrelic_end_transaction now creates transaction traces and span events in any case. It reports all traces and span events for segments that weren't ended at the time of its invocation as unknown.

  • Since 9.0, Predis calls weren't instrumented when the Predis client was loaded from a path ending in Predis/Client.php. This has been fixed.

  • For inbound distributed tracing payloads with invalid or missing values for pr (priority) and/or sa (sampled) the agent used to assign a default priority of -1 and/or a default sampled value of false to the transaction.

    • This has been fixed, the agent now keeps initial priority and sampled values if the respective values in the inbound distributed tracing payload are missing or invalid.
  • The daemon used to erroneously send SIGUSR1 signals to its parent process group in case one of the flags --foreground or --watchdog-foreground was given. This has been fixed.

Monday, November 11, 2019 - 14:00 Download

Known issues and workarounds

Potential memory exhaustion for long running transactions

New features in 9.3

Trace and entity metadata API calls

  • A new API function newrelic_is_sampled() has been added. This call returns true if the current transaction is part of a sampled distributed trace.

  • A new API function for obtaining linking metadata been added. newrelic_get_linking_metadata(). This call returns an opaque map of key/value pairs that can be used to correlate this application to other data in the New Relic backend.

  • A new API function newrelic_get_trace_metadata() has been added. This call returns a collection of metadata used to identify a trace: trace.id, which provides the currently executing trace's identifier; and span.id, which provides the span identifier associated with the currently executing span.

Configurable connection timeout

  • The PHP agent has introduced a new configuration newrelic.daemon.app_connect_timeout. Customers may use this to specify a timeout for the agent to wait for a daemon connection.

    With this timeout set, the agent will not immediately drop a transaction when the daemon hasn't connected to the backend yet, but rather grant the daemon time to establish the connection.

    It is recommended to only set this timeout when instrumenting long-lived background tasks, as in case of connection problems the agent will block for the given timeout at every transaction start.

Monday, October 7, 2019 - 14:00 Download

New features in 9.2

More flexibility for container deployments

  • The PHP daemon and agent no longer have to reside on the same host and can now communicate over a IPv4 or IPv6 TCP socket. This can be configured via the newrelic.daemon.address setting in the agent and the --address command line option for the daemon.

  • When terminating the New Relic PHP daemon via the SIGTERM signal (and/or the SIGINT signal if started with the -f, --foreground flag), the daemon will now send all buffered data to New Relic prior to exiting.

  • The PHP daemon has introduced a new configuration --watchdog-foreground. This keeps the daemon watchdog process in the foreground, whereas the --foreground configuration keeps the daemon worker process in the foreground. The new configuration makes it possible to use the daemon in a blocking way, without losing the additional stability provided by the watchdog process.

Upgrade notices

  • The PHP agent has introduced a new configuration newrelic.daemon.address which serves as an alias to newrelic.daemon.port. You may use either to specify the location of the New Relic PHP daemon. If both values are set, newrelic.daemon.address takes precedence.

    Similarly, the PHP daemon has introduced a new configuration --address which serves as an alias to --port. Customers may use either to specify the location of the New Relic PHP daemon. If both values are set, --address takes precedence.

  • When starting the daemon as an external process, the daemon will now wait for up to three seconds for the listening port to be ready to receive connections before forking into the background. This usually occurs in (much) less than a second, and most users with this configuration will notice no difference in practice.

    The time that the daemon will wait can be controlled by setting the --wait-for-port setting with a duration. This duration may be 0 to prevent any blocking. If the option is omitted, the default value is 3s.

    Note that this is not the default configuration shipped with the PHP agent, and generally is only used in conjunction with the PHP agent configured with newrelic.daemon.dont_launch set to 3.

    Daemons started in foreground mode (with the --foreground flag) are unaffected, and will behave as before.

Bug fixes

  • When duplicating database connections to generate explain plans, the agent will no longer make those connections persistent, even if the original connection was persistent.

  • The daemon now synchronously handles critical code paths related to harvesting and merging transaction data. This prevents crashes caused by race conditions.

  • Previously, the PHP agent was silently ignoring the setting newrelic.daemon.port if the value was outside of the range 1 - 65535. In this case, it used the default value of /tmp/.newrelic.sock. The PHP agent no longer silently ignores these port values; it now logs these errors in php_agent.log.

Known issues and workarounds

  • Potential memory exhaustion for long running transactions. See description under Known issues and workarounds in the PHP 9.0.0.242 release notes.
Wednesday, September 4, 2019 - 10:30 Download

New Features in 9.1

Symfony 4 support added.

  • Web transactions that use the Symfony 4 framework will now be automatically named based on the route or controller name.

Addition of the ability to migrate to Configurable Security Policies (CSP) on a per agent basis for accounts already using High Security Mode (HSM).

  • When both HSM and CSP are enabled for an account, an agent (this version or later) can successfully connect with either high_security: true or the appropriate security_policies_token configured.

Upgrade notices

  • Requests handled by PHP-FPM that result in a 404 error because the script does not exist, or a 403 error because PHP-FPM does not have permission to access the script, will now result in a transaction called 404 or 403, respectively, rather than being named after the request URI. This change was made to prevent metric grouping issues, particularly when sites are being probed by potential attackers.

    If you wish to capture the actual request URI for analysis, it can be attached to the transaction event under the request.uri attribute using the following configuration setting: newrelic.transaction_events.attributes.include=request.uri

Bug fixes

  • In version 9.0, Guzzle and Predis execution time could be double counted on application overview and transaction charts in APM, as time could be attributed to both PHP execution and the external or datastore time, respectively. This has been fixed, and charts should now revert back to their previous behavior.

  • Restarting a transaction from within a Drupal or WordPress hook could result in a segfault. This has been fixed.

Known issues and workarounds

  • Potential memory exhaustion for long running transactions. See description under Known issues and workarounds in the PHP 9.0.0.242 release notes.
Monday, August 19, 2019 - 10:30 Download

Notes

  • A bug that could result in segfaults when transactions were restarted (either directly through newrelic_start_transaction() or indirectly through newrelic_set_appname()) was fixed.

    This also affected customers using Laravel Queue instrumentation, as this uses transaction restarts internally.

  • PHPUnit may not have been detected on case sensitive filesystems on 9.0.0. This has been fixed.

  • A bug that could result in segfaults for CodeIgniter applications on PHP 7 when call_user_func_array() inlining failed was fixed.

Known issues and workarounds

  • Potential memory exhaustion for long running transactions. See description under Known issues and workarounds in the PHP 9.0.0.242 release notes.
Thursday, August 8, 2019 - 11:30 Download

New features in 9.0

Detailed transaction traces now available when distributed tracing is enabled.

This release includes a refactor of segment storage to allow the agent to sort and apply different prioritization of segments that are used for transaction traces instead of distributed tracing. The PHP agent 8.4 release included limited support for distributed tracing, which resulted in the loss of detailed transaction traces for individual PHP services when distributed tracing was enabled.

The refactor in this new release allows the agent to send up the segments (spans) you want to view for a distributed trace that includes PHP services. It also separately provides as much segment detail as possible when exploring transaction traces for an individual PHP service.

Notes:

  • The instructions to enable distributed tracing have not changed with this release.
  • The behavior of newrelic.transaction_tracer.detail has changed when distributed tracing is on. In the 8.4 - 8.7 PHP agent releases, newrelic.transaction_tracer.detail was disabled when distributed tracing was enabled. That is no longer the case. For more information, see the documentation for configuring trace level detail when using distributed tracing.
  • To enable the improved support for distributed tracing, the PHP agent's memory allocation strategy has changed in 9.0. The PHP agent will more aggressively allocate memory when a transaction starts, and the system allocator may choose not to release that memory back to the operating system immediately, depending on the configuration of the operating system kernel and C library. As a result, the memory usage of the PHP processes may now be higher than it was with previous versions of the PHP agent.

Upgrade notices for 9.0

With these distributed tracing enhancements, please check threshold values.

  • In the 8.4 - 8.7 PHP agent releases, we recommended that customers set newrelic.transaction_tracer.threshold = 0 so that the agent would report complete distributed traces even when a lightweight PHP service was part of the trace. This is no longer necessary.
  • When upgrading to the 9.0 release, we recommend that you review your newrelic.transaction_tracer.threshold settings, and return this value to its default or some higher value that is sensible for the application.

The daemon will now issue a warning if it cannot find a root certificate bundle on startup.

  • The daemon includes its own certificates and will still operate, but a future version of the PHP agent will remove the built-in certificates. At that point the PHP agent will not be able to communicate with New Relic's servers.
  • Recommendation: Ensure a root certificate bundle is installed on your host or in your container before using the PHP agent. This is generally available on most Linux distributions as a ca-certificates package. On FreeBSD, a bundle is available via the security/ca_root_nss package in ports.

The daemon may no longer be invoked with the --tls flag.

  • As of PHP agent version 8.0.0 the newrelic.daemon.ssl ini setting had been removed to increase security, but you could still invoke the daemon from the command line with --tls true. Command-line invocations of the daemon with the --tls flag will cause the invocation to fail.
  • As with all PHP agent versions since 8.0.0, TLS is always used for communication with New Relic servers.

Bug fixes

  • A potential segfault when using drupal_http_request under PHP 7.3 has been fixed.
  • In some cases, starting a new transaction during a request (via newrelic_start_transaction or newrelic_set_appname) could result in an incomplete state of framework and user function instrumentation.
  • When obfuscating SQL, comments are stripped without any loss of the SQL itself.
  • Predis 0.8 commands that used the synchronous executeCommand() code path (for example, HSET) on a clustered connection did not generate metrics. This has been fixed.

Known issues and workarounds

Potential memory exhaustion for long running transactions

PHP agent 9.x uses more memory than previous versions, as it is less aggressive about freeing the memory used to track function calls and segments during transactions: in the normal case, memory is only freed at the end of each transaction.

This tends to manifest mainly for users with long running transactions, such as background jobs to process message queues, transform or report on data, or send e-mails.

We apologize for the inconvenience this issue has caused, and are actively working to fix it. In the short term, we have four potential workarounds to mitigate this issue.

Workarounds:

  • 1. Start/stop transactions manually. If the affected transaction is one that performs a series of repetitive processes, such as a message queue consumer, you can manually instrument each iteration as a separate transaction. This provides you more fine-grained data on how the process is operating. By doing this, the memory used will be freed after each transaction. To implement this, you would ignore the initial automatic transaction with newrelic_end_transaction(true), then use newrelic_start_transaction()and newrelic_end_transaction() to instrument each transaction in turn.

  • 2. Reduce transaction trace detail. If you will need PHP 7.4 immediately, or any of the functionality added in the PHP agent 9.x releases, and can get by with traces only including information on datastore and external calls, then you can reduce the level of detail the PHP agent captures by changing this configuration setting: newrelic.transaction_tracer.detail = 0. With this setting, traces will no longer contain PHP function calls. NOTE: Transactions that make hundreds of thousands of datastore or external calls may still be affected by memory issues.

  • 3. Downgrade to PHP agent 8.7. If you don’t intend to use PHP 7.4 immediately, this is likely the simplest and fastest solution. To downgrade, you can either install from the tarballs at https://download.newrelic.com/php_agent/archive/8.7.0.242/, or downgrade to version 8.7.0.242 in your package manager and pin that version. Note that if distributed tracing is enabled on PHP agent 8.7, transaction tracer detail is automatically reduced (as per the next option).

  • 4. Cap the # of function segments that are created (stay on PHP agent 9.x). This is similar to the “reduce transaction trace detail” option, but also allows for a limited number of PHP function calls to be traced, at the cost of an increase in memory usage commensurate with the number of functions that are captured. (As a rough rule of thumb, each segment requires about 320-400 bytes of the heap.) To capture the first 5,000 function calls, you would add this configuration setting: newrelic.transaction_tracer.max_segments = 5000. With this setting, any PHP functions after the number of function calls that are configured will be ignored. NOTE: Transactions that make hundreds of thousands of datastore or external calls may still be affected by memory issues.

**NOTE: A more detailed explanation of these options can be found in our Explorer’s Hub post.

Thursday, March 14, 2019 - 11:35 Download

Bug Fixes

  • Transaction globals are now cleanly separated from request globals. This fixes crashes related to the initialization of multiple transactions during one request (mostly triggered by newrelic_set_appname()).
Thursday, March 14, 2019 - 02:00 Download

New Features

  • Support Laravel's handling of CORS HTTP OPTIONS.
    Requests for Laravel's built-in automatic handling of CORS HTTP OPTIONS requests will now be given the transaction name _CORS_OPTIONS.

Bug Fixes

  • A potential segfault when using PHP 7.3, opcache and multiple PHP workers has been fixed.
  • Uncaught exceptions within a job being executed by a Laravel Queue worker are now reported correctly.
  • Invoking function_exists() on a function disabled with the disable_functions configuration directive will now correctly return false.
Wednesday, December 19, 2018 - 01:00 Download

New Features

  • Added support for PHP 7.3.
    Keeping up with the latest and greatest from the PHP Core team, the New Relic PHP Agent now supports PHP 7.3.
  • Distributed Tracing Improvements!
    The PHP Agent's Distributed Tracing support (introduced in version 8.4 of the PHP Agent) now includes the `http.method` attributes for External spans.
  • Up to date PHPUnit support.
    The PHP Agent now supports automatic creation of custom events for PHPUnit 6, PHPUnit 7, and PHPUnit 8. You can read more about PHPUnit support (and more) over on the New Relic Blog.
Wednesday, December 5, 2018 - 11:00 Download

New Features

  • Support for Distributed tracing

    Distributed tracing lets you see the path that a request takes as it travels through your distributed system. By showing the distributed activity through a unified view, you can troubleshoot and understand a complex system better than ever before.

    Distributed tracing is available with an APM Pro or equivalent subscription. To see a complete distributed trace, you need to enable the feature on a set of neighboring services. Enabling distributed tracing changes the behavior of some New Relic features, so carefully consult the transition guide before you enable this feature.

    To enable distributed tracing, two parameters should be changed in the newrelic.ini file:
    newrelic.distributed_tracing_enabled = true
    and
    newrelic.transaction_tracer.threshold = 0

    Read more about about distributed tracing in the PHP Agent.

Bug Fixes

  • A bug in the PHP agent resulted in databaseCallCount attributes no longer being attached to Transaction events. The 8.4 release restores these attributes.
  • Predis 2 cluster connections could not be instrumented due to internal changes in Predis. The 8.4 release fixes this.

Pages