logging.handlers — Logging handler

Quellcode: Lib/logging/handlers.py

Die folgenden nützlichen Handler werden im Paket bereitgestellt. Beachten Sie, dass drei der Handler (StreamHandler, FileHandler und NullHandler) tatsächlich im logging-Modul selbst definiert sind, aber hier zusammen mit den anderen Handlern dokumentiert wurden.

StreamHandler

Die Klasse StreamHandler, die sich im Kernpaket logging befindet, sendet Protokollausgaben an Streams wie sys.stdout, sys.stderr oder jedes dateiähnliche Objekt (oder genauer gesagt, jedes Objekt, das write() und flush() Methoden unterstützt).

class logging.StreamHandler(stream=None)

Gibt eine neue Instanz der Klasse StreamHandler zurück. Wenn stream angegeben ist, verwendet die Instanz diesen für die Protokollausgabe; andernfalls wird sys.stderr verwendet.

emit(record)

Wenn ein Formatierer angegeben ist, wird dieser zur Formatierung des Datensatzes verwendet. Der Datensatz wird dann mit terminator in den Stream geschrieben. Wenn Ausnahminformationen vorhanden sind, werden diese mit traceback.print_exception() formatiert und an den Stream angehängt.

flush()

Leert den Stream durch Aufrufen seiner flush() Methode. Beachten Sie, dass die close() Methode von Handler geerbt wird und daher keine Ausgabe erzeugt, sodass manchmal ein expliziter flush()-Aufruf erforderlich sein kann.

setStream(stream)

Setzt den Stream der Instanz auf den angegebenen Wert, falls dieser unterschiedlich ist. Der alte Stream wird geleert, bevor der neue Stream gesetzt wird.

Parameter:

stream – Der Stream, den der Handler verwenden soll.

Rückgabewert:

der alte Stream, wenn der Stream geändert wurde, oder None, wenn dies nicht der Fall war.

Hinzugefügt in Version 3.7.

terminator

Zeichenkette, die als Terminator beim Schreiben eines formatierten Datensatzes in einen Stream verwendet wird. Standardwert ist '\n'.

Wenn Sie keine Zeilenumbruch-Terminierung wünschen, können Sie das Attribut terminator der Handler-Instanz auf die leere Zeichenkette setzen.

In früheren Versionen war der Terminator fest auf '\n' codiert.

Hinzugefügt in Version 3.2.

FileHandler

Die Klasse FileHandler, die sich im Kernpaket logging befindet, sendet Protokollausgaben in eine Disk-Datei. Sie erbt die Ausgabefunktionalität von StreamHandler.

class logging.FileHandler(filename, mode='a', encoding=None, delay=False, errors=None)

Gibt eine neue Instanz der Klasse FileHandler zurück. Die angegebene Datei wird geöffnet und als Stream für die Protokollierung verwendet. Wenn mode nicht angegeben ist, wird 'a' verwendet. Wenn encoding nicht None ist, wird es zum Öffnen der Datei mit dieser Kodierung verwendet. Wenn delay wahr ist, wird das Öffnen der Datei bis zum ersten Aufruf von emit() verzögert. Standardmäßig wächst die Datei unbegrenzt. Wenn errors angegeben ist, bestimmt es, wie Kodierungsfehler behandelt werden.

Geändert in Version 3.6: Neben Zeichenkettenwerten werden auch Path-Objekte für das Argument filename akzeptiert.

Geändert in Version 3.9: Der Parameter errors wurde hinzugefügt.

close()

Schließt die Datei.

emit(record)

Gibt den Datensatz in die Datei aus.

Beachten Sie, dass, wenn die Datei aufgrund des Herunterfahrens der Protokollierung beim Beenden geschlossen wurde und der Dateimodus 'w' ist, der Datensatz nicht ausgegeben wird (siehe bpo-42378).

NullHandler

Hinzugefügt in Version 3.1.

Die Klasse NullHandler, die sich im Kernpaket logging befindet, führt keine Formatierung oder Ausgabe durch. Es handelt sich im Wesentlichen um einen „No-Op“-Handler für Bibliotheksentwickler.

class logging.NullHandler

Gibt eine neue Instanz der Klasse NullHandler zurück.

emit(record)

Diese Methode tut nichts.

handle(record)

Diese Methode tut nichts.

createLock()

Diese Methode gibt None für das Lock zurück, da es keine zugrunde liegende I/O gibt, deren Zugriff serialisiert werden müsste.

Weitere Informationen zur Verwendung von NullHandler finden Sie unter Konfiguration von Logging für eine Bibliothek.

WatchedFileHandler

Die Klasse WatchedFileHandler, die sich im Modul logging.handlers befindet, ist ein FileHandler, der die Datei, in die er protokolliert, überwacht. Wenn sich die Datei ändert, wird sie geschlossen und unter Verwendung des Dateinamens wieder geöffnet.

Eine Dateänderung kann durch die Verwendung von Programmen wie newsyslog und logrotate erfolgen, die eine Rotation von Logdateien durchführen. Dieser Handler, der für die Verwendung unter Unix/Linux gedacht ist, überwacht die Datei, um festzustellen, ob sie sich seit der letzten Ausgabe geändert hat. (Eine Datei gilt als geändert, wenn ihr Gerät oder ihre Inode-Nummer sich geändert hat.) Wenn sich die Datei geändert hat, wird der alte Dateistream geschlossen und die Datei geöffnet, um einen neuen Stream zu erhalten.

Dieser Handler ist für die Verwendung unter Windows nicht geeignet, da unter Windows geöffnete Logdateien nicht verschoben oder umbenannt werden können – die Protokollierung öffnet die Dateien mit exklusiven Sperren –, sodass ein solcher Handler nicht benötigt wird. Außerdem wird ST_INO unter Windows nicht unterstützt; stat() gibt für diesen Wert immer Null zurück.

class logging.handlers.WatchedFileHandler(filename, mode='a', encoding=None, delay=False, errors=None)

Gibt eine neue Instanz der Klasse WatchedFileHandler zurück. Die angegebene Datei wird geöffnet und als Stream für die Protokollierung verwendet. Wenn mode nicht angegeben ist, wird 'a' verwendet. Wenn encoding nicht None ist, wird es zum Öffnen der Datei mit dieser Kodierung verwendet. Wenn delay wahr ist, wird das Öffnen der Datei bis zum ersten Aufruf von emit() verzögert. Standardmäßig wächst die Datei unbegrenzt. Wenn errors angegeben ist, bestimmt es, wie Kodierungsfehler behandelt werden.

Geändert in Version 3.6: Neben Zeichenkettenwerten werden auch Path-Objekte für das Argument filename akzeptiert.

Geändert in Version 3.9: Der Parameter errors wurde hinzugefügt.

reopenIfNeeded()

