Laravel - Hvordan man laver hændelseslogfiler

Så det er svært at logge nyttige data, og det er stadig sværere at logge nyttige data på en måde, der gør dem tilgængelige. Vi logger ofte kun de undtagelser, der er kastet, fordi det er ruten til problemet, når vi faktisk har brug for at se hele logfilenes historie under en anmodning, ikke kun stakesporet af, hvad der fik applikationen til at gå ned.

Forestil dig dette scenario, din kunde bruger dit websted lykkeligt, og så forsøger de noget for kun at modtage en stor 500-serverfejlside. Der er ingen kontekst på siden, intet der hjælper dem med at løse problemet. Hvis de ikke selv er meget tekniske, er de nødt til at finde en måde at beskrive, hvad de gjorde, da de kontakter din virksomheds support for svar.

Hvad der ville være bedre i stedet er, hvis du kan give din kunde en fejlkode på det tidspunkt, hvor det mislykkes. Derefter kan dit supportteam forsynes med den kode, som en udvikler matcher med loggdataene fra anmodningen, der producerede fejlen. Giver dig et øjeblik, hvor du kan begynde at undersøge.

Når vi udvikler i symfoni, kan vi oprette en “fingre krydset” Monolog-handler, og vi kunne gøre det samme i Laravel, men opsætningen, jeg vil vise dig noget andet, der fungerer, er lidt lettere at konfigurere. I teorien skal dette arbejde med alle Laravel 5.0+ projekter.

Opsætning af en besked logget begivenhedslytter

Til at begynde med er vi nødt til at samle alle logmeddelelser, som de er lavet. Laravels loggingssystem håndterer allerede afsendelsen af ​​disse, så vi behøver kun at lytte til dem. Dette kan opnås med:

php artisan make: listener LoggingListener -e Illuminate \\ Log \\ Events \\ MessageLogged

Rediger derefter lytteren som vist i eksemplet. Vi vil blot tilføje en samling, hvor vi kan skubbe disse MessageLogged-begivenheder til senere brug, hvis der skulle opstå en dødelig undtagelse.

Vi er også nødt til at ændre EventServiceProvider, nemlig lytteegenskapen for at sikre, at MessageLogged-begivenheder bliver leveret til vores nye LoggingListener-lytter.

Vi er også nødt til at gøre vores lytter til en singleton, ellers vil vi ikke kunne få adgang til begivenhederne, som når vi henter lytteren fra containeren, vil vi modtage en lytter med en tom samling. Til dette behøver kun at tilføjes en linje, som jeg har tilføjet til AppServiceProvider.

Ændring af undtagelseshåndtereren

Nu har vi vores samling af MessageLogged-begivenheder, som vi har brug for at ændre vores applikationsundtagelseshåndterer for at rapportere undtagelsen med logfilerne og udsende fejlkoden for brugeren at se. Denne klasse findes i app / Undtagelser / Handler.php, som som standard skal have to metoder derinde, rapportere og gengive.

For hurtigt at opsummere disse to funktioner, sker rapporten først, ideen med den er at være i stand til at sende undtagelsen til en form for ekstern service i tilfælde af en fejl. Du kan læse mere om dette i de officielle dokumenter. Renderfunktionen er simpelthen, hvordan du præsenterer en fejlside for brugeren efter en kritisk fejl. Vi ændrer ikke renderfunktionen, men vi bliver nødt til at ændre processen ved at tilsidesætte renderHttpException-metoden i den overordnede klasse.

Du kan se i rapportfunktionen, jeg har tilføjet en simpel mekanisme til at gemme rapporten på den lokale disk i en json-fil. Dette er udelukkende til demonstrationsformål. Du kan gøre ethvert antal ting med begivenhederne for at gøre det lettere at analysere. Også til at generere et unikt ID vælger jeg simpelthen at bruge str_random, som leveres af Laravel, men i alt ærligt kan du bruge alt, hvad du kan lide, bare sørg for, at det bliver unikt nok til at du ikke ender med flere brugere med det samme kode.

Hvad angår tilføjelse af renderHttpException-metoden, er koden i eksemplet næsten identisk med hvad der findes i den overordnede klasse, bortset fra i stedet for bare at videregive variabelfejlene og undtagelsen til visningen, vi giver nu også en errorCode-variabel.

Tilføjelse af en fejlside for at vise koden

Den sidste del er selvfølgelig, at vi skal have en fejlvisning, der viser den fejlkode, vi genererer.

Eventuelle kastede fejl skulle nu ende med at se på noget som skærmbilledet nedenfor.

Glem ikke på dette tidspunkt, hvis du ikke indstiller APP_DEBUG = sand til APP_DEBUG = falsk i din .env-fil, vil du ikke modtage produktionsfejlmeddelelsen!

En hurtig test

Her er en simpel lille rute, som du kan tilføje til ruter / web.php-test, som dine fejlrapporter genereres.

Denne test opretter to MessageLogged-begivenheder, den første til infolinjen og den anden, når Laravel fanger undtagelsen, hvilket i sidste ende får fejlsiden til at blive vist. Hvis du bruger eksemplekoden, opretter dette en tilsvarende json-fil i lager / app / incident / mappen i dit projekt.

Så nu har du en pålidelig proces til at få vist logfilerne for en enkelt fejl, hvis du har brug for det. Dette har virkelig kun været et eksempel på, hvad der kan gøres. Jeg er ikke i tvivl om, at du kan oprette et utroligt dybtgående system til sporing af hændelser med denne mekanisme.

Du kan finde den fuldt fungerende demokode på github.

Jeg er Peter Fox, en softwareudvikler i England, der blandt andet samarbejder med Laravel. Hvis du vil vide mere om mig, kan du på https://www.peterfox.me og føl dig fri til at følge mig @SlyFireFox på twitter for flere Laravel-tip og -tutorials.