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 auspalten 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.
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.
Die Django Debug Toolbar stellt verschiedene Analysebereiche bereit, die Einblick in das Verhalten einer Anfrage geben:elevant sind dabei folgende Bereiche:
SQL: Zeigt alle Datenbankabfragen, die während einer Anfrage ausgeführt wurden. Hier lassen sich ineffiziente Queries, doppelte Abfragen (N+1-Problem) und die jeweilige Ausführungszeit erkennen.
Templates: Gibt Auskunft darüber, welche Templates gerendert wurden und in welcher Reihenfolge. Das hilft, Template-Strukturen und Includes besser zu verstehen und zu debuggen.
Zeit (Timer): Misst die Dauer einzelner Verarbeitungsschritte sowie die Gesamtzeit der Anfrage. Dadurch lassen sich Performance-Probleme gezielt identifizieren.
Headers: Zeigt die HTTP-Request- und Response-Header an. Das ist besonders nützlich, um Caching-Verhalten, Content-Typen oder Weiterleitungen zu analysieren.
Zusammen liefern diese Bereiche ein klares Bild darüber, was während einer Anfrage im Hintergrund passiert.