die Django Debug Toolbar

Ein nützliches Werkzeug, um Django zu debuggen und zu sehen, was unter der Haube passiert, nutzen wir die Django Debug Toolbar. Die Toolbar ist ein kleines Tool, das sich quasi an unsere Seite als aufklappbares Widget haftet und uns bereitwillig Auskunft gibt. Erstmal müssen wir dieses Paket allerdings installieren.

Fügen wir die Debugtoolbar unseren unseren Dev-Dependencies hinzu:

uv add --dev django-debug-toolbar

Die Debugtoolbar in den Settings registrieren

Dann fügen wir in den event_manager/settings.py unterhalb der MIDDLEWARE-Liste noch folgende Zeile hinzu:

MIDDLEWARE = [
    "django.middleware.security.SecurityMiddleware",
    "django.contrib.sessions.middleware.SessionMiddleware",
    "django.middleware.locale.LocaleMiddleware",
    "django.middleware.common.CommonMiddleware",
    "django.middleware.csrf.CsrfViewMiddleware",
    "django.contrib.auth.middleware.AuthenticationMiddleware",
    "django.contrib.messages.middleware.MessageMiddleware",
    "django.middleware.clickjacking.XFrameOptionsMiddleware",
 ]

# hinzufügen:
MIDDLEWARE.extend(["debug_toolbar.middleware.DebugToolbarMiddleware"])

Zusätzlich registrieren wir die Toolbar noch in den installierten Apps, ebenfalls in den event_manager/settings.py.

# Apps, die nur lokal genutzt werden
INSTALLED_APPS.extend(
  ["debug_toolbar"]
)


DEBUG_TOOLBAR_CONFIG = {
    "INTERCEPT_REDIRECTS": False,
}

INTERNAL_IPS = ("127.0.0.1",)

INTERNAL_IPS

INTERNAL_IPS ist eine Django-Einstellung, die als Sicherheitsfilter fungiert und es Django ermöglicht, zu wissen, ob es in Ordnung ist (oder nicht), vertrauliche Informationen in seinen Anforderungen und der Debug-Informationsausgabe offenzulegen.

Live und Dev Settings

Momentan zeichnet sich ein Problem ab: Wir haben die debug_toolbar in den settings angelegt. Allerdings haben wir noch keine Live- und Produktions-Settings, und somit wäre die Debug-Toolbar auch in einer potentiellen Live-Umgebung sichtbar. Das werden wir später noch ändern, wenn wir die Konfiguration in Live und Dev aufpalten werden.

Moment mal, Live und Dev was?

Jedes Projekt läuft beim Entwickeln in der sogenannten Dev-Umgebung, also lokal auf dem Rechner des Entwicklers. In dieser Umgebung ist die Konstante DEBUG=True und es ist offensichtlich nützlich, Debug-Programme wie die Debug-Toolbar zu nutzen.

Wenn das Projekt fertig ist bzw. reif für die Veröffentlichung, kommt es in die Produktiv-Umgebung, auch Live-Umgebung genannt. Da dürfen diese Debug-Tools natürlich nicht mehr aktiviert sein, um Angreifern keine Möglichkeit zu bieten, Informationen über das System zu erfahren.

Die Debugtoolbar in den URLs registrieren

Ein letzten Schritt ist das Anlegen der URL für die Toolbar:

In den event_manager/urls.py importieren wir die Settings:

from django.conf import settings

und fügen nach den URL-Patterns folgenden Code ein:

if settings.DEBUG:
    import debug_toolbar

    urlpatterns = [
        path("__debug__/", include(debug_toolbar.urls)),
    ] + urlpatterns

Das heisst also, wenn wir im DEBUG-Modus laufen (DEBUG=True), soll die Debugtoolbar importiert und der entsprechende Path in die urlpatterns eingehängt werden.

Die event_manager/urls.py sollte jetzt so aussehen:

from django.conf import settings
from django.contrib import admin
from django.urls import include, path

urlpatterns = [
    path("admin/", admin.site.urls),
    path("events/", include("events.urls")),
]

if settings.DEBUG:
    import debug_toolbar

    urlpatterns = [
        path("__debug__/", include(debug_toolbar.urls)),
    ] + urlpatterns

Wenn wir jetzt den Runserver starten und http://127.0.0.1:8000/events/category/1 aufrufen, sehen wir auf der rechten Seite die Toolbar.

Das war’s, die Debug-Toolbar wird nun angezeigt und bietet verschiedene nützliche Informationen zu Ausführungszeit, SQL, statischen Dateien, Signalen usw.

../_images/toolbar.png

Die Django Debug Toolbar stellt verschiedene Analysebereiche bereit, mit denen sich nachvollziehen lässt, was während einer HTTP-Anfrage im Hintergrund passiert. Gerade bei der Entwicklung komplexerer Anwendungen ist sie ein wichtiges Werkzeug, um Fehler zu finden und Performance-Probleme frühzeitig zu erkennen.

Besonders relevant sind dabei folgende Bereiche:

  • SQL

    Zeigt alle Datenbankabfragen an, die während einer Anfrage ausgeführt wurden. Neben dem eigentlichen SQL-Statement werden auch die jeweilige Ausführungszeit sowie die Anzahl der Queries angezeigt.

    Dadurch lassen sich typische Probleme erkennen, z.B.:

    • unnötig viele Datenbankabfragen

    • doppelte Queries

    • sogenannte N+1-Probleme

    • langsame oder ineffiziente Abfragen

    Gerade beim Arbeiten mit Django-ORM, select_related() oder prefetch_related() ist dieser Bereich besonders hilfreich.

  • Templates

    Zeigt, welche Templates während der Anfrage gerendert wurden und in welcher Reihenfolge dies geschah.

    Dadurch wird sichtbar:

    • welche Basis-Templates verwendet werden

    • welche Includes eingebunden wurden

    • welches Template tatsächlich gerendert wurde

    • wie die Template-Hierarchie aufgebaut ist

    Das erleichtert das Debugging komplexer Template-Strukturen erheblich.

  • Zeit (Timer)

    Misst die Dauer einzelner Verarbeitungsschritte sowie die Gesamtzeit der Anfrage.

    Damit lässt sich analysieren:

    • wie lange Views benötigen

    • ob Datenbankzugriffe langsam sind

    • welche Teile einer Anfrage besonders viel Zeit verbrauchen

    Dieser Bereich ist hilfreich, um Performance-Probleme systematisch zu identifizieren.

  • Headers

    Zeigt die HTTP-Request- und Response-Header an.

    Damit lassen sich unter anderem prüfen:

    • Content-Types

    • Redirects

    • Cookies

    • Cache-Header

    • Sicherheits-Header

    Besonders beim Arbeiten mit APIs, Authentifizierung oder Caching ist dieser Bereich oft sehr nützlich.

Zusammen liefern diese Analysebereiche ein sehr detailliertes Bild darüber, wie Django eine Anfrage verarbeitet und welche Komponenten dabei beteiligt sind.

Weitere nutzvolle Informationen: