Documentation Home
Connectors and APIs Manual
Download this Manual
PDF (US Ltr) - 4.1Mb
PDF (A4) - 4.1Mb

5.5.8 OpenTelemetry Tracing Support

For applications on Linux systems that use OpenTelemetry (OTel) instrumentation, the connector adds query and connection spans to the trace generated by application code and forwards the current OpenTelemetry context to the server. OpenTelemetry tracing was introduced in the Connector/ODBC 8.1.0 release.


OTel context forwarding works only with MySQL Enterprise Edition, a commercial product. To learn more about commercial products, see

Enabling and Disabling Tracing

By default, the connector forwards the context only when an instrumented application installs the required OpenTelemetry SDK libraries and configures the trace exporter to send trace data to some destination. If the application code does not use instrumentation, then the legacy connector does not use it either.

Connector/ODBC supports a connection property option, OPENTELEMETRY, which has these values:

  • PREFERRED: Default. Use instrumentation in the connection if the required OpenTelemetry instrumentation is available. Otherwise, permit the connection to operate without any OpenTelemetry instrumentation.

  • DISABLED: The connector does not create OpenTelemetry spans or forward the OpenTelemetry context to the server.

    Setting to boolean false behaves the same as DISABLED.

When you build code that links to Connector/ODBC and uses OTel instrumentation, the additional spans generated by the connector appear in the traces generated by your code. Spans generated by the connector are sent to the same destination (trace exporter) where other spans generated by the user code are sent as configured by user code. It is not possible to send spans generated by the connector to any other destination.

This implementation is distinct from the implementation provided through the MySQL client library (or the related telemetry_client client-side plugin).


OTel instrumentation in the ODBC driver only functions if the application is built with the -rdynamic compiler option so that symbols defined in user code are externally visible. Without this, the OTel context is not forwarded to the server (as the driver has no way of getting the current OTel context) and the spans generated by the ODBC driver will be not sent to the destination specified in the application (they will be discarded).