Java >> Java tutorial >  >> Tag >> Spring

Log på Spring Boot Microservices

Logning er en vigtig del af virksomhedsapplikationer. Logning hjælper ikke kun med at undersøge et problem, men hjælper også med at opbygge relevante metrikker. Disse målinger er vigtige fra et forretningsperspektiv. Faktisk skriver virksomheder serviceniveauaftaler (SLA) ved hjælp af disse metrics. I dette indlæg vil vi tale om at logge på Spring Boot-baserede Microservices.

Hvis du er ny til Spring Boot og Microservices, vil jeg anbefale at læse om Spring Boot og Microservices.

Hvorfor logger vi, og hvad logger vi?

Produktionsniveau-applikationerne kan fejle når som helst af forskellige årsager. For at en udvikler skal undersøge sådanne problemer rettidigt, bliver det afgørende at have logfiler tilgængelige. Logfiler er en nøgle til gendannelse af programmer.

Spørgsmålet kommer, hvad logger vi? Udviklere, softwarearkitekter investerer nok tid til at beslutte, hvad der skal logges. Det er lige så vigtigt ikke at logge en masse information. Du ønsker ikke at miste kritisk information. Åbenbart bør man ikke logge nogen af ​​PII (Personal Identificable Information). Et paradigme, som udviklere kan bruge, er "Hvad vil hjælpe mig med at undersøge problemer i koden, hvis applikationen fejler?". Især hvis en kritisk forretningsbeslutning skal kommenteres i koden, er det en lige så holdbar mulighed at logge denne beslutning.

Samtidig kan man bruge et tilfældigt genereret sporings-id i loggene til at spore anmodning-svaret. Den sværeste del er at bevare denne idé gennem hele programmets levetid.

Logføring og observerbarhed

Mikrotjenester kommunikerer med eksterne API'er, andre mikrotjenester. Fremover er det vigtigt at logge detaljerne i sådan kommunikation. I hændelsesdrevne mikrotjenester kan man logge detaljer om hændelser. Med cloud-infrastruktur er det blevet nemmere at logge detaljer fra mikrotjenester. Cloud-infrastruktur som AWS tilbyder CloudWatch til at indsamle disse logfiler og derefter bruge ELK-stakken til at overvåge logfilerne. Observerbarhedsværktøjer som New Relic, Sumo Logic forbinder dog med forskellige cloud-infrastrukturer. De indsamler logfiler og tilbyder fleksibilitet til at vise, forespørge og bygge metrics baseret på logfiler.

Derfor har udviklere nok værktøjer til at logge data fra applikationer for at forbedre sporbarhed og fejlfinding.

Log ind Spring Boot-baserede mikrotjenester

Lad os se på logningen i en Spring Boot-baseret mikroservice. Vi vil oprette en simpel mikroservice og vise, hvilken slags logningskonfiguration vi kan bruge.

Vores hovedklasse ser ud som nedenfor:

package com.betterjavacode.loggingdemo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class LoggingdemoApplication {

	public static void main(String[] args) {
		SpringApplication.run(LoggingdemoApplication.class, args);
	}

}

Som udgangspunkt har mikrotjenesten ikke noget i øjeblikket. Uanset hvad har vi en hovedklasse, og vi vil se, hvordan logningen kommer ind i billedet.

Som en del af applikationen har jeg inkluderet en enkelt afhængighed

implementation 'org.springframework.boot:spring-boot-starter-web'

Denne afhængighed inkluderer også spring-boot-starter-logging . spring-boot-starter-logging er en standard logkonfiguration, som Spring Boot tilbyder. Vi vil undersøge flere detaljer.

Standard logføringskonfiguration

spring-boot-stater-logging afhængighed omfatter slf4j som en skovningsfacade med logback som logningsramme.

SLF4J er en skovningsfacade, som en række rammer understøtter. Fordelen ved at bruge denne facade er, at vi nemt kan skifte fra en ramme til en anden. Logback er standardrammerne i enhver spring boot-applikation, men vi kan nemt skifte til Log4j, Log4J2 eller Java Util Logging.

spring-boot-starter-logging inkluderer de nødvendige broer, der tager logfiler fra andre afhængigheder og uddelegerer dem til logningsrammerne.

Konfiguration af logback-logning

Analogt med det, vi tilføjede som en mikrotjeneste og standardlogningen, vil vi se, hvordan vi kan bruge logback-logningskonfigurationen. Hvis vi ikke leverer nogen konfiguration, vil spring boot bruge standardkonfigurationen for logback . Det vil tilføje logfilerne til konsollen med logniveauet som info . Logningsrammer hjælper os med at udbrede logfilerne til forskellige mål såsom konsoller, filer, databaser eller endda Kafka.

