So verwenden Sie die Java-Protokollierung richtig

In Bezug auf Protokolle denken alle, dass es relativ einfach ist. Wir müssen nur die relevanten Abhängigkeitspakete einführen, und der Rest besteht darin, die im Projekt benötigten Informationen zu drucken. Aber je einfacher die Dinge sind, desto einfacher ist es für uns, sie zu ignorieren, was dazu führt, dass einige Fehler auftreten, die nicht auftreten sollten. Wie können wir als strenger Programmierer zulassen, dass dies geschieht? Lassen Sie uns also mehr über die korrekte Verwendung von Protokollen erfahren.

Text

Protokollspezifikationen

Benennung

Die erste ist die Benennung der Protokolldatei. Versuchen Sie, sich mit dem Namen vertraut zu machen Das Team muss außerdem eine einheitliche Namenskonvention verwenden, da sonst „schmutzige, unordentliche“ Protokolldateien die Effizienz aller Beteiligten bei der Fehlerbehebung beeinträchtigen. Es wird empfohlen, es „projectName_logName_logType.log“ zu nennen, damit Sie anhand des Namens klar erkennen können, zu welchem ​​Projekt die Protokolldatei gehört, um welchen Typ es sich handelt und welche Funktion sie hat. In unserem MessageServer-Projekt kann beispielsweise der Name der Protokolldatei für die Überwachung von Rabbitmq-Konsumenten als „messageserver_rabbitmqconsumer_monitor.log“ definiert werden.

Speicherzeit

Bezüglich der Protokollspeicherzeit wird empfohlen, normale Protokolldateien 15 Tage lang aufzubewahren. Wenn es wichtiger ist, kann sie entsprechend der tatsächlichen Situation verlängert werden Bitte beachten Sie den jeweiligen Speicherplatz auf dem Server und die Größe der Protokolldatei. Treffen Sie die beste Wahl.

Protokollebene

Übliche Protokollebenen sind wie folgt:

DEBUG-Ebene: Zeichnet Debugger-bezogene Informationen auf. INFO-Ebene: Zeichnet aussagekräftige Informationen über den normalen Betrieb des Programms auf. WARN-Stufe: Zeichnet Informationen auf, die möglicherweise Fehler verursachen können. FEHLER-Ebene: Zeichnet Informationen über den aktuellen Programmfehler auf und erfordert Aufmerksamkeit und Bearbeitung. Schwerwiegende Stufe: Zeigt an, dass ein schwerwiegender Fehler aufgetreten ist und das Programm die Ausführung unterbricht.

Es wird empfohlen, diese vier Ebenen im Projekt zu verwenden: ERROR, WARN, INFO und DEBUG.

Korrekte Haltung

1. Beurteilen Sie die Log-Stufe im Voraus

//条件判断if(logger.isDebugEnabled){
    logger.debug("server info , id : " + id + ", user : " + user);
}//使用占位符logger.debug("server info , id : {}, user : {}",id,user);

Protokolle auf DEBUG- und INFO-Ebene sind in unserem Programm relativ häufig vorhanden. Wenn unser Projekt größer wird und die Anzahl der Protokolle zunimmt, müssen wir zur effizienteren Ausführung des Programms anhand von Bedingungen oder Platzhaltern beurteilen, ob das Protokoll gedruckt werden soll. Warum? Wenn die in unserem Projekt konfigurierte Protokollebene WARN ist, gilt für unsere folgende Protokollausgabeanweisung „logger.debug(“server info, id: „ + id +“, user: „ + user);“, obwohl das Protokoll dies nicht tut gedruckt, aber der String-Verkettungsvorgang wird ausgeführt. Da unser Benutzer ein Instanzobjekt ist, wird auch die toString-Methode ausgeführt, was viele Systemressourcen verschwendet.

2. Vermeiden Sie redundante Protokollausgaben

In unserer Produktionsumgebung ist die Ausgabe von DEBUG-Protokollen generell verboten, was leicht zu ernsthaften Schäden an normal laufenden Programmen führen kann . Impact, wir sind in unseren letzten Projekten auf ähnliche Situationen gestoßen.

