Logging...?

[Msinn]

Nein, bei macht der Editor (läuft auf meinem Mac) einfach weiter wenn ich auf meinem NUC shng neu starte...

Die beiden HTTP GET Zeilen enthalten ja einen Hinweis auf knx. Nutzt Du das normale knx Plugn oder das von thengsty? Hast Du evtl. Bus Monitorig konfiguriert oder ähnliches?

[Morg]

Ja, es gibt Editoren, die "live scrolling" machen. Aber wie gesagt, das wäre noch ein Fenster mehr.

Das knx-Plugin ist das normale, aber das hat hier glaube ich nix zu suchen.

Ich frage von außerhalb (mit python urllib) per network-Plugin die beiden Items ab, und die Zeilen sehen aus wie Zugriffs"logs", vorn die Quell-IP, dann das HTTP-Kommando (GET und URL) mit Status, und hinten der User-Agent (urllib). Das muss also vom network-Plugin oder von einer dort eingebundenen Library kommen. Was anderes kann ich mir da nicht vorstellen.

[Msinn]

Da das netwpork Plugin als ein Teil von shng Logger nutzt, die in der logging.yaml definiert simd und Du dort keinen Formatter hast der ein solches Log Format erzeugt, stimmt wohl Deine Annahme das das aus einem genutzten Package kommt (analog zum cherrypy Output). Wie gesagt, das console Logging kann man nicht vernünftig kontrollieren....

[Morg]

Noch eine andere Frage: ich habe mal versucht, einzelne Log-Ebenen ("logger"?) auszuschalten; gibt es dafür spezielle Optionen?

Ich habe in der Python-Doc zum logging den NullHandler gefunden, der würde genau tun, was ich möchte (einfach nicht loggen), aber wenn ich versuche, den so einzubinden, wie auch StreamHandler oder TimedRotatingFileHandler eingebunden werden (class: logging.handlers.NullHandler), bekomme ich einen Haufen Fehler...

Traceback (most recent call last):
  File "/usr/lib/python3.7/logging/config.py", line 389, in resolve
    self.importer(used)
ModuleNotFoundError: No module named 'logging.handlers.NullHandler'; 'logging.handlers' is not a package

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/lib/python3.7/logging/config.py", line 562, in configure
    handler = self.configure_handler(handlers[name])
  File "/usr/lib/python3.7/logging/config.py", line 712, in configure_handler
    klass = self.resolve(cname)
  File "/usr/lib/python3.7/logging/config.py", line 396, in resolve
    raise v
  File "/usr/lib/python3.7/logging/config.py", line 389, in resolve
    self.importer(used)
ValueError: Cannot resolve 'logging.handlers.NullHandler': No module named 'logging.handlers.NullHandler'; 'logging.handlers' is not a package

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "bin/smarthome.py", line 1318, in <module>
    sh = SmartHome(extern_conf_dir=extern_conf_dir)
  File "bin/smarthome.py", line 288, in __init__
    self.init_logging(self._log_conf_basename, MODE)
  File "bin/smarthome.py", line 515, in init_logging
    logging.config.dictConfig(doc)
  File "/usr/lib/python3.7/logging/config.py", line 799, in dictConfig
    dictConfigClass(config).configure()
  File "/usr/lib/python3.7/logging/config.py", line 570, in configure
    '%r' % name) from e
ValueError: Unable to configure handler 'nolog'

Den NullHandler gibt es seit Python 3.1, kann es sein, dass man den in shng erst aktivieren müsste?

[Morg]

Okay, manche Fragen lösen sich durch probieren.

Wenn ich class: logging.NullHandler angebe, geht es (so wie beim StreamHandler). Das "reguläre" Logging kann ich damit unterdrücken.

Die vier Meldungen (ENGINE Bus STARTING usw) kommen von CherryPy und sind idiotischerweise als "ERROR" klassifiziert. Neben der mMn falschen Einordnung loggt cherrypy die parallel noch auf StdErr und damit indirekt auf die sichtbare Konsole. Könnte man userseitig mit Umleitungen filtern.

Die Fragen zu den IP-Logmeldungen schiebe ich mal in den Webservices-Thread

[Msinn]

Ich bin immer noch der Meingung dir beiden Zeilen kommen aus cherrypy und können wie ich oben schrieb durch den logger cherrypy.access gesteuert werden.

[Morg]