Med konfigurationsfilen (logback-spring.xml ), kan vi også indstille mønsteret for beskeder. Hvis du vil bruge log4j2 i stedet for at logge tilbage, kan du læse dette indlæg om logning og fejlhåndtering.

Følgende konfigurationsfil viser, hvordan vi logger:

<configuration>
    <property name="LOGDIRECTORY" value="./logs" />
    <appender name="Console" class="ch.qos.logback.core.ConsoleAppender">
        <layout class="ch.qos.logback.classic.PatternLayout">
            <Pattern>
                %black(%d{ISO8601}) %highlight(%-5level) [%blue(%t)] %yellow(%C{1.}): %msg%n%throwable
            </Pattern>
        </layout>
    </appender>
    <appender name="RollingFile" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>${LOGDIRECTORY}/microservice.log</file>
        <encoder
                class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
            <Pattern>%d %p %C{1.} [%t] %m%n</Pattern>
        </encoder>

        <rollingPolicy
                class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <fileNamePattern>${LOGDIRECTORY}/archived/microservice-%d{yyyy-MM-dd}.%i.log
            </fileNamePattern>
            <timeBasedFileNamingAndTriggeringPolicy
                    class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP">
                <maxFileSize>5MB</maxFileSize>
            </timeBasedFileNamingAndTriggeringPolicy>
        </rollingPolicy>
    </appender>
    <root level="info">
        <appender-ref ref="RollingFile" />
        <appender-ref ref="Console" />
    </root>

    <logger name="com.betterjavacode" level="debug" additivity="false">
        <appender-ref ref="RollingFile" />
        <appender-ref ref="Console" />
    </logger>
</configuration>

Vi vil dissekere denne fil for at forstå, hvad hver linje i konfigurationen gør.

Først konfigurerede vi en egenskab LOGDIRECTORY peger på en fysisk mappe på maskinen, hvor logfiler vil blive gemt. Vi bruger denne egenskab i appender og rollingPolicy .

Forskellige muligheder for logning

Efterfølgende bruger vi appender fra Logback-konfiguration til at konfigurere, hvor vi vil tilføje vores logfiler. I dette tilfælde har vi konfigureret til Console og File .

For ConsoleAppnder , vi bruger et mønster af meddelelser, der inkluderer en dato og tid i sort farve, logniveau i blåt, pakke i gul farve. Logmeddelelsen vil have standardfarven.

For RollingFileAppender , har vi en linje, der angiver, hvad der vil være filnavnet, og hvor det vil blive gemt. I dette tilfælde logger vi på microservice.log i LOGDIRECTORY . Den næste linje angiver mønsteret for logmeddelelsen.

  • %d – DatoTid
  • %p – mønster på logniveau
  • %C – Klassenavn
  • %t – tråd
  • %m – besked
  • %n – linjeseparator

Derefter definerer vi RollingPolicy . Vi vil sikre os, at vi ikke logger oplysningerne i en enkelt fil, og den bliver ved med at vokse i størrelse. Vi udløser udrulningen af ​​logfilen, når den når en filstørrelse på 5 MB og gemmer den gamle fil i arkivbiblioteket med navnet microservice-date-number.log .

For at komme videre, vil vi diskutere logniveauet i næste afsnit.

Konfiguration af logniveau

Den sidste del af konfigurationsfilen angiver logniveau. På rodniveau logger vi alt på INFO niveau. Grundlæggende vil vores applikation logge alle de beskeder, der er skrevet med INFO logniveau i koden.

Men den næste konfiguration giver os mulighed for at indstille logniveauet på pakken. I pakken, der starter med com.betterjavacode , log alle de beskeder, der er på DEBUG niveau.

Udførelse af Spring Boot-applikationen

Nu vil vi se på, hvordan dette vil være i vores demo-mikrotjeneste.

Jeg har en simpel RestController i min applikation, der henter company oplysninger som nedenfor:

 package com.betterjavacode.loggingdemo.controller;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

import java.util.ArrayList;
import java.util.List;

@RestController
@RequestMapping("/v1/companies")
public class CompanyController
{
    private static final Logger LOGGER = LoggerFactory.getLogger(CompanyController.class);
    @GetMapping
    public List getAllCompanies()
    {
        LOGGER.debug("Getting all companies");

        List result = new ArrayList<>();

        result.add("Google");
        result.add("Alphabet");
        result.add("SpaceX");

        LOGGER.debug("Got all companies - ", result);

        return result;
    }
}

Kør nu vores applikation og få adgang til API http://localhost:8080/v1/companies/ , vil vi få listen over virksomheder, men vi vil også være i stand til at se log-on-konsollen som nedenfor:

