Send OpenTelemetry data from a Django app to Axiom
This guide explains how to send OpenTelemetry data from a Django app to Axiom using the Python OpenTelemetry SDK.
Prerequisites
- Create an Axiom account.
- Create a dataset in Axiom where you send your data.
- Create an API token in Axiom with permissions to update the dataset you have created.
Install required dependencies
Install the necessary Python dependencies by running the following command in your terminal:
Alternatively, you can add these dependencies to your requirements.txt
file:
Then, install them using the command:
Get started with a Django project
- Create a new Django project if you don’t have one already:
- Go to your project directory:
- Create a Django app:
Set up OpenTelemetry Tracing
Update manage.py
to initialize tracing
This code initializes OpenTelemetry instrumentation for Django when the project is run. Adding DjangoInstrumentor().instrument()
ensures that all incoming HTTP requests are automatically traced, which helps in monitoring the app’s performance and behavior without manually adding trace points in every view.
Create exporter.py
for tracer configuration
This file configures the OpenTelemetry tracing provider and exporter. By setting up a TracerProvider
and configuring the OTLPSpanExporter
, you define how and where the trace data is sent. The BatchSpanProcessor
is used to batch and send trace spans efficiently. The tracer created at the end is used throughout the app to create new spans.
Use the tracer in your views
In this step, modify the Django views to use the tracer defined in exporter.py
. By wrapping the view logic within tracer.start_as_current_span
, you create spans that capture the execution of these views. This provides detailed insights into the performance of individual request handlers, helping to identify slow operations or errors.
Update settings.py
for OpenTelemetry instrumentation
In your Django project’s settings.py
, add the OpenTelemetry Django instrumentation. This setup automatically creates spans for HTTP requests handled by Django:
Update the app’s urls.py to include the views
Include your views in the URL routing by updating urls.py
Updating urls.py
with these entries sets up the URL routing for the Django app. It connects the URL paths to the corresponding view functions. This ensures that when users visit the specified paths, the corresponding views are executed, and their spans are created and sent to Axiom for monitoring.
Run the project
Run the command to start the Django project:
In your browser, go to http://127.0.0.1:8000/rolldice
to interact with your Django app. Each time you load the page, the app displays a message and sends the collected traces to Axiom.
Send data from an existing Django project
Manual instrumentation
Manual instrumentation in Python with OpenTelemetry involves adding code to create and manage spans around the blocks of code you want to trace. This approach allows for precise control over the trace data.
- Install necessary OpenTelemetry packages to enable manual tracing capabilities in your Django app.
- Set up OpenTelemetry in your Django project to manually trace app activities.
- Configure OpenTelemetry to your Django settings to capture telemetry data upon app startup.
- Manually instrument views to create custom spans that trace specific operations within your Django app.
- Apply manual tracing to database operations by wrapping database cursor executions with OpenTelemetry spans.
Automatic instrumentation
Automatic instrumentation in Django with OpenTelemetry simplifies the process of adding telemetry data to your app. It uses pre-built libraries that automatically instrument the frameworks and libraries.
- Install required packages that support automatic instrumentation.
- Automatically configure OpenTelemetry to trace Django app operations without manual span management.
- Initialize OpenTelemetry in Django to capture telemetry data from all HTTP requests automatically.
- Update
manage.py
to include OpenTelemetry initialization, ensuring that tracing is active before the Django app fully starts.
- (Optional) Combine automatic and custom manual spans in Django views to enhance trace details for specific complex operations.
Reference
List of OpenTelemetry trace fields
Field Category | Field Name | Description |
---|---|---|
General Trace Information | ||
_rowId | Unique identifier for each row in the trace data. | |
_sysTime | System timestamp when the trace data was recorded. | |
_time | Timestamp when the actual event being traced occurred. | |
trace_id | Unique identifier for the entire trace. | |
span_id | Unique identifier for the span within the trace. | |
parent_span_id | Unique identifier for the parent span within the trace. | |
HTTP Attributes | ||
attributes.http.method | HTTP method used for the request. | |
attributes.http.status_code | HTTP status code returned in response. | |
attributes.http.route | Route accessed during the HTTP request. | |
attributes.http.scheme | Protocol scheme (HTTP/HTTPS). | |
attributes.http.url | Full URL accessed during the HTTP request. | |
User Agent | ||
attributes.http.user_agent | User agent string, providing client software and OS. | |
Custom Attributes | ||
attributes.custom[“http.host”] | Host information where the HTTP request was sent. | |
attributes.custom[“http.server_name”] | Server name for the HTTP request. | |
attributes.custom[“net.peer.ip”] | IP address of the peer in the network interaction. | |
Network Attributes | ||
attributes.net.host.port | Port number on the host receiving the request. | |
Operational Details | ||
duration | Time taken for the operation, typically in microseconds or milliseconds. | |
kind | Type of span (For example, server, internal). | |
name | Name of the span, often a high-level title for the operation. | |
Scope and Instrumentation | ||
scope | Instrumentation scope, (For example., opentelemetry.instrumentation.django.) | |
Service Attributes | ||
service.name | Name of the service generating the trace, typically set as the app or service name. | |
Telemetry SDK Attributes | ||
telemetry.sdk.language | Programming language of the SDK used for telemetry, typically ‘python’ for Django. | |
telemetry.sdk.name | Name of the telemetry SDK, for example., OpenTelemetry. | |
telemetry.sdk.version | Version of the telemetry SDK used in the tracing setup. |
List of imported libraries
The exporter.py
file and other relevant parts of the Django OpenTelemetry setup import the following libraries:
exporter.py
This module creates and manages trace data in your app. It creates spans and tracers which track the execution flow and performance of your app.
TracerProvider acts as a container for the configuration of your app’s tracing behavior. It allows you to define how spans are generated and processed, essentially serving as the central point for managing trace creation and propagation in your app.
BatchSpanProcessor is responsible for batching spans before they’re exported. This is an important aspect of efficient trace data management as it aggregates multiple spans into fewer network requests, reducing the overhead on your app’s performance and the tracing backend.
The Resource class is used to describe your app’s service attributes, such as its name, version, and environment. This contextual information is attached to the traces and helps in identifying and categorizing trace data, making it easier to filter and analyze in your monitoring setup.
The OTLPSpanExporter is responsible for sending your app’s trace data to a backend that supports the OTLP such as Axiom. It formats the trace data according to the OTLP standards and transmits it over HTTP, ensuring compatibility and standardization in how telemetry data is sent across different systems and services.
manage.py
The DjangoInstrumentor module is used to automatically instrument Django applications. It integrates OpenTelemetry with Django, enabling automatic creation of spans for incoming HTTP requests handled by Django, and simplifying the process of adding telemetry to your app.
views.py
This import brings in the tracer instance defined in exporter.py
, which is used to create spans for tracing the execution of Django views. By wrapping view logic within tracer.start_as_current_span
, it captures detailed insights into the performance of individual request handlers.
Was this page helpful?