newrelic / newrelic-php-agent

The New Relic PHP Agent

New Relic PHP agent

The New Relic APM PHP agent monitors your application to help you identify and solve performance issues. The PHP agent consists of a PHP extension (which collects data from your application) and a local proxy daemon (which transmits the data to New Relic).

Installation

The PHP agent supports many of the most common PHP releases, PHP frameworks, databases, and libraries. Prior to installation, please ensure your system meets the compatibility requirements.

To get started with installation, see the PHP Agent installation documentation. The PHP agent pre-built package includes the interactive newrelic-install script, which automates some installation tasks. Also, see our advanced installation documentation for Docker or other container installations.

Getting Started

See our Introduction to New Relic for PHP to learn how to use the PHP agent with your application.

Building and Testing

For instructions on how to build and test the agent, please see our development guide.

Support

Should you need assistance with New Relic products, you are in good hands with several support diagnostic tools and support channels.

Troubleshooting

For help with framework troubleshooting, this guide steps you through common framework troubleshooting questions.

New Relic offers NRDiag, a client-side diagnostic utility that automatically detects common problems with New Relic agents. If NRDiag detects a problem, it suggests troubleshooting steps. If you have a New Relic Support Plan, NRDiag can also automatically attach troubleshooting data to a New Relic Support ticket.

If the issue is confirmed as a bug or is a feature request, please file a GitHub issue.

Support Channels

• New Relic Documentation: Comprehensive guidance for using our platform
• New Relic Community: The best place to engage in troubleshooting questions
• New Relic Developer: Resources for building a custom observability applications
• New Relic University: A range of online training for New Relic users of every level
• New Relic Technical Support 24/7/365 ticketed support. Read more about our Technical Support Offerings.

Privacy

At New Relic we take your privacy and the security of your information seriously. We are committed to protecting your information and must emphasize the importance of not sharing personal data in public forums. We ask all users to scrub logs and diagnostic information for sensitive information, whether personal, proprietary, or otherwise.

We define "Personal Data" as any information relating to an identified or identifiable individual, including, for example, your name, phone number, post code or zip code, Device ID, IP address, and email address.

Please review New Relic’s General Data Privacy Notice for more information.

Contributing

We encourage your contributions to improve New Relic's PHP agent! Keep in mind when you submit your pull request, you'll need to sign the CLA via the click-through using CLA-Assistant. You only have to sign the CLA one time per project. If you have any questions, or to execute our corporate CLA, required if your contribution is on behalf of a company, please drop us an email at [email protected].

A note about vulnerabilities

As noted in our security policy, New Relic is committed to the privacy and security of our customers and their data. We believe that providing coordinated disclosure by security researchers and engaging with the security community are important means to achieve our security goals.

If you believe you have found a security vulnerability in this project or any of New Relic's products or websites, we welcome and greatly appreciate you reporting it to New Relic through HackerOne.

If you would like to contribute to this project, please review these guidelines.

To all contributors, we thank you! Without your contribution, this project would not be what it is today. We also host a community project page dedicated to the New Relic PHP agent.

License

The PHP agent is licensed under the Apache 2.0 License and also uses source code from third-party libraries. You can find full details on which libraries are used and the terms under which they are licensed in the third-party notices document.

newrelic-php-agent's Issues

PHP 8.0: Update version of libxml used by NRLAMP

Summary

The version of libxml in nrlamp needs to be upgraded. This ticket is part of issue #32.

Desired Behavior

• The version of libxml installed by nrlamp is version 2.9.0 or later.
• PHP 5.2 and PHP 5.3 are removed from our jenkins jobs (see below for why this is included in this ticket).

Pre-reqs and dependencies

• All of our jenkins jobs are will need to be updated to remove at least PHP 5.2 since it will not build with libxml 2.9.0+.
• Since both 5.2 and 5.3 are now EOL, we might as well remove PHP 5.3 as part of this ticket.

Additional context

See the MMF doc for more details.

Laravel 7 - transaction names saved as UUIDs rather than class & function

Description

Seems like transaction names are not being saved ever since upgrading to Laravel 7.

Instead, they appear like this: generated::AhiRBYxyLAmfeypt.

Steps to Reproduce

Install the agent on a server running Laravel 7.

Expected Behavior

I would expect to see the full class name / path + function being called.

Additional context

I opened a ticket on the discussion forums here:

https://discuss.newrelic.com/t/php-transactions-no-longer-showing-correct-namespace-class-function-details/121752/6

Someone answered mentioning that Laravel 7 upgrade may be the issue, but I also see that Laravel 7 is on the list of supported frameworks:

https://docs.newrelic.com/docs/agents/php-agent/getting-started/php-agent-compatibility-requirements#frameworks

Laravel 4.x, 5.x, 6.x, and 7.x

Use transaction id on start_transaction / stop_transaction()

Summary

Are there any plans to add any kind of transaction identifier in start_transaction()\end_transaction()?
In the current implementation, there is only boolean being returned and this means that we cannot finish an exact transaction and only have to believe that by calling end_transaction() it will stop the one we want. It works in a typical PHP application as it is single-threaded but doesn’t work when it comes to applications that stay in-memory (either CLI or web).
F.e. in C implementation, on start transaction it returns a pointer to the transaction that can be used later to stop exactly this one transaction.

Possible Solution

Return any kind of identifier. Either string with id or just a pointer to the transaction.

Additional context

We have two use cases where it is important: swoole based web API and CLI based multi-thread application

PHP 8 - Address Apache naming changes

Summary

The naming scheme of the Apache module has changed from php7_* to php_*. Account for this when PHP 8 headers are used.

Desired Behavior

• Apache based applications are correctly instrumented on PHP 8 machines.
  • Easiest test would be to use the php8/apache docker images, and pull up phpinfo
• Older versions of PHP continue to function correctly.

9.16: Docs

Part of #77

GitHub and docs.newrelic.com documentation (release notes, etc)

Virtuoso: Remaining recipes not covered by MVP

The Virtuoso work is broken down into three MMFs, of which this is the 2nd, as described in MMF doc

9.16: Agent Release Tasks

Top level agent release ticket

• 9.16: Docs
• 9.16: Cross-Platform Installation and Sanity Testing
• 9.16: Stability Testing
• 9.16: Performance Testing

9.16: Performance Testing

Part of #77

Simple Performance, throughput per second over five runs, using cross_version_arena docker image:

PHP 7.2.13 (cli) (built: Dec 10 2018 14:26:50) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies

===================================================================
Benchmark phpinfo
===================================================================
I    disabled  8.1.0.209  8.2.0.221  8.3.0.226  8.4.0.231  8.5.0.234
1/4  1123.84   507.57     505.52     503.75     493.39     494.01
2/4  1146.58   506.69     504.68     503.50     493.65     495.75
3/4  1137.86   506.87     503.66     502.23     492.19     493.67
4/4  1138.32   507.40     503.71     502.56     492.91     494.64

