3.1 Liste over hendelsesnivåer
Logging er prosessen med å registrere eventuelle hendelser som oppstår mens programmet kjører. Din plikt som programmerer er record everything importantfordi da, når productiondet er merkelige og/eller alvorlige feil, vil du ikke ha noe annet enn disse loggene.
Enhver feil vil bli eliminert mange ganger raskere hvis du har all informasjon om den og om all historien til samtalene. Men en enkel konklusjon følger herfra - å logge alt generelt: anrop av alle metoder, verdier for alle parametere.
Dette er heller ikke et alternativ – for mye informasjon er like ille som for lite. Vi trenger smart logging. Laget av mann for mann. Og her kommer vi til det første faktum om logging - alle oppføringer i loggen er delt inn i kategorier selv på tidspunktet for opprettelsen.
Programmereren, når han skriver en hendelse til loggen, må selv bestemme hvor viktig denne informasjonen er. Alvorlighetsnivået for hendelsen velges av forfatteren av meldingen. Det log4jer 5 nivåer av viktighet for logget informasjon:
DEBUGINFOWARNERRORFATAL
Nedenfor vil vi fortelle mer om dem.
3.2 DEBUG
Nivået DEBUGanses som minst viktig. Informasjon som er skrevet til loggen med dette viktighetsnivået er kun nødvendig under applikasjonsfeilsøking. For å logge informasjon som trengs under feilsøking, brukes 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 oppmerksom, metoden debuger helt i begynnelsen av metoden (metoden har ikke hatt tid til å gjøre noe ennå) og skriver verdien av variabelen som er sendt til metoden til loggen. Dette er den vanligste brukssaken for metoden debug().
3.3 INFO og ADVARSEL
De neste to nivåene er INFOog WARN. Det er to metoder for dem - info()og warn().
Nivået INFObrukes ganske enkelt for informasjonsmeldinger: dette og det skjer. Når du begynner å analysere en feil i loggen, kan det være svært nyttig å lese bakgrunnen. Metoden er perfekt for dette info().
Nivået WARNbrukes til å skrive advarsler (fra ordet advarsel ). Vanligvis, med dette viktighetsnivået, skrives det informasjon om at noe gikk galt, men programmet vet hva det skal gjøre i denne situasjonen.
For eksempel, i ferd med å skrive en fil til disk, viste det seg at en slik fil allerede eksisterer. Her kan programmet logge en advarsel (advarsel), men vise brukeren en dialogboks og tilby å velge et annet 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 FEIL og FATAL
Til slutt er de to viktigste loggingsnivåene ERRORog FATAL. For dem er det også spesielle metoder med samme navn: error()og fatal().
De bestemte seg også for å dele feil inn i to kategorier - ordinære feil og fatale feil . En fatal feil resulterer oftest i programkrasj (for skrivebordsapplikasjoner) eller nettjenestekrasj (for nettapplikasjoner).
Et annet godt eksempel er Windows-operativsystemet. Hvis programmet ditt nettopp krasjet, er dette fra operativsystemets synspunkt Error. Og hvis selve operativsystemet har falt og du ser Windows-blåskjermen, så er dette allerede Fatal error.
ErrorI Java-applikasjoner er hendelser oftest Fatalforbundet med opphevede unntak. 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 Hva skal logges
Det er selvfølgelig ikke verdt å logge alt på rad. I de fleste tilfeller forverrer dette loggens lesbarhet kraftig, og tross alt skrives loggen i utgangspunktet for å bli lest.
I tillegg kan du ikke skrive diverse personlig og økonomisk informasjon til loggen. Nå med dette strengt og enkelt kan du støte på bøter eller søksmål. Før eller siden vil en slik tømmerstokk lekke til siden og da vil det ikke være noen problemer.
Så hva skal logges?
Først må du logge starten av applikasjonen . Etter at applikasjonen har startet, anbefales det å logge driftsmodus og ulike viktige innstillinger - dette vil gjøre det lettere å lese loggen i fremtiden.
For det andre må du logge statusen til alle tredjepartstjenester som applikasjonen din fungerer med: postsystemer, eventuelle eksterne tjenester. Som et minimum må du sikre øyeblikket for tilkobling til dem for å sikre at de fungerer som de skal.
For det tredje må alle unntak logges . Hvis de forventes, kan informasjon om dem skrives kompakt. Fullstendig informasjon om unntak gir 50%-80% viktig informasjon når du søker etter en feil.
Du må også logge programmets avslutning . Applikasjonen må avsluttes normalt og ikke kaste dusinvis av feil inn i loggen. Ofte på dette stedet kan du finne oppgaver som sitter fast, problemer med trådpoolen eller problemer med å slette midlertidige filer.
Pass på å logge alt relatert til sikkerhet og brukerautorisasjon . Hvis en bruker prøver å logge på eller tilbakestille passordet sitt 10 ganger på rad, skal denne informasjonen gjenspeiles i loggene.
Logg så mye informasjon som mulig om asynkrone oppgaver - unntak går ofte tapt i slike tråder. For en asynkron oppgave, sørg for å logge starten og slutten. Vellykket fullføring skal logges på samme måte som en problematisk.
Hva annet? Lansering av tidsbestemte oppgaver, lansering av lagrede oppgaver SQL-procedures, synkronisering av data, alt relatert til distribuerte transaksjoner. Jeg tror det er nok til å begynne med. Du vil legge til denne listen i fremtiden.