Prüft, ob sich die Datei geändert hat. Wenn ja, wird der vorhandene Stream geleert und geschlossen und die Datei erneut geöffnet, typischerweise als Vorbereitung für die Ausgabe des Datensatzes in die Datei.

Hinzugefügt in Version 3.6.

emit(record)

Gibt den Datensatz in die Datei aus, ruft aber zuerst reopenIfNeeded() auf, um die Datei bei Bedarf wieder zu öffnen.

BaseRotatingHandler

Die Klasse BaseRotatingHandler, die sich im Modul logging.handlers befindet, ist die Basisklasse für die rotierenden Dateihandler RotatingFileHandler und TimedRotatingFileHandler. Sie müssen diese Klasse normalerweise nicht instanziieren, aber sie verfügt über Attribute und Methoden, die Sie möglicherweise überschreiben müssen.

class logging.handlers.BaseRotatingHandler(filename, mode, encoding=None, delay=False, errors=None)

Die Parameter entsprechen denen für FileHandler. Die Attribute sind

namer

Wenn dieses Attribut auf ein aufrufbares Objekt gesetzt ist, delegiert die Methode rotation_filename() an dieses aufrufbare Objekt. Die an das aufrufbare Objekt übergebenen Parameter sind diejenigen, die an rotation_filename() übergeben wurden.

Hinweis

Die Namensfunktion wird während des Rollovers ziemlich oft aufgerufen, daher sollte sie so einfach und schnell wie möglich sein. Sie sollte auch jedes Mal die gleiche Ausgabe für eine gegebene Eingabe zurückgeben, sonst funktioniert das Rollover-Verhalten möglicherweise nicht wie erwartet.

Es ist auch erwähnenswert, dass bei der Verwendung eines Namens darauf geachtet werden sollte, bestimmte Attribute im Dateinamen zu erhalten, die während des Rollovers verwendet werden. Zum Beispiel erwartet RotatingFileHandler, dass es eine Reihe von Logdateien gibt, deren Namen aufeinanderfolgende Zahlen enthalten, damit der Rollover wie erwartet funktioniert, und TimedRotatingFileHandler löscht alte Logdateien (basierend auf dem Parameter backupCount, der an den Initialisierer des Handlers übergeben wird), indem die ältesten zu löschenden Dateien ermittelt werden. Damit dies geschieht, sollten die Dateinamen anhand des Datums-/Zeitanteils des Dateinamens sortierbar sein, und ein Namensgeber muss dies berücksichtigen. (Wenn ein Namensgeber gewünscht ist, der dieses Schema nicht beachtet, muss er in einer Unterklasse von TimedRotatingFileHandler verwendet werden, die die Methode getFilesToDelete() überschreibt, um zum benutzerdefinierten Namensschema zu passen.)

Hinzugefügt in Version 3.3.

rotator

Wenn dieses Attribut auf ein aufrufbares Objekt gesetzt ist, delegiert die Methode rotate() an dieses aufrufbare Objekt. Die an das aufrufbare Objekt übergebenen Parameter sind diejenigen, die an rotate() übergeben wurden.

Hinzugefügt in Version 3.3.

rotation_filename(default_name)

Ändert den Dateinamen einer Logdatei beim Rollen.

Dies wird bereitgestellt, damit ein benutzerdefinierter Dateiname angegeben werden kann.

Die Standardimplementierung ruft das Attribut 'namer' des Handlers auf, wenn es aufrufbar ist, und übergibt ihm den Standardnamen. Wenn das Attribut nicht aufrufbar ist (Standard ist None), wird der Name unverändert zurückgegeben.

Parameter:

default_name – Der Standardname für die Logdatei.

Hinzugefügt in Version 3.3.

rotate(source, dest)

Rotiert beim Rollen die aktuelle Logdatei.

Die Standardimplementierung ruft das Attribut 'rotator' des Handlers auf, wenn es aufrufbar ist, und übergibt ihm die Quell- und Zielargumente. Wenn das Attribut nicht aufrufbar ist (Standard ist None), wird die Quelle einfach in das Ziel umbenannt.

Parameter:

  • source – Der Quell-Dateiname. Dies ist normalerweise der Basis-Dateiname, z. B. „test.log“.

  • dest – Der Ziel-Dateiname. Dies ist normalerweise das, worin die Quelle rotiert wird, z. B. „test.log.1“.

Hinzugefügt in Version 3.3.

Der Grund für die Existenz der Attribute ist, dass Sie keine Unterklasse erstellen müssen – Sie können dieselben aufrufbaren Objekte für Instanzen von RotatingFileHandler und TimedRotatingFileHandler verwenden können. Wenn entweder die Namens- oder die Rotator-Aufrufvariable eine Ausnahme auslöst, wird dies auf die gleiche Weise wie jede andere Ausnahme während eines emit()-Aufrufs behandelt, d. h. über die Methode handleError() des Handlers.

Wenn Sie Rotation-bezogene Verarbeitungen stärker ändern müssen, können Sie die Methoden überschreiben.

Ein Beispiel finden Sie unter Verwendung eines Rotators und Namensgebers zur Anpassung der Log-Rotation-Verarbeitung.

RotatingFileHandler

Die Klasse RotatingFileHandler im Modul logging.handlers unterstützt die Rotation von Disk-Logdateien.

class logging.handlers.RotatingFileHandler(filename, mode='a', maxBytes=0, backupCount=0, encoding=None, delay=False, errors=None)

Gibt eine neue Instanz der Klasse RotatingFileHandler zurück. Die angegebene Datei wird geöffnet und als Stream für die Protokollierung verwendet. Wenn mode nicht angegeben ist, wird 'a' verwendet. Wenn encoding nicht None ist, wird es zum Öffnen der Datei mit dieser Kodierung verwendet. Wenn delay wahr ist, wird das Öffnen der Datei bis zum ersten Aufruf von emit() verzögert. Standardmäßig wächst die Datei unbegrenzt. Wenn errors angegeben ist, bestimmt es, wie Kodierungsfehler behandelt werden.

Sie können die Werte maxBytes und backupCount verwenden, um die Datei bei einer vordefinierten Größe rotieren zu lassen. Wenn die Größe überschritten zu werden droht, wird die Datei geschlossen und eine neue Datei wird stillschweigend für die Ausgabe geöffnet. Die Rotation erfolgt jedes Mal, wenn die aktuelle Logdatei fast maxBytes lang ist; wenn jedoch entweder maxBytes oder backupCount Null ist, erfolgt keine Rotation, sodass Sie im Allgemeinen backupCount auf mindestens 1 setzen und ein nicht-null maxBytes haben möchten. Wenn backupCount nicht null ist, speichert das System alte Logdateien, indem es die Erweiterungen „.1“, „.2“ usw. an den Dateinamen anhängt. Zum Beispiel würden Sie bei einem backupCount von 5 und einem Basisdateinamen von app.log app.log, app.log.1, app.log.2 bis hin zu app.log.5 erhalten. Die Datei, in die geschrieben wird, ist immer app.log. Wenn diese Datei gefüllt ist, wird sie geschlossen und in app.log.1 umbenannt, und wenn die Dateien app.log.1, app.log.2 usw. existieren, werden sie entsprechend in app.log.2, app.log.3 usw. umbenannt.