Logfilen vil se ud som nedenfor:


2021-12-04 18:20:32,221 INFO org.springframework.boot.StartupInfoLogger [main] Starting LoggingdemoApplication using Java 1.8.0_212 on YMALI2019 with PID 3560
2021-12-04 18:20:32,223 DEBUG org.springframework.boot.StartupInfoLogger [main] Running with Spring Boot v2.6.0, Spring v5.3.13
2021-12-04 18:20:32,224 INFO org.springframework.boot.SpringApplication [main] No active profile set, falling back to default profiles: default
2021-12-04 18:20:33,789 INFO org.springframework.boot.web.embedded.tomcat.TomcatWebServer [main] Tomcat initialized with port(s): 8080 (http)
2021-12-04 18:20:33,798 INFO org.apache.juli.logging.DirectJDKLog [main] Initializing ProtocolHandler ["http-nio-8080"]
2021-12-04 18:20:33,799 INFO org.apache.juli.logging.DirectJDKLog [main] Starting service [Tomcat]
2021-12-04 18:20:33,799 INFO org.apache.juli.logging.DirectJDKLog [main] Starting Servlet engine: [Apache Tomcat/9.0.55]
2021-12-04 18:20:33,875 INFO org.apache.juli.logging.DirectJDKLog [main] Initializing Spring embedded WebApplicationContext
2021-12-04 18:20:33,875 INFO org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext [main] Root WebApplicationContext: initialization completed in 1580 ms
2021-12-04 18:20:34,212 INFO org.apache.juli.logging.DirectJDKLog [main] Starting ProtocolHandler ["http-nio-8080"]
2021-12-04 18:20:34,230 INFO org.springframework.boot.web.embedded.tomcat.TomcatWebServer [main] Tomcat started on port(s): 8080 (http) with context path ''
2021-12-04 18:20:34,239 INFO org.springframework.boot.StartupInfoLogger [main] Started LoggingdemoApplication in 2.564 seconds (JVM running for 3.039)
2021-12-04 18:20:34,242 INFO com.betterjavacode.loggingdemo.LoggingdemoApplication [main] After starting the application.........
2021-12-04 18:20:39,526 INFO org.apache.juli.logging.DirectJDKLog [http-nio-8080-exec-1] Initializing Spring DispatcherServlet 'dispatcherServlet'
2021-12-04 18:20:39,526 INFO org.springframework.web.servlet.FrameworkServlet [http-nio-8080-exec-1] Initializing Servlet 'dispatcherServlet'
2021-12-04 18:20:39,527 INFO org.springframework.web.servlet.FrameworkServlet [http-nio-8080-exec-1] Completed initialization in 0 ms
2021-12-04 18:20:39,551 DEBUG com.betterjavacode.loggingdemo.controller.CompanyController [http-nio-8080-exec-1] Getting all companies
2021-12-04 18:20:39,551 DEBUG com.betterjavacode.loggingdemo.controller.CompanyController [http-nio-8080-exec-1] Got all companies - [Google, Alphabet, SpaceX]

Sporing af anmodningerne

Tidligere har jeg sagt, hvorfor vi logger. Når der er flere mikrotjenester, og hver mikrotjeneste kommunikerer med andre og eksterne API'er, er det vigtigt at have en måde at spore anmodningen på. En af måderne er at konfigurere et mønster i logback-spring.xml .

En anden mulighed er at bruge Filter og MDC (Mapping Diagnostic Context). Grundlæggende vil hver anmodning, der kommer til API, blive opsnappet gennem Filter. I Filter kan du tilføje et unikt id til MDC-kortet. Brug logningsmønsteret, der bruger nøglen fra MDC-kortet. På denne måde vil din anmodning have sporingsoplysninger. En ting at huske er at rydde konteksten fra MDC, når din API har svaret på klienten.

Konfiguration af logfiler til overvågning

I virksomhedsverdenen er en måde at konfigurere logfiler på at gemme logfilerne i filer og gemme disse filer på en central placering på en skyserver. AWS tilbyder lettere fleksibilitet til at trække denne information i cloud watch fra storage S3, og så kan man bruge værktøjer som Kibana og Elastic search til at overvåge logfiler og metrics.

Konklusion

I dette indlæg beskrev vi, hvordan man bruger logning i forårsopstartsbaserede mikrotjenester. Vi diskuterede også Logback konfiguration, som man kan bruge, mens man bruger Logback framework i Spring Boot-applikationen.

De fleste af disse fremgangsmåder er standard, og hvis de følges korrekt, skal du sikre fejlfinding og overvågning af applikationer i et produktionsmiljø.


Java tag