Eftersom vi säljer supportavtal där vi ansvarar för våra kunders webbplatser är det viktigt för oss att ständigt kunna ligga steget före, helst till den nivån där vi kan arbeta proaktivt och hindra allvarliga fel – innan de uppstår. Om någonting händer våra kunders webbplatser förväntas vi kunna svara på varför någonting har hänt, samt se till att det inte händer igen.
Det finns många anledningar till varför saker kan hända. Vi tar ofta över ansvaret för andras webbplatser och dessa kan ha en hel del kvalitetsbrister. En administratör med hög behörighet kan av misstag råkat klicka på fel knapp och på så sätt genomfört en stor förändring. Ett annat inte alltför ovanligt scenario är att webbplatsen är byggd kring färdiga tillägg som efter en tid stöter på kompabilitetsproblem med nyare versioner av WordPress. I vissa fall har vi till och med sett att utvecklare tar bort funktioner ur sina tillägg – vilket kan innebära att en administratör inte kan fullfölja sin arbetsuppgift.
För en organisation som har investerat mycket i sin webbplats är det därför viktigt att webbplatsen testas och övervakas noggrant. För att vara säker på att funktionaliteten fungerar behöver man en mängd olika verktyg. I denna artikel kommer jag att prata om ett av verktygen som vi använder för att säkerställa att saker fungerar – loggövervakning.
Vad är loggövervakning?
Loggövervakning så som vi använder det innebär att vi löpande importerar så mycket logghändelser som möjligt från våra kunders servrar kontinuerligt med ett verktyg som heter Splunk. En ren instans av Splunk innehåller endast rådata, men med hjälp av Splunks gränssnitt och scriptspråk kan vi göra sökningar på vissa typer av händelser. Vi kan sedan visualisera dessa händelser på en mängd olika sätt för att skapa oss en skräddarsydd ”Dashboard” som visar relevant information för just våra ändamål.
Att göra en sökning är mycket enkelt och intuitivt, och med ett par peka-klicka manövrar har man konstruerat en liten widget av sin sökning. Man kan sedan dra runt sina widgets i sin dashboard enkelt med simpel drag-och-släpp. Det finns även en förnämlig funktion för att smidigt och med peka-klicka låta mjukvaran ta fram komplexa regular expressions för att ta fram specifik data ur en komplex datamängd.
Vad kan man visa?
Splunk hjälper oss att visa information om varje server – diskstorlek, processorkraft, processer & användare utan att behöva göra några speciella inställningar. Genom att hämta hem loggfiler kan vi även få en mängd relevant information som berättar viktiga saker för oss gällande kvalité på kundens webbplats, såsom allvarliga fel i kod, bruteforce-attacker, felaktiga rättigheter mm. Det går till och med att förutsäga tendenser. Vad Splunk inte gör direkt är att visa WordPress-specifik information som kan vara relevant för oss. Då vi av prestandaskäl gärna inte vill sätta på debug (felsökningsläge) i en produktionsmiljö så finns det ingen loggdata att tillgå. Vi måste därför själva berätta för WordPress att – och vad – den skall logga. Detta gör vi genom att använda diverse tillägg.
Visa inloggningsförsök med WP fail2ban
En första åtgärd som kan vara bra att göra är att använda fail2ban tillsammans med WP fail2ban. Detta innebär att alla inloggningar som görs till WordPress automatiskt loggas i syslog (och därmed i Splunk).
Med hjälp av den data vi får till Splunk av WP fail2ban kan vi nu göra en enkel sökning för att få ut alla misslyckade inloggningsförsök:
Authentication failure for * from *
Detta visar antagligen en lång rad rådata. Detta är lite svårt att få översikt på, eftersom vi har många kunder. Därför vill vi göra detta till en kurva som visar tendens över tid. I denna kurva vill vi helst att varje maskin skall ha sin egen stapel. Genom att göra några tillägg till vår sökning kan vi få Splunk att göra sökningen så den visar förändring över tid.
Authentication failure for * from * | timechart count by host
Denna visualisering, översatt i dashboard widgets, ger oss något sådant här:
Denna visualisering gjorde att vi enkelt kunde förvandla ”spiken” som man ser i statistiken till ett ärende: Vrid lite på fail2ban inställningarna för att minska antalet bruteforce-försök som inte stoppas av brandväggen till installationen (som då automatiskt appliceras även på WordPress)
Visa potentiella problem med Angry Creative Inspector
Vi har tillverkat ett eget tillägg (som för närvarande är en Alpha / Beta) Angry Creative Inspector, som berättar saker för Splunk som vi av erfarenhet vet kan vara viktiga.
Vi har sorterat in saker i tre sorters kategorier:
- Notice
- Warning
- Error
En Notice är någonting som inte är någon fara – man kan kolla på detta när man hinner. En Warning är någonting som man antagligen vill fixa ganska snart. Ett Error-meddelande är någonting man vill titta på med omedelbar verkan.
För närvarande klarar AC Inspectorn att rapportera följande händelser:
- Multisite kompatibel
- Site aktivering / deaktivering (Multisite)
- Plugin aktivering / deaktivering
- Filrättigheter (Plugins & Uppladdningar)
- Kollar om produktionsserver har fel konstanter (tex DISALLOW_FILE_MODS)
Här finns det mycket att göra och vi mottar med glädje hjälp att vidareutveckla pluginet. Några av våra mål är:
- Tydligt genomgående format på loggar
- Sanitetskontrollera filträd
- En administratör ska kunna bestämma loggformat själv
- En administratör ska kunna skapa en lista över kritiska plugins
- En administratör ska kunna se i loggarna om sökmotorindexeringen blockeras
Hur gör vi då för att använda Angry Creative Inspector ihop med Splunk? Vi söker helt enkelt i Splunk på dess olika loggnivåer och visualiserar dessa i en dashboard. Detta är så vi har valt att göra det, eftersom ett litet fel kan trigga kanska många Notice/Warning/Error meddelanden. Vår sökning ser då ut ungefär såhär:
"[AC_Inspector]" "NOTICE" | timechart count by host
Lägger vi in den sökningen samt gör lite olika typer av datumbegränsningar för till exempel det senaste dygnet så får vi en dashboard i Splunk där vi mycket snabbt och smidigt kan se vad som händer i vår miljö utan att behöva gräva särskilt djupt i loggarna. Det innebär att vår dashboard i Splunk kanske ser ut ungefär såhär:
Slutsats
Sammanfattningsvis fungerar Splunk som ett utmärkt verktyg för att snabbt kunna felsöka och åtgärda problem som uppstår i våra WordPress installationer. Splunk löser problemet med HUR vi kan genomföra detta på ett bra sätt, och ersätter det med en större utmaning: att veta VAD man skall titta efter och visualisera.