Geändert in Version 3.6: Neben Zeichenkettenwerten werden auch Path-Objekte für das Argument filename akzeptiert.

Geändert in Version 3.9: Der Parameter errors wurde hinzugefügt.

doRollover()

Führt eine Rotation durch, wie oben beschrieben.

emit(record)

Gibt den Datensatz in die Datei aus und berücksichtigt dabei die oben beschriebene Rotation.

shouldRollover(record)

Prüft, ob der übergebene Datensatz dazu führen würde, dass die Datei das konfigurierte Größenlimit überschreitet.

TimedRotatingFileHandler

Die Klasse TimedRotatingFileHandler im Modul logging.handlers unterstützt die Rotation von Disk-Logdateien in bestimmten zeitlichen Abständen.

class logging.handlers.TimedRotatingFileHandler(filename, when='h', interval=1, backupCount=0, encoding=None, delay=False, utc=False, atTime=None, errors=None)

Gibt eine neue Instanz der Klasse TimedRotatingFileHandler zurück. Die angegebene Datei wird geöffnet und als Stream für die Protokollierung verwendet. Beim Rotieren wird auch die Dateinamenserweiterung festgelegt. Die Rotation basiert auf dem Produkt von when und interval.

Sie können when verwenden, um die Art von interval anzugeben. Die Liste der möglichen Werte ist unten aufgeführt. Beachten Sie, dass sie nicht zwischen Groß- und Kleinschreibung unterscheiden.

Wert

Art des Intervalls

Wenn/wie atTime verwendet wird

'S'

Sekunden

Ignoriert

'M'

Minuten

Ignoriert

'H'

Stunden

Ignoriert

'D'

Tage

Ignoriert

'W0'-'W6'

Wochentag (0=Montag)

Verwendet zur Berechnung der anfänglichen Rotationszeit

'midnight'

Rotiert um Mitternacht, wenn atTime nicht angegeben ist, andernfalls zur Zeit atTime

Verwendet zur Berechnung der anfänglichen Rotationszeit

Bei wochentagsbasierter Rotation geben Sie „W0“ für Montag, „W1“ für Dienstag usw. bis „W6“ für Sonntag an. In diesem Fall wird der für interval übergebene Wert nicht verwendet.

Das System speichert alte Logdateien, indem es Erweiterungen an den Dateinamen anhängt. Die Erweiterungen basieren auf Datum und Uhrzeit und verwenden das strftime-Format %Y-%m-%d_%H-%M-%S oder einen führenden Teil davon, abhängig vom Rotationsintervall.

Bei der erstmaligen Berechnung der nächsten Rotationszeit (wenn der Handler erstellt wird) wird die letzte Änderungszeit einer vorhandenen Logdatei oder andernfalls die aktuelle Zeit verwendet, um zu berechnen, wann die nächste Rotation stattfinden wird.

Wenn das Argument utc wahr ist, werden UTC-Zeiten verwendet; andernfalls wird die lokale Zeit verwendet.

Wenn backupCount nicht null ist, werden höchstens backupCount Dateien aufbewahrt, und wenn beim Eintreten der Rotation weitere erstellt würden, wird die älteste gelöscht. Die Löschlogik verwendet das Intervall, um zu bestimmen, welche Dateien gelöscht werden sollen. Das Ändern des Intervalls kann also dazu führen, dass alte Dateien herumliegen.

Wenn delay wahr ist, wird das Öffnen der Datei bis zum ersten Aufruf von emit() verzögert.

Wenn atTime nicht None ist, muss es eine datetime.time Instanz sein, die die Tageszeit angibt, zu der die Rotation stattfindet, für die Fälle, in denen die Rotation auf „Mitternacht“ oder „an einem bestimmten Wochentag“ gesetzt ist. Beachten Sie, dass in diesen Fällen der Wert atTime effektiv zur Berechnung der *anfänglichen* Rotation verwendet wird und nachfolgende Rotationen über die normale Intervallberechnung berechnet werden.

Wenn errors angegeben ist, bestimmt es, wie Kodierungsfehler behandelt werden.

Hinweis

Die Berechnung der anfänglichen Rotationszeit erfolgt bei der Initialisierung des Handlers. Die Berechnung nachfolgender Rotationszeiten erfolgt nur, wenn eine Rotation eintritt, und eine Rotation tritt nur beim Ausgeben von Protokollen ein. Wenn dies nicht berücksichtigt wird, kann dies zu Verwirrung führen. Wenn beispielsweise ein Intervall von „jede Minute“ eingestellt ist, bedeutet dies nicht, dass Sie immer Logdateien mit Zeiten (im Dateinamen) sehen werden, die durch eine Minute getrennt sind. Wenn während der Ausführung der Anwendung Protokollausgaben häufiger als einmal pro Minute generiert werden, *dann* können Sie damit rechnen, Logdateien mit Zeiten zu sehen, die durch eine Minute getrennt sind. Wenn andererseits nur alle fünf Minuten (sagen wir) Logmeldungen ausgegeben werden, gibt es Lücken in den Dateizeiten, die den Minuten entsprechen, in denen keine Ausgabe (und damit keine Rotation) stattfand.

Geändert in Version 3.4: Der Parameter atTime wurde hinzugefügt.

Geändert in Version 3.6: Neben Zeichenkettenwerten werden auch Path-Objekte für das Argument filename akzeptiert.

Geändert in Version 3.9: Der Parameter errors wurde hinzugefügt.

doRollover()

Führt eine Rotation durch, wie oben beschrieben.

emit(record)

Gibt den Datensatz in die Datei aus und berücksichtigt dabei die oben beschriebene Rotation.

getFilesToDelete()

Gibt eine Liste von Dateinamen zurück, die im Rahmen des Rollovers gelöscht werden sollen. Diese

shouldRollover(record)

Prüft, ob genügend Zeit für einen Rollover vergangen ist, und berechnet gegebenenfalls die nächste Rollover-Zeit.

SocketHandler

Die Klasse SocketHandler, im Modul logging.handlers, sendet Logging-Ausgaben an einen Netzwerk-Socket. Die Basisklasse verwendet einen TCP-Socket.

class logging.handlers.SocketHandler(host, port)

Gibt eine neue Instanz der Klasse SocketHandler zurück, die für die Kommunikation mit einem entfernten Rechner bestimmt ist, dessen Adresse durch host und port angegeben wird.

Geändert in Version 3.4: Wenn port als None angegeben wird, wird ein Unix-Domain-Socket unter Verwendung des Wertes in host erstellt – andernfalls wird ein TCP-Socket erstellt.

close()

Schließt den Socket.

emit()

Pickelt das Attribut-Dictionary des Datensatzes und schreibt es im Binärformat in den Socket. Bei Fehlern mit dem Socket wird das Paket stillschweigend verworfen. Wenn die Verbindung zuvor verloren gegangen ist, wird die Verbindung wiederhergestellt. Um den Datensatz am empfangenden Ende in einen LogRecord zu entpickeln, verwenden Sie die Funktion makeLogRecord().

handleError()

Behandelt einen Fehler, der während emit() aufgetreten ist. Die wahrscheinlichste Ursache ist eine verlorene Verbindung. Schließt den Socket, damit wir beim nächsten Ereignis erneut versuchen können.

makeSocket()

Dies ist eine Factory-Methode, die es Unterklassen ermöglicht, den genauen Socke-Typ zu definieren, den sie wünschen. Die Standardimplementierung erstellt einen TCP-Socket (socket.SOCK_STREAM).

makePickle(record)

Pickelt das Attribut-Dictionary des Datensatzes im Binärformat mit einem Längenpräfix und gibt es zur Übertragung über den Socket bereit zurück. Die Details dieses Vorgangs sind äquivalent zu

data = pickle.dumps(record_attr_dict, 1)
datalen = struct.pack('>L', len(data))
return datalen + data

Beachten Sie, dass Pickles nicht vollständig sicher sind. Wenn Sie Bedenken hinsichtlich der Sicherheit haben, sollten Sie diese Methode überschreiben, um einen sichereren Mechanismus zu implementieren. Sie können beispielsweise Pickles mit HMAC signieren und sie dann am empfangenden Ende verifizieren oder alternativ das Entpickeln globaler Objekte am empfangenden Ende deaktivieren.

send(packet)

Sendet ein gepickeltes Byte-String-Paket an den Socket. Das Format des gesendeten Byte-Strings ist wie in der Dokumentation für makePickle() beschrieben.

Diese Funktion ermöglicht Teilsendungen, die auftreten können, wenn das Netzwerk stark ausgelastet ist.

createSocket()

Versucht, einen Socket zu erstellen; im Fehlerfall wird ein exponentieller Backoff-Algorithmus verwendet. Bei einem anfänglichen Fehler wird die Nachricht, die der Handler zu senden versucht hat, verworfen. Wenn nachfolgende Nachrichten von derselben Instanz behandelt werden, wird die Verbindung erst nach einiger Zeit versucht. Die Standardparameter sind so eingestellt, dass die anfängliche Verzögerung eine Sekunde beträgt, und wenn die Verbindung auch nach dieser Verzögerung noch nicht hergestellt werden kann, verdoppelt der Handler die Verzögerung bei jedem Versuch bis zu einem Maximum von 30 Sekunden.

Dieses Verhalten wird durch die folgenden Handler-Attribute gesteuert

  • retryStart (anfängliche Verzögerung, Standardwert 1,0 Sekunden).

  • retryFactor (Multiplikator, Standardwert 2,0).

  • retryMax (maximale Verzögerung, Standardwert 30,0 Sekunden).

Das bedeutet, dass, wenn der entfernte Listener startet, *nachdem* der Handler verwendet wurde, Sie möglicherweise Nachrichten verlieren (da der Handler erst versucht, eine Verbindung herzustellen, wenn die Verzögerung abgelaufen ist, aber während der Verzögerungsperiode Nachrichten einfach stillschweigend verwirft).

DatagramHandler

Die Klasse DatagramHandler im Modul logging.handlers erbt von SocketHandler, um das Senden von Logging-Nachrichten über UDP-Sockets zu unterstützen.

class logging.handlers.DatagramHandler(host, port)

Gibt eine neue Instanz der Klasse DatagramHandler zurück, die für die Kommunikation mit einem entfernten Rechner bestimmt ist, dessen Adresse durch host und port angegeben wird.

Hinweis

Da UDP kein Streaming-Protokoll ist, gibt es keine persistente Verbindung zwischen einer Instanz dieses Handlers und host. Aus diesem Grund kann bei Verwendung eines Netzwerk-Sockets bei jedem Protokollieren eines Ereignisses eine DNS-Auflösung erforderlich sein, was zu einer gewissen Latenz im System führen kann. Wenn dies Sie beeinträchtigt, können Sie die Auflösung selbst durchführen und diesen Handler mit der aufgelösten IP-Adresse anstelle des Hostnamens initialisieren.

Geändert in Version 3.4: Wenn port als None angegeben wird, wird ein Unix-Domain-Socket unter Verwendung des Wertes in host erstellt – andernfalls wird ein UDP-Socket erstellt.

emit()

Pickelt das Attribut-Dictionary des Datensatzes und schreibt es im Binärformat in den Socket. Bei Fehlern mit dem Socket wird das Paket stillschweigend verworfen. Um den Datensatz am empfangenden Ende in einen LogRecord zu entpickeln, verwenden Sie die Funktion makeLogRecord().

makeSocket()

Die Factory-Methode von SocketHandler wird hier überschrieben, um einen UDP-Socket (socket.SOCK_DGRAM) zu erstellen.

send(s)

Sendet einen gepickelten Byte-String an einen Socket. Das Format des gesendeten Byte-Strings ist wie in der Dokumentation für SocketHandler.makePickle() beschrieben.

SysLogHandler

Die Klasse SysLogHandler, im Modul logging.handlers, unterstützt das Senden von Logging-Nachrichten an einen entfernten oder lokalen Unix-Syslog.

class logging.handlers.SysLogHandler(address=('localhost', SYSLOG_UDP_PORT), facility=LOG_USER, socktype=socket.SOCK_DGRAM, timeout=None)

Gibt eine neue Instanz der Klasse SysLogHandler zurück, die für die Kommunikation mit einem entfernten Unix-Rechner bestimmt ist, dessen Adresse durch address in Form eines (host, port)-Tupels angegeben wird. Wenn address nicht angegeben ist, wird ('localhost', 514) verwendet. Die Adresse wird zum Öffnen eines Sockets verwendet. Eine Alternative zur Angabe eines (host, port)-Tupels ist die Angabe einer Adresse als String, z. B. '/dev/log'. In diesem Fall wird ein Unix-Domain-Socket verwendet, um die Nachricht an den Syslog zu senden. Wenn facility nicht angegeben ist, wird LOG_USER verwendet. Die Art des geöffneten Sockets hängt vom Argument socktype ab, das standardmäßig socket.SOCK_DGRAM ist und somit einen UDP-Socket öffnet. Um einen TCP-Socket zu öffnen (für die Verwendung mit neueren Syslog-Daemons wie rsyslog), geben Sie einen Wert von socket.SOCK_STREAM an. Wenn timeout angegeben ist, wird ein Timeout (in Sekunden) für die Socket-Operationen festgelegt. Dies kann verhindern, dass das Programm unendlich hängt, wenn der Syslog-Server nicht erreichbar ist. Standardmäßig ist timeout None, was bedeutet, dass kein Timeout angewendet wird.

