logging ausstellen

[Boa]

Hallo,

Ich finde keine Möglichkeit über eine log.conf den Logger zu deaktivieren. Es ist doch gerade Sinn der Konfigurationsdatei das Logging möglichst problemlos an dei Gegebenheiten anzupassen. Da gehört das abstellen (z.B. für Performance Tests) doch dazu.
Ich nutze Python 2.6

In log4j ging das mit log4j.rootLogger=off
Gibt es etwas äquivalentes für das logging Modul?

MfG,
Boa

[derdon]

Als gute logging-lib kann ich Logbook empfehlen.

[Boa]

Als gute logging-lib kann ich Logbook empfehlen.

Soweit ich gesehen habe bietet das Modul keine Möglichkeit zur externen Konfiguration. Abesehen davon ist es noch in der Alpha Version.

[deets]

Ich verstehe dein Problem nicht. Das logging-Modul erlaubt alle moeglichen Dinge, uA auch Konfigurations-Dateien. Muss man halt benutzen. Wenn natuerlich jemand ein Programm geschrieben hat, dass mittels logging.basicConfig einfach irgendwas setzt - dann hast du ein Problem. Aber default-maessig loggt nix.

[Boa]

@deets: Ich habe ja nicht behauptet dass in jedem Python standardmäßig gelogged wird. Aber ich habe einige Module die standardmäßig in meherer Dateien loggen und möchte z.B. wenn ich den Code weiterreiche vorher die Ausgabe aller Logger deaktivieren. Dazu möchte ich nicht in jedes Modul reingehen und es umschreiben sondern einfach über die Konfigurationsdatei einen Parameter setzen der das logging deaktiviert.

[deets]

Verstehe ich immer noch nicht. Wer reicht denn da welchen code weiter? Wie konfigurierst du denn das Logging jetzt?

[deets]

Um das nochmal klarer zu machen: wenn du wirklich code hast, der von selbst das logging aktiviert, dann benutzt du es falsch. Und es gibt keinen magischen schalter, den man umlegen kann, um das rueckgaengig zu machen. Das wirst du dann schon umprogrammieren muessen.

Nur das "auesserste" Programm, also zur Not ein Hilfsskript, oder eine __main__-Methode darf das logging konfigurieren. Das ist halt so, und das ist bei Java auch nicht anders.

[lunar]

@Boa: Die einzige Möglichkeit wäre, dass Level des betroffenen Loggers auf "CRITICAL" zu setzen, um die Logging-Ausgaben möglichst zu minimieren.

Alles weitere hat deets schon gesagt.

[BlackJack]

Man könnte statt `CRITICAL` noch eine Stufe einführen die höher ist um auch `CRITICAL`-Ausgaben zu unterbinden. Andererseits ist es vielleicht nicht so schlecht *die* Stufe tatsächlich noch auszugeben.

[Boa]

Hallo,

Verstehe ich immer noch nicht. Wer reicht denn da welchen code weiter? Wie konfigurierst du denn das Logging jetzt?

Ich reiche meinen Code weiter. Das Logging konfiguriere ich über eine externe Konfigurationsdatei die ich in jedem Modul per logging.config.fileConfig einbinde.

Um das nochmal klarer zu machen: wenn du wirklich code hast, der von selbst das logging aktiviert, dann benutzt du es falsch. Und es gibt keinen magischen schalter, den man umlegen kann, um das rueckgaengig zu machen. Das wirst du dann schon umprogrammieren muessen.

Nur das "auesserste" Programm, also zur Not ein Hilfsskript, oder eine __main__-Methode darf das logging konfigurieren. Das ist halt so, und das ist bei Java auch nicht anders.

