Slik setter du opp og leser av logg i WordPress for å finne feil og angrep raskere

Mange feilsituasjoner i WordPress føles tilfeldige: siden er treg, innloggingen feiler av og til, eller et plugin slutter å fungere uten tydelig grunn. Uten gode logger blir feilsøking fort gjetting.

Med en enkel logg-strategi får du en «svart boks-opptaker» for nettstedet ditt. Da kan du se hva som skjedde rett før en feil, oppdage angrepsforsøk tidligere og ta mer informerte valg om hvilke tiltak som faktisk virker.

Hva slags logging trenger et vanlig WordPress-nettsted?

Du kan drukne i detaljer hvis du slår på alt som finnes av logging. Målet er ikke å lagre absolutt alt, men å ha nok informasjon til å forstå hva som skjer når noe går galt.

For de fleste nettsteder er dette et fornuftig utgangspunkt:

• PHP-feillogg (for «white screen», 500-feil og plugin-problemer)
• Webserver-logg (trafikk, 404-feil, mistenkelige forespørsler)
• WordPress-spesifikk logg (innlogginger, administratorhandlinger, plugin-endringer)
• Sikkerhetslogg fra et sikkerhetsplugin (forsøk på innlogging, blokkeringer, skanninger)

Slik slår du på innebygd feillogging i WordPress

WordPress har en innebygd feillogg som ofte er nok for å avdekke vanlige PHP- og plugin-feil. Du aktiverer den iwp-config.php-filen i roten av installasjonen.

Før du endrer noe: ta en sikkerhetskopi av filen, og gjør endringen i et testmiljø hvis du har mulighet. Små tastefeil i wp-config.php kan gjøre hele nettstedet utilgjengelig.

Eksempel på fornuftig feil-logging i wp-config.php

Se etter linjen som definererWP_DEBUG. Hvis den ikke finnes, kan du legge til dette rett før linjen som sier/* That’s all, stop editing! Happy blogging. */:

Eksempeloppsett for et produksjonsmiljø:

• WP_DEBUGsettes til true for å aktivere intern feilhåndtering
• WP_DEBUG_LOGsettes til true for å skrive til loggfil
• WP_DEBUG_DISPLAYsettes til false, så feil ikke vises til besøkende

Loggfilen havner normalt iwp-content/debug.log. Denne filen bør ikke være offentlig tilgjengelig, så kontroller at den ikke kan lastes ned direkte i nettleseren.

Hvor finner du serverloggene dine?

De viktigste loggene ligger vanligvis hos driftsleverandøren din. Nøyaktig plassering varierer, men du kan ofte finne dem i kontrollpanelet for hosting eller via filtilgang.

Vanlige logger du bør kjenne til:

• access.log: alle forespørsler til nettstedet (URL-er, IP-adresser, statuskoder)
• error.log: serverfeil, PHP-feil og enkelte konfigurasjonsproblemer

Hvis du er usikker på hvor du finner disse, sjekk dokumentasjonen til hosting-leverandøren, eller spør support om «tilgang til Apache/Nginx access og error logs».

Når lønner det seg å bruke et logging- eller sikkerhetsplugin?

Serverlogger og debug.log er tekniske og kan være tunge å lese. For mindre redaksjoner er ofte et plugin den enkleste veien til oversikt over hva som skjer i WordPress-delen av nettstedet.

Typiske behov der et plugin er nyttig:

• Du vil se hvem som har publisert, endret eller slettet innhold
• Du vil følge med på innloggingsforsøk og rolleendringer
• Du vil ha varsler ved uvanlige hendelser, for eksempel mange mislykkede innlogginger

Hva bør du se etter i et aktivitetslogg-plugin?

Det finnes flere alternativer, og ingen passer alle. Se etter:

• Mulighet til å filtrere på hendelsestyper (innlogging, innhold, system)
• Enkel måte å eksportere eller slette gamle logger på
• God dokumentasjon og jevnlige oppdateringer
• Mulighet for å begrense hvem som kan se loggene

Typiske situasjoner der logging sparer deg for timer

1. Etter en plugin- eller temaoppdatering blir siden hvit
Første steg er å sjekkedebug.logogserverens error.log. Ofte vil du se en konkret PHP-feil, for eksempel en funksjon som mangler eller en fil som ikke kan lastes. Det peker deg direkte til synderen.

2. Nettsiden er plutselig treg uten åpenbar grunn
Her er kombinasjonen avaccess.logog eventuelt sikkerhetslogg nyttig. Kanskje ser du mange forespørsler mot en spesifikk URL, en flom av XML-RPC-kall eller bots som tråler gjennom hele nettstedet raskt.

3. Noe innhold er borte, men ingen «innrømmer» å ha slettet det
Et aktivitetslogg-plugin kan ofte vise hvem som slettet eller endret innlegget, når det skjedde og fra hvilken IP-adresse. Det gjør det lettere å rydde opp og eventuelt justere rettigheter og rutiner.

Enkel rutine for gjennomgang av logger

Logging er lite verdt hvis ingen ser på den. Du trenger ikke sitte og stirre på loggfiler, men litt struktur gjør stor forskjell:

• Sett av et fast tidspunkt, for eksempel en gang i uken, til å kikke raskt gjennom aktivitetsloggen
• Sjekk serverens error.log når du opplever treghet eller feil
• Noter større mønstre, for eksempel gjentatte mislykkede innlogginger mot samme brukernavn
• Rydd bort eller arkiver gamle loggfiler med jevne mellomrom, så de ikke vokser ubegrenset

Unngå vanlige feil med logging

Noen fallgruver går igjen:

• WP_DEBUG_DISPLAY står på i produksjon: da kan besøkende se tekniske detaljer som ikke bør deles. Sørg for at feil ikke vises direkte i nettleseren.
• Loggfiler blir offentlige: filer som debug.log bør ikke være tilgjengelige via nettadressen. Test med nettleseren og steng eventuelt tilgangen via serveroppsett.
• For mye detaljert logging: ekstremt detaljnivå gir store filer og vanskelig oversikt. Start moderat, og øk nivået midlertidig ved konkrete feilsituasjoner.

Få mer verdi ut av loggene over tid

Detaljnivået du trenger vil variere med størrelse og kompleksitet på nettstedet. Det viktigste er at du har en grunnleggende logg på plass før noe går galt, ikke etterpå.

Hvis nettstedet er forretningskritisk, kan det være aktuelt å koble loggene til et eget logg- eller overvåkingssystem. Da blir det enklere å søke, varsle og lagre historikk over lengre tid. Sjekk med driftsleverandøren din hvilke alternativer som finnes.

Uansett løsning, sørg for at minst én person i teamet vet hvor loggene ligger, hvordan de ser ut og hvem som har ansvar for å følge med. Bare det gir et tydelig løft i kvaliteten på feilsøking og sikkerhetsarbeid.