Beachten Sie, dass, wenn Ihr Server nicht auf UDP-Port 514 lauscht, SysLogHandler möglicherweise nicht zu funktionieren scheint. In diesem Fall prüfen Sie, welche Adresse Sie für einen Domain-Socket verwenden sollten – dies ist systemabhängig. Auf Linux ist es normalerweise '/dev/log', aber auf OS/X ist es '/var/run/syslog'. Sie müssen Ihre Plattform überprüfen und die entsprechende Adresse verwenden (Sie müssen diese Prüfung möglicherweise zur Laufzeit durchführen, wenn Ihre Anwendung auf mehreren Plattformen laufen soll). Unter Windows müssen Sie praktisch die UDP-Option verwenden.

Hinweis

Auf macOS 12.x (Monterey) hat Apple das Verhalten seines Syslog-Daemons geändert – er lauscht nicht mehr auf einem Domain-Socket. Daher können Sie nicht erwarten, dass SysLogHandler auf diesem System funktioniert.

Siehe gh-91070 für weitere Informationen.

Geändert in Version 3.2: socktype wurde hinzugefügt.

Geändert in Version 3.14: timeout wurde hinzugefügt.

close()

Schließt den Socket zum entfernten Host.

createSocket()

Versucht, einen Socket zu erstellen und, falls es sich nicht um einen Datagramm-Socket handelt, ihn mit dem anderen Ende zu verbinden. Diese Methode wird während der Handler-Initialisierung aufgerufen, aber es wird nicht als Fehler betrachtet, wenn das andere Ende zu diesem Zeitpunkt nicht lauscht – die Methode wird erneut aufgerufen, wenn ein Ereignis ausgegeben wird, falls zu diesem Zeitpunkt kein Socket vorhanden ist.

Hinzugefügt in Version 3.11.

emit(record)

Der Datensatz wird formatiert und dann an den Syslog-Server gesendet. Wenn Ausnahmedetails vorhanden sind, werden sie *nicht* an den Server gesendet.

Geändert in Version 3.2.1: (Siehe: bpo-12168.) In früheren Versionen wurde die an die Syslog-Daemons gesendete Nachricht immer mit einem NUL-Byte beendet, da frühe Versionen dieser Daemons eine NUL-terminierte Nachricht erwarteten – obwohl dies nicht in der entsprechenden Spezifikation (RFC 5424) enthalten ist. Neuere Versionen dieser Daemons erwarten das NUL-Byte nicht, entfernen es aber, wenn es vorhanden ist, und noch neuere Daemons (die sich enger an RFC 5424 halten) leiten das NUL-Byte als Teil der Nachricht weiter.

Um die einfachere Handhabung von Syslog-Nachrichten angesichts all dieser unterschiedlichen Daemon-Verhaltensweisen zu ermöglichen, wurde das Anhängen des NUL-Bytes über ein Klassenattribut append_nul konfigurierbar gemacht. Dieses ist standardmäßig auf True gesetzt (wodurch das vorhandene Verhalten beibehalten wird), kann aber auf eine SysLogHandler-Instanz gesetzt werden, damit diese Instanz den NUL-Terminator *nicht* anhängt.

Geändert in Version 3.3: (Siehe: bpo-12419.) In früheren Versionen gab es keine Möglichkeit für ein "Ident" oder "Tag" Präfix, um die Quelle der Nachricht zu identifizieren. Dies kann jetzt über ein Klassenattribut spezifiziert werden, das standardmäßig auf "" gesetzt ist, um das vorhandene Verhalten beizubehalten, aber auf einer SysLogHandler-Instanz überschrieben werden kann, damit diese Instanz das Ident vor jede verarbeitete Nachricht stellt. Beachten Sie, dass das bereitgestellte Ident Text und keine Bytes sein muss und exakt so der Nachricht vorangestellt wird.

encodePriority(facility, priority)

Kodiert die Facility und Priorität in einen Integer. Sie können Strings oder Integers übergeben – wenn Strings übergeben werden, werden interne Zuordnungsdictionaries verwendet, um sie in Integers umzuwandeln.

Die symbolischen LOG_-Werte sind in SysLogHandler definiert und spiegeln die Werte wider, die in der sys/syslog.h-Headerdatei definiert sind.

Prioritäten

Name (String)

Symbolischer Wert

alert

LOG_ALERT

crit oder critical

LOG_CRIT

debug

LOG_DEBUG

emerg oder panic

LOG_EMERG

err oder error

LOG_ERR

info

LOG_INFO

notice

LOG_NOTICE

warn oder warning

LOG_WARNING

Facilities

Name (String)

Symbolischer Wert

auth

LOG_AUTH

authpriv

LOG_AUTHPRIV

cron

LOG_CRON

daemon

LOG_DAEMON

ftp

LOG_FTP

kern

LOG_KERN

lpr

LOG_LPR

mail

LOG_MAIL

news

LOG_NEWS

syslog

LOG_SYSLOG

user

LOG_USER

uucp

LOG_UUCP

local0

LOG_LOCAL0

local1

LOG_LOCAL1

local2

LOG_LOCAL2

local3

LOG_LOCAL3

local4

LOG_LOCAL4

local5

LOG_LOCAL5

local6

LOG_LOCAL6

local7

LOG_LOCAL7
mapPriority(levelname)

Ordnet einen Logging-Levelnamen einem Syslog-Prioritätsnamen zu. Möglicherweise müssen Sie dies überschreiben, wenn Sie benutzerdefinierte Level verwenden oder wenn der Standardalgorithmus für Ihre Bedürfnisse nicht geeignet ist. Der Standardalgorithmus ordnet DEBUG, INFO, WARNING, ERROR und CRITICAL den äquivalenten Syslog-Namen zu und alle anderen Levelnamen werden 'warning' zugeordnet.

NTEventLogHandler

Die Klasse NTEventLogHandler, im Modul logging.handlers, unterstützt das Senden von Logging-Nachrichten an ein lokales Windows NT-, Windows 2000- oder Windows XP-Ereignisprotokoll. Bevor Sie es verwenden können, benötigen Sie Mark Hammonds Win32-Erweiterungen für Python.

class logging.handlers.NTEventLogHandler(appname, dllname=None, logtype='Application')

