Puncte:0

Sentry cu PHP și nginx: erorile nu mai apar în tabloul de bord Sentry

drapel gb

Am rămas blocat cu configurația mea nginx (nginx/1.14.2) pentru o aplicație php (php-7.4) care ar trimite în mod normal notificări de eroare către sentinelă.

Am mutat o aplicație php de pe un server apache pe server nginx și acum erorile mele de santinelă nu mai sunt raportate... ce am greșit?

aici este configurația mea nginx:

Server {

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

    index index.php;

    nume_server *****.com;

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

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

    asculta [::]:443 ssl ipv6only=on; # gestionat de Certbot
    asculta 443 ssl; # gestionat de Certbot
    ssl_certificate /etc/letsencrypt/live/*****./fullchain.pem; # gestionat de Certbot
    ssl_certificate_key /etc/letsencrypt/live/*****./privkey.pem; # gestionat de Certbot
    includ /etc/letsencrypt/options-ssl-nginx.conf; # gestionat de Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # gestionat de Certbot

}
Server {
    dacă ($gazdă = *****.com) {
        returnează 301 https://$host$request_uri;  
    } # gestionat de Certbot


    asculta 80;
    asculta [::]:80;

    nume_server *****.com;
    întoarce 404; # gestionat de Certbot


}

și apelul meu php


    Sentry\init(['dsn' => 'https://*****.ingest.sentry.io/***' ]);
    throw new Exception ("Sentry lucrează pe mașina ".$_ENV['ENV'].");

În timp ce compozitorul este instalat folosind această parte composer.json

„necesită”: {
        "sentry/sdk": "^3.1",
....

Aveți idei sau idei despre cum să depanați asta?

ACTUALIZAȚI

Fișierul jurnal de erori găsește acest lucru (deci eroarea este capturată):

2021/07/02 13:22:12 [eroare] 17232#17232: *193 FastCGI trimis în stderr: „Mesaj PHP: PHP Eroare fatală: Excepție neprinsă: Sentry lucrează pe mașina de TEST! în /var/www/services/ some-service/Config/sentryloader.php:13
Urmărirea stivei:
#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 {principal}
  aruncat în /var/www/services/some-service/Config/sentryloader.php pe linia 13" în timp ce citiți antetul răspunsului din amonte, client: ****ip****, server: ****.com, cerere: „GET /get HTTP/1.1”, în amonte: „fastcgi://unix:/var/run/php/php-fpm.sock:”, gazdă: „****.com”

ACTUALIZAȚI: snippets/fastcgi-php.conf :

# regex pentru a împărți $uri în $fastcgi_script_name și $fastcgi_path
fastcgi_split_path_info ^(.+?\.php)(/.*)$;

# Verificați dacă scriptul PHP există înainte de a-l transmite
try_files $fastcgi_script_name =404;

# Ocoliți faptul că try_files resetează $fastcgi_path_info
# vezi: http://trac.nginx.org/nginx/ticket/321
setați $path_info $fastcgi_path_info;
fastcgi_param PATH_INFO $path_info;

fastcgi_index index.php;
include fastcgi.conf;
Michael Hampton avatar
drapel cz
Verificați jurnalul de erori PHP. Asigurați-vă că înregistrați erori PHP și că codul dvs. generează mesaje, după caz.
drapel gb
Am verificat deja. Se întâmplă în fișierul definit. Deși mesajul pare diferit de apache. Ar putea fi o problemă?
Michael Hampton avatar
drapel cz
Clasa aia Sentry nu înregistrează erori sau aruncă excepții?!
drapel gb
Unde le pot găsi? Altundeva? Eroarea pe care am postat-o ​​este tot ce există în jurnalul de erori nginx.
Michael Hampton avatar
drapel cz
Du-te să vezi documentația lui.
drapel gb
clasa sentinelă trebuie să se conecteze la același fișier ca și restul aplicației php ... deci nu, nu aruncă nicio excepție
Michael Hampton avatar
drapel cz
Totuși, primești erori PHP înregistrate. În acest moment, problema va fi cu codul dvs. sau cu serviciul terță parte cu care vorbește. Ar trebui să te concentrezi acolo. Puteți obține ajutor pentru depanarea codului pe [so].
drapel gb
Codul funcționează bine sub apache. același cod, același ID de santinelă, aceeași eroare. Care ar fi diferența majoră între apache și nginx în acest context?
drapel gb
Am venit aici pentru că depanarea codului a fost prima mea fază și deja exhaustivă. Deci problema trebuie să fie fie nginx, fie invocarea sentinei pe nginx. Deoarece nu sunt expert în nginx și nici în sentinelă, cred că acesta este stackexchange-ul potrivit, nu? Michael, e ok, dacă nu știi o soluție. Poate altcineva are o idee...
mforsetti avatar
drapel tz
care este sistemul tau de operare? dacă sunteți pe CentOS, încercați jurnalele SELinux. ai deja instalat `php-curl`? se pare că `sentry/sdk` necesită cURL pentru a-și apela API-ul HTTP.
drapel gb
Sistemul de operare este debian 10, ad curl: `php7.4-curl este deja cea mai nouă versiune (7.4.20-1+0~20210604.45+debian10~1.gbpfeee62).`
mforsetti avatar
drapel tz
încercați să [trimiteți](https://docs.sentry.io/platforms/php/usage/) un mesaj manual sau prin „catch”. dacă mesajul este afișat pe Sentry, probabil că nu ați setat [gestionrul de excepții](https://www.php.net/manual/en/function.set-exception-handler.php) al scriptului dvs. la Sentry.
drapel gb
Cum aș seta asta?
drapel gb
Am încercat trimiterea cu în catch, nimic :/ dar poate reușesc să depanez asta cumva...
drapel sv
Am putea avea conținutul `snippets/fastcgi-php.conf`?
drapel gb
@pothi: actualizat, ce mi-ar spune acel fișier? (Nu am atins configurația după instalare, de altfel, ar trebui să fie toate valorile implicite)
mforsetti avatar
drapel tz
utilizați `\Sentry\captureMessage('Ceva a mers prost');`. încercați să verificați dacă nu ați epuizat toată cota de eveniment și [încercați să dezactivați Spike Protection](https://blog.sentry.io/2018/05/08/event-spike-protection#can-i-turn -protecție-spike-off).
drapel gb
Nu, nu, am doar o vizualizare a erorilor care raportează instrumentul până acum și, în timp ce această configurare specifică a aplicației par să nu raporteze nimic, alte aplicații de pe alte servere raportează în continuare, precum și replicarea mea locală a exact aceeași aplicație, dar pe un server apache. , poate raporta erori.
drapel gb
De asemenea, am dezactivat firewall-ul și am verificat dacă aceasta ar putea fi o problemă - încă fără notificări.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.