Best Practices für die Verwendung von Markern in SLF4J / Logback

Wir verwenden die SLF4J + Logback-Kombination bereits seit einiger Zeit in unserem Projekt und sind ziemlich zufrieden damit, aber unsere Protokollierungsstrategie ist recht einfach. Wir verwenden einfache klassenbasierte Logger und keine ausgefallenen Dinge wie MDC oder Marker.

Ich möchte wissen, ob jemand in der Community diese Funktionen tatsächlich nutzt und wie sie zur Verbesserung der Protokollierung / Filterung verwendet werden.

Ich interessiere mich besonders dafür, wo, warum und wie man ^[1] Marker für die Protokollierung verwenden würde. Sie scheinen mir eine ziemlich nette Funktion zu sein, um der Protokollierung semantischen Kontext hinzuzufügen - z. B. während eine Klasse möglicherweise mehrere Probleme behandelt, kann man aufgaben- / bedankenspezifische Markierungen verwenden, um Protokollanweisungen zu unterscheiden.

Was sind die Best Practices, Konventionen oder Strategien zum Erstellen und Verwenden von Markern bei der Protokollierung?

Update: Ich denke, was ich wirklich will, ist nicht so sehr, warum ich Markierungen verwenden soll, sondern vielmehr, wie Teil - gibt es einige bewährte Methoden zum Benennen von Markierungen (z. B. die Verwendung von einfachem Text mit Leerzeichen oder durch Striche / Unterstriche / Satzzeichen getrennten Namen von Schlüsselwortstilen ), sollte es eine Art Pool von "Standardnamen" geben, die Dinge basierend auf den Geschäftsfunktionen benennen. Die Fragen, die ich wahrscheinlich selbst herausfinden kann, aber wenn ich diese Funktionen systematisch nutzen und sie einem Entwicklerteam vorstellen möchte, ist es sinnvoll, einige formalisierbare Richtlinien zu haben, um ...

^[1] - Wenn ich frage, wie man Marker verwendet, frage ich nicht wirklich, wie man API verwendet (es ist wirklich ganz einfach) - Ich beziehe mich eher auf die allgemeinere Ebene, wie man die Protokollierung mit Markern konsistent einrichten würde

Erstens, wie @darioo sagte:

• MDC wird zum Zuordnen mehrerer Ereignisse zu wenigen "Entitäten" verwendet.
• [Marker] werden für "spezielle" Ereignisse verwendet, die Sie von üblichen Ereignissen filtern lassen möchten

Also Ihre Behauptung, dass Sie MDC dafür verwenden möchten. Markierungen dienen zum Hervorheben von "besonderen" Ereignissen - wenn Sie so wollen, zum Filtern - und nicht zum "Schneiden". Beispielsweise können Sie Slices basierend auf einem bestimmten Benutzer erstellen, aber basierend auf unerwarteten Ausnahmen filtern. In diesem Fall würden Sie eine Benutzer- MDC-Dimension und einen UnexpectedException- Marker erstellen .

Aber dies spricht anscheinend nicht die Frage an, die Sie sich vorgestellt haben. Sie beziehen sich eher auf die allgemeinere Ebene, wie man die Protokollierung mithilfe von Markern konsistent einrichten würde. Lassen Sie uns das ansprechen:

MDC dient zum Schneiden und Würfeln und Marker zum Filtern . Diese Aktivitäten werden während der Prüfung und in der Produktion durchgeführt . Daher müssen Sie entscheiden, nach welchen Dimensionen Sie die Protokolldaten aufteilen möchten und nach welchen Fällen es nützlich sein kann, sie zu filtern, wenn Tests / Produktion anstehen. Jede Dimension erhält eine MDC-Dimension. Jeder Fall erhält einen Marker. So einfach ist das.

Die Entwickler müssen hier keine Entscheidungen treffen. Eine einzelne Person oder ein Team sollte zur Entwurfszeit entscheiden , welche Art von Schneiden, Würfeln und Filtern unterstützt werden muss. Dies sollte informiert werden, indem man sich vorstellt, welche Art von Analyseaufgaben man erwartet, dass sie ausgeführt werden.

Dieselbe Person oder dasselbe Team sollte über die Namenskonvention entscheiden. Es ist völlig willkürlich . Wählen Sie etwas, das ästhetisch ansprechend, selbstbeschreibend (am wichtigsten) und spezifisch genug ist, um mit späteren Ergänzungen nicht in Konflikt zu geraten. Bindestriche vs. Unterstriche sind äußerst pingelig und alarmierend, aber beachten Sie, dass es für ESL-Mitarbeiter weniger verwirrend sein kann, Unterstriche zu lesen (zumindest im Vergleich zu CamelCase). Gleichzeitig ärgert dies Berichten zufolge einige Entwickler, da das Erreichen der erforderlichen Schlüssel umständlich ist.

