Skip to content

Python

The agent traces your Python services with OpenTelemetry auto-instrumentation, loaded at startup with no code change. How it attaches depends on where the service runs, so each environment is covered below. For the shared opt-in flow, restart consent, and automatic rollback, see the Application APM overview.

The instrumentation ships inside the KloudMate agent package and upgrades with it. When you instrument a Python service, the agent stops eBPF monitoring from tracing that service’s own requests, so you get the richer application spans without duplicates, on one connected trace.

When you turn on SDK tracing for a systemd service, the agent writes a startup config that loads the instrumentation through PYTHONPATH, then restarts the service after you confirm. It sets a fixed service.name, the sampling rate, and where to send traces up front. Turning tracing off removes the config and restarts the service. Running the same action twice changes nothing.

For a Python app under PM2, the agent restarts it with tracing switched on (pm2 restart <app> --update-env). Each app keeps its PM2 process name as its service.name. The agent covers PM2 for every user on the host, not just root. If an app doesn’t come back up after the change, the agent undoes it and restarts the app.

The agent can instrument a Python process only when it runs under systemd or PM2. A process started on its own can’t be instrumented automatically. Run it under systemd or PM2 first; the Application Performance Monitoring card flags these and tells you so.

Choose SDK for the workload and the agent adds the OpenTelemetry Operator annotation instrumentation.opentelemetry.io/inject-python. The Operator injects the instrumentation, and that workload’s pods roll to pick it up.

If a workload isn’t detected automatically, add the annotation yourself, then restart the deployment:

kubectl patch deployment <name> -n <ns> -p '{"spec":{"template":{"metadata":{"annotations":{"instrumentation.opentelemetry.io/inject-python":"km-agent/km-agent-instrumentation-crd"}}}}}'

The Operator and its Cert Manager prerequisite are installed with the agent. See Kubernetes setup and the Kubernetes installation guide.

On Amazon ECS, the agent injects the Python instrumentation into the services you name, on both the EC2 and Fargate launch types. It rewrites the task definition and sends traces to the collector: the per-instance daemon on EC2, or a sidecar on Fargate. List your Python services in KM_ECS_SERVICES when you install. See the Amazon ECS install guide.

When the agent monitors Docker containers, whether in Docker mode or as a Linux service on a Docker host, each Python container offers Off, eBPF, and SDK in the Application Performance Monitoring card. eBPF needs no code change and no restart.

SDK adds the OpenTelemetry Python instrumentation by recreating the container with the same settings, which restarts it for a few seconds. If the new container doesn’t come up healthy, the agent starts the original again. It needs a glibc-based image, such as python:3.12-slim, and a Python version the bundle includes. Alpine (musl) images use eBPF. Containers managed by Docker Compose or Swarm aren’t recreated: their row shows the settings to add at the next deploy. See Instrument Java, Node.js, Python, and .NET containers.

The agent injects the instrumentation through the per-service registry environment at HKLM\SYSTEM\CurrentControlSet\Services\<service>\Environment. It sets PYTHONPATH, then restarts the service. For how Windows discovers services and traces IIS, see Windows platform notes.

  • SDK injection covers Python 3.10 through 3.13. Other versions, such as 3.14, are covered by eBPF monitoring instead.
  • The bundled instrumentation is glibc-only. On Alpine or other musl-based images it won’t load; use a glibc-based image.
  • Standalone Python needs systemd or PM2. Without one of them, there’s no automatic way to instrument the app.