Verständnis von Open WebUI Logging 🪵

Logging ist unerlässlich für Debugging, Monitoring und das Verständnis des Verhaltens von Open WebUI. Dieser Leitfaden erklärt, wie Logging sowohl im Browser-Client (Frontend) als auch im Anwendungsserver/Backend funktioniert.

🖥️ Browser-Client Logging (Frontend)

Für die Frontend-Entwicklung und das Debugging verwendet Open WebUI standardmäßiges Browser-Konsolen-Logging. Das bedeutet, dass Sie Protokolle direkt in den integrierten Entwicklertools Ihres Webbrowsers sehen können.

So greifen Sie auf Browser-Protokolle zu

1. Entwicklertools öffnen: In den meisten Browsern können Sie die Entwicklertools öffnen, indem Sie

   • mit der rechten Maustaste irgendwo auf der Open WebUI-Seite klicken und "Untersuchen" oder "Element untersuchen" auswählen.
   • F12 drücken (oder Cmd+Opt+I auf macOS).

2. Zum Tab "Konsole" navigieren: Klicken Sie im Bedienfeld der Entwicklertools auf den Tab "Konsole".

Arten von Browser-Protokollen

Open WebUI verwendet hauptsächlich JavaScript's console.log() für das Client-seitige Logging. Sie sehen verschiedene Arten von Meldungen in der Konsole, darunter

• Informationsmeldungen: Allgemeiner Anwendungsfluss und Status.
• Warnungen: Mögliche Probleme oder nicht kritische Fehler.
• Fehler: Probleme, die die Funktionalität beeinträchtigen könnten.

Browser-spezifische Entwicklertools

Verschiedene Browser bieten leicht unterschiedliche Entwicklertools, aber alle bieten eine Konsole zur Anzeige von JavaScript-Protokollen. Hier sind Links zur Dokumentation für gängige Browser

• [Blink] Chrome/Chromium (z.B. Chrome, Edge): Chrome DevTools Dokumentation
• [Gecko] Firefox: Firefox Developer Tools Dokumentation
• [WebKit] Safari: Safari Developer Tools Dokumentation

⚙️ Anwendungsserver/Backend Logging (Python)

Das Backend von Open WebUI verwendet Pythons integriertes logging-Modul, um Ereignisse und Informationen serverseitig aufzuzeichnen. Diese Protokolle sind entscheidend für das Verständnis des Serververhaltens, die Diagnose von Fehlern und die Überwachung der Leistung.

Schlüsselkonzepte

• Python logging Modul: Open WebUI nutzt die Standard-Python-logging-Bibliothek. Wenn Sie mit Python-Logging vertraut sind, werden Sie diesen Abschnitt unkompliziert finden. (Für tiefere Informationen siehe die Python Logging Dokumentation).
• Konsolenausgabe: Standardmäßig werden Backend-Protokolle an die Konsole (Standardausgabe) gesendet, wodurch sie in Ihrem Terminal oder in den Protokollen Ihres Docker-Containers sichtbar sind.
• Logging-Level: Logging-Level steuern die Ausführlichkeit der Protokolle. Sie können Open WebUI konfigurieren, um mehr oder weniger detaillierte Informationen basierend auf diesen Levels anzuzeigen.

🚦 Logging-Level erklärt

Python-Logging verwendet eine Hierarchie von Levels, um Protokollmeldungen nach Schweregrad zu kategorisieren. Hier ist eine Aufschlüsselung der Levels, vom höchsten zum niedrigsten Schweregrad

Level	Numerischer Wert	Beschreibung	Anwendungsfall
CRITICAL	50	Schwerwiegende Fehler, die zum Abbruch der Anwendung führen können.	Katastrophale Ausfälle, Datenbeschädigung.
ERROR	40	Fehler, die auf Probleme hinweisen, die Anwendung aber möglicherweise weiterhin funktioniert.	Behebbare Fehler, fehlgeschlagene Operationen.
WARNING	30	Mögliche Probleme oder unerwartete Situationen, die untersucht werden sollten.	Veraltete Warnungen, Ressourcenbeschränkungen.
INFO	20	Allgemeine Informationsmeldungen über den Anwendungsbetrieb.	Startmeldungen, Schlüsselereignisse, normaler Betriebsablauf.
DEBUG	10	Detaillierte Debugging-Informationen für Entwickler.	Funktionsaufrufe, Variablenwerte, detaillierte Ausführungsschritte.
NOTSET	0	Alle Meldungen werden protokolliert. (Standardmäßig WARNING, wenn nicht gesetzt).	Nützlich, um absolut alles zu erfassen, typischerweise für sehr spezifisches Debugging.

Standard-Level: Das Standard-Logging-Level von Open WebUI ist INFO.

🌍 Globales Logging-Level (GLOBAL_LOG_LEVEL)