===================================================================
Benchmark laravel
===================================================================
I    disabled  8.1.0.209  8.2.0.221  8.3.0.226  8.4.0.231  8.5.0.234
1/4  20.58     19.80      19.70      19.77      19.77      19.67
2/4  20.74     19.70      19.80      19.77      19.74      19.79
3/4  20.68     19.77      19.75      19.68      19.69      19.78
4/4  20.68     19.78      19.74      19.76      19.69      19.63

Expose newrelic_set_transaction_timing to PHP

This could be a great possibility to measure a time on our own and just send it

Summary

Desired Behavior

The method newrelic_set_transaction_timing(float $timing) should be provided by PHP agent and set the timing of the transaction, completely the same way as in C SDK

Guzzle 6 Middleware pushed multiple times, reaching max recursion

Description

I am using Google_Client with Google_Service_MyBusiness and my cron jobs are failing since adding the PHP agent because it's Guzzle 6 middleware ends up being duplicated multiple times as I make requests to the Google APIs, which causes hundreds of instances of newrelic\Guzzle6\middleware to be present in Guzzle's HandlerStack, resulting in my code reaching the max recursion limit set in XDebug.

Steps to Reproduce

Example with the books API (happens with any Google API)

$client = new \Google_Client();
$client->setApplicationName("Client_Library_Examples");
$client->setDeveloperKey("YOUR_API_KEY");

$service = new \Google_Service_Books($client);
$results = $service->volumes->listVolumes('Henry David Thoreau', array('filter' => 'free-ebooks'));
$results = $service->volumes->listVolumes('Henry David Thoreau', array('filter' => 'free-ebooks'));
$results = $service->volumes->listVolumes('Henry David Thoreau', array('filter' => 'free-ebooks'));

foreach ($results->getItems() as $item) {
	echo $item['volumeInfo']['title'], "<br /> \n";
}

var_dump($client->getHttpClient()->getConfig('handler'));

Expected Behavior

The middleware is added once and only once to the guzzle HandlerStack.

Relevant Logs / Console output

Output from the above example:

array (size=9)
      0 => 
        array (size=2)
          0 => 
            object(Closure)[307]
              ...
          1 => string 'http_errors' (length=11)
      1 => 
        array (size=2)
          0 => 
            object(Closure)[308]
              ...
          1 => string 'allow_redirects' (length=15)
      2 => 
        array (size=2)
          0 => 
            object(Closure)[309]
              ...
          1 => string 'cookies' (length=7)
      3 => 
        array (size=2)
          0 => 
            object(Closure)[310]
              ...
          1 => string 'prepare_body' (length=12)
      4 => 
        array (size=2)
          0 => string 'newrelic\Guzzle6\middleware' (length=27)
          1 => string '' (length=0)
      5 => 
        array (size=2)
          0 => string 'newrelic\Guzzle6\middleware' (length=27)
          1 => string '' (length=0)
      6 => 
        array (size=2)
          0 => string 'newrelic\Guzzle6\middleware' (length=27)
          1 => string '' (length=0)
      7 => 
        array (size=2)
          0 => 
            object(Google\Auth\Middleware\SimpleMiddleware)[420]
              ...
          1 => string 'google_auth' (length=11)
      8 => 
        array (size=2)
          0 => string 'newrelic\Guzzle6\middleware' (length=27)
          1 => string '' (length=0)

Error occurring in production:

Error: Xdebug has detected a possible infinite loop, and aborted your script with a stack depth of '512' frames
#249 /libs/vendor/guzzlehttp/psr7/src/MessageTrait.php(189): is_scalar
#248 newrelic/Guzzle6(1): newrelic\Guzzle6\{closure}
#247 newrelic/Guzzle6(1): newrelic\Guzzle6\{closure}
#246 newrelic/Guzzle6(1): newrelic\Guzzle6\{closure}
#245 newrelic/Guzzle6(1): newrelic\Guzzle6\{closure}
#244 newrelic/Guzzle6(1): newrelic\Guzzle6\{closure}
#243 newrelic/Guzzle6(1): newrelic\Guzzle6\{closure}
#242 newrelic/Guzzle6(1): newrelic\Guzzle6\{closure}
#241 newrelic/Guzzle6(1): newrelic\Guzzle6\{closure}
...
...
...
#32 newrelic/Guzzle6(1): newrelic\Guzzle6\{closure}
#31 newrelic/Guzzle6(1): newrelic\Guzzle6\{closure}
#30 newrelic/Guzzle6(1): newrelic\Guzzle6\{closure}
#29 newrelic/Guzzle6(1): newrelic\Guzzle6\{closure}
#28 newrelic/Guzzle6(1): newrelic\Guzzle6\{closure}
#27 newrelic/Guzzle6(1): newrelic\Guzzle6\{closure}
#26 newrelic/Guzzle6(1): newrelic\Guzzle6\{closure}
#25 newrelic/Guzzle6(1): newrelic\Guzzle6\{closure}
#24 newrelic/Guzzle6(1): newrelic\Guzzle6\{closure}
#23 newrelic/Guzzle6(1): newrelic\Guzzle6\{closure}
#22 newrelic/Guzzle6(1): newrelic\Guzzle6\{closure}
#21 newrelic/Guzzle6(1): newrelic\Guzzle6\{closure}
#20 newrelic/Guzzle6(1): newrelic\Guzzle6\{closure}
#19 newrelic/Guzzle6(1): newrelic\Guzzle6\{closure}
#18 newrelic/Guzzle6(1): newrelic\Guzzle6\{closure}
#17 newrelic/Guzzle6(1): newrelic\Guzzle6\{closure}
#16 /libs/vendor/guzzlehttp/guzzle/src/PrepareBodyMiddleware.php(66): GuzzleHttp\PrepareBodyMiddleware::__invoke
#15 /libs/vendor/guzzlehttp/guzzle/src/Middleware.php(29): GuzzleHttp\Middleware::GuzzleHttp\{closure}
#14 /libs/vendor/guzzlehttp/guzzle/src/RedirectMiddleware.php(70): GuzzleHttp\RedirectMiddleware::__invoke
#13 /libs/vendor/guzzlehttp/guzzle/src/Middleware.php(57): GuzzleHttp\Middleware::GuzzleHttp\{closure}
#12 /libs/vendor/guzzlehttp/guzzle/src/HandlerStack.php(67): GuzzleHttp\HandlerStack::__invoke
#11 /libs/vendor/guzzlehttp/guzzle/src/Client.php(277): GuzzleHttp\Client::transfer
#10 /libs/vendor/guzzlehttp/guzzle/src/Client.php(98): GuzzleHttp\Client::sendAsync
#9 /libs/vendor/guzzlehttp/guzzle/src/Client.php(106): GuzzleHttp\Client::send
#8 /libs/vendor/google/auth/src/HttpHandler/Guzzle6HttpHandler.php(34): Google\Auth\HttpHandler\Guzzle6HttpHandler::__invoke
#7 /libs/vendor/google/apiclient/src/Google/Http/REST.php(74): Google_Http_REST::doExecute
#6 /libs/vendor/google/apiclient/src/Google/Task/Runner.php(176): Google_Task_Runner::run
#5 /libs/vendor/google/apiclient/src/Google/Http/REST.php(58): Google_Http_REST::execute
#4 /libs/vendor/google/apiclient/src/Google/Client.php(842): Google_Client::execute
#3 /libs/vendor/google/apiclient/src/Google/Service/Resource.php(232): Google_Service_Resource::call
#2 /libs/classmaps/GoogleMyBusiness.php(1727): Google_Service_MyBusiness_AccountsLocations_Resource::patch
#1 /jobs/AgencySync.php(124): CronJob\AgencySync::execute
#0 /scripts/Cron.php(39): null