Gibt eine neue Instanz der Klasse NTEventLogHandler zurück. Der appname wird verwendet, um den Anwendungsnamen zu definieren, wie er im Ereignisprotokoll erscheint. Ein entsprechender Registrierungseintrag wird unter diesem Namen erstellt. Der dllname sollte den vollständigen Pfad zu einer .dll oder .exe angeben, die Meldungsdefinitionen enthält, die im Protokoll gespeichert werden sollen (wenn nicht angegeben, wird 'win32service.pyd' verwendet – diese wird mit den Win32-Erweiterungen installiert und enthält einige grundlegende Platzhalter-Meldungsdefinitionen. Beachten Sie, dass die Verwendung dieser Platzhalter Ihre Ereignisprotokolle groß machen wird, da die gesamte Nachrichtenquelle im Protokoll gespeichert wird. Wenn Sie schlankere Protokolle wünschen, müssen Sie den Namen Ihrer eigenen .dll oder .exe übergeben, die die von Ihnen gewünschten Meldungsdefinitionen für das Ereignisprotokoll enthält). Der logtype ist entweder 'Application', 'System' oder 'Security' und ist standardmäßig 'Application'.

close()

An diesem Punkt können Sie den Anwendungsnamen aus der Registrierung als Quelle für Ereignisprotokolleinträge entfernen. Wenn Sie dies tun, können Sie die Ereignisse jedoch nicht wie vorgesehen im Event Log Viewer sehen – er muss auf die Registrierung zugreifen können, um den .dll-Namen zu erhalten. Die aktuelle Version tut dies nicht.

emit(record)

Ermittelt die Nachrichten-ID, die Ereigniskategorie und den Ereignistyp und protokolliert dann die Nachricht im NT-Ereignisprotokoll.

getEventCategory(record)

Gibt die Ereigniskategorie für den Datensatz zurück. Überschreiben Sie dies, wenn Sie Ihre eigenen Kategorien angeben möchten. Diese Version gibt 0 zurück.

getEventType(record)

Gibt den Ereignistyp für den Datensatz zurück. Überschreiben Sie dies, wenn Sie Ihre eigenen Typen angeben möchten. Diese Version führt eine Zuordnung mithilfe des Attributs typemap des Handlers durch, das in __init__() auf ein Dictionary gesetzt wird, das Zuordnungen für DEBUG, INFO, WARNING, ERROR und CRITICAL enthält. Wenn Sie Ihre eigenen Level verwenden, müssen Sie entweder diese Methode überschreiben oder ein geeignetes Dictionary im typemap-Attribut des Handlers platzieren.

getMessageID(record)

Gibt die Nachrichten-ID für den Datensatz zurück. Wenn Sie Ihre eigenen Nachrichten verwenden, könnten Sie dies tun, indem Sie die an den Logger übergebene msg als ID anstelle einer Formatzeichenkette verwenden. Dann könnten Sie hier mithilfe einer Dictionary-Suche die Nachrichten-ID abrufen. Diese Version gibt 1 zurück, was die Basis-Nachrichten-ID in win32service.pyd ist.

SMTPHandler

Die Klasse SMTPHandler, im Modul logging.handlers, unterstützt das Senden von Logging-Nachrichten an eine E-Mail-Adresse über SMTP.

class logging.handlers.SMTPHandler(mailhost, fromaddr, toaddrs, subject, credentials=None, secure=None, timeout=1.0)

Gibt eine neue Instanz der Klasse SMTPHandler zurück. Die Instanz wird mit den Absender- und Empfängeradressen sowie der Betreffzeile der E-Mail initialisiert. toaddrs sollte eine Liste von Strings sein. Um einen nicht standardmäßigen SMTP-Port anzugeben, verwenden Sie das Tupelformat (Host, Port) für das Argument mailhost. Wenn Sie einen String verwenden, wird der Standard-SMTP-Port verwendet. Wenn Ihr SMTP-Server eine Authentifizierung benötigt, können Sie ein (Benutzername, Passwort) Tupel für das Argument credentials angeben.

Um die Verwendung eines sicheren Protokolls (TLS) anzugeben, übergeben Sie ein Tupel an das Argument secure. Dies wird nur verwendet, wenn Authentifizierungsanmeldeinformationen bereitgestellt werden. Das Tupel sollte entweder ein leeres Tupel oder ein Tupel mit einem Wert sein, der den Namen eines Schlüsseldatei angibt, oder ein 2-Werte-Tupel mit den Namen der Schlüsseldatei und Zertifikatsdatei. (Dieses Tupel wird an die Methode smtplib.SMTP.starttls() übergeben.)

Ein Timeout kann für die Kommunikation mit dem SMTP-Server über das Argument timeout angegeben werden.

Geändert in Version 3.3: Der Parameter timeout wurde hinzugefügt.

emit(record)

Formatiert den Datensatz und sendet ihn an die angegebenen Empfänger.

getSubject(record)

Wenn Sie eine Betreffzeile angeben möchten, die vom Datensatz abhängt, überschreiben Sie diese Methode.

MemoryHandler

Die Klasse MemoryHandler, im Modul logging.handlers, unterstützt das Puffern von Logging-Datensätzen im Speicher und deren periodisches Auslagern an einen *Ziel*-Handler. Das Auslagern erfolgt, wenn der Puffer voll ist oder wenn ein Ereignis einer bestimmten Schwere oder höher auftritt.

MemoryHandler ist eine Unterklasse des allgemeineren BufferingHandler, einer abstrakten Klasse. Diese puffert Logging-Datensätze im Speicher. Jedes Mal, wenn ein Datensatz zum Puffer hinzugefügt wird, wird eine Prüfung durchgeführt, indem shouldFlush() aufgerufen wird, um zu sehen, ob der Puffer ausgelagert werden soll. Wenn dies der Fall ist, soll flush() das Auslagern durchführen.

class logging.handlers.BufferingHandler(capacity)

Initialisiert den Handler mit einem Puffer der angegebenen Kapazität. Hier bedeutet *capacity* die Anzahl der gepufferten Logging-Datensätze.

emit(record)

Fügt den Datensatz dem Puffer hinzu. Wenn shouldFlush() wahr zurückgibt, wird flush() aufgerufen, um den Puffer zu verarbeiten.

flush()

Bei einer BufferingHandler-Instanz bedeutet das Leeren, dass der Puffer auf eine leere Liste gesetzt wird. Diese Methode kann überschrieben werden, um ein nützlicheres Leerverhalten zu implementieren.

shouldFlush(record)

Gibt True zurück, wenn der Puffer seine Kapazität erreicht hat. Diese Methode kann überschrieben werden, um benutzerdefinierte Flush-Strategien zu implementieren.

class logging.handlers.MemoryHandler(capacity, flushLevel=ERROR, target=None, flushOnClose=True)

