Fehlercodes xAPI Endpunkt

Was ist dein Vorschlag bzgl. des Logs?

Vielleicht ist es auch eher ein Feature-Request und gehört in ein anderes Ticket.

ist im Prinzip auch das gleiche wie #99 (comment 2822393) . Ich weiß nicht, ob Django schon etwas in die Richtung mitliefert. In Richtung Logging Memory Handler (alle logs werden während des Processings gebuffert) und Middleware, die am Ende eines Requests alles flusht (ggf. als "message=" mit in den Request log). Chatgpt hatte mir etwas in folgende Richtung vorgeschlagen:

" Configure a MemoryHandler in your LOGGING setting Add a handler that collects (but does not immediately emit) log records:


LOGGING = {
    "version": 1,
    "disable_existing_loggers": False,
    "formatters": {
        "verbose": {
            "format": "%(asctime)s %(levelname)s %(name)s %(message)s",
        },
    },
    "handlers": {
        "buffer": {
            "class": "logging.handlers.MemoryHandler",
            "capacity": 1000,           # how many records to buffer
            "flushLevel": "CRITICAL",   # never auto‑flush (we’ll flush manually)
            "target": "console",
        },
        "console": {
            "class": "logging.StreamHandler",
            "formatter": "verbose",
        },
    },
    "loggers": {
        "": {
            "handlers": ["buffer"],
            "level": "INFO",
        },
    },
}

Add middleware that flushes at the end of each request python Kopieren

# middleware.py

import logging
from logging.handlers import MemoryHandler

class RequestBufferingMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        response = self.get_response(request)

        root_logger = logging.getLogger()
        for handler in root_logger.handlers:
            if isinstance(handler, MemoryHandler):
                handler.flush()

        return response

Then register it after any error‑raising middleware in your MIDDLEWARE list:

MIDDLEWARE = [
    ...,
    "django.middleware.common.CommonMiddleware",
    "myapp.middleware.RequestBufferingMiddleware",
]

What happens? During the request, every logger.info(), Django’s own “Bad Request…” and its access‑log entry all go into the MemoryHandler buffer.

When Django builds the response, the middleware calls flush(), which emits all buffered messages at once to your console (or whatever your “target” handler is).

You’ll now see one combined block of text per HTTP request — exactly what you asked for."

Meine Anfrage war:

rights-engine-1       | Bad Request: /xapi/statements
rights-engine-1       | Invalid access token: ...
rights-engine-1       | 172.18.0.7 - - [26/Mar/2025:13:18:03 +0000] "POST /xapi/statements HTTP/1.1" 400 82 "-" "Go-http-client/2.0"

my django application is outputting 3 lines of log that does not seem to be connected to the same request, but i know they are. How can i configure django to ut them into single log output?

Halte ich für nicht so sinnvoll und kenne ich auch von keinem anderen Webserver wie Apache, Nginx, etc. Sollte man trennen von dem 400 Response.

Ich finde der vergleich zwischen Nginx und Apache hinkt hier etwas.

Gibt da noch andere Ansätze - Request Ids, etc. @benjaminLedel Jedenfalls bleibt

rights-engine-1       | Bad Request: /xapi/statements
rights-engine-1       | Invalid access token: ...
rights-engine-1       | 172.18.0.7 - - [26/Mar/2025:13:18:03 +0000] "POST /xapi/statements HTTP/1.1" 400 82 "-" "Go-http-client/2.0"

mangelhaft. Log-Aggregtion/Filtering ist hier recht schwer - mit grep nach einem Error, Warn oder dergleichen Suchen ist hier nicht unbedingt zielführend. Normalerweise würde ich etwas wie folgt erwarten (muss jetzt nicht direkt JSON sein):

{"time":"2024-12-30T21:12:45.9876543+08:00","level":"ERROR","msg":"Database connection failed","uri":"/api/orders","status":500,"error":"SqlException","details":"Timeout expired while attempting to connect to database"}

Dein Beispiel-Code oben macht aber etwas ganz anderes, was du willst. Es buffert Einträge und gibt die dann insgesamt aus. Was du möchtest, dass die Formatierung im Log ein Log-Level enthält und mit der URL anfängt.

Das war wie erwähnt die erste Antwort von chatgpt. Es gibt da verschiedene Probleme:

Man kann nicht erkennen, welcher Log output zu welchem Request gehört
Es ist unklar, was für eine Art Log das ist
In diesem Fall hatte ich zum Beispiel keine Möglichkeit beim Provider System zu erfahren, was der Body der 400er Antwort war (da stand drin, dass der Token invalide war) - ich habe das nur herausgefunden, da Polaris keine Statements geprinted hatte, nachdem ich die Option eingeschaltet hatte. Als ich in den Code geschaut hatte, wusste ich, dass eigentlich nur noch der Token invalide sein konnte.

In diesem Fall wäre es hilfreich gewesen den Log-Output mit beim Request zu haben - ob das die beste Lösung ist weiß ich nicht; Funktioniert in anderen Systemen aber recht gut

"POST /xapi/statements HTTP/1.1" 400 82 "-" "Go-http-client/2.0" ist genau das richtige, hier fehlt nur irgendein Hinweis in welche Richtung das Problem gehen könnte

Hier der Commit für den 400er statt 401: 0342a6f7

assigned to @martin.ulrich.breuer and unassigned @benjaminLedel

added test label

mentioned in issue #99

assigned to @benjaminLedel and unassigned @martin.ulrich.breuer

changed milestone to %Release 1.0.1

Fehlercodes xAPI Endpunkt

Designs

Child items ...

Activity