2017-03-03 1 views
0

Ich möchte zu meinem Protokoll einen String-Schlüssel und einen Integer-Wert mit Log4j2 hinzufügen. Gibt es eine Möglichkeit, es zu tun? wenn ich Objekte, die dem ThreadContext hinzugefügt konnte ich nur String hinzuzufügen: String Schlüssel und Werte, aber das hilft nicht, ich Zahlen, die ich in Kibana (einige Grafiken)log4j2 und benutzerdefinierte Schlüsselwert mit JSONLayout

Dank, Kobi

Antwort

0

präsentieren müssen Ich fand die Standardlog4j2-Implementierung etwas problematisch für die Übergabe von benutzerdefinierten Feldern mit Werten. Meiner Meinung nach sind aktuelle Java-Logging-Frameworks nicht gut geeignet, um strukturierte Log-Ereignisse zu schreiben.

Wenn Sie Hacks mögen, können Sie überprüfen, https://github.com/skorhone/gelfj-alt/tree/master/src/main/java/org/graylog2/log4j2. Es ist eine Bibliothek für Gelf geschrieben. Eine der bereitgestellten Funktionen ist ein Layout (ExtGelfjLayout), das das Extrahieren von benutzerdefinierten Feldern (siehe FieldExtractor) aus Ereignissen unterstützt. Aber ... um ein solches Ereignis zu senden, müssen Sie Ihre eigene Logging-Fassade auf log4j2 schreiben.

+0

Log4j2 hat eine eingebaute GelfLayout –

+0

Ja, aber es unterstützt keine anderen Werte als Strings. Ganz zu schweigen davon, wie unintuitiv es ist, Werte mit Threadkontext (Kontextmap) zu übergeben –

+0

Ich sehe was du jetzt meinst. Es gibt einige laufende Arbeiten zur Unterstützung anderer Typen in ThreadContext: https://issues.apache.org/jira/browse/LOG4J2-1648 und https://issues.apache.org/jira/browse/LOG4J2-1629. Es ist möglich, ThreadContext vollständig zu vermeiden, indem Schlüssel/Wert-Paare aus einer anderen Quelle in das LogEvent eingefügt werden. Dies wird (kurz) unter Custom Context Data Injectors (http://logging.apache.org/log4j/2.x/manual/extending.html#Custom_ContextDataInjector) erwähnt. –

0

Das eingebaute GelfLayout kann nützlich sein.

Es stimmt, dass der Standard-ThreadContext nur String: String-Schlüsselwerte unterstützt. Die Arbeit in LOG4J2-1648 ermöglicht es Ihnen, andere Arten in ThreadContext zu verwenden:

  1. Log4j Weiterempfehlen ThreadContext Karte Implementierung zu verwenden, die den ObjectThreadContextMap-Schnittstelle implementiert. Der einfachste Weg, dies zu erreichen, ist das Setzen der Systemeigenschaft log4j2.garbagefree.threadContextMap auf true.
  2. Die Standard-ThreadContext-Fassade hat nur Methoden für Strings, daher müssen Sie Ihre eigene Fassade erstellen. Die unten sollte funktionieren:

    public class ObjectThreadContext { 
        public static boolean isSupported() { 
         return ThreadContext.getThreadContextMap() instanceof ObjectThreadContextMap; 
        } 
    
        public static Object getValue(String key) { 
         return getObjectMap().getValue(key); 
        } 
    
        public static void putValue(String key, Object value) { 
         getObjectMap().putValue(key, value); 
        } 
    
        private static ObjectThreadContextMap getObjectMap() { 
         if (!isSupported()) { throw new UnsupportedOperationException(); } 
         return (ObjectThreadContextMap) ThreadContext.getThreadContextMap(); 
        } 
    } 
    

Es ist möglich, ThreadContext insgesamt durch die Injektion von Schlüssel-Wert-Paaren aus einer anderen Quelle in die LogEvent zu vermeiden. Dies wird (kurz) unter Custom Context Data Injectors (http://logging.apache.org/log4j/2.x/manual/extending.html#Custom_ContextDataInjector) erwähnt.

Verwandte Themen