Es sieht ganz danach aus als würden wir aneinander vorbeireden.
Ich habe in meinem Code standardmäßig das Logging aktiviert um ihn zu debuggen oder sonst zu analysieren. Ich denke nicht dass ich deshalb Logging falsch einsetze. Wenn doch begründe bitte diese Behauptung.
Ich habe nach keinem magischen Ausschalter gesucht sondern nach einem der das Logging deaktiviert wenn man die entsprechende Konfigurationsdatei anpasst. Ich meine dabei eine statische Konfiguration, nicht zur Laufzeit. Vielleicht war das nicht ganz klar.
Und wie gesagt in Java geht das eben doch. Wenn du meinst dass ich mich irre kann ich dir ein Bespiel schicken, das ist aber mit etwas Aufwand verbunden. Den zu setzenden Parameter habe ich ja beschrieben.
Warum darf ich das Logging nur in meiner main konfigurieren? Es steht mir doch frei z.B. das Format in jedem anderen Modul anzupassen.

@lunar und BlackJack:
Hmm, ja daran habe ich schon gedacht. Aber es ist eben doch umständlich. Dann muss ich für jeden Handler der eine eigenes Level definiert, sowie für den roothandler das entsprechende Level setzen. Außerdem wäre es mir lieber wenn der Logger nach einer Direktive wie Logging=OFF einfach gar nichts mehr macht. Beim anpassen des Levels werden immer noch die Dateien geschrieben. Das ist ein Problem, denn wenn ich mein Paket installiere braucht es root Rechte um die Logs zu erstellen. Im Notfall werde ich die Rechte des entsprechenden Ordners anpassen.

Vielen Dank für eure Hilfe,
Boa

[deets]

Ich reiche meinen Code weiter. Das Logging konfiguriere ich über eine externe Konfigurationsdatei die ich in jedem Modul per logging.config.fileConfig einbinde.

Und da ist dein Fehler.

Es sieht ganz danach aus als würden wir aneinander vorbeireden.
Ich habe in meinem Code standardmäßig das Logging aktiviert um ihn zu debuggen oder sonst zu analysieren. Ich denke nicht dass ich deshalb Logging falsch einsetze. Wenn doch begründe bitte diese Behauptung.

Habe ich doch schon: Code, der als Library verwendung findet (und so interpretiere ich deine Aussage von "weitergeben") darf das logging-Modul nicht konfigurieren. Das widerspricht dem Design des Moduls logging, und produziert schwer zu findende Fehler, wenn dadurch mehrere Versuche gestartet werden, das logging zu konfigurieren.

Also raus mit den fileConfig-calls aus dem weitergegebenen Code, und rein in ein aufrufendes Skript.

[Boa]

Ich reiche meinen Code weiter. Das Logging konfiguriere ich über eine externe Konfigurationsdatei die ich in jedem Modul per logging.config.fileConfig einbinde.

Und da ist dein Fehler.

Es sieht ganz danach aus als würden wir aneinander vorbeireden.
Ich habe in meinem Code standardmäßig das Logging aktiviert um ihn zu debuggen oder sonst zu analysieren. Ich denke nicht dass ich deshalb Logging falsch einsetze. Wenn doch begründe bitte diese Behauptung.

Habe ich doch schon: Code, der als Library verwendung findet (und so interpretiere ich deine Aussage von "weitergeben") darf das logging-Modul nicht konfigurieren. Das widerspricht dem Design des Moduls logging, und produziert schwer zu findende Fehler, wenn dadurch mehrere Versuche gestartet werden, das logging zu konfigurieren.

Also raus mit den fileConfig-calls aus dem weitergegebenen Code, und rein in ein aufrufendes Skript.

Ahh, gut jetzt wird mir deine Aussage klarer. Der Code ist in dem Sinne keine Library sondern vereinfacht gesagt ein Modul für den Endanwender.
Es besteht deshalb keine Gefahr dass logging auf diese Weise konfiguriert wird.
Deiner Lösund folgend würde ich für die Weitergabe eine zweite main haben oder einen Parameter an main einführen, sodass das Logging standardmäßig aus ist. Klingt vernünftig. Aber werfen die anderen Module wenn ich die Konfigurationsdatei nicht lade dann keine Fehler wenn sie ihren Logger mit logging.getLogger holen? Oder eben die Log Ausgaben produzieren?

[lunar]

