ThingWorx Modelldefinition in Composer > System > Protokolle > Protokollierung konfigurieren
Protokollierung konfigurieren
Eine Standarddatei internal-logback.xml ist Teil der ThingWorx Datei .war und wird verwendet, um das Logback-Untersystem zu konfigurieren. Um die Datei zu suchen, entpacken Sie die Datei Thingworx.war, und entpacken Sie WEB_INF/lib/thingworx-platform-common-[version_number].jar.
Sie können internal-logback.xml in /ThingworxPlatform/logback.xml kopieren und Änderungen vornehmen. Diese logback.xml-Dateien werden nicht gestapelt und erben nicht voneinander. Anschließend können Sie die aktualisierte Datei im ThingWorx Konfigurationsverzeichnis default/ThingworxPlatform für jede ThingWorx Instanz platzieren.
Protokollebene für DEBUG ändern
Sie können einen Eintrag ändern, um zu erzwingen, dass für die Protokollebene einer bestimmten Klasse ein DEBUG ausgeführt wird. Sie können z.B. folgende Änderungen vornehmen:
<logger name="org.springframework.security" level="INFO" additivity="false">
<appender-ref ref="ASYNC_APPENDER_SECURITY"/>
</logger>
in Folgendes mitlevel="DEBUG":
<logger name="org.springframework.security" level="DEBUG" additivity="false">
<appender-ref ref="ASYNC_APPENDER_SECURITY"/>
</logger>
Sie können auch einen neuen Eintrag mit der spezifischen Protokollebene hinzufügen. Beispiel:
<logger name="com.thingworx.security.authentication.sso" level="DEBUG" additivity="false">
<appender-ref ref="ASYNC_APPENDER_SECURITY"/>
</logger>
Ein Eintrag auf Paketebene wie dieser aktiviert die Protokollierung für dieses Paket und die Unterpakete.
Appender
Sie können angeben, in welchem Protokoll die Informationen angezeigt werden sollen, indem Sie den richtigen Appender in <appender-ref ref="[Appender-Name]"/> angeben. Mögliche Appender sind:
• ASYNC_APPENDER_CONSOLE – Konsolenausgabe
• ASYNC_APPENDER_APPLICATION – Anwendungsprotokoll
• ASYNC_APPENDER_ERROR – Fehlerprotokoll
• ASYNC_APPENDER_SECURITY – Sicherheitsprotokoll
• ASYNC_APPENDER_SCRIPT – Skriptprotokoll
• ASYNC_APPENDER_SCRIPT_ERROR – Skriptfehlerprotokoll
• ASYNC_APPENDER_CONFIGURATION – Konfigurationsprotokoll
• ASYNC_APPENDER_DATABASE – Datenbankprotokoll
• ASYNC_APPENDER_COMMUNICATION – Kommunikationsprotokoll
Asynchroner Appender
ThingWorx verwendet die Logback-Protokollierungsbibliothek mit Konsolen- und rollierenden Datei-Appendern. Beide Appender werden vom asynchronen Appender umschlossen, der die Verbindung zwischen den Protokollantragstellern und den tatsächlichen Protokollschreibvorgängen trennt. Die Protokoll-Antragsteller rufen die append(logEvent)-Methode für AsyncAppender auf. Diese Methode fügt das logEvent der internen Warteschlange innerhalb des AsyncAppender hinzu. Daher kann der Protokoll-Antragsteller seine Arbeit fortsetzen, ohne darauf warten zu müssen, dass logEvent in die Zielkonsole oder Datei geschrieben wird. Im AsyncAppender wählt ein interner Thread das älteste logEvent aus der internen Warteschlange aus und ruft append(LogEvent) in der Protokoll-Appender-Konsole oder -Datei auf. Die interne Warteschlange dient auch als Puffer, der Datenverluste bei kurzen Aktivitätsausbrüchen verhindert, wenn die Protokollierungsanforderungen pro Sekunde die interne Appender-Schreibgeschwindigkeit überschreiten.Weitere Informationen finden Sie unter https://logback.qos.ch/manual/appenders.html.
Sie können die folgenden Parameter für den AsyncAppender in der Datei logback.xml konfigurieren:
Parameter
Umgebungsvariable
Basistyp
Standard
Beschreibung
queueSize
unterschiedlich für jeden AsyncAppender; siehe Tabelle unten
INTEGER
256
Maximale Kapazität der blockierenden Warteschlange. Dieser Wert wird während der Erstellung des AsyncAppender verwendet und kann nicht geändert werden. Dieser Wert kann pro Appender festgelegt werden.
discardingThreshold
DISCARDING_THRESHOLD
INTEGER
0%
Wenn die blockierende Warteschlange noch 20 % Kapazität übrig hat, löscht sie standardmäßig Ereignisse mit den Ebenen TRACE, DEBUG und INFO und behält Ereignisse mit den Ebenen WARN und ERROR bei. Um alle Ereignisse beizubehalten, legen Sie discardingThreshold auf 0 fest.
maxFlushTime
MAX_FLUSH_TIME
INTEGER
1000 ms
Maximales Timeout für die Warteschlangenbereinigung in Millisekunden. Abhängig von der Warteschlangentiefe und der Latenz für den referenzierten Appender kann der AsyncAppender einen nicht akzeptablen Zeitraum benötigen, um die Warteschlange vollständig zu leeren. Wenn der LoggerContext angehalten wird, wartet die AsyncAppender-Methode zum Anhalten, ob der Worker-Thread abgeschlossen in diesem Zeitraum wird. Ereignisse, die innerhalb dieser Zeit nicht verarbeitet werden können, werden verworfen. Die Semantik dieses Werts ist mit der von Thread.join(long) identisch.
neverBlock
NEVER_BLOCK
BOOLEAN
false
Standardmäßig ist dieser Parameter auf "false" festgelegt, was bedeutet, dass der Appender das Anhängen an eine vollständige Warteschlange blockiert, anstatt die Meldung zu löschen. Wenn Sie die Einstellung auf "true" festlegen, wird die Meldung vom Appender gelöscht und die Anwendung nicht blockiert.
Warteschlangen-Größenwerte für asynchrone Appender
Jeder AsyncAppender hat einen eigenen Wert für queueSize, da Protokollierer unterschiedliche Lasten verarbeiten müssen und unterschiedliche Warteschlangengrößen benötigen.
Appender-Name
Umgebungsvariable
Standard
ASYNC_APPENDER_APPLICATION
MAX_QUEUE_SIZE_APPLICATION
10000
ASYNC_APPENDER_CONSOLE
ASYNC_APPENDER_CONSOLE
10000
ASYNC_APPENDER_CONFIGURATION
MAX_QUEUE_SIZE_CONFIGURATION
1000
ASYNC_APPENDER_SECURITY
MAX_QUEUE_SIZE_SECURITY
1000
ASYNC_APPENDER_DATABASE
MAX_QUEUE_SIZE_DATABASE
1000
ASYNC_APPENDER_COMMUNICATION
MAX_QUEUE_SIZE_COMMUNICATION
1000
ASYNC_APPENDER_ERROR
MAX_QUEUE_SIZE_ERROR
5000
ASYNC_APPENDER_SCRIPT
MAX_QUEUE_SIZE_SCRIPT
5000
ASYNC_APPENDER_SCRIPT_ERROR
MAX_QUEUE_SIZE_SCRIPT_ERROR
5000
Sie können die Standardwerte ändern, indem Sie die zugeordnete Umgebungsvariable festlegen. Wenn Sie einen Server in Eclipse ausführen, müssen Sie die Umgebungsvariablen in Run configuration/server/environment festlegen.
Die durch Umgebungsvariablen festgelegten Werte werden nur beim Serverstart übernommen. Wenn Sie einen der Werte nach dem Starten des Servers ändern möchten, müssen Sie ihn daher neu starten.
Protokolleinstellungen
Die standardmäßigen Logback-Konfigurationseinstellungen für rollierende Dateien und Archivierung finden Sie unten. Sie können diese Einstellungen in Composer unter Untersysteme > LoggingSubsystem > Konfiguration > Protokollaufbewahrungs-Einstellungen konfigurieren.
Protokollaufbewahrungs-Einstellungen
Eigenschaftenname
Standard
Beschreibung
Maximale Dateigröße in KB
MAX_FILE_SIZE
100000
Grenzwert für die Größe jeder Protokolldatei
Maximale Anzahl der Tage für Archiv
MAX_HISTORY_SIZE
7
Anzahl der Tage, die Protokolldateien im Archiv aufbewahrt werden
Gesamtgröße aller beizubehaltenden Protokolldateien in GB
TOTAL_SIZE_CAP
10
Grenzwert für die Größe aller Protokolldateien im Archiv
Cluster-Modus im Vergleich zu Einzelserver-Modus
Im Cluster-Modus schreiben mehrere Instanzen ihre Protokolle in eine einzelne Datei. Dazu müssen Sie das prudent-Flag in der RollingFileAppender-Konfiguration aktivieren. Es gibt jedoch Einschränkungen:
• Im prudent-Modus ist Dateikomprimierung nicht zulässig. Eine Instanz kann nicht geschrieben werden, während eine andere komprimiert wird.
• Die Dateieigenschaft von FileAppender muss leer sein. Bei den meisten Betriebssystemen ist das Umbenennen einer Datei nicht zulässig, während ein anderer Prozess geöffnet ist.
Im folgenden Beispiel wurde RollingFileAppender mit SizeAndTimeBasedRollingPolicy im Cluster-Modus konfiguriert:
<!-- configuration appender -->
<appender name="CONFIGURATION" class="ch.qos.logback.core.rolling.RollingFileAppender">
<!-- Support multiple-JVM writing to the same log file -->
<prudent>true</prudent>
<rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
<fileNamePattern>{LOG_PATH}/ConfigurationLog.%d{yyyy-MM-dd}.%i.log</fileNamePattern>
<maxHistory>{MAX_HISTORY_SIZE}</maxHistory>
<totalSizeCap>{TOTAL_SIZE_CAP}</totalSizeCap>
<maxFileSize>{MAX_FILE_SIZE}</maxFileSize>
</rollingPolicy>
<encoder class="com.thingworx.logging.ThingWorxPatternLayoutEncoder">
<pattern>{CONFIGURATION_LAYOUT_PATTERN}</pattern>
</encoder>
</appender>
Im Einzelserver-Modus wird die aktive Protokolldatei in {ThingworxStorage}/logs platziert. Die Rollover-Datei befindet sich in {ThingworxStorage}/logs/archive.
Im folgenden Beispiel ist RollingFileAppender mit SizeAndTimeBasedRollingPolicy im Einzelserver-Modus konfiguriert:
<!-- application appender -->
<appender name="APPLICATION" class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>{LOG_PATH}/ApplicationLog.log</file>
<rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
<fileNamePattern>{LOG_PATH}/archives/ApplicationLog.%d{yyyy-MM-dd}.%i.log</fileNamePattern>
<maxHistory>{MAX_HISTORY_SIZE}</maxHistory>
<totalSizeCap>{TOTAL_SIZE_CAP}</totalSizeCap>
<maxFileSize>{MAX_FILE_SIZE}</maxFileSize>
</rollingPolicy>
<encoder class="com.thingworx.logging.ThingWorxPatternLayoutEncoder">
<pattern>{LAYOUT_PATTERN}</pattern>
</encoder>
</appender>
War dies hilfreich?