Parsing med Grok

}

Listing 3.5: Filter för borttagning av Filebeats taggar i logstash.conf

3.2.3 Parsing med Grok

Som tidigare beskrivet (se sektion 2.2.5.1, sid. 8) så är Grok ett plugin till Logstash, till för att parsa nyckelord ur texter. Grok använder sig av reguljära uttryck för att hitta och plocka ut dessa nyckelord. Grok har support för många typer av mönster redan från början. Colin Surprenant, en av skaparna av Grok, listar på sin githubsida [18] alla mönster som finns fördefinerade. Dessvärre skiljer sig testdatans mönster från de som finns fördefinerade och kan därför inte läsas med de mönster som redan finns i Grok. Det som i första skedet var intressant att parse:a var huvudet av varje loggmeddelande. Det verktyget utvecklarna på AFRY använder för att skriva till loggen heter SLF4J och med deras inställningar får logghuvudet det format som presenteras i listing 3.1 på sidan 15.

De individuella delarna i logghuvudet är i allra högsta grad av intresse för inläsning.

Att kunna sortera logg-meddelanden med avsende på vilken service det är som skrivit kan underlätta mycket vid felsökning. Det Grok kunde erbjuda var läsning av vissa av de individuella delarna av detta format. Som visat på Surprenants github [18] har Grok fördefinerad reguljära uttryck och kan med dem läsa både timestamp, log_level, och UUID som finns i detta logghuvud, som beskriver tiden då logg-meddelandet skrevs, kategori av loggmeddelandet respektive ett unikt ID. Det Grok inte kunde känna igen var det sista fältet inom parenteser som vi kallar thread_id; samt fältet som

innehåll-20 KAPITEL 3. IMPLEMENTATION er information om från vilken service ett logg-meddelande härstammar som vi kallar log_category. Lösningen på detta var att plocka ut alla tecken (oavsett vad de är) mellan parenteserna som omsluter fälten i formatet och döpa de till just thread_id respektive log_category. Hur detta logghuvud specificerades i ett reguljärt uttryck med hjälp av Grok visas överst i listing 3.6.

I samband med utvecklingen av de reguljära uttrycken för Grok togs även steget in i nästa iteration av projektet. Tidigare hade endast logginlägg skrivna till server-loggen tagits hänsyn till, härefter lästes även inlägg från apache-server-loggen. Dessa logg-typer skiljer sig något, inte minst i formatet av logghuvudet. Detta krävde då speci-ella reguljära uttryck för att matcha även dessa logghuvuden. Den ursprungliga ser-verloggens logghuvud motsvaras av den översta delen av listing 3.6 som defineras som “SERVER_LOGHEAD”. De tre nästkommande definitionerna motsvarar de nya loggtyper som tillkom. Att skriva dessa reguljära uttryck kan vara påfrestande och svårt att förstå sig på. För att underlätta utvecklingen av mönstren som Grok skulle använda utnyttjades webbverktyget Grok Debugger (se sektion 2.4.2, sid. 11).

För att sedan applicera dessa reguljära uttryck behövde logstash konfigureras för att

3.2. IMPLEMENTATION AV ELASTICSTACK 21 använda dem. Uttrycken specificerades i en fil utan filändelse och placerades i en egen mapp där logstash är installerat.

Listing 3.7: Filter för parsning av logghuvuden i logstash.conf

Listing 3.7 visar hur de reguljära uttrycken implementeras i filen logstash.conf.

Notera att de olika definitionerna för logghuvuden är separerade med “|”-tecken som motsvarar en “eller” operator.

Logstash standard utmatning är för varje rad ett individuellt event i json format [19] där varje tagg definieras enligt “key: value”, definitionen kan även observeras i listing 3.6. När Grok har applicerat sina filter kommer även de nya fälten definieras på samma sätt i logstash och elasticsearch vilket tillåter användning, sökning, och sortering.

I varje event i json-filen specificeras också vilken datatyp varje tagg har. Som standard är definitionen av typen string. För att bättre kunna utnyttja den inlästa datamängden är det fördelaktigt att tilldela varje tagg en lämplig datatyp. Ett exempel på detta är taggen payload_size som är en del av logghuvudet i apache-loggen. Denna tagg motsvarar storleken på det paket som skickades då logginlägget skrevs. För att bättre kunna hantera denna tagg är det fördelaktigt att lagra den som ett heltal istället för en string. För att göra denna konvertering av datatyp krävs att detta specificeras i logstash.conf enligt exemplet i listing 3.8.

22 KAPITEL 3. IMPLEMENTATION

Listing 3.8: Konvertering av datatyp för fältet payload_size i logstash.conf

f i l t e r {

Listing 3.9: Omdefiniering av datum i logstash.conf

Listing 3.9 är ett ett annat exempel på konvertering av en typ av tagg. Alla event lagrade i en json-fil har som standard en tidsstämpel. Denna tidsstämpel motsvarar den tid då Filebeat har läst loggen, inte när loggen faktiskt är skriven. I normala fall när Elasticstack appliceras live på en aktiv server är detta inget problem, men i denna PoC används statisk data från tidigare datum som inte alls stämmer överens med när datan läses. För att lösa detta kan tidsstämpeln som parsas från logginlägget konverteras till typen timestamp och låta denna ersätta den ursprungliga tidsstämpeln. För att göra denna konvertering krävs ett plugin till logstash (se sektion 2.2.5.2, sid. 9). Detta plugin kan även hantera de olika formaten på tiden som de olika typerna av loggfilerna har.

Även detta framgår i listing 3.9. Det är även nämnvärt att denna konvertering kan vara

3.2. IMPLEMENTATION AV ELASTICSTACK 23 användbar i driftsatt miljö också. Då läsning av tidigare loggdata kan förekomma, eller om Elasticstack under en kort period varit avstängd är det i allra högsta grad relevant att tagga data med den tid då den faktiskt skrevs och inte när den lästes.

Gemensamt för många av de exemplen i listings ovan är att de är definierade inom filter i logstash.conf. För att förtydliga krävs inte en ny filter-definition för varje funk-tion, det är möjligt att lägga både mutate, date och grok funktionerna inom samma filter.

För fullständigt exempel på filen logstash.conf och exempel på detta, se Bilaga B.