@Boa: Die Verwendung unkonfigurierter Logger erzeugt keinen Fehler, sondern eben nur keine Logging-Ausgaben. Du kannst also in Modulen beliebig viele Logger verwenden, ohne dass Du jeden dieser Logger zwangsweise konfigurieren musst.

Du musst auch nicht in jedem Modul ".fileConfig()" ausführen. Im Gegenteil, dass ist eigentlich sogar falsch, und dürfte dazu führen, dass identische Handler doppelt erzeugt werden. Normalerweise führt man diese Funktion nur einmal im Eintrittspunkt des Programms aus, um alle Logger zu konfigurieren.

[deets]

@lunar

Stimmt leider nicht ganz, siehe hier..

Deiner Lösund folgend würde ich für die Weitergabe eine zweite main haben oder einen Parameter an main einführen, sodass das Logging standardmäßig aus ist. Klingt vernünftig. Aber werfen die anderen Module wenn ich die Konfigurationsdatei nicht lade dann keine Fehler wenn sie ihren Logger mit logging.getLogger holen? Oder eben die Log Ausgaben produzieren?

So ganz verstehe ich zwar noch nicht, was du genau machen willst, aber zu der letzten Frage: jein. Leider beschwert sich das logging schon beim ersten versuch, eine Nachricht auszugeben, wenn man da nicht Vorkehrungen trifft. Das ist vom Autor so mal empfohlen worden.

Kannst du selbst mal schnell ausprobieren:

Code: Alles auswählen

import sys
import logging

logger = logging.getLogger(__name__)

class NullHandler(logging.Handler):
    def emit(self, *args, **kwargs):
        pass

if len(sys.argv) == 2 and sys.argv[1] == "nullhandler":
    logging.getLogger().addHandler(NullHandler())

def test():
    logger.error("foobarbaz")


test()

Das ist leider eine Schwaeche von logging (zumindest bis Python2.6, kA ob das spaeter schon so geloest wurde, dass es da einen einfacheren weg gibt. Aber es schadet auch nix, die 5 Zeilen in dein Modul oben reinzupacken.

[deets]

@lunar

oh, und noch eine Anmerkung: noch mieser bei der doppelten Konfiguration ist, dass die alten Handler disabled werden. Dadurch konfiguriert man beim ersten mal was zurecht, und irgend ein anderer config-call zerbretzelt das dann - und man sieht nix.

[Boa]

@deets: Der NullHandler existiert in v. 2.6 noch nicht, sonst hätte ich den auch in der Konfigurationsdatei einstellen können.

[deets]

@Boa

Das wuerde dir ja nix helfen, denn es geht ja gerade darum, *keine* Konfigurationsdatei zu haben. Es ist ein etwas nervendes Verhalten des logging-Moduls, es sollte diesen NullHandler auf root implizit gesetzt haben (oder einfach die Warnung nicht schmeissen), aber so ist's halt.

[Boa]

Wie gesagt, den NullHandler gibt es in der von mir Verwendeten Python Version nicht. Ich werde das Logging lassen wie es ist und die Rechte bei der Installation entsprechend setzen. Das sollte fürs Erste reichen.

Dank noch Mal,
Boa

[lunar]

@Boa: Den NullHandler kannst Du wie gezeigt trivialerweise selbst implementieren. Du sollst ihn auch nicht in der Konfigurationsdatei einstellen, sondern den in einem Modul verwendeten Handlern im Quelltext zuweisen, um die von deets (danke für die Korrektur übrigens) erwähnte Warnung zu unterdrücken.

In der Konfigurationsdatei konfigurierst Du dann nur genau die Logger, die auch loggen sollen, und lässt den Rest einfach unangetastet.

[deets]

Den NullHandler gibt es *nirgends*. Deswegen habe ich den ja implementiert. Dieses Rezept (einen NullHandler bauen & an den root-handler zu haengen) ist die Standard-Vorgehensweise, um den "no handler found"-text auszuschalten. Hast du das Skript ueberhaupt mal laufen lassen?