Dann ist es an der Zeit, die Verwendung des Additivitätsattributs

<logger name="xx" additivity="true">

zu erlernen. Wenn es hier auf „true“ konfiguriert ist, ist dies die Standardsituation. Zu diesem Zeitpunkt erbt der aktuelle Logger den Appender des übergeordneten Loggers . Um es ganz klar auszudrücken: Die Protokollausgabe wird nicht nur in die aktuelle Protokolldatei ausgegeben, sondern auch in die übergeordnete Datei. Um wiederholtes Drucken zu vermeiden, setzen wir diesen Parameter im Allgemeinen auf „false“, um unnötige Ausgaben zu reduzieren.

Stellen Sie sicher, dass die Protokolldatensatzinformationen vollständig sind.

In unserem Code muss der Protokolldatensatzinhalt den Ausnahmestapel enthalten. Bitte geben Sie keine einfachen Protokolle wie „XX-Fehler“ aus . Dies ist wichtig, da das Debuggen von Fehlern nicht hilfreich ist. Daher müssen wir beim Aufzeichnen von Ausnahmen wie

logger.error("rabbitmq consumer error,cause : "+e.getMessage(),e);

Stapelinformationen mitbringen. Denken Sie daran, dass Sie bei der Ausgabe einer Objektinstanz sicherstellen müssen, dass das Objekt die toString-Methode überschreibt, da sonst nur sein HashCode-Wert ausgegeben wird.

4. Definieren Sie die Logger-Variable als statisch

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

Stellen Sie sicher, dass ein Objekt nur ein Logger-Objekt verwendet, um zu vermeiden, dass es jedes Mal neu erstellt wird, da es sonst zu OOM kommen kann.

5. Verwenden Sie die Protokollebene richtig

try{    //..}catch(xx){
    logger.info(..);
}

Auf diese Weise werden alle Informationen, die ursprünglich FEHLER waren, in der INFO-Protokolldatei gedruckt, und nicht informierte Kollegen starren weiterhin auf das Fehlerprotokoll . , und das Problem kann nicht gefunden werden, es wird die Arbeitseffizienz beeinträchtigen, oder?

6 Es wird empfohlen, die Kombination slf4j+logback zu verwenden

Die Logback-Bibliothek selbst hat slf4j bereits implementiert Schnittstelle, daher ist keine Einführung erforderlich. Es gibt keine redundanten Adapter, und die Protokollierung bietet auch weitere Vorteile. Es wird empfohlen, dass neue Projekte diese Kombination verwenden können. Beachten Sie außerdem, dass wir nach der Einführung von slf4j darauf achten sollten, ob die tatsächlich verwendete Protokollbibliothek von uns eingeführt wird oder ob sie möglicherweise die Protokollbibliothek verwendet, die von unserem Abhängigkeitspaket eines Drittanbieters bereitgestellt wird, was dazu führen kann, dass unser Protokoll ungültig ist .

7. Protokollaggregationsanalyse

Protokollaggregation kann die Protokolle zwischen verschiedenen Servern zur Analyse und Verarbeitung vereinheitlichen. Heute ist der ELK-Technologie-Stack auch EFG (fluentd+elasticsearch+grafana). relativ ausgereifte Open-Source-Lösungen.

Am Beispiel von ELK können Sie die von der Anwendung gedruckte Protokolldatei direkt über logstash auf unserem Server lesen oder die relevanten Socket-Informationen in der Protokollkonfigurationsdatei in unserem Projekt konfigurieren und ausdrucken. Zu diesem Zeitpunkt werden die Protokollinformationen direkt an logstash ausgegeben. Anschließend wird es zur Speicherung und Kibana-Anzeige an Elasticsearch übergeben.

Verwandte Tutorials: Java-Video-Tutorial

Das obige ist der detaillierte Inhalt vonSo verwenden Sie die Java-Protokollierung richtig. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!