OpenTelemetry Python

repository·main·Indexed 25 days ago

https://github.com/open-telemetry/opentelemetry-python

Implementation of the OpenTelemetry specification for Python applications to collect, process, and export traces, metrics, and logs. It consists of the opentelemetry-api for abstract definitions and the opentelemetry-sdk for the reference implementation, along with separate packages for exporters and propagators. The project also includes opentelemetry-configuration for declarative SDK setup via JSON or YAML and an internal opentelemetry-codegen-json library for generating Python code from OTLP JSON representations.

Tokens
55.3K
Snippets
116
Records
356
Agent score
79%

What's inside opentelemetry-python

  1. What is opentelemetry-exporter-otlp-common?

    main

    This package provides OpenTelemetry OTLP export utilities. It is designed to be used by OpenTelemetry signal exporters (such as those for traces, metrics, and logs) that transmit telemetry using the OTLP protocol.

    Note: All functionality in this package is currently marked as internal. It is intended for use by other OpenTelemetry exporter packages and is not intended for direct use by application developers.

  2. Understand the basic trace examples

    main

    The basic_tracer examples demonstrate two primary patterns for instrumenting Python applications:

    1. basic_trace: Demonstrates the full lifecycle of telemetry, including how to configure a SpanProcessor and an Exporter, how to initialize a tracer, and how to manually create and manage a span.
    2. resources: Demonstrates how to attach resource information (metadata about the entity producing the telemetry, such as service name or version) to a Provider.

    Detailed source files can be found in the docs/examples/basic_tracer/ directory.

  3. Customize metrics output using Views

    main

    OpenTelemetry Python allows you to customize how metrics are processed and output by the SDK using Views. Views can be used to modify the aggregation, naming, or attribute set of metrics before they are exported.

    Common scenarios for using Views include:

    • Changing Aggregation: Configure a different default aggregation for a specific instrument (e.g., change_aggregation.py).
    • Renaming Metrics: Change the name of a metric (e.g., change_name.py).
    • Limiting Attributes: Restrict the number of attributes output for a metric to prevent cardinality explosion (e.g., limit_num_of_attrs.py).
    • Dropping Measurements: Filter out specific measurements from an instrument (e.g., drop_metrics_from_instrument.py).
    • Custom Reservoirs: Use a custom ExemplarReservoir (e.g., change_reservoir_factory.py).
  4. Understand Declarative Configuration behavior and limitations

    main

    When using OTEL_CONFIG_FILE, keep the following behaviors in mind:

    • Authoritative Source: The config file is the sole source for SDK construction. Standard OTEL_* environment variables are ignored.
    • No Python-specific Env Vars: OTEL_PYTHON_* variables (like OTEL_PYTHON_TRACER_CONFIGURATOR) are not applied. You must capture this behavior in the config file or your code.
    • Omitted Sections: If a provider section (e.g., tracer_provider) is omitted from the file, it results in a no-op provider.
    • Global Disable: Setting disabled: true at the top level of the configuration file turns the entire SDK into a no-op.