Python-Monitoring und APM
Starten Sie Ihre Anwendung mit opentelemetry-instrument, und Obseria zeigt Traces, Fehler und Runtime-Metriken für Django-, Flask-, FastAPI- und Celery-Services, korreliert mit Logs und Infrastruktur.
Warum Python mit Obseria überwachen
Start ohne Code
opentelemetry-bootstrap erkennt installierte Bibliotheken und installiert passende Instrumentierungen; opentelemetry-instrument aktiviert sie beim Start.
Web-Apps und Worker in einem Trace
Requests, Celery-Tasks und ausgehende Aufrufe werden verknüpft; Hintergrundverarbeitung ist kein blinder Fleck mehr.
Fehler mit Kontext
Exceptions werden mit Stacktrace, Request-Attributen und dem verursachenden Release am Span erfasst.
Python-Frameworks und Bibliotheken, die Obseria überwacht
- Django. Views, Middleware und ORM-Queries werden mit Routen-Template und Statuscode getract.
- Flask und FastAPI. WSGI- und ASGI-Anwendungen erhalten Server-Spans je Endpoint, auch für async Handler.
- Celery. Spans für Veröffentlichung und Ausführung von Tasks verbinden Producer, Broker und Worker.
- requests, httpx, urllib3 und aiohttp. Ausgehende HTTP-Aufrufe propagieren den W3C-Trace-Kontext.
- psycopg, SQLAlchemy, PyMySQL und redis-py. Datenbank- und Cache-Operationen erscheinen als Client-Spans mit Dauer.
- boto3 und botocore. AWS-SDK-Aufrufe werden inklusive Service- und Operationsnamen getract.
Die Python-Kennzahlen, auf die es ankommt
Obseria erfasst diese Werte automatisch und zeigt sie in fertigen Dashboards und Alerts.Tempo und Nachfrage
Zeigt, wie schnell Ihre Python-Dienste antworten und wie viele Anfragen sie gleichzeitig bearbeiten.
Tempo externer Dienste
Zeigt, wie lange Ihre Anwendung auf andere Dienste und Partner wartet, und deckt langsame externe Abhängigkeiten auf.
Verbrauch an Ressourcen
Macht sichtbar, wie viel Rechenleistung und Speicher Ihre Anwendung benötigt, als Grundlage für passende Server und Kostenkontrolle.
Interne Arbeitslast
Zeigt, wie oft die Anwendung Speicher aufräumt und parallele Aufgaben wechselt, beides versteckte Ursachen für Verzögerungen.
Alle 8 Metriken im Detail anzeigen
| Metrik | Einheit | Aussage |
|---|---|---|
http.server.request.duration | s | Latenz eingehender Requests je Route und Statuscode. |
http.server.active_requests | {request} | Laufende Requests; Wachstum bei gleichem Durchsatz heißt: Requests hängen. |
http.client.request.duration | s | Latenz ausgehender HTTP-Aufrufe zu nachgelagerten Services. |
process.runtime.cpython.cpu.utilization | 1 | CPU-Nutzung des Python-Prozesses, wegen des GIL oft auf einen Kern begrenzt. |
process.runtime.cpython.memory | By | Residenter und virtueller Speicher des Interpreter-Prozesses. |
process.runtime.cpython.gc_count | {count} | Garbage Collections je Generation. |
process.runtime.cpython.thread_count | {thread} | Aktive Threads im Prozess. |
process.runtime.cpython.context_switches | {switch} | Freiwillige und unfreiwillige Kontextwechsel, ein Hinweis auf Contention. |
Python-Monitoring in wenigen Minuten einrichten
- Schritt 1
Distro installieren
Installieren Sie opentelemetry-distro und den OTLP-Exporter per pip und führen Sie opentelemetry-bootstrap für Ihre Bibliotheken aus.
- Schritt 2
Per Umgebung konfigurieren
Setzen Sie OTEL_SERVICE_NAME, den OTLP-Endpoint von Obseria und Ihr Token.
- Schritt 3
Startbefehl umschließen
Stellen Sie Ihrem gewohnten Befehl opentelemetry-instrument voran, etwa für Gunicorn oder Uvicorn.
pip install opentelemetry-distro opentelemetry-exporter-otlp
opentelemetry-bootstrap -a install
export OTEL_SERVICE_NAME="billing-api"
export OTEL_RESOURCE_ATTRIBUTES="deployment.environment.name=production"
export OTEL_TRACES_EXPORTER="otlp"
export OTEL_METRICS_EXPORTER="otlp"
export OTEL_LOGS_EXPORTER="otlp"
export OTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLED="true"
export OTEL_EXPORTER_OTLP_ENDPOINT="${OBSERIA_OTLP_ENDPOINT}"
export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer%20${OBSERIA_TOKEN}"
opentelemetry-instrument uvicorn app.main:app --host 0.0.0.0 --port 8000Sofort einsatzbereit
Dashboards, Alerts und SLOs, die bereitstehen, sobald die ersten Daten ankommen.
- Python-Service-Health mit RED-Metriken
- Celery-Tasks: Durchsatz, Fehler, Dauer
- Alert auf p95-Latenz je Endpoint
- Alert bei neuen Exception-Typen nach Deploy
- Langsamste Datenbank-Queries je Service
Python-Monitoring: Darauf kommt es an
Warum Python-Monitoring wichtig ist
Python betreibt Web-APIs mit Django, Flask und FastAPI, Datenpipelines, Machine-Learning-Services und unzählige Hintergrund-Worker auf Basis von Celery. Diese Workloads verhalten sich sehr unterschiedlich: Eine synchrone Django-Anwendung skaliert über Worker-Prozesse, ein FastAPI-Service hängt an einer asynchronen Event Loop, und ein Celery-Worker ist auf einen gesunden Broker angewiesen. Python-Monitoring muss alle drei abdecken und miteinander verbinden, denn eine langsame API-Antwort hat ihre Ursache oft in einer Queue oder einem Datenbankaufruf weiter unten.
OpenTelemetry bietet Zero-Code-Instrumentierung für Python. Der Befehl opentelemetry-bootstrap prüft die installierten Pakete und ergänzt passende Instrumentierungsbibliotheken, opentelemetry-instrument aktiviert sie beim Start des Interpreters. So wird Python APM möglich, ohne den Anwendungscode anzufassen.
Signale für das Python Performance Monitoring
- Latenz und Fehler:
http.server.request.durationje Route sowie an Spans erfasste Exceptions liefern die RED-Sicht je Service. - Parallelität:
http.server.active_requestszeigt laufende Requests. Steigt der Wert bei gleichbleibendem Durchsatz, sind Worker blockiert. - CPU und GIL:
process.runtime.cpython.cpu.utilizationnahe einem Kern pro Prozess bedeutet CPU-gebundenen Code, den zusätzliche Threads nicht beschleunigen. - Speicher und GC:
process.runtime.cpython.memoryundprocess.runtime.cpython.gc_countmachen Leaks und allokationsintensive Codepfade sichtbar. - Abhängigkeiten: Client-Spans für Datenbanken, Caches und HTTP-APIs zeigen, wohin die Request-Zeit tatsächlich fließt.
Typische Performance-Probleme in Python
Blockierende Aufrufe in async Code
Ein synchroner Datenbanktreiber oder time.sleep in einem async def-Handler blockiert die Event Loop eines FastAPI- oder aiohttp-Service. Alle Requests dieses Workers werden gleichzeitig langsamer. Traces zeigen lange Lücken ohne Child-Spans, Profile die blockierende Funktion.
Erschöpfte Worker
Gunicorn und uWSGI arbeiten mit einer festen Anzahl von Workern. Belegen langsame Upstream-Aufrufe diese Worker, warten neue Requests im Backlog. Steigende aktive Requests und Timeouts am Load Balancer sind die typischen Anzeichen.
N+1-Queries im ORM
Django ORM und SQLAlchemy machen es leicht, pro Zeile eine eigene Query abzusetzen. Trace-Wasserfälle mit Dutzenden identischer SQL-Spans machen das Problem offensichtlich; die Lösung ist meist select_related oder Eager Loading.
Speicherwachstum in langlebigen Workern
Celery-Worker und Datenjobs, die Referenzen auf große Objekte halten, wachsen, bis das Betriebssystem sie beendet. Speicher pro Prozess im Zeitverlauf zusammen mit der Task-Dauer zeigt, welcher Task verantwortlich ist.
Stille Task-Fehler
Hintergrund-Tasks, die scheitern und unbemerkt wiederholt werden, verbergen Probleme so lange, bis Daten fehlen. Getracte Task-Ausführungen mit Fehlerstatus machen Fehler und Retries neben dem auslösenden Request sichtbar.
Langsame Kaltstarts nach dem Deployment
Python importiert Module teils verzögert, und Frameworks füllen Caches erst bei der ersten Nutzung. Die ersten Requests je Worker nach einem Rollout können daher deutlich langsamer sein. Ein Vergleich der Latenz je service.version trennt Aufwärmeffekte von echten Regressionen.
Teure Serialisierung
Große Antworten mit verschachtelten Objekten verbringen viel Zeit in der JSON-Serialisierung oder in Pydantic-Validierung. Im Trace erscheint das als Zeit im Server-Span ohne passende Child-Spans; ein CPU-Profil zeigt die betroffenen Funktionen und macht gezielte Optimierung möglich.
Best Practices für Python APM
- Führen Sie
opentelemetry-bootstrapim Build aus, damit die Instrumentierungen zu Ihren Abhängigkeiten passen. - Initialisieren Sie OpenTelemetry bei Pre-Fork-Servern wie Gunicorn in jedem Worker, wie in der Dokumentation von OpenTelemetry Python beschrieben.
- Aktivieren Sie die Logging-Instrumentierung, um Log-Einträge um Trace-IDs zu ergänzen.
- Ergänzen Sie eigene Spans für teure Geschäftsschritte, etwa Modell-Inferenz oder Berichtserstellung.
- Nutzen Sie Tail-based Sampling, um alle fehlerhaften und langsamen Traces zu behalten.
So unterstützt Obseria das Python-Monitoring
Obseria verarbeitet OpenTelemetry-Traces, -Metriken und -Logs aus Python per OTLP. Ihre Instrumentierung bleibt offen, und Daten lassen sich jederzeit exportieren. Der Obseria Agent ergänzt Host- und Container-Kontext und läuft auf Kubernetes als DaemonSet. TopoGraph zeigt, wie APIs, Celery-Worker, Broker und Datenbanken voneinander abhängen. Continuous Profiling mit unter 1 % Overhead findet heiße Funktionen. Steigen die Fehler nach einem Release, korreliert Obseria Intelligence Deployment, ausfallende Abhängigkeit und betroffene Endpoints und erklärt die Ursache mit einer Beweiskette. Dashboards, Alerts und SLOs sind inklusive.
Verwandte Integrationen
Passende Funktionen
Distributed Tracing
Verfolgen Sie jeden Request über Services, Queues und Datenbanken hinweg und finden Sie den langsamen Span oder die fehlerhafte Abhängigkeit in Sekunden.
Mehr erfahrenFehler-Tracking
Die Errors Inbox gruppiert Exceptions aus Backend, Frontend und Mobile Apps zu Issues, zeigt deren Auswirkung und bündelt Zuweisung und Lösung in einem Workflow.
Mehr erfahrenContinuous Profiling
Dauerhaftes Continuous Profiling zeigt, welche Funktionen in Produktion CPU, Speicher und Locks beanspruchen, mit unter 1 % Overhead und Verknüpfung zu Traces.
Mehr erfahrenMehr erfahren
Was ist APM (Application Performance Monitoring)?
Was ist APM? Wie Application Performance Monitoring Latenz, Durchsatz und Fehler misst, wie Distributed Tracing funktioniert und welche Kennzahlen zählen.
Was ist OpenTelemetry?
Was ist OpenTelemetry? So erzeugen API, SDKs, Collector, OTLP und Semantic Conventions herstellerneutrale Traces, Metriken, Logs und Profile.
Häufige Fragen zum Python-Monitoring
Nein. opentelemetry-instrument aktiviert beim Start die Instrumentierung unterstützter Bibliotheken. Eigene Spans über die OpenTelemetry API sind optional.
Für Django, Flask, FastAPI, Starlette, Celery und viele Clients wie requests, httpx, psycopg, SQLAlchemy, redis-py und boto3 gibt es offizielle OpenTelemetry-Instrumentierungen.
Ja. Stellen Sie dem Startbefehl opentelemetry-instrument voran. Für Gunicorn mit vorgeforkten Workern folgen Sie dem Post-Fork-Muster aus der Dokumentation von OpenTelemetry Python.
Ja. Die Celery-Instrumentierung erzeugt Spans für Veröffentlichung und Ausführung von Tasks und propagiert den Kontext über den Broker. Der Task erscheint im Trace des auslösenden Requests.
Ja. Mit aktivierter Logging-Instrumentierung enthalten Log-Einträge Trace- und Span-IDs, und Obseria verknüpft jede Logzeile mit ihrem Trace.
Starten Sie heute mit dem Python-Monitoring
Binden Sie Python in Minuten per OpenTelemetry oder Obseria Agent an. 14 Tage kostenlos.