Sådan håndteres logfiler i mikrotjenester

Logning er en af ​​de vigtigste dele af softwaresystemer. Uanset om du lige er begyndt at arbejde på et nyt stykke software, eller dit system kører i et stort produktionsmiljø, vil du altid finde dig selv at søge hjælp fra logfiler.

På grund af dette er logfiler det første, udviklere kigger efter, når noget går galt, eller noget ikke fungerer som forventet.

Logning af de rigtige oplysninger på den rigtige måde gør en udviklers liv så meget lettere. Og for at blive bedre til logning skal du vide, hvad og hvordan du logger.

I denne artikel vil vi se på nogle grundlæggende loggingsetiketter, der kan hjælpe dig med at få mest muligt ud af dine logfiler.

Hvad skal jeg logge på, og hvordan fungerer logning?

Lad os starte med et eksempel på et e-handelssystem og se på logning i dets Order Management Service (OMS).

Antag, at en kundeordre mislykkes på grund af en fejl fra Inventory Management Service (IMS), en downstream-tjeneste, som OMS bruger til at verificere den tilgængelige beholdning.

Lad os antage, at OMS allerede har accepteret en ordre. Men under det sidste bekræftelsestrin returnerer IMS følgende fejl, fordi produktet ikke længere er tilgængeligt i beholdningen.

404 Product Not Available

Hvad skal man logge på?

Normalt logger du fejlen på denne måde:

log.error(“Exception in fetching product information - {}”, ex.getResponseBodyAsString())

Dette vil sende en log i følgende format:

[2020-09-27T18:54:41,500+0530]-[ERROR]-[InventoryValidator]-[13] Exception in fetching product information - Product Not Available

Nå, der er ikke meget information tilgængelig i denne logopgørelse, er der? En log som denne tjener ikke meget formål, fordi den mangler kontekstuelle oplysninger om fejlen.

Kan vi tilføje flere oplysninger til denne log for at gøre det mere relevant til fejlfinding? Hvad med at tilføje ordre-id og produkt-id?

log.error("Exception in processing Order #{} for Product #{} due to exception - {}", orderId, productId, ex.getResponseBodyAsString())

Dette vil sende en log i følgende format:

[2020-09-27T18:54:41,500+0530]-[ERROR]-[InventoryValidator]-[13] Exception in processing Order #182726 for Product #21 due to exception - Product Not Available

Nu giver det meget mening! Når vi ser på logfilerne, kan vi forstå, at der opstod en fejl under behandling af ordre nr. 182726, fordi produkt nr. 21 ikke var tilgængeligt.

Sådan logges

Mens ovenstående log giver perfekt mening for os mennesker, er det måske ikke det bedste format til maskiner. Lad os se på et eksempel for at forstå hvorfor.

Antag, at der er et eller andet problem med tilgængeligheden af ​​et bestemt produkt (f.eks. Produkt nr. 21), som alle ordrer, der indeholder det produkt, fejler. Du har fået tildelt opgaven til at finde alle de mislykkede ordrer til dette produkt.

Du gør med glæde et grepfor produkt nr. 21 i dine logfiler og venter spændt på resultaterne. Når søgningen er færdig, får du noget som dette

[2020-09-27T18:54:41,500+0530]-[ERROR]-[InventoryValidator]-[13] Exception in processing Order #182726 for Product #21 due to exception - Product Not Available [2020-09-27T18:53:29,500+0530]-[ERROR]-[InventoryValidator]-[13] Exception in processing Order #972526 for Product #217 due to exception - Product Not Available [2020-09-27T18:52:34,500+0530]-[ERROR]-[InventoryValidator]-[13] Exception in processing Order #46675754 for Product #21 due to exception - Product Not Available [2020-09-27T18:52:13,500+0530]-[ERROR]-[InventoryValidator]-[13] Exception in processing Order #332254 for Product #2109 due to exception - Product Not Available

Ikke helt hvad du forventede, ikke? Så hvordan kan du forbedre dette? Struktureret logning til undsætning.

Hvad er struktureret logning?

Struktureret logning løser disse almindelige problemer og giver loganalyseværktøjer mulighed for at give yderligere muligheder. Logfiler skrevet i et struktureret format er mere maskinvenlige, hvilket betyder, at de let kan parses af en maskine.

Dette kan være nyttigt i følgende scenarier:

  • Udviklere kan søge i logfiler og korrelere begivenheder, hvilket er uvurderligt både under udvikling såvel som til fejlfinding af produktionsproblemer.
  • Forretningsteam kan analysere disse logfiler og udføre analyser over bestemte felter (for eksempel unikt produktantal pr. Dag) ved at udtrække og sammenfatte disse felter.
  • Du kan oprette dashboards (både forretningsmæssige og tekniske) ved at parsere logfilerne og udføre aggregater over relevante felter.

Lad os bruge vores tidligere logopgørelse og foretage en lille ændring for at gøre den struktureret.

log.error("Exception in processing OrderId={} for ProductId={} due to Error={}", orderId, productId, ex.getResponseBodyAsString())

Dette vil sende en log i følgende format:

[2020-09-27T18:54:41,500+0530]-[ERROR]-[InventoryValidator]-[13] Exception in processing OrderId=182726 for ProductId=21 due to Error=Product Not Available

Nu kan denne logmeddelelse let parses af maskinen ved at bruge “=” som en afgrænser for at udtrække OrderId, ProductIdog Errorfelter. Vi kan nu foretage en nøjagtig søgning for ProductId=21at udføre vores opgave.

Dette giver os også mulighed for at udføre mere avanceret analyse på logfilerne, såsom at udarbejde en rapport om alle ordrer, der mislykkedes med sådanne fejl.

Hvis du bruger et loghåndteringssystem som Splunk, kan forespørgslen Error=”Product Not Available” | stats count by ProductIdnu producere følgende resultat:

+-----------+-------+ | ProductId | count | +-----------+-------+ | 21 | 5 | | 27 | 12 | +-----------+-------+

Vi kunne også bruge et JSON-layout til at udskrive vores logfiler i JSON-formatet:

{ "timestamp":"2020-09-27T18:54:41,500+0530" "level":"ERROR" "class":"InventoryValidator" "line":"13" "OrderId":"182726" "ProductId":"21" "Error":"Product Not Available" }

Det er vigtigt at forstå tilgangen bag struktureret logning. Der er ingen fast standard, og det kan gøres på mange forskellige måder.

Konklusion

I denne artikel så vi faldgruberne ved ustruktureret skovhugst og fordelene og fordelene ved struktureret skovhugst.

Loghåndteringssystemer som Splunk er enormt nydt af en velstruktureret logbesked og kan tilbyde nem søgning og analyse på loghændelser.

Den største udfordring er imidlertid, når det kommer til struktureret logning, at etablere et standardsæt med felter til din software. Dette kan opnås ved at følge en brugerdefineret logningsmodel eller centraliseret logning, der sikrer, at alle udviklere bruger de samme felter i deres logmeddelelser.

Tak fordi du har været hos mig indtil videre. Håber du kunne lide artiklen. Du kan få kontakt med mig på LinkedIn, hvor jeg regelmæssigt diskuterer teknologi og liv. Se også på nogle af mine andre artikler. God læselyst. ?