3.1 Lista över händelsenivåer

Loggning är processen att registrera alla händelser som inträffar medan programmet körs. Din plikt som programmerare är record everything importantatt då, när productiondet finns konstiga och/eller allvarliga fel, har du inget annat än dessa loggar.

Eventuella fel kommer att elimineras många gånger snabbare om du har all information om det och om all historik för samtalen. Men en enkel slutsats följer härifrån - att logga allt i allmänhet: anrop av alla metoder, värden för alla parametrar.

Detta är inte heller ett alternativ – för mycket information är lika dåligt som för lite. Vi behöver smart loggning. Gjord av människa för människa. Och här kommer vi till det första faktumet om loggning - alla poster i loggen är indelade i kategorier även när de skapades.

Lista över händelsenivåer

Programmeraren, när han skriver en händelse till loggen, måste själv bestämma hur viktig denna information är. Händelsens svårighetsgrad väljs av författaren till meddelandet. Det log4jfinns 5 nivåer av betydelse för loggad information:

  • DEBUG
  • INFO
  • WARN
  • ERROR
  • FATAL

Nedan kommer vi att berätta mer om dem.

3.2 DEBUG

Nivån DEBUGanses vara den minst viktiga. Information som skrivs till loggen med denna nivå av betydelse behövs endast under applikationsfelsökning. För att logga information som behövs under felsökningen används metoden debug().

Exempel:

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;
        }
    }
}

Var uppmärksam, metoden debugär i början av metoden (metoden har inte hunnit göra något ännu) och skriver värdet på variabeln som skickas till metoden till loggen. Detta är det vanligaste användningsfallet för metoden debug().

3.3 INFO och VARNING

De följande två nivåerna är INFOoch WARN. Det finns två metoder för dem - info()och warn().

Nivån INFOanvänds helt enkelt för informationsmeddelanden: det här och det händer. När du börjar analysera ett fel i loggen kan det vara mycket användbart att läsa dess bakgrund. Metoden är perfekt för detta info().

Nivån WARNanvänds för att skriva varningar (från ordet varning ). Vanligtvis, med denna nivå av betydelse, skrivs information om att något gick fel, men programmet vet vad det ska göra i den här situationen.

Till exempel, i processen att skriva en fil till disk, visade det sig att en sådan fil redan finns. Här kan programmet logga en varning (varning), men visa användaren en dialogruta och erbjuda sig att välja ett annat filnamn.

Exempel:

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

    public boolean saveFile(FileData file) {
        logger.info(“save the file ” + file.getName());
        boolean resultOK = SaveUtils.save(file);
        if (resultOK) return true;

        logger.warn(“file writing problem ” + file.getName());
        String filename = Dialog.selectFile();
        boolean result = SaveUtils.save(file, filename);
        return result;
    }

3.4 FEL och DÖDLIGT

Slutligen är de två viktigaste loggningsnivåerna ERRORoch FATAL. För dem finns det också speciella metoder med samma namn: error()och fatal().

De beslutade också att dela upp fel i två kategorier - vanliga fel och fatala fel . Ett fatalt fel resulterar oftast i en programkrasch (för stationära applikationer) eller en webbtjänstkrasch (för webbapplikationer).

Ett annat bra exempel är operativsystemet Windows. Om ditt program precis kraschade är detta ur operativsystemets synvinkel Error. Och om själva operativsystemet har fallit och du ser Windows blå skärm av döden, så är detta redan Fatal error.

ErrorI Java-applikationer är händelser oftast Fatalförknippade med upphöjda undantag. Exempel:

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;
        }
    }
}

3.5 Vad som ska loggas

Naturligtvis är det inte värt att logga allt i rad. I de flesta fall försämrar detta loggens läsbarhet kraftigt, och trots allt skrivs loggen i första hand för att kunna läsas.

Dessutom kan du inte skriva olika personlig och ekonomisk information till loggen. Nu med detta strikt och enkelt kan du stöta på böter eller stämningar. Förr eller senare kommer en sådan stock att läcka åt sidan och då blir det inga problem.

Så vad ska loggas?

Först måste du logga starten av applikationen . Efter att applikationen har startat rekommenderas det att logga dess driftläge och olika viktiga inställningar - detta kommer att göra det lättare att läsa loggen i framtiden.

För det andra måste du logga status för alla tredjepartstjänster som din applikation fungerar med: postsystem, eventuella externa tjänster. Som ett minimum måste du säkra anslutningsögonblicket till dem för att se till att de fungerar korrekt.

För det tredje måste alla undantag loggas . Om de förväntas kan information om dem skrivas kompakt. Fullständig information om undantag ger 50%-80% av viktig information när man söker efter en bugg.

Du måste också logga programmets avstängning . Applikationen måste avslutas normalt och inte kasta dussintals fel i loggen. Ofta på denna plats kan du hitta uppgifter som har fastnat, problem med trådpoolen eller problem med att ta bort temporära filer.

Se till att logga allt som har med säkerhet och användarauktorisering att göra . Om en användare försöker logga in eller återställa sitt lösenord 10 gånger i rad, bör denna information återspeglas i loggarna.

Logga så mycket information som möjligt om asynkrona uppgifter - undantag går ofta förlorade i sådana trådar. För en asynkron uppgift, se till att logga dess start och slut. Ett framgångsrikt slutförande bör loggas på samma sätt som ett problem.

Vad annars? Starta tidsinställda uppgifter, lansera lagrade uppgifter SQL-procedures, synkronisera data, allt relaterat till distribuerade transaktioner. Jag tror att det räcker till en början. Du kommer att lägga till i den här listan i framtiden.