Closed TheFrankman closed 1 year ago
@chris-skilltech while the package does help it doesn't seem to fix error reporting
@trothwell-carsguide We've been using the following in our app\Exceptions\Handler.php
to handle error reporting:
public function register()
{
$this->reportable(function (Throwable $e) {
if (function_exists('newrelic_notice_error')) {
newrelic_notice_error($e);
}
});
}
Using the middleware from above that contains newrelic_name_transaction
worked but our transaction are coming through as
WebTransaction/Custom/OurAccountName\SearchController@search instead of WebTransaction/Action/OurAccountName\SearchController@search
So just be aware of that.
Upgrading to New Relic 10 alone didn't fix this for us FYI
@ak-war, re:
we are expecting a release sometime in October 2022 that will address this issue.
Any updates on when in October the release will be?
Come on now @ak-war we pay a lot of money for this service which has been useless for months. No updates at all from your end. We deserve a reply that's better than "We don't know, we hope soon".
Unfortunately, this is even not working on the dev branch. I tried to compile the PHP agent from the source still it fails.
RUN git clone https://github.com/newrelic/newrelic-php-agent.git && cd newrelic-php-agent && git checkout dev && \
make all && make agent-install && cp bin/daemon /usr/local/bin/nr-daemon && make clean && cd .. && rm -rf newrelic-php-agent
I'm testing newrelic integration with Laravel, drop is the point when I restarted my docker.
If this service doesn't work, then why do we pay for it?
If this service doesn't work, then why do we pay for it?
Tbh, we are planning on moving to Sentry in the next few days (our release_candidate
is already using it)
Any update here? We will be forced to switch to another product in a few weeks if we don't get a solution.
Thank you everyone for your constructive feedback. A release will be made around November 3 that will be fixing this issue.
@ak-war Is that a final release or a dev release ? Can we test this ?
@EvanRijn It will be an official release, we do not have a dev release.
@ak-war perfect! is tomorrow still the release day ?
New Relic PHP Agent v10.3.0.315 has been released with the fix: https://github.com/newrelic/newrelic-php-agent/releases.
Docs referenced on the release notes are not working:
@nsinisterra thanks for catching that - links should be correct now.
Awesome team! I'm able to confirm that this update fix the problem! No other issues for now.
NOTE: For other doing the update right now, we have 4 apps running the APM Agent. In 3 of them, make an apt upgrade
was enough, but one of the servers have requested the license key again to update, get your licence key before start the process. Regards!
Unfortunately we're still having the same issue on the new agent (10.3.0.315-1). Seeing a lot of messages in the php_agent logs with:
2022-11-04 16:44:10.946 +0000 (10460 10460) warning: User instrumentation from opcache: missing 'scripts' key in status information
I have confirmed that we've successfully updated the agent using yum info newrelic-php5
and newrelic-daemon -v
. However, running Magento 2.4.4-p2, which listed as explicitly compatible with the PHP agent, we are still seeing everything clumped together under index.php
in APM Transctions.
Are there any other steps we need to take other than installing the new agent, or is this issue not really fixed?
nsinisterra
Can you share the installed module list ?
Can you share the installed module list ?
I'm a bit unclear. The supported operating systems lists CentOS 6 or higher, but then states CentOS 6 support was dropped. Is CentOS 7 supported?
However, running Magento 2.4.4-p2, which listed as explicitly compatible
Our customers are also using Magento 2.4.4 (and up) are also affected, and also the only ones using PHP 8.1. Those using versions under 2.4.4 for Magento and < PHP 8.1 are having no issues.
We're also receiving issues about all requests marked as index.php
although we're on the latest 10.3.0.315
version. This is with Magento 2.4.x (I believe 2.4.4 and up) and PHP 8.1.
What strikes to me is that prior to the 10.3.0.315
version, we were having issues that transactions were named as either index.php
or unknown
. After updating to the 10.3.0.315
version, both problems seemed to disappear, but since yesterday we have seen the index.php
grouped transactions reappearing again:
Please let us know/keep us posted about the status of this problem, as many merchants and developers are preparing their applications to be ready for both black friday and the holiday season in general.
@theloveofcode or @tdgroot - Would one of you mind opening a new github issue on the repo so we can track the Magento 2 impact? We'd like to increase visibility on this issue and separate it from this Laravel-specific issue. We believe this and #436 were resolved by the 10.3.0
release.
Resolved by 10.3.0
release. Please re-open if the issue re-occurs.
I upgraded very pessimistically but i am happy to report that at least for the last hour, transactions are now correct labelled and not unknown.
Let's hope that support for PHP8.2 takes less than a year once it's released.
(Laravel V9, New Relic 10.3.0, PHP8.1)
Hi @tdgroot, hope you doing well.
Are you still experiencing an issue with NR 10.3.0.315
version on Magento 2.4.x
(I believe 2.4.4 and up) and PHP 8.1
?
Thanks in advance for your help!
Update on this issue
The error rate being 100% was actually legitimate and I have resolved it BUT all transactions are still being labelled as unknown.
Description
1 day after switching to the new release all of the transactions are labeled as unknown and the error rate is 100% despite no errors being thrown.
I have opened a forum discussion for this but I have had no response : https://discuss.newrelic.com/t/php-new-relic-completely-broken-after-php-8-1-upgrade/179337
Relevant Logs / Console output
DAEMON STATUS
PHP AGENT LOGS
Daemon logs from today are empty
Your Environment
We are running out of the box newrelic.ini settings and config template
Additional context