Gibt eine neue Instanz der Klasse MemoryHandler zurück. Die Instanz wird mit einer Puffergröße von capacity (Anzahl der gepufferten Datensätze) initialisiert. Wenn flushLevel nicht angegeben ist, wird ERROR verwendet. Wenn kein target angegeben ist, muss das Ziel mit setTarget() gesetzt werden, bevor dieser Handler etwas Nützliches tut. Wenn flushOnClose als False angegeben ist, wird der Puffer beim Schließen des Handlers *nicht* geleert. Wenn nicht angegeben oder als True angegeben, tritt das vorherige Verhalten des Leeren des Puffers beim Schließen des Handlers ein.

Geändert in Version 3.6: Der Parameter flushOnClose wurde hinzugefügt.

close()

Ruft flush() auf, setzt das Ziel auf None und leert den Puffer.

flush()

Bei einer MemoryHandler-Instanz bedeutet das Leeren, dass die gepufferten Datensätze an das Ziel gesendet werden, falls eines vorhanden ist. Der Puffer wird ebenfalls geleert, wenn gepufferte Datensätze an das Ziel gesendet werden. Überschreiben Sie diese Methode, wenn Sie ein anderes Verhalten wünschen.

setTarget(target)

Setzt den Ziel-Handler für diesen Handler.

shouldFlush(record)

Prüft auf volle Puffer oder einen Datensatz auf dem flushLevel oder höher.

HTTPHandler

Die Klasse HTTPHandler, im Modul logging.handlers, unterstützt das Senden von Logging-Nachrichten an einen Webserver unter Verwendung von entweder GET oder POST Semantik.

class logging.handlers.HTTPHandler(host, url, method='GET', secure=False, credentials=None, context=None)

Gibt eine neue Instanz der Klasse HTTPHandler zurück. Der host kann die Form host:port haben, falls Sie eine spezifische Portnummer verwenden müssen. Wenn keine method angegeben ist, wird GET verwendet. Wenn secure wahr ist, wird eine HTTPS-Verbindung verwendet. Der Parameter context kann auf eine ssl.SSLContext-Instanz gesetzt werden, um die für die HTTPS-Verbindung verwendeten SSL-Einstellungen zu konfigurieren. Wenn credentials angegeben ist, sollte es ein 2-Tupel bestehend aus Benutzer-ID und Passwort sein, das in einem HTTP-'Authorization'-Header mittels Basic Authentication platziert wird. Wenn Sie Anmeldedaten angeben, sollten Sie auch secure=True angeben, damit Ihre Benutzer-ID und Ihr Passwort nicht unverschlüsselt übertragen werden.

Geändert in Version 3.5: Der Parameter context wurde hinzugefügt.

mapLogRecord(record)

Stellt ein Dictionary bereit, basierend auf record, das URL-kodiert und an den Webserver gesendet werden soll. Die Standardimplementierung gibt einfach record.__dict__ zurück. Diese Methode kann überschrieben werden, wenn z. B. nur ein Teil von LogRecord an den Webserver gesendet werden soll oder wenn spezifischere Anpassungen des an den Server gesendeten Materials erforderlich sind.

emit(record)

Sendet den Datensatz als URL-kodiertes Dictionary an den Webserver. Die Methode mapLogRecord() wird verwendet, um den Datensatz in das zu sendende Dictionary zu konvertieren.

Hinweis

Da die Vorbereitung eines Datensatzes für die Übertragung an einen Webserver nicht dasselbe ist wie eine generelle Formatierungsoperation, hat die Verwendung von setFormatter() zur Angabe eines Formatter für einen HTTPHandler keine Auswirkung. Anstatt format() aufzurufen, ruft dieser Handler mapLogRecord() und dann urllib.parse.urlencode() auf, um das Dictionary in ein für die Übertragung an einen Webserver geeignetes Format zu kodieren.

QueueHandler

Hinzugefügt in Version 3.2.

Die Klasse QueueHandler, im Modul logging.handlers, unterstützt das Senden von Logging-Nachrichten an eine Warteschlange, wie sie in den Modulen queue oder multiprocessing implementiert sind.

Zusammen mit der Klasse QueueListener kann QueueHandler verwendet werden, um Handlern die Arbeit in einem separaten Thread von demjenigen, der das Logging durchführt, ausführen zu lassen. Dies ist wichtig in Webanwendungen und auch in anderen Serviceanwendungen, bei denen Threads, die Clients bedienen, so schnell wie möglich antworten müssen, während potenziell langsame Operationen (wie das Senden einer E-Mail über SMTPHandler) in einem separaten Thread durchgeführt werden.

class logging.handlers.QueueHandler(queue)

Gibt eine neue Instanz der Klasse QueueHandler zurück. Die Instanz wird mit der Warteschlange initialisiert, an die Nachrichten gesendet werden sollen. Die queue kann jedes warteschlangenähnliche Objekt sein; sie wird von der Methode enqueue() unverändert verwendet, die wissen muss, wie Nachrichten an sie gesendet werden. Die Warteschlange muss *nicht* über die Task-Tracking-API verfügen, was bedeutet, dass Sie SimpleQueue-Instanzen für queue verwenden können.

Hinweis

Wenn Sie multiprocessing verwenden, sollten Sie SimpleQueue vermeiden und stattdessen multiprocessing.Queue verwenden.

Warnung

Das Modul multiprocessing verwendet einen internen Logger, der über get_logger() erstellt und abgerufen wird. multiprocessing.Queue protokolliert DEBUG Level-Nachrichten beim Einreihen von Elementen. Wenn diese Protokollnachrichten von einem QueueHandler über dieselbe multiprocessing.Queue-Instanz verarbeitet werden, führt dies zu einem Deadlock oder einer unendlichen Rekursion.

emit(record)

Stellt das Ergebnis der Vorbereitung des LogRecord in die Warteschlange. Sollte ein Fehler auftreten (z. B. weil eine begrenzte Warteschlange voll ist), wird die Methode handleError() aufgerufen, um den Fehler zu behandeln. Dies kann dazu führen, dass der Datensatz stillschweigend verworfen wird (wenn logging.raiseExceptions False ist) oder eine Meldung auf sys.stderr ausgegeben wird (wenn logging.raiseExceptions True ist).

prepare(record)

Bereitet einen Datensatz für die Einreihung vor. Das von dieser Methode zurückgegebene Objekt wird eingereiht.

Die Basisimplementierung formatiert den Datensatz, um die Nachricht, Argumente, Ausnahmen und Stapelinformationen zusammenzuführen, falls vorhanden. Sie entfernt auch nicht-pickelbare Elemente aus dem Datensatz an Ort und Stelle. Insbesondere überschreibt sie die Attribute msg und message des Datensatzes mit der zusammengeführten Nachricht (erhalten durch Aufruf der Methode format() des Handlers) und setzt die Attribute args, exc_info und exc_text auf None.

