Logging in Gateways ab OCT Version 2026.02

Diese Anleitung beschreibt, wie der Status von Pipeline-Ausführungen in OCT Gateways gezielt über Python-Logging gesteuert werden kann.

1. Verwendung von Logging in Python für OCT-Pipelines

Diese Anleitung gilt für Gateways, die über die Pipeline-Steps „Python“ oder „Container“ ausgeführt werden.

Um den Status einer Pipelineausführung steuern zu können, müssen speziell formatierte Logeinträge im Python-Skript erzeugt werden.

Das OCT-Pipeline-Prozesslog erkennt bestimmte Präfixe, sofern diese in eckigen Klammern [ ] stehen. Nur dann werden sie korrekt interpretiert und ausgewertet.

Für die Umsetzung empfiehlt sich das Standardmodul logging von Python. Dieses ist bereits in Python und muss nicht zusätzlich installiert werden. Es wird einfach zu Beginn des Skripts eingebunden:

import logging

Das Logging-Modul eignet sich besonders gut, da sich die Formatierung der Logausgaben flexibel anpassen lässt.

2. Übersicht der Präfixe

Präfix	Wofür?	Beispiel	Log-Level in OCT
[DEBUG]	Debugging-Nachrichten (standardmäßig ausgeblendet, optional sichtbar)	logging.debug(“Funktion ‘Datenabruf’ aufgerufen.”)	Debug
[INFO]	Allgemeine Informationen zum Programmablauf	logging.info(“Datenabruf erfolgreich beendet”)	Info
[WARNING]	Warnung - Pipeline wird gelb markiert (“Prozess wurde mit Warnungen beendet”)	logging.warning(“Konfiguration nicht gefunden, verwende Standardwerte”)	Warning
[ERROR]	Fehler - gesamte Pipeline wird rot markiert (“Prozess mit Fehlern beendet”)	logging.error(“Datenabruf fehlgeschlagen”)	Error

3. Beispiele

Das folgende Beispiel zeigt eine typische Konfiguration mit:

Ausgabe in eine lokale Logdatei (inkl. Zeitstempel)
Ausgabe ins Terminal bzw. OCT-Prozesslog (ohne Zeitstempel, aber mit Präfixen. Das OCT-Prozesslog benutzt eigene Zeitstempel, daher sind diese hier nicht notwendig.)

Python

import sys
import logging

# Logverzeichnis für die lokale Textlogdatei erstellen
script_dir = os.path.dirname(os.path.abspath(__file__))
log_folder = os.path.join(script_dir, "log")
os.makedirs(log_folder, exist_ok=True)
log_filename = os.path.join (log_folder,datetime.now().strftime("Log_%Y-%m-%d_%H-%M-%S.log"))

logger = logging.getLogger()
#Loglevel DEBUG: alle LOGLEVEL >= Debug werden ausgegeben. Wenn hier INFO gesetzt wird, dann werden keine DEBUG Logs ausgegeben
logger.setLevel(logging.DEBUG)

#Ausgabe in die lokale Textdatei mit Zeitstempel konfigurieren
file_handler = logging.FileHandler(log_filename, encoding="utf-8")
file_handler.setLevel(logging.DEBUG)
file_handler.setFormatter(logging.Formatter(
    "%(asctime)s - [%(levelname)s] - %(message)s",
    "%Y-%m-%d %H:%M:%S"
))
#Ausgabe über Standardoutputstream auf das Terminal/OCT Prozesslog ohne Zeitstempel
console_handler = logging.StreamHandler(sys.stdout)
console_handler.setLevel(logging.DEBUG)
console_handler.setFormatter(logging.Formatter(
    "[%(levelname)s] %(message)s" #hier wichtig: die [ ] um den Levelname damit OCT es erkennt
))
#beide Ausgabekanäle zum Logger hinzufügen
logger.addHandler(file_handler)
logger.addHandler(console_handler)

Wenn man nun mit diesem Setup folgende Zeilen im Pythonskript ausgeben lässt, …

Python

logging.info   ("Diese Logausgabe wird als Info angezeigt.")
logging.warning("Diese Logausgabe wird als Warnung angezeigt.")
logging.debug  ("Diese Logausgabe wird als Debug angezeigt.")
logging.error  ("Diese Logausgabe wird als Fehler angezeigt.")

… erhält man dieses Ergebnis im OCT-Prozesslog:

So sieht die gleichzeitig erfolgte Ausgabe in der lokalen Textdatei aus:

2026-03-11 15:24:27 - [INFO] - Diese Logausgabe wird als Info angezeigt.
2026-03-11 15:24:27 - [WARNING] - Diese Logausgabe wird als Warnung angezeigt.
2026-03-11 15:24:27 - [DEBUG] - Diese Logausgabe wird als Debug angezeigt.
2026-03-11 15:24:27 - [ERROR] - Diese Logausgabe wird als Fehler angezeigt.

4. Hinweise & Best Practices

Präfixe müssen immer exakt in eckigen Klammern [ ] stehen.
Verwende [ERROR]nur, um echte Fehler anzuzeigen, da dies die gesamte Pipeline als fehlgeschlagen markiert.
[WARNING] eignet sich für nicht-kritische Probleme mit Fallback-Verhalten, z. B. bei einer Retry-Logik (Warnung, erster Versuch beim Datenabruf ist fehlgeschlagen, aber der zweite Versuch war erfolgreich).
[DEBUG] ist ideal für detaillierte Analysen und technische Informationen.