Für die Entscheidung über eine Richtlinie bedeutet dies lediglich, zu definieren, in welchen Fällen eine bestimmte Marker- oder MDC-Dimension verwendet werden muss . Halten Sie dies eng (zentralisiert, absichtlich), lassen Sie jedoch Feedback von Entwicklern zu, wenn sie der Meinung sind, dass die Dimensionen und Markierungen für die jeweilige Aufgabe nicht ausreichen. Überarbeiten / fügen Sie Dimensionen und / oder Attribute nach Bedarf hinzu.

Verstehen Sie, dass diese Richtlinie fast notwendigerweise projektspezifisch sein wird . Nicht jedes Projekt benötigt dieselbe Protokollierungsanalyse. Stellen Sie sich einige Alptraumszenarien vor. Stellen Sie sich dann vor, wie Sie die Protokolle in diesem Szenario analysieren möchten. Sie möchten wahrscheinlich kein kompliziertes Skript schreiben müssen, um zu verfolgen, welche Nachricht zu welchem ​​Kontext gehört und welcher Status zu welchem ​​Zeitpunkt welcher ist, oder? Codieren Sie alle erforderlichen Informationen als Abmessungen und Markierungen und sparen Sie sich den Aufwand, wenn etwas schief geht.

Erstens MDC.

MDC ist in einer Umgebung sehr nützlich, in der Sie eine "Entität" haben, die mit einem bestimmten Verhalten verbunden ist. Ein typisches Beispiel: Benutzer, der mit einer Webanwendung interagiert. Nehmen wir also an, Sie haben viele Benutzer, die mit Ihrer Web-App herumspielen. Mit MDC können Sie sie problemlos und ohne großen Aufwand verfolgen. Vereinfachtes Beispiel:

...[Sandy][abcd] clicked on "change profile"
...[Joe][1234] clicked on "weather reports"
...[Joe][1234] clicked on "Europe"
...[Sandy][abcd] clicked on "logout"
...[Joe][1234] clicked on "logout"
...[Sandy][efgh] logged in

Hier verwenden Sie MDC an zwei Stellen: für den Benutzernamen und für die Sitzungs-ID. Auf diese Weise können Sie die Sitzung eines Benutzers leicht abrufen, um zu sehen, was er getan hat.

Zweitens Marker.

Marker werden normalerweise für "besondere" Umstände verwendet, z. B. zum Senden einer E-Mail an einen Administrator wegen schwerwiegender kritischer Fehler. Nicht alle Fehler fallen immer in dieselbe Kategorie. Einige müssen angemessen behandelt werden.

Wenn ein Benutzer Ihren Dienst beendet, wird er normalerweise in ein INFO-Protokoll verschoben. Sie können jedoch auch eine Markierung für solche Instanzen verwenden, wenn Ereignisse wie dieses in einer separaten Protokolldatei gespeichert werden sollen, damit Sie sie überwachen können einfacher für die statistische Erfassung von Benutzern, die das Programm verlassen.

Faustregel:

• MDC wird zum Zuordnen mehrerer Ereignisse zu wenigen "Entitäten" verwendet.
• Marker werden für "spezielle" Ereignisse verwendet, die Sie von üblichen Ereignissen filtern lassen möchten

Markierungen können verwendet werden , Farbe ein oder markieren einzelne Log - Anweisung. Was Sie mit diesen Farben, dh Markern, machen, liegt ganz bei Ihnen. Zwei Muster scheinen jedoch für die Verwendung von Markern gemeinsam zu sein (das erste häufiger als das zweite).

1. Auslösen : Einige Appender könnten angewiesen werden, bei Vorhandensein eines bestimmten Markers eine Aktion auszuführen. Zum Beispiel SMTPAppenderkann eine E - Mail senden , so konfiguriert werden , wenn ein Protokollereignis mit dem markiert NOTIFY_ADMINMarker unabhängig von der Protokollebene. Siehe markergestütztes Triggern in der Logback-Dokumentation. Sie können auch Protokollebenen und Markierungen zum Auslösen kombinieren.

2. Filtern : Sie können beispielsweise alle Ihre persistenzbezogenen Protokolle (in verschiedenen und mehreren Klassendateien) mit der Farbe "DB" färben / markieren. Sie können dann nach "DB" filtern: Deaktivieren Sie die Protokollierung mit Ausnahme der mit DB gekennzeichneten Protokollanweisungen. Weitere Informationen finden Sie im Kapitel über Filter in der Logback-Dokumentation (Suche nach MarkerFilter).

Wenn Sie logstash verwenden und die json-Protokollierung aktiviert haben, gibt es als Ergänzung eine weitere mögliche Verwendung von Marker - zum Protokollieren von Variablen, die einer bestimmten Protokollnachricht zugeordnet werden sollen. Dies ist konsistenter und einfacher zu analysieren, als es in den Nachrichtentext aufzunehmen. Sehr nützlich, wenn es zu Ihrem Anwendungsfall passt.

Details finden Sie hier:

https://github.com/logstash/logstash-logback-encoder#loggingevent_custom_event