Your Environment

PHP Version: 7.3.25
Agent Version: 9.14.0.290

Additional context

N/A

No web transaction data on Laravel 8

Description

Hi,

We have upgrade our Laravel application to version 8 and are using Newrelic agent v. 9.14.0.290-14bb02701b5c. We are currently not seeing any web transactions. Is that because the agent does not support Laravel 8 yet? We do get non-web transactions reported

Steps to Reproduce

Expected Behavior

Relevant Logs / Console output

Your Environment

Ubuntu 16.04.3 LTS
Php 7.4
Laravel 8.16.0

Additional context

[PHP] Infinite Tracing Polish - handle cell shifts

9.16: Cross-Platform Installation and Sanity Testing

Part of #77

Run the xPlatform Jenkins job, ensure only false failures occur (Agent version mismatch, no-slow-sql, etc)

[PHP] Laravel Lumen Support

• PHP agent works OOTB with latest release of Laravel Lumen:

  • user experience (transaction naming, transaction timing, etc) is similar or better to that of our support for other frameworks

  • installation and configuration of the PHP agent is not adversely impacted

• add to multiverse

• passes unit + multiverse + soak tests

• Updated docs as needed

• Demo to stakeholders (PM, EM)

• Ready for release

PHP 8.0: Jenkins GitHub Actions trigger

Summary

We need the ability to setup a jenkins proxy job that can trigger a GitHub Actions workflow and wait for it to complete. This ticket is part of issue #32.

Desired Behavior

• A script exists that will trigger a named GitHub Actions workflow on a specified git commit hash and wait for it to complete.
• The pass / fail state of the jenkins job accurately reflects the pass / fail state of the GitHub Actions workflow.
• Optional: The script also calls the artifact pull script once the build is complete (as the whole purpose of triggering a GitHub Actions workflow in this MMF is to generate artifacts for use by child jobs in jenkins).

Pre-reqs and dependencies

• This can be created using our existing ubuntu based workflow as an initial target.
• This script is needed in by the PR and inward singing jobs so they can trigger the build of the PHP 8.0 agent.

Additional context

See the MMF doc for more details.

PHP 8.0: GitHub Actions artifact pull script

Summary

We need the ability to pull artifacts from a GitHub actions workflow. This ticket is part of issue #32.

Desired Behavior

• A script exists that will pull artifacts from a targeted GitHub workflow. The script must be able to filter the targeted workflows by artifact name and git commit hash.

Pre-reqs and dependencies

• A prototype of this script that pulls against one of the prototype builds exists that can be used as a starting point. See the MMF doc (linked below) for more details.
• This script will be needed by most of our top-level jenkins jobs in order to retrieve the PHP 8.0 builds for 32-bit libc and 64-bit libc.

Additional context

See the MMF doc for more details.

PHP 8.0: 32-bit and 64-bit libc builds

Summary

We need 32-bit and 64-bit libc builds of the PHP 8.0 agent. This ticket is part of issue #32.

Desired Behavior

• Testing is done on the platform to ensure the agent builds cleanly.
• A GitHub Actions action exists to build each on each of the libc variants.
• The actions use official PHP 8.0 docker images to perform its build.
• A GitHub Actions workflow exists that will publish artifacts suitable for inclusion in our existing jenkins builds.

Pre-reqs and dependencies

• This is one of the tickets that will block the completion of the tickets to update the jenkins jobs.
• See the MMF doc for details on the research / prototyping that was done.
• If the artifacts produced by this build are not usable on the CentOS versions used by our automated tests, we may need to fall back and build on our CentOS 5 build machines until we can migrate those tests to run on a newer OS. (Refer to the MMF doc for details on which libraries need to be updated in that case).

Additional context

See the MMF doc for more details.

PHP 8 - Curl API changes

Summary

The implementation of curl has changed somewhat in PHP 8. Previously, curl handles were resources, but as of PHP 8 are now class objects. For this ticket, correct our instrumentation to account for this change when PHP 8 is defined.

Desired Behavior

• All occurrences of IS_RESOURCE are accounted for and fixed in our instrumentation
• Since curl_close() no longer closes the curl handle (a task left to GC), verify with valgrind that our tests do handle this situation gracefully and appropriately.
• Our Monolog Enricher's default Handler uses Curl to communicate with the NR API. Verify that this behavior still works as expected!

PHP 8 - Repair Laravel segfault when using `jit=1255`

Summary

Internal testing shows that Laravel tests segfault when using jit=1255. For this issue, repair any and all segfaults when using 1255, and if current tests do not adequately cover these cases, add such tests the the appropriate suite.

Desired Behavior

Laravel based applications do not trigger segmentation faults when jit=1255

Additional context

• PHP 8 JIT Source
• Internal team mobbing session gdb walkthrough

Error collector interferes with error handling even when disabled

Description

When using a different error handling system (ie. Sentry), setting newrelic.error_collector.enabled = false does not seem to completely disable that feature. In my case, this causes Sentry to report errors twice as an Error and FatalError respectively. This does not happen when completely disabling the New Relic agent.

Steps to Reproduce

• Setup both Sentry and New Relic in a project
• Set newrelic.error_collector.enabled = false
• Create an intentional PHP error
• Notice that the error is reported twice in Sentry

Expected Behavior

New Relic should not interfere in any way with error handling when newrelic.error_collector.enabled = false is set.

Relevant Logs / Console output

Issue initially filed in the Sentry repo getsentry/sentry-php#1156

The two exceptions generated

Error: Call to a member function test() on null
#2 /controller/Extranet/IndexController.php(50): Controller\Extranet\IndexController::show
#1 /libs/Class/Launcher.php(226): Launcher::start
#0 /index.php(6): null

Sentry\Exception\FatalErrorException: Error: Uncaught Error: Call to a member function test() on null in /var/www/controller/Extranet/IndexController.php:50
Stack trace:
#0 /var/www/libs/Class/Launcher.php(226): Controller\Extranet\IndexController->show()
#1 /var/www/index.php(6): Launcher->start()
#2 {main}
  thrown
#0 /controller/Extranet/IndexController.php(50): null

Your Environment

PHP Version: 7.3.25
Agent Version: 9.14.0.290
Sentry Version: 3.1.1

Additional context

N/A

PHP 8.0: Update inward singing job

