Score:0

Sentry with PHP and nginx: errors do not occur in sentry dashboard anymore

gb flag

I am stuck with my nginx (nginx/1.14.2) configuration for a php (php-7.4) App that would normally send error notifications to sentry.

I moved a php application from an apache to nginx server and now my sentry errors are not reported anymore ... what did I do wrong?

here is my nginx config:

server {

    root /var/www/services/some-sesrvice;

    index index.php;

    server_name *****.com;

     access_log /var/log/nginx/some-service.access.log;
     error_log /var/log/nginx/some-service.error.log;

    location / {
        try_files $uri $uri/ /index.php;
    }
    location ~ .php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php-fpm.sock;
    }

    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/*****./fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/*****./privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}
server {
    if ($host = *****.com) {
        return 301 https://$host$request_uri;  
    } # managed by Certbot


    listen 80;
    listen [::]:80;

    server_name *****.com;
    return 404; # managed by Certbot


}

and my php call


    Sentry\init(['dsn' => 'https://*****.ingest.sentry.io/***' ]);
    throw new Exception("Sentry is working on ".$_ENV['ENV']." machine!");

While composer is installed using this composer.json part

"require": {
        "sentry/sdk": "^3.1",
....

Any ideas or any ideas how to debug this?

UPDATE

The error log file finds this (so the error is captured):

2021/07/02 13:22:12 [error] 17232#17232: *193 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught Exception: Sentry is working on TEST machine! in /var/www/services/some-service/Config/sentryloader.php:13
Stack trace:
#0 /var/www/services/some-service/Config/bootstrap.php(15): include()
#1 /var/www/services/some-service/index.php(6): include('/var/www/servic...')
#2 {main}
  thrown in /var/www/services/some-service/Config/sentryloader.php on line 13" while reading response header from upstream, client: ****ip****, server: ****.com, request: "GET /get HTTP/1.1", upstream: "fastcgi://unix:/var/run/php/php-fpm.sock:", host: "****.com"

UPDATE: snippets/fastcgi-php.conf :

# regex to split $uri to $fastcgi_script_name and $fastcgi_path
fastcgi_split_path_info ^(.+?\.php)(/.*)$;

# Check that the PHP script exists before passing it
try_files $fastcgi_script_name =404;

# Bypass the fact that try_files resets $fastcgi_path_info
# see: http://trac.nginx.org/nginx/ticket/321
set $path_info $fastcgi_path_info;
fastcgi_param PATH_INFO $path_info;

fastcgi_index index.php;
include fastcgi.conf;
Michael Hampton avatar
cz flag
Check your PHP error log. Make sure you are actually logging PHP errors and that your code generates messages as appropriate.
gb flag
Checked that already. It does in the defined file. Although the message looks diffetent to apache. Could that be an issue?
Michael Hampton avatar
cz flag
Doesn't that Sentry class log any errors or throw exceptions?!
gb flag
Where can I find them? Somewhere else? The error I posted is all there is in the nginx error log.
Michael Hampton avatar
cz flag
Go look at its documentation.
gb flag
the sentry class must log to the same file as the rest of the php app ... so no it does not throw any exception
Michael Hampton avatar
cz flag
You're getting PHP errors logged though. At this point the problem is going to be with your code or with the third party service it is talking to. You should focus there. You can get help with debugging your code on [so].
gb flag
The code works fine under apache. same code, same sentry id, same error. What would be a major difference between apache and nginx in this context?
gb flag
I came here because the code debugging was my first and already exhaustive phase. So the issue must be either nginx or the invocation of sentry on nginx. As I am not an expert on nginx nor on sentry, I think this is the right stackexchange, right? Michael, it is ok, if you don't know a solution. Maybe someone else has a clue...
mforsetti avatar
tz flag
what's your OS? if you're on CentOS, try SELinux logs. do you have `php-curl` installed already? looks like `sentry/sdk` requires cURL to call its HTTP API.
gb flag
OS is debian 10, ad curl: `php7.4-curl is already the newest version (7.4.20-1+0~20210604.45+debian10~1.gbpfeee62).`
mforsetti avatar
tz flag
try [sending](https://docs.sentry.io/platforms/php/usage/) a message manually, or via `catch`. if the message is shown on Sentry, you probably haven't set your script's [exception handler](https://www.php.net/manual/en/function.set-exception-handler.php) to Sentry's.
gb flag
How would I set that?
gb flag
I tried the sending with in the catch, nothing :/ but maybe i can debug that somehow...
sv flag
Could we have the content of `snippets/fastcgi-php.conf`?
gb flag
@pothi: updated, what would tell me that file? (I have not touched the config after insallation btw. it should all be default values)
mforsetti avatar
tz flag
use `\Sentry\captureMessage('Something went wrong');`. try checking if you haven't use up all your event quota, and [try turning off Spike Protection](https://blog.sentry.io/2018/05/08/event-spike-protection#can-i-turn-spike-protection-off).
gb flag
No no, I have just a view errors reporting the tool so far, and while this specific app setup seem to not report anything, other apps on other servers still report, and also my local replication of the exact same app but on an apache server, can report errors.
gb flag
I also turned off the firewall and checked if this could be an issue - still no ntifications.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.