3.1 Lijst met gebeurtenisniveaus
Loggen is het proces van het vastleggen van gebeurtenissen die plaatsvinden terwijl het programma draait. Jouw taak als programmeur is record everything importantwant dan productionheb je, als er vreemde en/of ernstige fouten zijn, niets anders dan deze logs.
Elke fout wordt vele malen sneller geëlimineerd als u alle informatie erover en over de hele geschiedenis van de oproepen hebt. Maar vanaf hier volgt een simpele conclusie - om alles in het algemeen te loggen: aanroepen van alle methoden, waarden van alle parameters.
Ook dit is geen optie - te veel informatie is net zo erg als te weinig. We hebben slimme logging nodig. Gemaakt door de mens voor de mens. En hier komen we bij het eerste feit over loggen - alle items in het log zijn zelfs op het moment van creatie in categorieën verdeeld.
De programmeur moet bij het schrijven van een gebeurtenis naar het logboek zelf bepalen hoe belangrijk deze informatie is. Het ernstniveau van de gebeurtenis wordt gekozen door de auteur van het bericht. Er log4jzijn 5 niveaus van belangrijkheid van gelogde informatie:
DEBUGINFOWARNERRORFATAL
Hieronder zullen we er meer over vertellen.
3.2 DEBUGGEN
Het niveau DEBUGwordt als het minst belangrijk beschouwd. Informatie die met dit belangrijkheidsniveau naar het logboek wordt geschreven, is alleen nodig tijdens het debuggen van toepassingen. Om informatie te loggen die nodig is tijdens het debuggen, wordt de methode gebruikt debug().
Voorbeeld:
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;
}
}
}Let op, de methode debugstaat helemaal aan het begin van de methode (de methode heeft nog geen tijd gehad om iets te doen) en schrijft de waarde van de variabele die aan de methode is doorgegeven naar het logboek. Dit is de meest voorkomende use case voor de methode debug().
3.3 INFO en WAARSCHUWING
De volgende twee niveaus zijn INFOen WARN. Er zijn twee methoden voor hen - info()en warn().
Het niveau INFOwordt alleen gebruikt voor informatieve berichten: dit en dat gebeurt. Wanneer u begint met het ontleden van een fout in het logboek, kan het erg handig zijn om de achtergrond ervan te lezen. De methode is hier perfect voor info().
Het niveau WARNwordt gebruikt om waarschuwingen te schrijven (van het woord waarschuwing ). Meestal wordt bij dit niveau van belangrijkheid informatie geschreven dat er iets mis is gegaan, maar het programma weet wat het in deze situatie moet doen.
Tijdens het schrijven van een bestand naar schijf bleek bijvoorbeeld dat zo'n bestand al bestaat. Hier kan het programma een waarschuwing (waarschuwing) loggen, maar de gebruiker een dialoogvenster laten zien en aanbieden om een andere bestandsnaam te selecteren.
Voorbeeld:
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 FOUT en FATAAL
Ten slotte zijn de twee belangrijkste logboekniveaus ERRORen FATAL. Voor hen zijn er ook speciale methodes met dezelfde namen: error()en fatal().
Ze besloten ook om fouten in twee categorieën te verdelen: gewone fouten en fatale fouten . Een fatale fout resulteert meestal in een applicatiecrash (voor desktopapplicaties) of een webservicecrash (voor webapplicaties).
Een ander goed voorbeeld is het Windows-besturingssysteem. Als uw programma zojuist is gecrasht, dan is dit vanuit het oogpunt van het besturingssysteem Error. En als het besturingssysteem zelf is gevallen en je het Windows blue screen of death ziet, dan is dit al Fatal error.
ErrorIn Java-toepassingen worden gebeurtenissen meestal Fatalgeassocieerd met opgeheven uitzonderingen. Voorbeeld:
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 Wat te loggen
Het is natuurlijk niet de moeite waard om alles achter elkaar te loggen. In de meeste gevallen verslechtert dit de leesbaarheid van het logboek aanzienlijk, en het logboek wordt immers in de eerste plaats geschreven om gelezen te worden.
Bovendien kunt u verschillende persoonlijke en financiële informatie niet naar het logboek schrijven. Nu kunt u hiermee strikt en gemakkelijk boetes of rechtszaken krijgen. Vroeg of laat lekt zo'n blok naar de zijkant en dan zijn er geen problemen.
Wat moet er dan gelogd worden?
Eerst moet u de start van de applicatie loggen . Nadat de toepassing is gestart, wordt aanbevolen om de werkingsmodus en verschillende belangrijke instellingen te loggen - dit zal het in de toekomst gemakkelijker maken om het log te lezen.
Ten tweede moet u de status loggen van alle services van derden waarmee uw applicatie werkt: mailingsystemen, eventuele externe services. U moet minimaal het moment van verbinding met hen beveiligen om ervoor te zorgen dat ze correct werken.
Ten derde moeten alle uitzonderingen worden vastgelegd . Als ze worden verwacht, kan informatie erover compact worden geschreven. Volledige informatie over uitzonderingen geeft 50%-80% van de belangrijke informatie bij het zoeken naar een bug.
U moet ook het afsluiten van de toepassing loggen . De toepassing moet normaal worden afgesloten en mag geen tientallen fouten in het logboek genereren. Vaak kun je op deze plek vastzittende taken, problemen met de threadpool of problemen met het verwijderen van tijdelijke bestanden vinden.
Zorg ervoor dat u alles registreert met betrekking tot beveiliging en gebruikersautorisatie . Als een gebruiker 10 keer achter elkaar probeert in te loggen of zijn wachtwoord opnieuw in te stellen, moet deze informatie worden weergegeven in de logboeken.
Log zoveel mogelijk informatie over asynchrone taken - uitzonderingen gaan vaak verloren in dergelijke threads. Zorg ervoor dat u voor een asynchrone taak het begin en einde ervan vastlegt. Succesvolle afronding moet op dezelfde manier worden geregistreerd als een problematische afronding.
Wat nog meer? Getimede taken starten, opgeslagen taken starten SQL-procedures, gegevens synchroniseren, alles met betrekking tot gedistribueerde transacties. Ik denk dat dat genoeg is om te beginnen. U zult deze lijst in de toekomst aanvullen.