Summary

Our inward singing jenkins job needs to be updated to include a PHP 8.0 build of the agent. This ticket is part of issue #32.

Desired Behavior

• Running the top-level inward singing job results in a build and test of a PHP 8.0 version of the agent.
• A separate child job exists for PHP 8.0 (following the pattern of the existing jobs).
• The building and testing occurs on 32-bit libc, 64-bit libc, 64-bit musl, and 64-bit FreeBSD targets.

Pre-reqs and dependencies

• 32-bit and 64-bit libc PHP 8.0 agent builds
• 64-bit musl AMI updates
• 64-bit FreeBSD AMI updates

Additional context

See the MMF doc for more details.

PHP Agent Causes Fatal Errors in Guzzle Requests

Description

After installing & enabling the NewRelic PHP Agent on an Ubuntu machine running PHP7.3, Laravel 7.x we're seeing numerous Guzzle requests fail with a Unsupported operand types exception. Other users have reported similar errors and there's a thread on the NewRelic forums here. Disabling the extension resolves the issue.

Steps to Reproduce

Will work to further create a sample repo / test scenario.

Expected Behavior

Relevant Logs / Console output

Sample exception here

[object] (Error(code: 0): Unsupported operand types at /var/www/vendor/guzzlehttp/guzzle/src/Client.php:310)
[stacktrace]
#0 /var/www/vendor/guzzlehttp/guzzle/src/Client.php(148): GuzzleHttp\\Client->prepareDefaults(Array)
#1 /var/www/vendor/guzzlehttp/guzzle/src/Client.php(182): GuzzleHttp\\Client->requestAsync('shouldReport', Array, Array)
#2 /var/www/vendor/guzzlehttp/guzzle/src/Client.php(95): GuzzleHttp\\Client->request('shouldReport', Array, Array)
#3 /var/www/vendor/guzzlehttp/guzzle/src/Client.php(62): GuzzleHttp\\Client->__call('shouldReport', Array)
#4 /var/www/vendor/laravel/framework/src/Illuminate/Http/Client/PendingRequest.php(621): GuzzleHttp\\Client->__construct(Array)
#5 /var/www/vendor/laravel/framework/src/Illuminate/Http/Client/PendingRequest.php(554): Illuminate\\Http\\Client\\PendingRequest->buildClient()
#6 /var/www/vendor/laravel/framework/src/Illuminate/Support/helpers.php(404): Illuminate\\Http\\Client\\PendingRequest->Illuminate\\Http\\Client\\{closure}(1)
#7 /var/www/vendor/laravel/framework/src/Illuminate/Http/Client/PendingRequest.php(570): retry(0, Object(Closure), 100)
#8 /var/www/vendor/laravel/framework/src/Illuminate/Http/Client/PendingRequest.php(474): Illuminate\\Http\\Client\\PendingRequest->send('POST', 'redacted', Array)
#9 /var/www/app/Jobs/ProcessorJob.php(54): Illuminate\\Http\\Client\\PendingRequest->post('redacted', Array)
#10 [internal function]: App\\Jobs\\ProcessorJob->handle()
#11 /var/www/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(37): call_user_func_array(Array, Array)
#12 /var/www/vendor/laravel/framework/src/Illuminate/Container/Util.php(37): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#13 /var/www/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(95): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#14 /var/www/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(39): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#15 /var/www/vendor/laravel/framework/src/Illuminate/Container/Container.php(596): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#16 /var/www/vendor/laravel/framework/src/Illuminate/Bus/Dispatcher.php(94): Illuminate\\Container\\Container->call(Array)
#17 /var/www/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(128): Illuminate\\Bus\\Dispatcher->Illuminate\\Bus\\{closure}(Object(App\\Jobs\\ProcessorJob))
#18 /var/www/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(103): Illuminate\\Pipeline\\Pipeline->Illuminate\\Pipeline\\{closure}(Object(App\\Jobs\\ProcessorJob))
#19 /var/www/vendor/laravel/framework/src/Illuminate/Bus/Dispatcher.php(98): Illuminate\\Pipeline\\Pipeline->then(Object(Closure))
#20 /var/www/vendor/laravel/framework/src/Illuminate/Queue/CallQueuedHandler.php(83): Illuminate\\Bus\\Dispatcher->dispatchNow(Object(App\\Jobs\\ProcessorJob), false)
#21 /var/www/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(128): Illuminate\\Queue\\CallQueuedHandler->Illuminate\\Queue\\{closure}(Object(App\\Jobs\\ProcessorJob))
#22 /var/www/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(103): Illuminate\\Pipeline\\Pipeline->Illuminate\\Pipeline\\{closure}(Object(App\\Jobs\\ProcessorJob))
#23 /var/www/vendor/laravel/framework/src/Illuminate/Queue/CallQueuedHandler.php(85): Illuminate\\Pipeline\\Pipeline->then(Object(Closure))
#24 /var/www/vendor/laravel/framework/src/Illuminate/Queue/CallQueuedHandler.php(59): Illuminate\\Queue\\CallQueuedHandler->dispatchThroughMiddleware(Object(Illuminate\\Queue\\Jobs\\RedisJob), Object(App\\Jobs\\Or$
#25 /var/www/vendor/laravel/framework/src/Illuminate/Queue/Jobs/Job.php(98): Illuminate\\Queue\\CallQueuedHandler->call(Object(Illuminate\\Queue\\Jobs\\RedisJob), Array)
#26 /var/www/vendor/laravel/framework/src/Illuminate/Queue/Worker.php(356): Illuminate\\Queue\\Jobs\\Job->fire()
#27 /var/www/vendor/laravel/framework/src/Illuminate/Queue/Worker.php(306): Illuminate\\Queue\\Worker->process('redis', Object(Illuminate\\Queue\\Jobs\\RedisJob), Object(Illuminate\\Queue\\WorkerOptions))
#28 /var/www/vendor/laravel/framework/src/Illuminate/Queue/Worker.php(132): Illuminate\\Queue\\Worker->runJob(Object(Illuminate\\Queue\\Jobs\\RedisJob), 'redis', Object(Illuminate\\Queue\\WorkerOptions))
#29 /var/www/vendor/laravel/framework/src/Illuminate/Queue/Console/WorkCommand.php(112): Illuminate\\Queue\\Worker->daemon('redis', 'default', Object(Illuminate\\Queue\\WorkerOptions))
#30 /var/www/vendor/laravel/framework/src/Illuminate/Queue/Console/WorkCommand.php(96): Illuminate\\Queue\\Console\\WorkCommand->runWorker('redis', 'default')
#31 [internal function]: Illuminate\\Queue\\Console\\WorkCommand->handle()
#32 /var/www/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(37): call_user_func_array(Array, Array)
#33 /var/www/vendor/laravel/framework/src/Illuminate/Container/Util.php(37): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#34 /var/www/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(95): Illuminate\\Container\\Util::unwrapIfClosure(Object(Closure))
#35 /var/www/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(39): Illuminate\\Container\\BoundMethod::callBoundMethod(Object(Illuminate\\Foundation\\Application), Array, Object(Closure))
#36 /var/www/vendor/laravel/framework/src/Illuminate/Container/Container.php(596): Illuminate\\Container\\BoundMethod::call(Object(Illuminate\\Foundation\\Application), Array, Array, NULL)
#37 /var/www/vendor/laravel/framework/src/Illuminate/Console/Command.php(134): Illuminate\\Container\\Container->call(Array)
#38 /var/www/vendor/symfony/console/Command/Command.php(258): Illuminate\\Console\\Command->execute(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\OutputStyle))
#39 /var/www/vendor/laravel/framework/src/Illuminate/Console/Command.php(121): Symfony\\Component\\Console\\Command\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Illuminate\\Console\\$
#40 /var/www/vendor/symfony/console/Application.php(911): Illuminate\\Console\\Command->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#41 /var/www/vendor/symfony/console/Application.php(264): Symfony\\Component\\Console\\Application->doRunCommand(Object(Illuminate\\Queue\\Console\\WorkCommand), Object(Symfony\\Component\\Console\\Input\\ArgvInpu$
#42 /var/www/vendor/symfony/console/Application.php(140): Symfony\\Component\\Console\\Application->doRun(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleO$
#43 /var/www/vendor/laravel/framework/src/Illuminate/Console/Application.php(93): Symfony\\Component\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Con$
#44 /var/www/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(129): Illuminate\\Console\\Application->run(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Cons$
#45 /var/www/artisan(37): Illuminate\\Foundation\\Console\\Kernel->handle(Object(Symfony\\Component\\Console\\Input\\ArgvInput), Object(Symfony\\Component\\Console\\Output\\ConsoleOutput))
#46 {main}

