it-swarm.com.de

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 damit einverstanden, aber unsere Protokollierungsstrategie ist recht einfach. Wir verwenden einfache klassenbasierte Logger und keine ausgefallenen Dinge wie MDC oder Markers.

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

Ich interessiere mich besonders für wo, warum und wie man es verwenden würde[1] Marker für die Protokollierung. Sie erscheinen mir als eine ziemlich nette Funktion, um der Protokollierung einen semantischen Kontext hinzuzufügen - z. Während eine Klasse mehrere Anliegen behandeln kann, kann man Task-/Anliegen-spezifische Marker verwenden, um Protokollanweisungen zu unterscheiden.

Was sind die besten Methoden, Konventionen oder Strategien zum Erstellen und Verwenden von Markern bei der Protokollierung?.

pdate: Ich schätze, was ich wirklich will, ist nicht so sehr warum Marker zu verwenden, sondern eher die Wie funktioniert die Benennung von Markern (z. B. Verwendung von Klartext mit Leerzeichen oder durch Bindestriche/Unterstriche/Interpunktionen getrennten Namen von Schlüsselwortstilen), wenn es eine Art von Namen gibt? von Pool von "Standardnamen", Benennung von Sachen basierend auf den Geschäftsfunktionen. 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, über formalisierbare Richtlinien zu verfügen ...


[1] - Indem ich frage, wie man Markierungen verwendet , frage ich nicht wirklich, wie man API verwendet (es ist wirklich ganz einfach) - ich beziehe mich eher auf das Mehr allgemeine Ebene, wie man die Protokollierung mithilfe von Markern konsistent einrichten würde

114
Roland Tepp

Erstens, wie @darioo sagte:

  • MDC wird zum Verknüpfen mehrerer Ereignisse mit wenigen "Entitäten" verwendet.
  • [Marker] werden für "spezielle" Ereignisse verwendet, die Sie aus den üblichen herausfiltern möchten

Also Ihre Behauptung, dass Sie MDC dafür verwenden möchten. Mit Markierungen werden "spezielle" Ereignisse hervorgehoben - wenn Sie so wollen, wird gefiltert - und nicht "aufgeschnitten". Beispielsweise können Sie Slices basierend auf einem bestimmten Benutzer erstellen, aber nach unerwarteten Ausnahmen filtern. In diesem Fall würden Sie eine Benutzer MDC-Dimension und eine UnexpectedException erstellen. Marker.


Aber das ist anscheinend nicht die Frage, die Sie im Sinn hatten. Sie beziehen sich "eher auf die allgemeinere Ebene, in der man die Protokollierung mithilfe von Markern konsistent einrichten würde". Gehen wir also auf Folgendes ein:

MDC dient zum Schneiden und Zerteilen , und Marker dienen zum Filtern . Diese Tätigkeiten werden während des Testens und in der Produktion ausgeführt. Aus diesem Grund müssen Sie entscheiden, nach welchen Dimensionen die Protokolldaten möglicherweise aufgeschlüsselt werden sollen und nach welchen Fällen eine Filterung sinnvoll sein kann, wenn Tests/Produktionen anstehen. Jede Dimension erhält eine MDC-Dimension. Jeder Fall bekommt 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 durch die Vorstellung, welche Art von Analyseaufgaben erwartet werden, informiert werden.

Dieselbe Person oder dasselbe Team sollte über die Namenskonvention entscheiden. Es ist völlig willkürlich. Wählen Sie etwas, das ästhetisch ansprechend ist, selbstbeschreibend (am wichtigsten) und spezifisch genug, um mit späteren Ergänzungen nicht in Konflikt zu geraten. Bindestriche vs. sind außerordentlich pingelig und beunruhigend. Beachten Sie jedoch, dass das Lesen von Unterstrichen für ESL-Mitarbeiter möglicherweise weniger verwirrend ist (zumindest im Vergleich zu CamelCase) ); Gleichzeitig ärgert dies angeblich einige Entwickler, da es schwierig ist, die erforderlichen Schlüssel zu erreichen.

Wenn Sie sich für eine Richtlinie entscheiden, müssen Sie nur definieren, in welchen Fällen eine bestimmte Marker- oder MDC-Dimension verwendet werden muss. Behalten Sie dies bei (zentralisiert, absichtlich), lassen Sie jedoch das Feedback der Entwickler zu, wenn sie der Ansicht sind, dass die Dimensionen und Markierungen für die jeweilige Aufgabe nicht ausreichen. Überarbeiten/Hinzufügen von Dimensionen und/oder Attributen nach Bedarf.

Verstehe diese Politik wird fast notwendigerweise projektspezifisch sein. Nicht jedes Projekt benötigt die gleiche Art der Protokollanalyse. Stellen Sie sich einige Albtraumszenarien 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 herauszufinden, welche Nachricht zu welchem ​​Kontext gehört und welcher Status zu welcher Zeit vorliegt, oder? Codieren Sie alle erforderlichen Informationen wie Maße und Markierungen und sparen Sie sich den Ärger, wenn etwas schief geht.

89
user359996

Erstens MDC.

MDC ist wirklich nützlich in einer Umgebung, 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 nachverfolgen. 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 auf einfache Weise durchsuchen, um zu sehen, was er gerade tut.

Zweitens Marker.

Markierungen werden normalerweise für "spezielle" Umstände verwendet, z. B. das Senden einer E-Mail an einen Administrator bei schwerwiegenden kritischen Fehlern. Nicht alle Fehler fallen immer in dieselbe Kategorie. Einige müssen angemessen behandelt werden.

Wenn ein Benutzer Ihren Dienst beendet, wird in der Regel ein INFO-Protokoll aufgerufen. 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 der Benutzer beenden.

Faustregel:

  • MDC wird zum Verknüpfen mehrerer Ereignisse mit wenigen "Entitäten" verwendet.
  • marker werden für "spezielle" Ereignisse verwendet, die Sie aus den üblichen herausfiltern möchten
67
darioo

Markierungen können verwendet werden, um color oder eine single log-Anweisung zu markieren. Was Sie mit diesen Farben, d. H. Markierungen, tun, liegt ganz bei Ihnen. Bei der Verwendung von Markern scheinen jedoch zwei Muster gemeinsam zu sein (das erste häufiger als das zweite).

  1. Auslösen : Einige Appender können angewiesen werden, bei Vorhandensein eines bestimmten Markers eine Aktion auszuführen. Beispielsweise kann SMTPAppender so konfiguriert werden, dass eine E-Mail gesendet wird, wenn ein Protokollierungsereignis unabhängig von der Protokollierungsstufe mit der Markierung NOTIFY_ADMIN Markiert ist. Siehe marker-based triggering in der Logback-Dokumentation. Sie können auch Protokollebenen und Marker 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 Rückmeldedokumentation (Suche nach MarkerFilter).

29
Ceki

Genau wie ein Nachtrag, wenn Sie Logstash verwenden und die JSON-Protokollierung aktiviert haben, gibt es 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

7
Mark D