Varför loggar behövs i Java

1.1 Introduktion till loggar

Loggen är en lista över händelser som har inträffat. Nästan som en nautisk dagbok eller dagbok. Tja, följaktligen är en logger ett objekt som du kan logga med. Inom programmering är det vanligt att logga nästan allt. Och i Java är allt så och till och med lite till.

Faktum är att Java-program mycket ofta är stora serverapplikationer utan ett användargränssnitt, konsol och så vidare. De behandlar förfrågningar från tusentals användare samtidigt och ofta uppstår olika fel. Speciellt när olika trådar börjar störa varandra.

Och faktiskt, det enda sättet att hitta sällan återgivna fel och misslyckanden i en sådan situation är att skriva till loggen/filen allt som händer i varje tråd.

Oftast skrivs information till loggen om parametrarna för metoden som den anropades med, alla avlyssnade fel och mycket mellanliggande information. Ju mer komplett loggen, desto lättare är det att återställa händelseförloppet och spåra orsakerna till ett fel eller fel.

Men ju större stocken är, desto svårare är det att arbeta med den. Ibland når loggarna flera gigabyte per dag. Det här är okej.

1.2 Misslyckade loggar

Som de första loggarna använde utvecklarna helt enkelt utdata till konsolen . Det är bekvämt att göra detta under applikationsfelsökning - när all viktig information och variabelvärden skrivs till konsolen. Men en sådan logg är helt otillämplig under den normala driften av applikationen.

För det första kan applikationen vilja mata ut något till själva konsolen, och användaren vill inte alls se tjänsteinformationen som är avsedd för programmeraren.

För det andra är storleken på konsolbufferten begränsad, du kan inte skriva mycket där.

Och slutligen, för det tredje, bör information om programfel som samlas in under lång tid skickas till programutvecklarna. Och det är mest bekvämt att skriva all denna information på en gång till en fil.

Utvecklarna löste snabbt det första problemet - de kom på en annan utgångsström - System.err. Du kan skriva meddelanden till den och de kommer att skickas till en separat tråd och inte till standardkonsolen.

Och till och med problemet med att skriva till en fil löstes:

// Define the file to which we will write the log
System.setErr(new PrintStream(new File("log.txt")));
// Display messages
System.err.println("Message 1");
System.err.println("Message 2");
// Display an error message
try {
    throw new Exception("Error message");
} catch (Exception e) {
    e.printStackTrace();
}

Men även i den här formen löste det inte hela problemet, så det beslutades att skapa ett speciellt bibliotek som skulle skriva loggmeddelanden till en fil. Hon gjorde det på ett smart sätt och tillät flexibiliteten att konfigurera filter för loggade händelser och data.

Hela loggningsprocessen består faktiskt av tre delar:

• Den första delen är informationsinsamling .
• Den andra delen är filtreringen av den insamlade informationen.
• Den tredje delen är inspelningen av den valda informationen.

1.3 Introduktion till log4j-loggern

Den första populära loggern i Java-communityt var log4j. Att inkludera det i projektet är väldigt enkelt, för detta behöver du bara lägga till ett par rader i din pom.xml

<dependency>
    <groupId>log4j</groupId>
    <artifactId>log4j</artifactId>
    <version>2.2.17</version>
</dependency>

Interaktionen mellan ditt program och en sådan logger skulle se ut ungefär så här:

class Manager {
   private static final Logger logger = LoggerFactory.getLogger(Manager.class);

   public boolean processTask(Task task) {
        logger.debug("processTask id = " + task.getId());
        try {
            task.start();
            task.progress();
            task.complete();
            return true;
        } catch (Exception e) {
            logger.error("Unknown error", e);
            return false;
        }
    }
}

Tre saker händer här:

Skapandet av objektet är markerat i grönt Logger . Dess objekt lagras i en statisk variabel för bekvämt vidare arbete med det. Och även getLogger()information om i vilken klass informationen är insamlad skickas till metoden.

Linjen som är markerad i blått är där vi loggar information av värde endast under felsökning . För detta används en speciell metod -debug()

Och slutligen är raden där vi sparar undantaget som har uppstått i loggen markerad med rött . Undantag är potentiella fel, så error().