Your Environment

• PHP 7.3.26 FPM
• Fresh installation of the NewRelic PHP Agent
• Laravel 7.25
• Guzzle requests were generated / called using the Http Laravel facade

Additional context

[PHP] Zend-to-Laminas cleanup

Zend HTTP is now Laminas HTTP (used by Magento 2.3+).

Acceptance Criteria

• PHP agent works OOTB with Laminas:
  • installation and configuration of the PHP agent is not adversely impacted
  • Confirm whether or not the user experience (transaction naming, transaction timing, etc) is similar or better to that of our support for Zend HTTP
    • Fix issues if fits in timebox of 2-3 engineer days
  • Document any remaining deltas in user experience from Zend HTTP
• add to multiverse
• passes unit + multiverse + soak tests
• Updated docs as needed
• Ready for release

9.16: Stability Testing

Part of #77

Drive traffic through application using popular PHP frameworks. Check for memory leaks and violations with valgrind.

Tests can be started via the Inward Singing Jenkins job.

Virtuoso: First PHP Recipes

For users of Debian or RHEL derived systems, running PHP under FPM with Apache or nginx, the New Relic Open Install Library can be used to easily install and configure the PHP Agent on their systems.

PHP 8.0: Update install scripts

Summary

The agent install scripts need to be updated to allow the agent to be installed if PHP 8.0 is present on the syste. This ticket is part of issue #32.

Desired Behavior

• The agent install scripts no longer block the installation of the agent if PHP 8.0 is detected.

Pre-reqs and dependencies

• Should be able to do the majority of the work on a vagrant box. May need an additional environment to test any .deb or .rpm related changes.

Additional context

See the MMF doc for more details.

PHP 8.0: 64-bit musl build

Summary

We need 64-bit musl builds of the PHP 8.0 agent. This ticket is part of issue #32.

Desired Behavior

• Testing is done on the platform to ensure the agent builds cleanly.
• Our jenkins alpine AMIs are updated to build PHP 8.0.

Pre-reqs and dependencies

• The nrlamp ticket as PHP 8.0 will not build without a newer version of libxml.
• This is one of the tickets that will block the completion of the tickets to update the jenkins jobs.

Additional context

See the MMF doc for more details.

PHP 8.0: 64-bit FreeBSD build

Summary

We need 64-bit FreeBSD builds of the PHP 8.0 agent. This ticket is part of issue #32.

Desired Behavior

• Testing is done on the platform to ensure the agent builds cleanly.
• Our jenkins FreeBSD AMIs are updated to build PHP 8.0.

Pre-reqs and dependencies

• The nrlamp ticket as PHP 8.0 will not build without a newer version of libxml.
• This is one of the tickets that will block the completion of the tickets to update the jenkins jobs.

Additional context

See the MMF doc for more details.

Modify agent to conform with new PHP 8.0 internal API changes

Summary

PHP 8.0 made quite a few internal API changes. The PHP agent needs to accommodate these changes.

Desired Behavior

PHP agent conforms to PHP 8.0 internal API changes.

Additional context

See associated MMF for more details.

Epic: [PHP] Spike: JIT + PHP-based instrumentation

See doc

At the end of our series of PHP 8 MMFs, our PHP agent support for PHP 8 will not include support for new PHP 8 JIT functionality. When our agent is installed in an PHP 8 environment, after detecting the New Relic PHP Agent, PHP 8 turns off JIT functionality and customers will not be able to use it.
PHP 8 provides the following error message:

PHP Warning:  JIT is incompatible with third party extensions that override zend_execute_ex(). JIT disabled. in Unknown on line 0

A new Observability API is being introduced that we need to explore to determine how to use this to do agent-like things that are currently disabled in presence of JIT.

Additionally, we believe writing new instrumentation in PHP will allow us easier use of the Observability API as well as provide us an easier migration path to OpenTelemetry, where instrumentation will be focused on PHP.

This investigation spike will cover three things:

1. Investigate the Observability API to determine how use use this to do agent-like things … Work and questions to answer include:
   1. Can we use the API with Symfony 4 or 5
   2. Can we swap our use of Zend Execute that is currently used by the NR agent for auto-instrumentation or the Observability API? If we can do a wholesale swap, then we use that on PHP 8, which allows us JIT support and we expect it will also reduce the complexity of our agent. We want to make the agent more modular and write new instrumentation in PHP.
   3. Separate from how we do that hook is what language we write our instrumentation thing
   4. When touch the next instrumentation → expect a LOT of churn because of PHP 8, and BONUS, we cut down on the cost of porting to OTel if we do that.
2. Investigate porting some instrumentation from C to PHP and identify how to get it to work with our agent daemon. We will need to determine how to create PHP wrappers for our current internal APIs written in C, and ideally we would publish those so that customers can write their own instrumentation that can talk to our Go daemon
   1. Port our existing C-based Symphony 4 or 5 instrumentation to be based on PHP. We have already done some prototyping in this area and we would extend that.
   2. Get a sense of the cost to do porting for a framework instrumentation
   3. Identify any limitations and start to draft how we would guide customers to write new PHP-based instrumentation to talk to our Go daemon
3. Performance testing of our PHP-based instrumentation using the Observability API
   1. We originally wrote the PHP agent in C for performance reasons, what is the impact on performance if instrumentation is now PHP-based?

