Fejlrapportering og logging i din webapp: Sentry, Flare og Ray

Fejlrapportering i en webapp betyder at fejl bliver fanget og sendt til udvikleren i det sekund de sker, sammen med de oplysninger der skal til for at rette dem. Sentry og Flare gør det på din app i drift, mens Ray er et værktøj udvikleren bruger på sin egen computer til at finde årsagen. Til en ren Laravel-app peger jeg typisk på Flare, og består din løsning af flere teknologier, er Sentry det sikre valg.

Ray er et af de værktøjer jeg selv bruger, og Ray og Flare kommer fra samme firma, belgiske Spatie. Det er godt at have i baghovedet når du læser sammenligningen.

Den korte version

Min tommelfingerregel: Er appen bygget i Laravel, og er resten JavaScript, så start med Flare. Har du kode i flere sprog, fx en native mobilapp eller en tjeneste i Python, så vælg Sentry. Ray er ikke et alternativ til nogen af dem. Det er et værktøj din udvikler bruger ved siden af.

Fejlrapportering er ét af flere lag i den løbende drift. Hvordan det hænger sammen med opdateringer, backup og support, har jeg samlet i guiden til drift og vedligehold af webapps.

Fejlrapportering, logging og fejlsøgning løser tre forskellige opgaver

Ordene bliver ofte brugt i flæng, men de dækker over tre forskellige ting, og du har typisk brug for alle tre.

Fejlrapportering fanger undtagelser, altså de steder hvor koden stopper fordi noget uventet skete. Værktøjet samler ens fejl i én sag, så 300 brugere der rammer den samme fejl, bliver til én sag med et tal på. Første gang en ny fejl dukker op, sender det en alarm. Hver sag har en stacktrace (listen over de kodelinjer der blev kørt lige før fejlen), oplysninger om browser og bruger og de handlinger der førte til fejlen.

Logging er appens dagbog. Koden skriver løbende beskeder om hvad den laver: at en betaling blev startet, at en synkronisering med økonomisystemet hentede 40 fakturaer, eller at et login blev afvist. Laravel har logging indbygget og kan ifølge Laravels dokumentation om logging skrive til filer, systemets log, Slack og eksterne tjenester. Loggen er især nyttig når der ikke opstår en fejl, men noget alligevel er galt, fx en mail der aldrig blev sendt.

Fejlsøgning er det udvikleren gør når fejlen skal findes og rettes. Her kommer Ray ind. I stedet for at skrive midlertidige udskrifter i koden og lede efter dem i browseren eller loggen, sender udvikleren værdier, databaseforespørgsler og mails til et separat vindue. Det retter ikke fejlen, men det forkorter tiden fra "jeg kan se fejlen" til "den er rettet".

De tre lag arbejder sammen. Flare eller Sentry fortæller at der er en fejl og hvor den sidder. Loggen viser hvad der skete op til. Ray hjælper udvikleren med at genskabe og rette den lokalt.

Hvorfor fejl skal fanges før brugerne melder dem

Uden fejlrapportering er dine brugere dit alarmsystem. Det er et dårligt alarmsystem af tre grunde.

Mange brugere skriver aldrig. De prøver igen, giver op eller finder en omvej. I en B2B-app kan det betyde at en medarbejder hos din kunde bruger en halv time om ugen på at arbejde uden om fejlen, og at irritationen hober sig op indtil den dukker op ved næste forhandling om aftalen.

Når meldingen endelig kommer, er den sen og uden detaljer. En typisk besked lyder "det virker ikke", og så skal udvikleren bruge tid på at gætte sig frem til hvilken side, hvilken bruger og hvilket tidspunkt det drejer sig om. Den tid betaler du for.

Du opdager heller ikke mønstre. En fejl der rammer en lille del af betalingerne, ligner tilfældigheder set fra supporten. I et værktøj til fejlrapportering er det en sag med et tal der vokser.

Den største gevinst kommer lige efter en ny version er sat i drift. Med fejlrapportering kan udvikleren se inden for minutter om ændringen har skabt nye fejl, og rulle tilbage før de fleste brugere når at mærke det. For dig betyder det færre supporthenvendelser og at du kan nå at kontakte dine egne kunder før de kontakter dig.

Er hele appen nede, er det en anden situation. Til den har jeg skrevet en nødplan til når din hjemmeside eller app er nede.

Sentry, Flare og Ray i praksis

