Durchdachtes Logging in Server & SDK

[MHajoha]

• Fehler im Paket sollten im Server maximal einzeilig und maximal auf DEBUG/INFO geloggt werden, im SDK aber prominent und mit Stacktrace
  • Naheligender Ansatz: Sinnvolle Logger-Aufteilung im Server, deren Threshold per default WARN oder ERROR ist und im SDK auf DEBUG gesetzt wird.
  • Bonus: Ein Logger pro Paket bzw. Worker, dann kann bei Problemen nur das problematische Paket "laut" gestellt werden
• Worker-Output (Siehe _StderrBuffer) nur im SDK ausgeben. (Im Server dann opt-in.)
• Spam von Limits 'WorkerResourceLimits(max_memory=209715200, max_cpu_time_seconds_per_call=10)' were given, but thread-based workers don't support resource limits reduzieren, z.B. einmaliges Logging beim Start oder Limits nicht oder nur für SubprocessWorker hardcoden.

[MHajoha]

@tumidi falls du noch Punkte hinzufügen möchtest

[tumidi]

@tumidi falls du noch Punkte hinzufügen möchtest

• in SDK/Server jeweils eine zentrale logging.py erstellen, dort einen zentralen logger konfigurieren
  • config, wie logging level, etc für diesen logger ändern (ansonsten ändern wir die log levels global, also auch für libraries)
  • child logger verwenden anstatt, wie aktuell log = logging.getLogger("questionpy-sdk:builder")
• bspw. bei -vv logging für alle logger ändern (um auf Wunsch debug logs aus libraries zu bekommen)
• tblib nutzen, um tracebacks zu serialisieren und per structlog schön anzeigen zu können (Exceptions passieren ja potentiell in einem anderen Prozess)
• Schöne Stacktraces im SDK (Konsole) für bessere DX
  • stuctlog
• Stacktraces aus dem Server im SDK web frontend anzeigen?

[larsbonczek]

Zur Zeit werden bekannte Fehler im Worker nicht in die Konsole des Servers geloggt. Das macht das debuggen der Pakete aber schwerer. Ich musste dafür hier diese Zeile einfügen:

web_logger.exception("There was an error in the worker while processing the request.")

Ich denke das wird sowieso überarbeitet, ich wollte das nur hier festhalten, damit es nicht vergessen wird.