Sie können das globale Logging-Level für das gesamte Open WebUI-Backend mit der Umgebungsvariable GLOBAL_LOG_LEVEL ändern. Dies ist der direkteste Weg, die allgemeine Protokollierungs-Ausführlichkeit zu steuern.

Wie es funktioniert

Das Setzen von GLOBAL_LOG_LEVEL konfiguriert den Root-Logger in Python und beeinflusst alle Logger in Open WebUI und möglicherweise einige Drittanbieterbibliotheken, die basicConfig verwenden. Es verwendet logging.basicConfig(force=True), was bedeutet, dass es jede bestehende Root-Logger-Konfiguration überschreibt.

Beispiel: Setzen auf DEBUG

• Docker-Parameter

  --env GLOBAL_LOG_LEVEL="DEBUG"

• Docker Compose (docker-compose.yml)

  environment:
    - GLOBAL_LOG_LEVEL=DEBUG

Auswirkung: Das Setzen von GLOBAL_LOG_LEVEL auf DEBUG erzeugt die ausführlichsten Protokolle, einschließlich detaillierter Informationen, die für die Entwicklung und Fehlerbehebung hilfreich sind. Für Produktionsumgebungen könnten INFO oder WARNING geeigneter sein, um das Protokollvolumen zu reduzieren.

⚙️ App/Backend-spezifische Logging-Level

Für eine feinere Kontrolle bietet Open WebUI Umgebungsvariablen, um Logging-Level für spezifische Backend-Komponenten festzulegen. Logging ist ein fortlaufender Arbeitsprozess, aber ein gewisses Maß an Kontrolle wird durch diese Umgebungsvariablen ermöglicht. Diese Variablen ermöglichen es Ihnen, das Logging für verschiedene Teile der Anwendung fein abzustimmen.

Verfügbare Umgebungsvariablen

Umgebungsvariable	Komponente/Modul	Beschreibung
AUDIO_LOG_LEVEL	Audioverarbeitung	Logging im Zusammenhang mit Audiotranskription (faster-whisper), Text-to-Speech (TTS) und Audiohandling.
COMFYUI_LOG_LEVEL	ComfyUI-Integration	Logging für Interaktionen mit ComfyUI, falls Sie diese Integration nutzen.
CONFIG_LOG_LEVEL	Konfigurationsmanagement	Logging im Zusammenhang mit dem Laden und Verarbeiten von Open WebUI-Konfigurationsdateien.
DB_LOG_LEVEL	Datenbankoperationen (Peewee)	Logging für Datenbankinteraktionen mit dem Peewee ORM (Object-Relational Mapper).
IMAGES_LOG_LEVEL	Bilderzeugung (AUTOMATIC1111/Stable Diffusion)	Logging für Bilderzeugungsaufgaben, insbesondere bei Verwendung der AUTOMATIC1111 Stable Diffusion-Integration.
MAIN_LOG_LEVEL	Hauptanwendungsausführung (Root-Logger)	Logging vom Haupteinstiegspunkt der Anwendung und dem Root-Logger.
MODELS_LOG_LEVEL	Modellmanagement	Logging im Zusammenhang mit dem Laden, Verwalten und Interagieren mit Sprachmodellen (LLMs), einschließlich Authentifizierung.
OLLAMA_LOG_LEVEL	Ollama Backend-Integration	Logging für Kommunikation und Interaktion mit dem Ollama-Backend.
OPENAI_LOG_LEVEL	OpenAI API-Integration	Logging für Interaktionen mit der OpenAI API (z.B. für Modelle wie GPT).
RAG_LOG_LEVEL	Retrieval-Augmented Generation (RAG)	Logging für die RAG-Pipeline, einschließlich der Chroma-Vektordatenbank und Sentence-Transformers.
WEBHOOK_LOG_LEVEL	Authentifizierungs-Webhook	Erweitertes Logging für die Authentifizierungs-Webhook-Funktionalität.

Wie man es benutzt

Sie können diese Umgebungsvariablen auf die gleiche Weise wie GLOBAL_LOG_LEVEL setzen (Docker-Parameter, Docker Compose environment-Sektion). Um beispielsweise detaillierteres Logging für Ollama-Interaktionen zu erhalten, könnten Sie setzen

environment:
  - OLLAMA_LOG_LEVEL=DEBUG

Wichtiger Hinweis: Im Gegensatz zu GLOBAL_LOG_LEVEL beeinflussen diese App-spezifischen Variablen möglicherweise nicht das Logging von *allen* Drittanbietermodulen. Sie steuern hauptsächlich das Logging innerhalb des Open WebUI-Codes.

Durch das Verständnis und die Nutzung dieser Logging-Mechanismen können Sie Ihre Open WebUI-Instanz effektiv überwachen, debuggen und Einblicke gewinnen.