Protokollierung und Diagnose

Letzte Aktualisierung: 14.10.2026

QV2QS schreibt bei jedem Lauf strukturierte Diagnoseprotokolle. Das Protokollierungssystem hat zwei Ebenen: ein persistentes Systemprotokoll, das über mehrere Läufe hinweg bestehen bleibt, und ein strukturiertes Protokoll pro Lauf, das mit der Konvertierungsausgabe geliefert wird.

Systemprotokoll

QV2QS pflegt eine rotierende Protokolldatei an einem festen Standort auf der Festplatte. Das Systemprotokoll beginnt, wenn die ausführbare Datei gestartet wird, und zeichnet Ereignisse auf Anwendungsebene auf, unabhängig von jedem Projekt oder Batch.

Standort: %LOCALAPPDATA%\QV2QS\qv2qs.log

Das Systemprotokoll verwendet einen rotierenden Dateihandler mit den folgenden Einstellungen.

Wenn die aktive Protokolldatei 25 MB erreicht, dreht QV2QS die Datei und erstellt eine neue Protokolldatei. Die drei aktuellsten Backups werden beibehalten. Ältere Backups werden automatisch gelöscht.

Laufspezifisches strukturiertes Protokoll

Jeder Konvertierungslauf erzeugt eine separate Protokolldatei, die detaillierte Ereignisse für diesen Lauf enthält. Die Datei heißt qv2qs_run_<version>_<timestamp>.log und liegt im Tabulator-getrennte Werte (TSV)-Format mit einer JSON-Datenspalte vor.

Standard-Standort: %LOCALAPPDATA%\QV2QS\logs\

Im Einzelprojektmodus verschiebt QV2QS die Protokolldatei in den logs/ Unterordner des Projektausgabeordners (zum Beispiel <outputDir>/Sales/logs/), nachdem der Ausgabeordner initialisiert wurde. Die Protokolldatei ist in der Konvertierungsausgabe enthalten.

Im Stapelmodus werden projektbezogene Protokolle in den logs/ Unterordner innerhalb jedes Projektausgabeordners geschrieben.

Protokolldateiformat

Jede Protokolldatei beginnt mit einer TSV-Kopfzeile:

ts_utc	level	version	run_id	logger	event	message	data

Zeitstempelkollisionen

Wenn zwei Läufe innerhalb derselben Sekunde starten und denselben Zeitstempel erzeugen, hängt QV2QS _2, _3 oder nachfolgende Nummern an den Dateinamen an, um ein Überschreiben zu vermeiden.

Welches Protokoll ist zu prüfen

QV2QS schreibt in zwei separate Protokolle in verschiedenen Phasen eines Laufs. Das Systemprotokoll ist immer verfügbar. Das Pro-Lauf-Protokoll wird erst nach Abschluss der Startinitialisierung erstellt.

Protokollstufen

Fünf Log-Level stehen zur Verfügung, aufgelistet von der ausführlichsten zur am wenigsten ausführlichen.

Legen Sie die Protokollstufe mit --logLevel oder der QV2QS_LOG_LEVEL Umgebungs-Variable fest. Das CLI-Flag hat Vorrang, wenn beide gesetzt sind.

Stellen Sie --logLevel DEBUG so ein, dass die detaillierteste Ausgabe erfasst wird. Einträge auf Debug-Ebene umfassen Konvertierungsentscheidungen, Cloud-API-Aufrufe, Skriptänderungen und Details zur Objektverarbeitung.

Um die Debug-Protokollierung zu aktivieren, ohne die Befehlszeile zu ändern, setzen Sie die Umgebungsvariable, bevor Sie QV2QS ausführen:

set QV2QS_LOG_LEVEL=DEBUG
QV2QS.exe --prjPath ./MyApp-prj --outputDir ./output --qvw MyApp.qvw --unbuildOnly

Protokollbereinigung

Protokolldateien sammeln sich über Läufe hinweg im persistenten Protokollverzeichnis an. Verwenden Sie --cleanLogs, um Protokolldateien, die älter als 30 Tage sind, zu Beginn eines Laufs zu löschen. Die Bereinigung betrifft nur das persistente Protokollverzeichnis; projektbezogene Protokolle in Ausgabeverzeichnissen sind nicht betroffen.

Geheimnismaskierung

Log-Einträge maskieren sensible Werte automatisch. API-Schlüssel, Token, Passwörter und Client-Geheimnisse werden geschwärzt, sodass nur die letzten vier Zeichen angezeigt werden. Kommandozeilenargumente, die vertrauliche Informationen enthalten, werden bei der Protokollierung ebenfalls maskiert.

QlikView Desktop-Engine-Protokollierung

Wenn die PRJ-Generierung aktiviert ist, protokolliert QV2QS, welche QlikView Desktop-Engine für jede Datei verwendet wird. Das Protokollereignis prj_generate_start zeichnet auf, ob die gebündelte portable Engine oder eine systeminstallierte Version aktiv ist und die Dateiversion der gebündelten ausführbaren Datei enthält, sofern verfügbar.

Nachdem die Verbindung zu QlikView Desktop hergestellt wurde, erfasst das Ereignis prj_qv_ready die QlikView-Version, die von der laufenden Engine gemeldet wird (zum Beispiel, 12.100.20100.0). Wenn die gebündelte Engine verwendet wird, erfasst das exe_file_version Feld die Dateiversion, die aus der ausführbaren Datei gelesen wurde.

Im Stapelmodus zeichnet das Protokollereignis prj_batch_prereq die Engine-Auswahl und die gebündelte Version für den gesamten Stapel auf, bevor Dateien verarbeitet werden. Wenn weder eine gebündelte Engine noch eine Systeminstallation verfügbar ist, wird der Fehler als prj_batch_no_qv im Systemprotokoll protokolliert.

Stellen Sie --logLevel DEBUG so ein, dass detaillierte Schritte zur Engine-Auflösung erfasst werden, einschließlich der Dateipfade, die während der Engine-Erkennung überprüft wurden.

Konsolenausgabe vs. Dateiprotokollierung

Konsolenausgabe und Dateiprotokollierung sind unabhängige Systeme.

Konsolenausgabe erscheint nicht in den Protokolldateien. Das --console silent Flag unterdrückt die Konsolenausgabe, ohne die Dateiprotokollierung zu beeinflussen.

CLI-Argumente

Mehr erfahren

• Argumentreferenz
• Fehlerbehebung für