Hændelsesniveauer

3.1 Liste over hændelsesniveauer

Logning er processen med at registrere eventuelle hændelser, der opstår, mens programmet kører. Din pligt som programmør er, record everything importantfordi du så, når productionder er mærkelige og/eller alvorlige fejl, ikke har andet end disse logfiler.

Enhver fejl vil blive elimineret mange gange hurtigere, hvis du har alle oplysninger om det og om al opkaldshistorikken. Men en simpel konklusion følger herfra - at logge alt generelt: opkald af alle metoder, værdier af alle parametre.

Dette er heller ikke en mulighed – for meget information er lige så slemt som for lidt. Vi har brug for smart logning. Lavet af mand for mand. Og her kommer vi til det første faktum om logning - alle poster i loggen er opdelt i kategorier selv på tidspunktet for deres oprettelse.

Programmereren skal, når han skriver en hændelse til loggen, selv bestemme, hvor vigtig denne information er. Hændelsens sværhedsgrad vælges af meddelelsens forfatter. Der log4jer 5 niveauer af vigtighed af logget information:

• DEBUG
• INFO
• WARN
• ERROR
• FATAL

Nedenfor vil vi fortælle om dem mere detaljeret.

3.2 DEBUG

Niveauet DEBUGanses for at være det mindst vigtige. Oplysninger, der er skrevet til loggen med dette niveau af betydning, er kun nødvendige under applikationsfejlretning. For at logge information, der er nødvendig under fejlfinding, bruges metoden debug().

Eksempel:

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

Vær opmærksom, metoden debuger helt i begyndelsen af ​​metoden (metoden har ikke haft tid til at gøre noget endnu) og skriver værdien af ​​den variable, der er sendt til metoden, til loggen. Dette er den mest almindelige anvendelse af metoden debug().

3.3 INFO og ADVARSEL

De næste to niveauer er INFOog WARN. Der er to metoder til dem - info()og warn().

Niveauet INFObruges blot til informationsmeddelelser: det og det sker. Når du begynder at parse en fejl i loggen, kan det være meget nyttigt at læse dens baggrund. Metoden er perfekt til dette info().

Niveauet WARNbruges til at skrive advarsler (fra ordet advarsel ). Normalt, med dette niveau af vigtighed, skrives der information om, at noget gik galt, men programmet ved, hvad det skal gøre i denne situation.

For eksempel, i færd med at skrive en fil til disk, viste det sig, at en sådan fil allerede eksisterer. Her kan programmet logge en advarsel (advarsel), men vise brugeren en dialogboks og tilbyde at vælge et andet filnavn.

Eksempel:

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 FEJL og FATAL

Endelig er de to vigtigste logningsniveauer ERRORog FATAL. For dem er der også specielle metoder med samme navne: error()og fatal().

De besluttede også at opdele fejl i to kategorier - almindelige fejl og fatale fejl . En fatal fejl resulterer oftest i et programnedbrud (for desktop-applikationer) eller et webservicenedbrud (for webapplikationer).

Et andet godt eksempel er Windows-operativsystemet. Hvis dit program lige er gået ned, så er dette set fra operativsystemets synspunkt Error. Og hvis selve operativsystemet er faldet, og du ser Windows' blå skærm af død, så er dette allerede Fatal error.

ErrorI Java-applikationer er begivenheder oftest Fatalforbundet med rejste undtagelser. Eksempel:

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 Hvad skal logges

Det kan selvfølgelig ikke betale sig at logge alt i en række. I de fleste tilfælde forringer dette loggens læsbarhed markant, og loggen bliver trods alt skrevet i første omgang for at blive læst.

Derudover kan du ikke skrive diverse personlige og økonomiske oplysninger til loggen. Nu med dette strengt og nemt kan du løbe ind i bøder eller retssager. Før eller siden vil en sådan log lække til siden, og så vil der ikke være nogen problemer.

Hvad skal så logges?

Først skal du logge starten af ​​applikationen . Efter at applikationen er startet, anbefales det at logge dens driftstilstand og forskellige vigtige indstillinger - dette vil gøre det lettere at læse loggen i fremtiden.

For det andet skal du logge status for alle tredjepartstjenester, som din applikation fungerer med: postsystemer, eventuelle eksterne tjenester. Som minimum skal du sikre tidspunktet for forbindelse til dem for at sikre, at de fungerer korrekt.

For det tredje skal alle undtagelser logges . Hvis de forventes, kan oplysninger om dem skrives kompakt. Fuldstændig information om undtagelser giver 50%-80% af vigtig information, når du søger efter en fejl.

Du skal også logge programmets lukning . Applikationen skal afsluttes normalt og ikke smide snesevis af fejl i loggen. Ofte her kan du finde fastlåste opgaver, problemer med trådpuljen eller problemer med at slette midlertidige filer.

Sørg for at logge alt relateret til sikkerhed og brugerautorisation . Hvis en bruger forsøger at logge på eller nulstille sin adgangskode 10 gange i træk, bør disse oplysninger afspejles i loggene.

Log så meget information som muligt om asynkrone opgaver - undtagelser går ofte tabt i sådanne tråde. For en asynkron opgave skal du sørge for at logge dens start og slutning. Succesfuld gennemførelse skal logges på samme måde som en problematisk.

Hvad ellers? Lancering af tidsindstillede opgaver, lancering af lagrede opgaver SQL-procedures, synkronisering af data, alt relateret til distribuerede transaktioner. Jeg tror, ​​det er nok til en start. Du vil tilføje til denne liste i fremtiden.