Python supported components and versions
- Instana AutoTrace webhook
- Python runtimes
- Supported environments
- Tracing
- Sensor data collection
- AutoProfile
- See also
Instana AutoTrace webhook
The Instana AutoTrace Webhook can automatically instrument your Python processes across an entire Kubernetes cluster.
Python runtimes
Tracing support for Tornado
, asyncio
, and aiohttp
is limited to the runtimes of Python up to 3.10.
Python | Versions | Python sensor version |
---|---|---|
CPython | >= 3.8 and < 3.13 | >= 2.5.0 |
CPython | >= 3.7 and < 3.10 | < 2.5.0 |
CPython | >= 2.7 and <= 3.6 | < 2.0.0 |
Long-term support
Instana follows the official long-term support (LTS) and end-of-life (EOL) timeline from Python.
When a Python version reaches its EOL date, it is offered an extra support period that ranges from one to two years. Update your Python version regularly to avoid problems.
Supported environments
The Instana Python package supports a wide range of environments such as:
Platform
- Linux (x86_64)
- AWS Fargate
- AWS Lambda
- Kubernetes
- Google Cloud
- Docker
Tracing
The Instana Python sensor supports distributed tracing across other Instana instrumented platforms, technologies, and languages. It offers automatic tracing of all requests and supports OpenTracing. For more information, see OpenTracing.
Frameworks | Support policy | Versions | Python sensor version |
---|---|---|---|
ASGI | 45 days | >= 2.0.0 and <= 3.0.0 | Any |
Celery | 45 days | >= 4.3.0 and <= 5.4.0 | Any |
Django | 45 days | >= 1.11.0 and <= 5.1.1 | Any |
FastAPI | 45 days | >= 0.51.0 and <= 0.114.2 | Any |
Flask | 45 days | >= 0.12.0 and <= 3.0.3 | Any |
Pyramid | 45 days | >= 1.6.5 and <= 2.0.2 | Any |
Sanic | On demand | >= 19.0.0 and < 21.9.0 | >= 2.0.0 |
Starlette | 45 days | >= 0.12.13 and <= 0.38.2 | Any |
Tornado | 45 days | >= 4.5.3 and < 6.0.0 | < 2.0.0 |
Webapp2 | On demand | >= 1.5.0 and < 3.0.0 | < 2.0.0 |
WSGI | 0 day | PEP 333 >= 1.0 and 1.0.1 | Any |
Clients | Support policy | Versions | Python sensor version |
---|---|---|---|
Aiohttp | 45 days | >= 3.1.0 and <= 3.10.5 | Any |
Asynqp | Deprecated | >= 0.5.1 and <= 0.6.0 | < 2.0.0 |
Boto3 | 45 days | >= 1.15.0 and <= 1.35.19 | Any |
Couchbase | On demand | >= 2.3.5 and <= 2.5.12 | Any |
Google-cloud-pubsub (*) | 45 days | <= 2.23.0 | Any |
Google-cloud-storage | 45 days | >= 1.24.0 and <= 2.14.0 | Any |
Grpcio | 45 days | >= 1.14.1 and <= 1.65.5 | Any |
Mysqlclient | 45 days | >= 1.3.14 and <= 2.2.4 | Any |
Pika | 45 days | >= 1.0.0 and <= 1.3.2 | Any |
PyMySQL | 45 days | >= 0.6.7 and <= 1.1.1 | Any |
Pymongo | 45 days | >= 3.7.0 and <= 4.8.0 | Any |
Psycopg2 | 45 days | >= 2.7.2 and <= 2.9.9 | Any |
Redis | 45 days | >= 2.10.6 and <= 5.0.8 | Any |
Requests | 45 days | >= 2.16.1 and <= 2.32.3 | Any |
SQLAlchemy | 45 days | >= 1.1.5 and <= 2.0.33 | Any |
Urllib3 | 45 days | >= 1.26.5 and <= 2.2.2 | Any |
(*): The Instana Python package supports only the pull message delivery of Google Pub/Sub.
Other libraries | Support policy | Versions |
---|---|---|
Gevent | On demand | >= 1.4 and <= 23.7.0 |
Tracing notes and limitations
Thread starting permission
The Instana Python tracer needs permission to create and start Python threading.Timer
objects. On most systems, this permission is granted by default. In some nested containerization scenarios, for example in some "Docker
in Docker" container versions, the permission is not granted by default.
If you see exceptions like RuntimeError: can't start new thread
, then insufficient permissions are the most likely cause. If you upgrade or change the "Docker in Docker" container, but the needed permissions are not
granted for the internal application container, then you can use the --privileged
permission as a last resort to start the application container.
Tracing across thread boundaries
The Instana Python package does not support tracing across thread boundaries. For example, when a request is first handled on a single thread, and then the workload is distributed to multiple other threads with the help of multiprocessing.ThreadPool
,
outgoing calls that happen in those other threads are not captured. Because every exit span needs to have an entry span, and the initiating entry span is out of the thread scope, such outgoing calls are not recorded. This is caused by
the inherent characteristic of the default OpenTracing ThreadLocalScopeManager
, and the lack of a ThreadPool
specific scope manager.
Tracing non-async functions in FastAPI
The Instana Python package supports only the tracing of coroutine-based concurrency in FastAPI. This is because the non-async functions that are executed on a thread pool cannot be followed through thread boundaries.
Tracing with multiple tracers
It is not supported to trace a single Python application with Instana and a third-party tracer, for example, with New Relic tracer or OpenTelemetry at the same time.
Supported web servers
- uWSGI
- mod_wsgi
- Nginx WSGI
- uvicorn
The gunicorn
web server is not supported officially by the Instana Python package.
Sensor data collection
Tracked configuration
- Name
- Runtime
- PID
- Loaded modules
Metrics
- GC activity
- Memory usage
- Threads
- Paging
- I/O
- Events
- Context switching
AutoProfile
Profiles | Python versions | Platforms |
---|---|---|
CPU usage | >= 2.7 and >= 3.4 | Linux and macOS |
Memory allocation rate | >= 3.4 | Linux and macOS |
Blocking calls | >= 2.7 and >= 3.4 | Linux and macOS |