Sie möchten diese Methode möglicherweise überschreiben, wenn Sie den Datensatz in ein Dict oder eine JSON-Zeichenkette konvertieren oder eine modifizierte Kopie des Datensatzes senden möchten, während das Original unberührt bleibt.

Hinweis

Die Basisimplementierung formatiert die Nachricht mit Argumenten, setzt die Attribute message und msg auf die formatierte Nachricht und setzt die Attribute args und exc_text auf None, um das Pickling zu ermöglichen und weitere Formatierungsversuche zu verhindern. Das bedeutet, dass ein Handler auf der Seite von QueueListener nicht über die Informationen verfügt, um benutzerdefinierte Formatierungen durchzuführen, z. B. von Ausnahmen. Möglicherweise möchten Sie QueueHandler unterklassen und diese Methode überschreiben, um z. B. zu vermeiden, exc_text auf None zu setzen. Beachten Sie, dass die Änderungen an message / msg / args darauf abzielen, sicherzustellen, dass der Datensatz pickelbar ist, und Sie möglicherweise nicht in der Lage sind, dies zu vermeiden, je nachdem, ob Ihre args pickelbar sind. (Beachten Sie, dass Sie möglicherweise nicht nur Ihren eigenen Code, sondern auch Code in Bibliotheken berücksichtigen müssen, die Sie verwenden).)

enqueue(record)

Reiht den Datensatz mit put_nowait() in die Warteschlange ein; Sie möchten diese Methode möglicherweise überschreiben, wenn Sie blockierendes Verhalten, ein Timeout oder eine angepasste Warteschlangenimplementierung verwenden möchten.

listener

Wenn über die Konfiguration mit dictConfig() erstellt, enthält dieses Attribut eine QueueListener-Instanz zur Verwendung mit diesem Handler. Andernfalls ist es None.

Hinzugefügt in Version 3.12.

QueueListener

Hinzugefügt in Version 3.2.

Die Klasse QueueListener, im Modul logging.handlers, unterstützt den Empfang von Logging-Nachrichten aus einer Warteschlange, wie sie in den Modulen queue oder multiprocessing implementiert sind. Die Nachrichten werden in einem internen Thread aus einer Warteschlange empfangen und auf demselben Thread an einen oder mehrere Handler zur Verarbeitung weitergeleitet. Obwohl QueueListener selbst kein Handler ist, wird er hier dokumentiert, da er Hand in Hand mit QueueHandler arbeitet.

Zusammen mit der Klasse QueueHandler kann QueueListener verwendet werden, um Handlern die Arbeit in einem separaten Thread von demjenigen, der das Logging durchführt, ausführen zu lassen. Dies ist wichtig in Webanwendungen und auch in anderen Serviceanwendungen, bei denen Threads, die Clients bedienen, so schnell wie möglich antworten müssen, während potenziell langsame Operationen (wie das Senden einer E-Mail über SMTPHandler) in einem separaten Thread durchgeführt werden.

class logging.handlers.QueueListener(queue, *handlers, respect_handler_level=False)

Gibt eine neue Instanz der Klasse QueueListener zurück. Die Instanz wird mit der Warteschlange, an die Nachrichten gesendet werden sollen, und einer Liste von Handlern initialisiert, die Einträge in der Warteschlange verarbeiten werden. Die Warteschlange kann jedes warteschlangenähnliche Objekt sein; sie wird unverändert an die Methode dequeue() übergeben, die wissen muss, wie Nachrichten daraus zu holen sind. Die Warteschlange muss *nicht* über die Task-Tracking-API verfügen (obwohl sie, falls verfügbar, verwendet wird), was bedeutet, dass Sie SimpleQueue-Instanzen für queue verwenden können.

Hinweis

Wenn Sie multiprocessing verwenden, sollten Sie SimpleQueue vermeiden und stattdessen multiprocessing.Queue verwenden.

Wenn respect_handler_level True ist, wird die Stufe eines Handlers berücksichtigt (im Vergleich zur Stufe der Nachricht), wenn entschieden wird, ob Nachrichten an diesen Handler übergeben werden sollen; andernfalls ist das Verhalten wie in früheren Python-Versionen - jede Nachricht wird immer an jeden Handler übergeben.

Geändert in Version 3.5: Das Argument respect_handler_level wurde hinzugefügt.

Geändert in Version 3.14: QueueListener kann nun als Kontextmanager über with verwendet werden. Beim Betreten des Kontexts wird der Listener gestartet. Beim Verlassen des Kontexts wird der Listener gestoppt. __enter__() gibt das QueueListener-Objekt zurück.

dequeue(block)

Entnimmt einen Datensatz aus der Warteschlange und gibt ihn zurück, optional blockierend.

Die Basisimplementierung verwendet get(). Sie möchten diese Methode möglicherweise überschreiben, wenn Sie Timeouts verwenden oder mit benutzerdefinierten Warteschlangenimplementierungen arbeiten möchten.

prepare(record)

Bereitet einen Datensatz zur Verarbeitung vor.

Diese Implementierung gibt einfach den übergebenen Datensatz zurück. Sie möchten diese Methode möglicherweise überschreiben, wenn Sie eine benutzerdefinierte Marshalling- oder Manipulationslogik für den Datensatz benötigen, bevor er an die Handler übergeben wird.

handle(record)

Verarbeitet einen Datensatz.

Dies durchläuft einfach die Handler und bietet ihnen den Datensatz zur Verarbeitung an. Das tatsächliche Objekt, das an die Handler übergeben wird, ist das, was von prepare() zurückgegeben wird.

start()

Startet den Listener.

Dies startet einen Hintergrundthread, um die Warteschlange auf zu verarbeitende LogRecords zu überwachen.

Geändert in Version 3.14: Löst RuntimeError aus, wenn sie aufgerufen wird und der Listener bereits läuft.

stop()

Stoppt den Listener.

Dies fordert den Thread zur Beendigung auf und wartet dann darauf, dass er dies tut. Beachten Sie, dass, wenn Sie dies vor dem Beenden Ihrer Anwendung nicht aufrufen, möglicherweise noch einige Datensätze in der Warteschlange verbleiben, die nicht verarbeitet werden.

enqueue_sentinel()

Schreibt ein Sentinel in die Warteschlange, um dem Listener mitzuteilen, dass er beenden soll. Diese Implementierung verwendet put_nowait(). Sie möchten diese Methode möglicherweise überschreiben, wenn Sie Timeouts verwenden oder mit benutzerdefinierten Warteschlangenimplementierungen arbeiten möchten.

Hinzugefügt in Version 3.3.

Siehe auch

Modul logging

API-Referenz für das Logging-Modul.

Modul logging.config

Konfigurations-API für das Logging-Modul.