Improve consistency in PHP version ifdef usage

Summary

The version specific PHP ifdefs should refer to the named version only and not the named version or higher.

Desired Behavior

PHP7 should only refer to PHP version 7, not version 8 in order to be consistent with the PHP5 and PHP8 ifdefs.

Possible Solution

We may also want to consider adding something like a PHP7_PLUS ifdef in order to avoid the more complex zend module version comparison ifdef used now.

Additional context

PR #49 is where the PHP8 ifdef was first added and when the inconsistency was introduced (since there is now a version greater than PHP 7.x).

PHP8 MMF#1: Install agent in PHP8 w/o faults

The outcome of this work is ability to use the PHP agent in an PHP 8 environment without crashes and to clearly document how to configure a PHP 8 service to be used with this base bones PHP8 support in our PHP agent.

This is part of multiple MMFs for PHP 8 work as outlined below.

MMF#1 Agent with PHP 8 support

MMF#2 Build Environment with PHP 8.0
MMF#3 Update Agent Tests with PHP 8.0
MMF#4 Release Agent with PHP 8.0 Support

PHP 8.0: Update PR job

Summary

Our PR jenkins job needs to be updated to include a PHP 8.0 build of the agent. This ticket is part of issue #32.

Desired Behavior

• The PR job builds and test a PHP 8.0 version of the agent.
• The building and testing occurs on 32-bit libc, 64-bit libc, 64-bit musl, and 64-bit FreeBSD targets.

Pre-reqs and dependencies

• 32-bit and 64-bit libc PHP 8.0 agent builds
• 64-bit musl AMI updates
• 64-bit FreeBSD AMI updates

Additional context

See the MMF doc for more details.

PHP8 MMF#2: Build Environment

This is part of multiple MMFs for PHP 8 work as outlined below.

#33 MMF#1 Agent with PHP 8 support

#32 MMF#2 Build Environment with PHP 8.0

#34 MMF#3 Update Agent Tests with PHP 8.0

#35 MMF#4 Release Agent with PHP 8.0 Support

PHP8 MMF#1: Install agent in PHP8 w/o faults

The outcome of this work is ability to use the PHP agent in an PHP 8 environment without crashes and to clearly document how to configure a PHP 8 service to be used with this base bones PHP8 support in our PHP agent.

This is part of multiple MMFs for PHP 8 work as outlined below.

#33 MMF#1 Agent with PHP 8 support
#32 MMF#2 Build Environment with PHP 8.0
#34 MMF#3 Update Agent Tests with PHP 8.0
#35 MMF#4 Release Agent with PHP 8.0 Support

PHP8: package newrelic-php5 produces error in PHP 8.0.1 after its package received an update

Description

the previous version of newrelic-php5 was still installed for php7.4 on our debian system that runs multiple concurrent php versions (7.4 + 8.0 currently), but for obvious reasons was not active for php 8.0. today the package got updated to 9.16.0.295, and this now causes the php8.0 binary to issue the following error upon startup:

Warning: PHP Startup: Unable to load dynamic library 'newrelic.so' (tried: /usr/lib/php/20200930/newrelic.so (/usr/lib/php/20200930/newrelic.so: cannot open shared object file: 
No such file or directory), /usr/lib/php/20200930/newrelic.so.so (/usr/lib/php/20200930/newrelic.so.so: cannot open shared object file: No such file or directory)) in Unknown on
 line 0

Steps to Reproduce

apt-get install newrelic-php5
php -v

Expected Behavior

upgrade of package should not touch configs of unsupported php version 8.0

Relevant Logs / Console output

root@felucia:~# apt-cache policy newrelic-php5 | head
newrelic-php5:
  Installed: 9.16.0.295
  Candidate: 9.16.0.295
  Version table:
 *** 9.16.0.295 500
        500 http://apt.newrelic.com/debian newrelic/non-free amd64 Packages
        100 /var/lib/dpkg/status
     9.15.0.293 500
        500 http://apt.newrelic.com/debian newrelic/non-free amd64 Packages
     9.14.0.290 500
root@felucia:~# apt-cache policy php8.0-cli
php8.0-cli:
  Installed: 8.0.1-1+0~20210112.7+debian10~1.gbp71cd4d
  Candidate: 8.0.1-1+0~20210112.7+debian10~1.gbp71cd4d
  Version table:
 *** 8.0.1-1+0~20210112.7+debian10~1.gbp71cd4d 750
        750 https://packages.sury.org/php buster/main amd64 Packages
        100 /var/lib/dpkg/status
root@felucia:~# php -v

Warning: PHP Startup: Unable to load dynamic library 'newrelic.so' (tried: /usr/lib/php/20200930/newrelic.so (/usr/lib/php/20200930/newrelic.so: cannot open shared object file: No such file or directory), /usr/lib/php/20200930/newrelic.so.so (/usr/lib/php/20200930/newrelic.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
PHP 8.0.1 (cli) (built: Jan 12 2021 13:59:46) ( NTS )
Copyright (c) The PHP Group
Zend Engine v4.0.1, Copyright (c) Zend Technologies
    with Zend OPcache v8.0.1, Copyright (c), by Zend Technologies

Your Environment

• debian 10
• php 7.4.14
• php 8.0.1
• newrelic-php5 9.16.0.295

Additional context

cron-apt update log:

CRON-APT RUN [/etc/cron-apt/config]: Mon Jan 25 22:00:02 CET 2021
CRON-APT SLEEP: 973, Mon Jan 25 22:16:15 CET 2021
CRON-APT ACTION: 3-download
CRON-APT LINE: /usr/bin/apt-get -o quiet=1 dist-upgrade -y -o APT::Get::Show-Upgraded=true --option Dpkg::Options::=--force-confdef --option Dpkg::Options::=--force-confold
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
The following packages will be upgraded:
  mutt newrelic-daemon newrelic-php5 newrelic-php5-common
4 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 17.3 MB of archives.
After this operation, 16.4 kB of additional disk space will be used.
Get:1 http://apt.newrelic.com/debian newrelic/non-free amd64 newrelic-php5-common all 9.16.0.295 [31.1 kB]
Get:2 http://security.debian.org buster/updates/main amd64 mutt amd64 1.10.1-2.1+deb10u5 [1582 kB]
Get:3 http://apt.newrelic.com/debian newrelic/non-free amd64 newrelic-daemon amd64 9.16.0.295 [4355 kB]
Get:4 http://apt.newrelic.com/debian newrelic/non-free amd64 newrelic-php5 amd64 9.16.0.295 [11.3 MB]
apt-listchanges: Reading changelogs...
Preconfiguring packages ...
Fetched 17.3 MB in 0s (44.5 MB/s)
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 134787 files and directories currently installed.)
Preparing to unpack .../newrelic-php5-common_9.16.0.295_all.deb ...
Unpacking newrelic-php5-common (9.16.0.295) over (9.15.0.293) ...
Setting up newrelic-php5-common (9.16.0.295) ...
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 134787 files and directories currently installed.)
Preparing to unpack .../newrelic-daemon_9.16.0.295_amd64.deb ...
Unpacking newrelic-daemon (9.16.0.295) over (9.15.0.293) ...
Setting up newrelic-daemon (9.16.0.295) ...
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 134787 files and directories currently installed.)
Preparing to unpack .../newrelic-php5_9.16.0.295_amd64.deb ...
WARNING: Module newrelic ini file doesn't exist under /etc/php/8.0/mods-available
WARNING: Module newrelic ini file doesn't exist under /etc/php/8.0/mods-available
Unknown PHP version: 8.0
Unpacking newrelic-php5 (9.16.0.295) over (9.15.0.293) ...
Preparing to unpack .../mutt_1.10.1-2.1+deb10u5_amd64.deb ...
Unpacking mutt (1.10.1-2.1+deb10u5) over (1.10.1-2.1+deb10u4) ...
Setting up newrelic-php5 (9.16.0.295) ...
Unknown PHP version: 8.0
Please restart your Web server(s) to complete installation.
Setting up mutt (1.10.1-2.1+deb10u5) ...
Processing triggers for man-db (2.8.5-2) ...
Processing triggers for mime-support (3.62) ...
Processing triggers for systemd (241-7~deb10u5) ...