Die beiden access-Zeilen kommen aus cherrypy, und zwar über die App, die das webservices-Plugin dort anmeldet. Sie kommen auch über den access-Logger - dann aber im korrekten Format, und die lassen sich auch steuern.

Die Zeilen, die direkt mit der IP anfangen, sind der "Inhalts"anteil der Access-Logmeldungen und werden von cherrypy (mal wieder) direkt in die Konsole geschrieben.

Ich habe das mit einer etwas brutalen Methode in http-Modul abwürgen können, aber das ist ja eigentlich nicht Sinn der Sache - auf der anderen Seite sollte so ein Modul wie cherrypy eigentlich nicht von sich aus auf die Konsole schreiben, aber das ist ein anderes Thema.

Vielleicht lässt sich das ja in webservices konfigurieren, ansonsten wäre es ggf. doch nochmal ein Thema für module.http....

Hinter cherrypy.config.update(global_conf) habe ich eingefügt:

    cherrypy.config.update(
        {
            'log.screen': False,
            'log.access_file': '',
            'log.error_file': ''
        }
    )

Damit wird nicht mehr "selbstständig" geloggt, sondern nur noch über die Vererbung an shng. Dort lässt es sich dann konfigurieren.

[Msinn]

Da sehe ich erstmal keine negativen Nebenwirkungen. Das kann ich ja für das kommende Release ins http Modul einbauen.

[Msinn]

Ich habe gerade gesehen, dass da bereits

        cherrypy.config.update({'log.screen': False})

stand. Das hatte also nicht gereicht?

[Morg]

In der Version, die ich hier habe (müsste nachsehen, ich glaube, der letzte Release) war es auskommentiert.

[Msinn]

Im v1.7.2 Master ist die Zeile zumindest nicht auskommentiert.

[wvhn]

Ich hänge mich hier mal an:
beim Testen des Websocketmoduls möchte ich von diesem möglichst viele Meldungen bekommen. Also habe ich den loglevel für "modules" auf "INFO" gesetzt.

   modules:
        # Default logger for SmartHomeNG modules
        handlers: [shng_details_file]
        level: INFO​

Dadurch wird aber auch der Logger vom Admin-Modul ziemlich gesprächig. Um das zu unterbinden habe ich verschiedenes versucht.

• Lege ich einen weiteren logger "modules.websocket" mit dem level: INFO an und setze den level für "modules" auf WARNING, dann bekomme ich alle Infos vom Websocket-Modul doppelt - vor allem aber schon in der Initialisierungsphase sehr viel mehr Infos.
• Lege ich stattdessen einen weiteren Logger "modules.admin" mit dem Level "WARNING" (gleiches Vorgehen wie im Beispiel "plugins.cli"), fängt das http-Modul an zu quatschen und das Websocket-Modul liefert auch erhöhten Output. Allerdings ist "admin" leise. In der Liste der Logger taucht modules.admin als eigener Logger mit Handler "shng_details_file" auf,
  grafik.png
  während ein auf gleiche Weise angelegter Logger für plugins.database auf den plugins-Logger referenziert.grafik.png
• Lege ich einen Filter mit "module: admin" an, dann ist das Ergebnis ungefähr wie im zweiten Fall. (Man kann nicht zusätzlich auf "level" filtern, oder? Die Liste der "Advanced Logger" zeigt dann nichts mehr an. Ich habe das als Fehler im Filter interpretiert).

Was muss/kann ich anders machen, um nur das Logging des Websocketmoduls auf "INFO" zu setzen?

Danke und Gruß
Wolfram

[stoepf]

[*]Lege ich einen weiteren logger "modules.websocket" mit dem level: INFO an und setze den level für "modules" auf WARNING, dann bekomme ich alle Infos vom Websocket-Modul doppelt - vor allem aber schon in der Initialisierungsphase sehr viel mehr Infos.

Bei den Plugins darf man keinen handler mehr angeben (https://github.com/smarthomeNG/smart...l.default#L175)
Hätte jetzt vermutet, dass das bei den Modulen vielleicht ähnlich ist.

Gruß Stefan

[Msinn]

wvhn Setz doch nur den Logger für das Websocket Modul uaf INFO und nicht den Sammellogger für alle Module.

Falls nicht vorhanden, füge einen Logger modules.websocket ein.

[Msinn]

stoepf

Bei den Plugins darf man keinen handler mehr angeben

wie kommst Du darauf? Du kannst je Plugin eine eigene Logger Konfiguration anlegen.