Sentry: bredest understøttelse

Sentry understøtter de fleste sprog og platforme, fra PHP og JavaScript til Python, iOS og Android. Har du en Laravel-backend, en Next.js-frontend og en mobilapp, kan alle tre sende fejl til samme sted, og du kan følge en fejl fra telefonen hele vejen til den kodelinje på serveren der fejlede.

Ifølge Sentrys prisside er Developer-planen gratis for én bruger og 5.000 fejl om måneden. Team-planen koster $26 om måneden ved årlig betaling og har ubegrænset antal brugere og 50.000 fejl. Logs er med i alle planer med 5 GB inkluderet. Sentry kan gemme dine data i Frankfurt, men valget træffes når organisationen oprettes og kan ikke ændres bagefter.

Bagsiden er at Sentry kan meget. Der er mange indstillinger, og prisen afhænger af mængden af fejl, logs og målinger af ydeevne. Det kræver lidt opmærksomhed at holde regningen forudsigelig.

Flare: bygget til Laravel

Flare er lavet af Spatie, som står bag mange udbredte pakker i Laravel-miljøet. Det kan mærkes i detaljerne. Flare har indbygget understøttelse af køer, job og Livewire og viser fejlene på en måde der passer til hvordan en Laravel-app er bygget. På frontend-siden fanger det fejl i JavaScript, React, Vue og Svelte.

På Flares prisside starter Hobby ved $9 om måneden for 10.000 fejl, men kun til ét projekt og én bruger. Standard koster $29 om måneden for 100.000 fejl med ubegrænset antal projekter og brugere. Alle planer har fejl, ydeevne og logs, data gemmes i 30 dage, og der er 10 dages gratis prøveperiode uden betalingskort. Flare tilbyder en databehandleraftale.

Bagsiden er at Flare er smallere. Har du kode i sprog der hverken er PHP eller JavaScript, skal den del have et andet værktøj, og så er det ofte enklere at samle det hele i Sentry.

Ray: udviklerens værktøj, ikke din alarm

Ray er en desktopapp til Mac, Windows og Linux. Udvikleren sender værdier, databaseforespørgsler, mails, hændelser og tidsmålinger fra koden til et separat vindue. Ray virker med Laravel, ren PHP, JavaScript, Vue, React og WordPress. Ifølge Rays egen side koster en licens $49 og gælder i et år, og prøveversionen viser op til 20 beskeder pr. session.

Ray er en del af min egen værktøjskasse i Laravel-projekter. Det er især nyttigt til at genskabe en fejl lokalt og til at se præcis hvilke databaseforespørgsler en side kører. Er dit problem at appen er langsom snarere end at den fejler, så se min gennemgang af hvorfor en webapp bliver langsom.

For dig som kunde er pointen enkel: jo hurtigere udvikleren finder årsagen, jo færre timer betaler du for. Men Ray fanger intet når appen kører hos dine brugere. Den bør kun installeres som udviklingspakke, så den slet ikke kommer med på produktionsserveren.

Hvad skal du vælge til din webapp?

Sådan ville jeg typisk vælge ud fra hvordan løsningen er bygget:

Laravels eget værktøj Nightwatch kan også fange fejl og er et reelt alternativ til Laravel-apps. Det gennemgår jeg sammen med værktøjer til oppetid og baggrundsjob i oversigten over værktøjer til overvågning af din webapp.

Det vigtigste valg er dog ikke værktøjet. Det er hvem der får alarmen, og hvad de gør med den. En fejlrapport der lander i en indbakke som ingen læser, er lige så meget værd som ingen fejlrapport. Lige så vigtigt er det at fjerne støj: kendte fejl der ikke betyder noget, fejl fra browserudvidelser hos den enkelte bruger og fejl fra testmiljøet. Ellers lærer alle hurtigt at ignorere alarmerne.

Hvornår hvert værktøj ikke passer

Sentry er for meget hvis du har en ren Laravel-app og et lille team der bare vil have fejlene serveret uden at lære et stort værktøj at kende. Har appen meget trafik og mange fejl, kan prisen også blive svær at forudsige, hvis ingen holder øje med forbruget.

Flare passer ikke hvis en væsentlig del af løsningen er skrevet i andre sprog end PHP og JavaScript, eller hvis du har en native mobilapp hvor nedbrud skal rapporteres. Så ender du med to værktøjer, og det er sjældent bedre end ét.