Running kernel seems to be up-to-date.

Services to be restarted:
 systemctl restart exim4.service
 systemctl restart nmbd.service
 systemctl restart php7.4-fpm.service
 systemctl restart smbd.service
 systemctl restart winbind.service

No containers need to be restarted.

No user sessions are running outdated binaries.```

PHP 8.0

Congrats on open sourcing the NewRelic PHP Agent 👏

PHP 8.0 will soon be released (November 26) and I was wondering if there is already work being done to support it.

Collect POST body

Summary

Collect POST body payload should be something simple.

Now collect the body seems to be something tricky and in some cases, like us, it's impossible.

Desired Behavior

Activate a simple newrelic.ini flag to collect it.

Possible Solution

Just add a new property in the newrelic.ini to activate it.

newrelic.body.include = true

Additional context

I think this feature is much needed for every project for debug purposes.

PHP8 MMF#3: Agent tests

This is part of multiple MMFs for PHP 8 work as outlined below.

#33 MMF#1 Agent with PHP 8 support

#32 MMF#2 Build Environment with PHP 8.0

#34 MMF#3 Update Agent Tests with PHP 8.0

#35 MMF#4 Release Agent with PHP 8.0 Support

Segfault encountered - causing intermittent 502 response errors

Description

I'm not sure if this is the right place to raise this, or whether the community discussion boards would be better.

As mentioned in the title, it appears as if the New Relic agent is causing segfaults intermittently. I can't seem to figure out what could be causing the issue, but the one function that keeps coming up is opcache_get_status().

It appears to only segfault after the daemon has connected to New Relic. After the initial page load, keep refreshing and you should eventually encounter a 502 status page.

Steps to Reproduce

I have created a Docker image that provides a reproducible way of experiencing the issue. Steps are outlined below:

1. Pull the Docker image garbetjie/php:7.4-newrelic-debug.

2. Run this image using the following command: docker run -e NEWRELIC_ENABLED=true -e NEWRELIC_LICENCE=XXX -e NEWRELIC_LOGLEVEL=verbosedebug -e NEWRELIC_DAEMON_LOGLEVEL=verbosedebug -e OPCACHE_ENABLED=false garbetjie/php:7.4-newrelic-debug. Replace NEWRELIC_LICENCE=XXX with the actual licence value.

3. If you want to enable opcache, change -e OPCACHE_ENABLED=false to -e OPCACHE_ENABLED=true.

Expected Behavior

I expected that every request would execute successfully, without any server errors.

Relevant Logs / Console output

2021-02-01 17:47:42.600 +0000 (78 78) debug: 'WT_IS_FILENAME & SCRIPT_FILENAME' naming is '/phpinfo.php'
Process 78 (version 9.15.0.293) received signal 11: segmentation violation
process id 78 fatal signal (SIGSEGV, SIGFPE, SIGILL, SIGBUS, ...)  - stack dump follows (code=0x7f021bfce000 bss=0x7f021c2c987c):
No backtrace on this platform.
PHP execution trace follows...
#0 opcache_get_status()
#1 unknown()

Your Environment

• PHP 7.4 FPM running in a Docker container based on Alpine Linux.
• New Relic version 9.15.0.293.

Additional context

PHP8 MMF#1: Install agent in PHP8 w/o faults

The outcome of this work is ability to use the PHP agent in an PHP 8 environment without crashes and to clearly document how to configure a PHP 8 service to be used with this base bones PHP8 support in our PHP agent.

This is part of multiple MMFs for PHP 8 work as outlined below.

MMF#1 Agent with PHP 8 support

MMF#2 Build Environment with PHP 8.0 MMF#3 Update Agent Tests with PHP 8.0 MMF#4 Release Agent with PHP 8.0 Support

Symfony framework detection

Hey Newrelic / @joshuabenuck

I've been reviewing the C code here. I see there's fw_symfony.c fw_symfony2.c and fw_symfony4.c.

Does the php extension auto-detect which version we're using? or do we have to tell it? More implementation-detail questions will follow once I know this answer.

Thank you for your time.

PHP 8 - Address `protobuf` vendored directory.

Summary

There is a PR (#27) to incorporate the upstream PHP 8 changes needed for compilation of protobuf on systems with PHP 8 headers. That PR should be revisited and retested before merging in.

Desired Behavior

• Vendored protobuf target builds on systems with PHP 8 headers.
• Since we do not use any of the non-c protobuf libraries that are built by protobuf's build system, we could perhaps omit the building of those in our Makefile. This would greatly reduce our build times, and prevent against issues like this in the future, however, to facilitate easy and reliable upgrading of protobuf, this should only happen if it can be minimally invasive. If this can be accomplished via their existing make system, then we should absolutely include it.

PHP 8 - Repair php cli segfault when using `jit=1255`

Summary

Internal testing shows that tests segfault when using php and jit=1255. For this issue, repair any and all segfaults when using 1255, and if current tests do not adequately cover these cases, add such tests the the appropriate suite.

Desired Behavior

php based applications do not trigger segmentation faults when jit=1255

Additional context

• PHP 8 JIT Source
• Internal team mobbing session gdb walkthrough
• Interestingly enough, such crashes are not seen when using php-cgi

[PHP 8] Internals Unit Test Updates

Description

#49 makes the necessary changes for the agent to compile with PHP 8 libs and headers, however it does not address the agent unit tests. For this ticket, ensure all unit tests pass after #49 is merged in main.

[Repolinter] Open Source Policy Issues

Repolinter Report

🤖This issue was automatically generated by repolinter-action, developed by the Open Source and Developer Advocacy team at New Relic. This issue will be automatically updated or closed when changes are pushed. If you have any problems with this tool, please feel free to open a GitHub issue or give us a ping in #help-opensource.

This Repolinter run generated the following results:

❗ Error	❌ Fail	⚠️ Warn	✅ Pass	Ignored	Total
0	1	0	6	0	7

• Fail
  • ❌ code-of-conduct-file-does-not-exist
• Passed
  • ✅ license-file-exists
  • ✅ readme-file-exists
  • ✅ readme-starts-with-community-plus-header
  • ✅ readme-contains-link-to-security-policy
  • ✅ readme-contains-discuss-topic
  • ✅ third-party-notices-file-exists

Fail #

❌ code-of-conduct-file-does-not-exist #

New Relic has moved the CODE_OF_CONDUCT file to a centralized location where it is referenced automatically by every repository in the New Relic organization. Because of this change, any other CODE_OF_CONDUCT file in a repository is now redundant and should be removed. For more information please visit https://docs.google.com/document/d/1y644Pwi82kasNP5VPVjDV8rsmkBKclQVHFkz8pwRUtE/view. Found files. Below is a list of files or patterns that failed:

• CODE_OF_CONDUCT.md
  • 🔨 Suggested Fix: Remove file

Passed #

Click to see rules

✅ license-file-exists #

Found file (LICENSE). New Relic requires that all open source projects have an associated license contained within the project. This license must be permissive (e.g. non-viral or copyleft), and we recommend Apache 2.0 for most use cases. For more information please visit https://docs.google.com/document/d/1vML4aY_czsY0URu2yiP3xLAKYufNrKsc7o4kjuegpDw/edit.

✅ readme-file-exists #

Found file (README.md). New Relic requires a README file in all projects. This README should give a general overview of the project, and should point to additional resources (security, contributing, etc.) where developers and users can learn further. For more information please visit https://github.com/newrelic/open-by-default.

✅ readme-starts-with-community-plus-header #

The first 5 lines contain all of the requested patterns. (README.md). The README of a community plus project should have a community plus header at the start of the README. If you already have a community plus header and this rule is failing, your header may be out of date, and you should update your header with the suggested one below. For more information please visit https://opensource.newrelic.com/oss-category/.

✅ readme-contains-link-to-security-policy #

Contains a link to the security policy for this repository (README.md). New Relic recommends putting a link to the open source security policy for your project (https://github.com/newrelic/<repo-name>/security/policy or ../../security/policy) in the README. For an example of this, please see the "a note about vulnerabilities" section of the Open By Default repository. For more information please visit https://nerdlife.datanerd.us/new-relic/security-guidelines-for-publishing-source-code.

✅ readme-contains-discuss-topic #

Contains a link to the appropriate discuss.newrelic.com topic (README.md). New Relic recommends directly linking the your appropriate discuss.newrelic.com topic in the README, allowing developer an alternate method of getting support. For more information please visit https://nerdlife.datanerd.us/new-relic/security-guidelines-for-publishing-source-code.

✅ third-party-notices-file-exists #

Found file (THIRD_PARTY_NOTICES.md). A THIRD_PARTY_NOTICES.md file can be present in your repository to grant attribution to all dependencies being used by this project. This document is necessary if you are using third-party source code in your project, with the exception of code referenced outside the project's compiled/bundled binary (ex. some Java projects require modules to be pre-installed in the classpath, outside the project binary and therefore outside the scope of the THIRD_PARTY_NOTICES). Please review your project's dependencies and create a THIRD_PARTY_NOTICES.md file if necessary. For JavaScript projects, you can generate this file using the oss-cli. For more information please visit https://docs.google.com/document/d/1y644Pwi82kasNP5VPVjDV8rsmkBKclQVHFkz8pwRUtE/view.

Magento2 - Soap Naming does not work in Version >=2.3.2

Magento2 - Soap Naming does not work in Version >=2.3.2

Description

Magento2 - Soap Naming does not work in Version >=2.3.2
Version 2.3.2 changed the call path for the Soap Handler from _prepareRequestData to prepareOperationInput
The new request path does not call the instrumented method.

• newrelic-php-agent/agent/fw_magento2.c

  Lines 373 to 374 in 5a9a855

  	NR_PSTR("Magento\\Webapi\\Controller\\Soap\\Request\\Handler::_"
  	"prepareRequestData"),

• Magento2 Current Code in Handler.php
• Commit the introduced the regression 365b9410827529ce6e8f7fded489ffcd132706a8f8dd9e5c7548777a416bfcac

Steps to Reproduce

• Install Agent
• Install Magento2
• Make any Soap Call (eg: integrationAdminTokenServiceV1)

Expected Behavior

Expected:

• Naming to match service (eg: WebTransaction/Action/Webapi/Soap/Magento\Integration\Api\AdminTokenServiceInterface/createAdminAccessToken; or so)

Actual:

• /FrontController/Magento\Webapi\Controller\Soap\Interceptor

Relevant Logs / Console output

NONE

Your Environment

Magento2 Version >= 2.3.2
Current PHP Agent

Additional context

Looking over the C code, it should be possible to wrap prepareOperationInput in a similar manner to _prepareRequestData.

The parameters to prepareOperationInput are about the same as the ones for _prepareRequestData.
Both contain serviceClass and serviceMethod; prepareOperationInput wraps the serviceMethod inside an array.
You can see this here as _prepareRequestData delegates to prepareOperationInput.

PHP8 MMF#4: Release agent w basic PHP8 support

For this release with bare bones support for PHP8, we will be documenting special application and agent configuration requirements to allow deployment of the agent in PHP8 environments. We will not be supporting the new JIT capabilities of PHP8.

This is part of multiple MMFs for PHP 8 work as outlined below.

#33 MMF#1 Agent with PHP 8 support

#32 MMF#2 Build Environment with PHP 8.0

#34 MMF#3 Update Agent Tests with PHP 8.0

#35 MMF#4 Release Agent with PHP 8.0 Support

PHP 8.0: Update primary jobs

Summary

Our primary jenkins jobs need to be updated to include a PHP 8.0 build of the agent. This ticket is part of issue #32.

Desired Behavior

• The main and big change jobs include a PHP 8.0 build of the agent.

Pre-reqs and dependencies

• Requires that all platforms be updated to build PHP 8.0 to be completed, but should be able to incrementally add platforms to this as they are updated.

Additional context

See the MMF doc for more details.

Further verification into excluding subpaths from WordPress instrumentation

In v9.15 of the agent, experimental support was added for excluding subpaths from WordPress instrumentation. This lowered the overall WordPress instrumentation overhead by reducing the number of files being instrumented at the cost of losing visibility into the excluded subpaths. This is enabled using the configuration setting newrelic.framework.wordpress.hooks_skip_filename.

To promote this from experimental to a full feature, we need to further verify the functionality of this feature. This includes:

• Multiverse tests for further verification
• Move the configuration setting from newrelic.ini.private.template to newrelic.ini.template
• Document this feature in our public configuration docs.
• Notify any stakeholders if the usability of this feature changes. (internal use only)