Zero-Code Instrumentation of Python using OpenTelemetry

Overview

Zero-code instrumentation in Python with OpenTelemetry uses an auto-instrumentation agent that dynamically instruments your application at runtime without requiring changes to the code. This allows capturing telemetry data such as traces, metrics, and logs from supported libraries and frameworks.

Install the OpenTelemetry Python Agent

To enable zero-code instrumentation, you need to install the OpenTelemetry distribution package and necessary exporters:

pip install opentelemetry-distro opentelemetry-exporter-otlp

• opentelemetry-distro: This package provides a convenient way to install OpenTelemetry, along with a set of default configurations and components that simplify the setup for instrumenting applications. It includes implementations for tracing, metrics, and logging.
• opentelemetry-exporter-otlp: This package is an exporter for OpenTelemetry that sends the collected telemetry data (logs, metrics, and traces) to a backend using the OpenTelemetry Protocol (OTLP). The OTLP exporter is a preferred way to transmit telemetry data due to its ability to handle multiple signal types (like metrics, traces, and logs) in a uniform manner.

Once installed, you can use the OpenTelemetry bootstrap command to automatically detect and install instrumentation for supported libraries:

opentelemetry-bootstrap -a install

Note: Ensure that your Python application includes the necessary dependencies before running the bootstrap command. For example, if your app uses Flask and requests, install them beforehand:

pip install flask requests

Define the Agent and Properties

Direct Command-Line Configuration

To instrument your Python application, start to design an opentelemetry-instrument command. The following parameters will define the agent and set a service name.

  --traces_exporter otlp \
  --metrics_exporter otlp \
  --logs_exporter otlp \
  --service_name my_python_service \

• traces_exporter: Specifies that the OpenTelemetry Protocol (OTLP) will be used as the traces exporter. This means that the trace data collected from your application will be sent to a backend using the OTLP.
• metrics_exporter: Specifies that the OTLP will be used as the metrics exporter. Similar to traces, this configuration ensures that metrics data is also sent to the backend via OTLP.
• logs_exporter: Specifies that the OTLP will be used as the logs exporter, meaning all log data will also be exported using the OTLP to the backend.
• service_name: Sets the name of the service being instrumented. This is useful for identifying your service in the telemetry data. Here, the service is named my_python_service.

Note: Don’t run the opentelemetry-instrument command yet - there is more configuration required in the following sections.

(Alternative) Use Environment Variables

Instead of modifying the command line, you can configure OpenTelemetry using environment variables:

export OTEL_TRACES_EXPORTER="otlp"
export OTEL_METRICS_EXPORTER="otlp"
export OTEL_LOGS_EXPORTER="otlp"
export OTEL_SERVICE_NAME="my_python_service"

Configure Exporters

To send telemetry data to Edge Delta, configure the OpenTelemetry exporters with the correct OTLP endpoint. The endpoint configuration depends on your environment. For example, in a Kubernetes Environment, you need a service open, for example ed-data-supply-svc, for the port that the exporters will send logs, metrics, and traces to. For non-kubernetes environments with exporters running in the same environment as the Edge Delta agent, such as on a Linux VM, the exporters will be able to communicate directly with the Edge Delta agent on localhost. In both instances, for HTTP (4318), include the path /v1/traces, /v1/metrics, or /v1/logs. For gRPC (4317), do not include the path. See Ingest Data from an OTLP Source.

The following examples are for a kubernetes deployment using gRPC.

Direct Command-Line Configuration

The following parameters will define the endpoint and protocol.

  --exporter_otlp_endpoint http://ed-data-supply-svc:4317 \
  --exporter_otlp_protocol grpc \

• exporter_otlp_endpoint: Specifies the endpoint to which the OTLP data (traces, metrics, and logs) will be sent. In this case, it’s pointing to a service at the specified address and port.
• exporter_otlp_protocol: Configures the protocol to be used by the OTLP exporter. Here, the gRPC protocol is specified, which is a modern, high-performance remote procedure call (RPC) framework.

(Alternative) Use Environment Variables

The following variables will define the endpoint and protocol.

export OTEL_EXPORTER_OTLP_ENDPOINT="http://ed-data-supply-svc:4317"
export OTEL_EXPORTER_OTLP_PROTOCOL="grpc"

Run and Verify Instrumentation

Run your Python application with OpenTelemetry enabled, ensuring telemetry data is sent directly to Edge Delta.

Command Line Approach:

Put all the command line parameters and run them with the opentelemetry-instrument command:

opentelemetry-instrument \
  --traces_exporter otlp \
  --metrics_exporter otlp \
  --logs_exporter otlp \
  --service_name my_python_service \
  --exporter_otlp_endpoint http://ed-data-supply-svc:4317 \
  --exporter_otlp_protocol grpc \
  python my_app.py

Environment Variables Approach:

After setting the environment variables, run the application normally:

python my_app.py

Check your application logs and OpenTelemetry debug logs for any errors related to telemetry export. Then, verify in Edge Delta that traces, logs, and metrics are being received and visualized correctly. Ensure all critical application operations are properly monitored by generating test traffic or sample requests.