Ray passer ikke som overvågning. Det kan ikke se hvad der sker hos dine brugere, og det giver ingen alarmer. Det er heller ikke nødvendigt for alle udviklere. Laravel Debugbar og Telescope er gratis alternativer, og nogle foretrækker en klassisk debugger. Valget af lokalt værktøj er udviklerens, ikke dit.

Og så den ærlige del: Har du en enkel hjemmeside uden login, betalinger eller baggrundsjob, behøver du sandsynligvis ikke fejlrapportering. En gratis oppetidstjeneste der giver besked hvis siden er nede, er nok. Har du allerede en udvikler der står for driften, bør det også være den udvikler der sætter værktøjet op, fordi den der retter fejlene, skal eje opsætningen.

Persondata i fejlrapporter: tjek det fra start

En fejlrapport kan indeholde navn, mailadresse, IP-adresse og det brugeren skrev i en formular lige før fejlen. Det er persondata, og udbyderen af værktøjet bliver din databehandler. Det er lettere at sætte op rigtigt fra start end at rydde op bagefter.

• Indgå en databehandleraftale med udbyderen, før værktøjet går live.
• Vælg hvor data skal ligge. Hos Sentry skal EU-regionen vælges når organisationen oprettes.
• Fjern følsomme felter som adgangskoder, CPR-numre og betalingsoplysninger, før de bliver sendt. Både Sentry og Flare har indstillinger til det.
• Sæt en fornuftig opbevaringstid. Flare gemmer data i 30 dage, og Sentry giver 30 dages historik på den gratis plan og op til 90 dage på Team-planen.
• Nævn værktøjet i din privatlivspolitik.

Jeg er udvikler og ikke jurist, så få en rådgiver til at se på det hvis du behandler følsomme oplysninger.

Næste skridt: sådan kommer du i gang

1. Beslut hvem der reagerer på alarmer, og hvor hurtigt. Hvad der bør stå i aftalen, har jeg samlet i tjeklisten til en serviceaftale med en udvikler.
2. Vælg værktøj ud fra hvad løsningen er bygget i: Flare til Laravel og JavaScript, Sentry hvis du har flere sprog eller en mobilapp.
3. Opret kontoen i virksomhedens navn, og inviter udvikleren som bruger.
4. Sæt det op i både backend og frontend, med testmiljø og drift adskilt.
5. Gennemgå fejlene efter to uger. Skjul de fejl der bare er støj, og ret dem der rammer flest brugere.

Vil du have en udvikler der både sætter fejlrapporteringen op og retter det den finder, kan du se hvordan jeg arbejder med vedligehold og videreudvikling af webapps.

Ofte stillede spørgsmål

Kan jeg ikke bare nøjes med Laravels logfiler?+

Kun hvis nogen læser dem jævnligt. Logfiler på serveren giver ingen alarm, de samler ikke ens fejl, og det er svært at se om en fejl rammer én eller tusind brugere. Til et lille internt værktøj kan en logkanal der sender kritiske fejl til Slack være nok i starten. Har appen betalende kunder, er et rigtigt værktøj til fejlrapportering billigere end den tid det tager at lede i logfiler.

Gør fejlrapportering min app langsommere?+

Næsten ikke, når det er sat rigtigt op. Selve fejlrapporten sendes kun når der sker en fejl. Måling af ydeevne koster lidt mere, fordi værktøjet registrerer forespørgsler løbende, men du kan som regel nøjes med at måle en del af trafikken. Mærker brugerne en forskel, er det typisk et tegn på at opsætningen skal justeres, ikke at værktøjet skal fjernes.

Skal fejlrapportering også køre i testmiljøet?+

Ja, men adskilt fra drift. Når testmiljøet sender fejl til samme værktøj, fanger du problemer før en ny version når ud til brugerne. Mærk fejlene med det miljø de kommer fra, og sæt alarmerne op så kun fejl fra drift vækker nogen. Ellers drukner de vigtige alarmer i støj fra test.

Hvem skal eje kontoen hos Sentry eller Flare?+

Din virksomhed. Opret kontoen med en fælles mailadresse og et betalingskort i virksomhedens navn, og inviter udvikleren som bruger. Så beholder du fejlhistorikken og alarmerne hvis du skifter udvikler, på samme måde som du bør eje koden, domænet og serveren. Det gør det også lettere for en ny udvikler at komme i gang.